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

[Andy Bierman <[e-mail]>]

On Thu, Jan 24, 2019 at 3:56 PM Eric Voit (evoit) <[e-mail]> wrote:

> On Thu, Jan 24, 2019 at 9:04 AM Eric Voit (evoit) <[e-mail]> wrote:
>
> > "Eric Voit (evoit)" <[e-mail]> wrote:
> > > > From: Martin Bjorklund, January 24, 2019 9:40 AM
> > > >
> > > > "Eric Voit (evoit)" <[e-mail]> wrote:
> > > > > > From: Martin Bjorklund, January 24, 2019 8:17 AM
> > > > > >
> > > > > > "Eric Voit (evoit)" <[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.
>
>
>


I agree.

Using the correct error-tag values plus identity names for error-app-tag
values allows
both generic clients and clients specialized for this application to both
work.



> Eric
>
>
>
>
>
> Andy
>
>
>
>
>
>

Andy


>
>
>
>
>