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

[Kent Watsen <[e-mail]>]

"Mehmet Ersue" <[e-mail]> wrote:
> 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.

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).



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