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

On Thu, Dec 15, 2016 at 9:55 AM, Kent Watsen <kwatsen@juniper.net> wrote:

>
>
> "Mehmet Ersue" <mersue@gmail.com> 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?
>
>

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
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>