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.
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
<Eric> I have removed this part of the notification message definition.
Eric
[...]
/martin
