Subject: [Netconf] Inconsistency in Section 1.4 of draft-ietf-netconf-restconf-18

From: "Mehmet Ersue" <[email-masked]>
Date: Wed, 14 Dec 2016 21:02:29 +0100

Dear NETCONF WG,

RFC Editor found an inconsistency in Section 1.4 of
draft-ietf-netconf-restconf-18, where paragraph 6 says:

   "If the NETCONF server is expecting a
   "persist-id" parameter to complete the confirmed commit procedure
   then the RESTCONF edit operation MUST fail with a "409 Conflict"
   status-line.  There error-tag "in-use" is returned in this case.  The
   error-tag value "resource-denied" is used in this case."

Myself as the document shepherd and the authors agreed to use the error-tag
value "invalid value" to align with the operations <cancel-commit> and
<commit> in RFC 6241.
The correction will be done as below:

OLD:
   There error-tag "in-use" is returned in this case.  The
   error-tag value "resource-denied" is used in this case.

NEW:
      The error-tag value "invalid-value" is used in this case.

Please speak up within 2 days if you have a strong objection.

Regards,
Mehmet

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 15 Dec 2016 12:47:11 +0100 (CET)

> Please speak up within 2 days if you have a strong objection.

I don't think invalid-value is appropriate.  It signals that the
client provided an invalid value for some parameter, but that's not
true in this case - there is nothing the client can do in order to fix
the situation.  I prefer to use 'resource-denied' (which is actually
what Mehmet suggested).

/martin

---

From: Kent Watsen <[email-masked]>
Date: Thu, 15 Dec 2016 17:55:27 +0000

What do NETCONF servers return when no persist-id is passed even though one is needed?  RFC 6241 isn’t clear.   RFC 6241 seems to only speak to when the wrong persist-id is passed.  Either case, RESTCONF SHOULD return the same error-tag value that a NETCONF server returns for these cases, right?

Kent

---

From: Andy Bierman <[email-masked]>
Date: Thu, 15 Dec 2016 10:06:50 -0800

On Thu, Dec 15, 2016 at 9:55 AM, Kent Watsen <[email-masked]> wrote:

> What do NETCONF servers return when no persist-id is passed even though
> one is needed?  RFC 6241 isn’t clear.   RFC 6241 seems to only speak to
> when the wrong persist-id is passed.  Either case, RESTCONF SHOULD return
> the same error-tag value that a NETCONF server returns for these cases,
> right?
>
>

Our server returns 'in-use' and error-app-tag 'outstanding-confirmed-commit'
if client B tries a <commit> on client A's confirmed commit.

rpc-reply {
  rpc-error {
    error-info {
      error-number 373
    }
    error-type protocol
    error-tag in-use
    error-severity error
    error-app-tag outstanding-confirmed-commit
    error-message 'cannot perform the operation with confirmed-commit
pending'
  }
}

However, our RESTCONF server supports the confirmed-commit procedure using
query parameters (confirmed, persist, persist-id, confirm-timeout) and also
a POST on /restconf/operations/commit.  (IMO some NETCONF operations are
needed to make RESTCONF as robust as NETCONF)

> Kent

Andy

>
>
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 15 Dec 2016 21:45:42 +0100 (CET)

> > the same error-tag value that a NETCONF server returns for these cases,

Agreed, but as you note RFC 6241 is not clear on the topic.

> Our server returns 'in-use'

Our does that as well.

Actually, the description for in-use says:

   Description:    The request requires a resource that already is in
                   use.

which matches this case fairly well.

resource-denied means something else:

   Description:    Request could not be completed because of
                   insufficient resources.

So, in-use is probably better.

/martin