Re: [netconf] [yang-doctors] Yangdoctors last call review of draft-ietf-netconf-subscribed-notifications-21

["Eric Voit (evoit)" <[e-mail]>]

On Thu, Jan 24, 2019 at 9:04 AM Eric Voit (evoit) <[e-mail]<mailto:[e-mail]>> wrote:
> "Eric Voit (evoit)" <[e-mail]<mailto:[e-mail]>> wrote:
> > > From: Martin Bjorklund, January 24, 2019 9:40 AM
> > >
> > > "Eric Voit (evoit)" <[e-mail]<mailto:[e-mail]>> wrote:
> > > > > From: Martin Bjorklund, January 24, 2019 8:17 AM
> > > > >
> > > > > "Eric Voit (evoit)" <[e-mail]<mailto:[e-mail]>> wrote:
> > > > > > Hi Andy,
> > > > > >
> > > > > >
> > > > > >
> > > > > > Thanks very much for the thorough YANG Doctor review.  I have
> > > > > > included the
> > > > > agreed upon comments, and uploaded to:
> > > > > >
> > > > > > draft-ietf-netconf-subscribed-notifications-22
> > > > > >
> > > > > > a summary of the clarifications made is at the end of the document.
> > > > > > Let me know if there anything else needed to conclude the YANG
> > > > > > doctor review of this document.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Also as the result of the ‘error-tag’ discussion with you and
> > > > > > Martin, we need to perform the refinement of the ‘error-tag’
> > > > > > mapping within both
> > > > > > draft-ietf-netconf-netconf-event-notifications
> > > Section
> > > > > > 7, and draft-ietf-netconf-restconf-notif Section 3.3.   Directly
> > > > > > below is some text and proposed error-tag mappings for those
> > > > > > documents.
> > > > > >
> > > > > >
> > > > > >
> > > > > >     o  An "error-tag" node with the value being a string that
> > > > > >
> > > > > >        corresponds to an identity associated with the error.
> > > > > > This
> > > > > >
> > > > > >        "error-tag" will correspond to the error identities
> > > > > > within
> > > > > >
> > > > > >        [I-D.draft-ietf-netconf-subscribed-notifications]
> > > > > > section
> > > > > >
> > > > > >        2.4.6 for general subscription errors:
> > > > > >
> > > > > >
> > > > > >
> > > > > >           error identity         uses error-tag
> > > > > >
> > > > > >           ---------------------- --------------
> > > > > >
> > > > > >           dscp-unavailable       invalid-value
> > > > >
> > > > > Ok.  But it is not clear to me when this error is actually
> > > > > supposed to be generated?  The leaf and identity have the same
> > > > > if-feature, so it isn't a special errro code for "unsupported leaf", which is
> good!
> > > > >
> > > > > Then I have to assume it is supposed to be some kind of runtime error?
> > > >
> > > > Yes.  A publisher, nor the network to which is connects does not
> > > > have
> > > > to:
> > > > (a) support all DSCP values, nor
> > > > (b) allow a particular value requested by a particular subscriber,
> > > > So this condition allows a publisher to reject a request for a
> > > > DSCP value where is knows the value will not be respected.
> > >
> > > Good explanation, I wish it was part of the "leaf dscp" in the
> > > module
> > > :)
> > >
> > > The dscp-unavailable identity doesn't add any addition value
> > > compared to the standard error.
> >
> > For NETCONF and RESTCONF, this is the case.
>
> And comi.  The point is, what makes the rpcs in this module so special
> that they have to invent a new error reporting scheme?   If we do that
> for these rpcs, why not for all other rpc in all other modules?

The current RPC error mechanisms ties YANG RPCs to NETCONF and RESTCONF transports.   Over many years there has been lots of work to align the subscription drafts to these existing mechanisms, while maintaining as much transport independence for hints as possible.


The subscription draft changes error reporting in significant ways, for the worse, not the better.
There are a set of error-tag values that are used for all protocol operations defined with rpc-stmt.
It was first defined in NETCONF but it has been applied to RESTCONF as well.

This draft uses identities to replace the set of common error-tags.  Instead, every single
rpc-stmt can have its own set of error codes. Even worse, a different set of error codes
depending on the protocol that was used.

Why should a 'resource-denied' error be something different in RESTCONF vs. NETCONF?
Or even in CoMI or some unknown protocol?  Why would 'invalid-value' be different,
depending on the operation?

It is 1 thing to change the documentation of YANG-based protocol operations.
It is another to omit mandatory information needed to work with NETCONF and RESTCONF.
If the error-tag values are properly documented and the NETCONF and RESTCONF mappings are identical
then there should not be any problems using standard error reporting.

<Eric> I believe that with this thread, that the error-tag values will be well documented and identical between NETCONF and RESTCONF transport drafts.

Eric


Andy