On Fri, Mar 23, 2018 at 4:04 AM, Martin Bjorklund <mbj@xxxxxxxxxx> wrote:
Hi,
One comment below.
"Eric Voit (evoit)" <evoit@xxxxxxxxx> 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
