Re: [Netconf] subscribed-notifications-12

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

Hi Tom,

> From: t.petch, April 20, 2018 6:09 AM
> 
> Eric
> 
> OK so far.
> 
> I am puzzled by the features for encoding.
> 
> I can see four cases for a publisher; no features, encode-xml and encode-json,
> encode-xml only, encode-json only.
> 
> The first case seems clear; the stream uses the encoding of the subscription.
> 
> The second also seems clear; the subscriber can choose either encoding.
>
> The third and the fourth puzzle me.  If only encode-xml is present, and the
> subscription is in xml, then the stream will be in xml, whether or not the
> encoding is specified.  If the subscription is in json, and the encoding is not
> specified, then the stream will be in json.  If the subscription is in json and the
> encoding is specified as xml, then the stream will be in xml.
> 
> If only encode-json is present, then it is vice versa, mutatis mutandis.
> 
> I find this an odd combination to specificy.

The ability to specify a particular encoding also is a function of  valid combinations of transport+encoding.  Independently of subscription, this general issue was recently articulated by Juergen:
https://www.ietf.org/mail-archive/web/netconf/current/msg14395.html 

To handle this in subscribed-notifications, a subscription is unable to select an encoding when alternative encodings are not supported on a selected transport.  The solution to this was proposed by Martin in:
https://www.ietf.org/mail-archive/web/netconf/current/msg14402.html
(search for "configurable-encoding")

So here are the specifics:

    leaf encoding {
      when 'derived-from(../transport, "sn:configurable-encoding")';
          ...
    }

This means that leaf encoding can only be set when the transport allows for configurable encodings.  So getting back to your third and fourth cases, the transport identity "netconf" does not have "configurable-encoding"*.  So these cases are explicitly not allowed for NETCONF.   Where there are transports where multiple encodings are possible (how often we will see this is TBD), we add a new error identity to the transport specific YANG model stating that this encoding is not available.

* To see the "netconf" identity, go to the YANG model in draft-ietf-netconf-netconf-event-notifications:
https://github.com/netconf-wg/notif-netconf/blob/master/draft-ietf-netconf-netconf-event-notifications-09.txt 
(the only reason this version isn't posted yet is that it is pending Einar's script tests on the appendix examples.)

Thanks,
Eric


> Tom Petch
> 
> ----- Original Message -----
> From: "Eric Voit (evoit)" <[e-mail]>
> To: "t.petch" <[e-mail]>
> Sent: Thursday, April 19, 2018 3:48 PM
> 
> 
> > Hi Tom,
> >
> > Thanks for the review.  You can see the updated draft at:
> >
> https://github.com/netconf-wg/rfc5277bis/blob/master/draft-ietf-netconf-
> subscribed-notifications-13.txt
> >
> > Some details inline...
> >
> > > -----Original Message-----
> > > From: t.petch, April 19, 2018 7:42 AM
> > > To: Eric Voit (evoit) <[e-mail]>; Kent Watsen
> <[e-mail]>;
> > > Alexander Clemm <[e-mail]>; [e-mail]
> > > Subject: subscribed-notifications-12
> > >
> > > Eric
> > >
> > > I see some quirks in this I-D that I think need fixing
> > >
> > > It lacks a note to the RFC Editor asking that XXXX be replaced with
> the number
> > > assigned to the I-D
> >
> > Placed this at the front of the section leading in to the YANG model
> >
> > > It lacks a note to the RFC Editor asking that the two dates in the
> YANG module
> > > be replaced with the date of publication
> >
> > Placed this at the front of the section leading in to the YANG model
> >
> > > I see no Copyright in the YANG module
> > >
> > > The YANG module references
> > >
> > > 6991
> > > 7223  (which is  superseded)
> > > 7951
> > > 7540
> > > none of which I see in the References of the I-D
> >
> > Fixed.
> >
> > > Good practice is to have a section just before the YANG module
> itself which
> > > lists the documents from whiuch imports are made or to which
> references are
> > > made (if you simply add RFC6991 as a Reference, you will get an
> unused
> > > Reference error).  See, for example, RFC8344
> >
> > Done.
> >
> > > There are a number of Informative References which I think should be
> > > Normative namely
> > > 8040
> >
> > Done.  Agree this should be Normative based on the use of yang-data.
> >
> > > 5246
> >
> > Done.
> >
> > > 6241
> >
> > Done
> >
> > > 6242
> >
> > Done
> >
> > > 7950
> >
> > I believe this one is an informative reference.  I.e., the reference
> in the YANG model is to an example of analogous behavior from HTTP2.  My
> reading of rfc7950 section 7.21.4 doesn't seem to require a reference to be
> normative.  If it does, I can move the information into the description.
> >
> > Thanks again,
> > Eric
> >
> >
> > > Tom Petch
> >
> >