Re: [Netconf] Yangdoctors last call review of draft-ietf-netconf-subscribed-notifications-10

[Andy Bierman <[e-mail]>]

On Fri, Mar 23, 2018 at 4:04 AM, Martin Bjorklund <[e-mail]> wrote:

> Hi,
>
> One comment below.
>
>
> "Eric Voit (evoit)" <[e-mail]> wrote:
> > Hi Andy,
> >
> >
> >
> > Thanks very much for the excellent comments.   Thoughts in-line...
> >
> >
> >
> > Also where changes were made, you can see them in the working copy at:
> >
> > https://github.com/netconf-wg/rfc5277bis/blob/master/draft-
> ietf-netconf-subscribed-notifications-11.txt
> >
> > (there are two agreed changes from the WG session to be embedded, but
> > the comments below are in there.)
> >
> >
> >
> >
> >
> > > From: Andy Bierman, March 15, 2018 6:01 PM
> >
> > >
> >
> > > Reviewer: Andy Bierman
> >
> > > Review result: Almost Ready
> >
> > >
> >
> > >
> >
> > > 1.2 Terminology
> >
> > >
> >
> > >    Notification message: A set of transport encapsulated information
> >
> > >    intended for a receiver indicating that one or more event(s) have
> >
> > >    occurred.  A notification message may bundle multiple event records.
> >
> > >    This includes the bundling of multiple, independent RFC 7950 YANG
> >
> > >    notifications.
> >
> > >
> >
> > >   >> Cannot find any text that supports this claim; find the contrary:
> >
> > >     from 2.6:
> >
> > >        This notification
> >
> > >        message MUST be encoded as one-way notification element
> >
> > >        of [RFC5277]
> >
> >
> >
> > The reason for this more inclusive term is to permit future
> > notification messages which allowing bundling.  This is as per adopted
> > NETCONF draft:
> >
> > draft-ietf-netconf-notification-messages
> >
> >
> >
> > I believe there are advantages in using the more inclusive term now,
> > rather than doing a future retrofit to this draft when
> > notification-messages completes.
>
> But later in this draft you state that there will be an update to this
> document when the notification messages draft is done.
>
> > I.e., I don't see it harming
> > anything in the specification with the expansive term.
>
> I think it will be confusing to readers to see the statement that this
> document support bundling, then it says that notifs MUST be encoded as
> 5277 notifications.
>
> I suggest you remove:
>
>   A notification message may bundle multiple event records.  This
>   includes the bundling of multiple, independent RFC 7950 YANG
>   notifications.
>
>
+1

There is no need for this spec to say anything about different notification
headers.
It is trivial to add a new parameter later to allow the client to request a
different message
format.


[...]
>
>
Andy


>
>
>
> /martin
>