Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06

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

Some updates for my comments for -07 based on the requests for -06.

> -----Original Message-----
> From: netconf <[e-mail]> On Behalf Of Eric Voit (evoit)
> Sent: Monday, January 25, 2021 9:36 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06
> 
> I have reviewed this document.  I believe it close to being ready.  I do
have three
> comments:
> 
> (1) Section 1.1
> There was an interaction in July 2020 about describes why subscription
state
> change notifications are not included within the draft.
> https://mailarchive.ietf.org/arch/msg/netconf/K0jnMW3GZknxihnNjKL4UlFTfoY
> /
> https://mailarchive.ietf.org/arch/msg/netconf/CYOosxZy_-
> tKKsrCCoLmQeFvEuI/
> Actually, we are talking only about a subset of the subscription state
change
> notifications, as <Subscription-Started> is include within examples of
this
> document.
> 
> Per Alex and my earlier requests, it would be good to include which state
change
> notifications are included, and why,  so that others have this context.
This
> would allow receivers to understand that the control plane messages which
> identify the current state of the subscription on the subscriber are not
available.
> Perhaps it might even drive others who might want this functionality to
add this
> upon the current http-notif.  This might be worth including in Section
1.1,
> Applicability Statement.

The majority of examples showing <subscription-started> have been removed.
The last place where they are discussed in -07 is the end of Section 2.   I
still feel that describing the coverage or non-coverage of the set of
subscription state change notifications within a stream of event provides a
useful context.

> (2) Section 2.1
> Learning Receiver Capabilities is critical, as Configured Subscriptions
can DOS a
> receiver if adequate protections are not on the publisher.  It would be
useful to
> list this here so that the topic is not missed in an implementation.
Alternatively
> this could be addressed in Section 5.

Thank you for including this as a new section.
 
> (3)
> In Sections 1.5 and 8.3 there is a reference to
I-D.ietf-netconf-notification-
> messages.  I am not sure how this impacts the eventual completion of this
draft,
> but defer to others who know the IETF process better.

Thanks for the changes here.

Eric
 
> Thanks,
> Eric
> 
> > -----Original Message-----
> > From: netconf <[e-mail]> On Behalf Of Rob Wilton
> > (rwilton)
> > Sent: Thursday, January 14, 2021 8:12 AM
> > To: [e-mail]; [e-mail]
> > Subject: [netconf] WGLC: draft-ietf-netconf-https-notif-06
> >
> > This message begins a two-week WGLC for
> > draft-ietf-netconf-https-notif-06 ending on Jan 28.  Here is a direct
link to the
> HTML version of the draft:
> >
> > 	https://tools.ietf.org/html/draft-ietf-netconf-https-notif-06
> >
> > Positive comments, e.g., "I've reviewed this document and believe it
> > is
> ready for
> > publication", are welcome!  This is useful and important, even from
> authors.
> > Objections, concerns, and suggestions are also welcomed at this time.
> >
> > Please note, the reason that I am making this request rather than the
> > WG
> chairs
> > is because both chairs are listed as authors on this document.
> >
> > Thank you,
> > Rob Wilton, OPS AD
> >
> > _______________________________________________
> > netconf mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netconf