Re: [netconf] WGLC on draft-ietf-netconf-notification-messages? (Was Re: Configured receiver capability exchange)

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

Hi Andy,



From: Andy Bierman, January 28, 2020 1:13 PM



On Mon, Jan 27, 2020 at 4:19 PM Mahesh Jethanandani <[e-mail] 
<mailto:[e-mail]> > wrote:

Hi Eric,



This e-mail triggers two responses. Let us deal with 
draft-ietf-netconf-notification-messages here, and I will bring up 
comments/questions related to draft-ietf-netconf-https-notif in the other 
thread.



You have indicated a desire that receiver capabilities should be documented by 
the transport specific draft, e.g. draft-ietf-netconf-https-notif, and not 
this draft. As such you believe that the draft is ready.



To the WG, the authors have indicated a desire to wrap up this draft, and 
would like us, the chairs, to issue a WGLC on it. Before we do that, we wanted 
to ask if the WG believes that the document is ready, and that there are no 
more issues that need to discussed/addressed by 
draft-ietf-netconf-notification-messages document at this time.







I would like to see clear and consistent text wrt to RFC 5277.

There is this confusing text:



      YANG one-way exchanges currently use a non-extensible header and

   encoding defined in section <https://tools.ietf.org/html/rfc5277#section-4> 
4 of RFC-5277.  These RFCs MUST be
   updated to enable this draft.  These RFCs SHOULD be updated to
   provide examples


This seems inconsistent with this text:


  Backwards Compatibility



   With this specification, there is no change to YANG's 'notification'
   statement

   Legacy clients are unaffected, and existing users of [RFC5277 
<https://tools.ietf.org/html/rfc5277> ],
   [RFC7950 <https://tools.ietf.org/html/rfc7950> ], and [RFC8040 
<https://tools.ietf.org/html/rfc8040> ] are free to use current behaviors 
until all
   involved device support this specification.



<eric> I don't see these as inconsistent.  The YANG notification statement is 
defined in RFC-7950 Section 7.16.   And legacy clients do not need to change.


It is rather odd to see RFC 2119 language used for a directive to a WG
to take on some sort of work item. (RFCs MUST be updated)

<eric>  I agree that RFC 2119 language is not proper here.  Perhaps the 
specific changes should be framed as notes to RFC editor.



I think this draft needs some sort of Applicability Statement. Why are servers 
supposed

to use this header and stop using the RFC 5277 header?

<eric> Makes sense, I will put together some text on this.



The mandatory info like subscription-id is redundant since the payload already 
has this info.

<eric> The subscription-id is only in the notifications defined in RFC-8641. 
I.e. "push-update" and " push-change-update".  This is the biggest gap which 
needs to be remedied.



This new header can make it much more difficult for a client to write code to 
process a notification,

since the header itself would be modeled with YANG and subject to change.  The 
processing

may also be slower because the added complexity.  It does not seem that every 
server needs

this added complexity.

<eric> This is one reason that this specification isn't ready to obsolete 
RFC-5277 notifications.



Eric







Cheers.



Mahesh and Kent (as co-chairs).







Andy



On Jan 15, 2020, at 12:23 PM, Eric Voit (evoit) <[e-mail] 
<mailto:[e-mail]> > wrote:



Hi Mahesh,



During the IETF 106 session, there was discussion on how both a publisher 
might know if there is receiver support for 
<https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-messages/?include_text=1> 
draft-ietf-netconf-notification-messages.  Section 6 highlights several of the 
considerations.   Relevant are the following:



(a) Remote device capability discovery from the point of view of the Publisher 
needs to be enhanced to know if the far end can interpret notification 
messages type beyond RFC-5277, Section 4.



(b) This capability discovery question is relevant for both configured 
subscription receivers and dynamic subscribers.



(c) The capability discovery question can be generalized beyond subscriptions, 
as there are many reasons to know the available capabilities of the far end.



(d) Capability discovery advertisement has traditionally been discussed within 
transport documents (e.g. RFC-6241 Section 8.1).





Based on (a)-(d), coming up with a transport independent point-solution within 
<https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-messages/?include_text=1> 
draft-ietf-netconf-notification-messages *just* to discover this single 
element of client functionality seems overkill/heavyweight.



I was fine with letting this remote capabilities discovery question sit for a 
while.   However 
<https://tools.ietf.org/html/draft-ietf-netconf-https-notif-01> 
draft-ietf-netconf-https-notif shows that we now must address this question. 
Specifically should the diagram section 1.4.1 show this capability exchange?



It turns out that independent of draft-ietf-netconf-notification-messages, 
there several questions in draft-ietf-netconf-https-notif which need to be 
answered prior to the section 1.4.1 arrow: "Send HTTPS POST message with YANG 
defined notification #1" anyway.  These questions are:

  (1) Does the targeted HTTPS receiver support configured subscriptions?

  (2) Can the targeted HTTP@ receiver accept a new subscription as described 
in a <subscription-started>?

Only if these questions are "yes", should the <subscription-started> be 
responded to with an "OK".



Add to this a third question driven from (a)-(d):

  (3) Does the receiver support the message type within 
"draft-ietf-netconf-notification-messages"?



A strawman way to handle the all three questions within 
draft-ietf-netconf-https-notif would be to respond to a <subscription-started> 
notification with an HTTP Status 202 (Accepted)" acknowledgement.  This 202 
would include body elements listing supported receiver resources.  Maybe 
something YANG encoded via ietf-yang-structure-ext containing:



      <foo xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

        <capabilities>

          <capability>

            urn:ietf:params:xml:ns:yang:ietf-notification-messages:1.0

          </capability>

        </capabilities>

      </foo>



What do you think of this approach?



Eric



Mahesh Jethanandani

[e-mail] <mailto:[e-mail]>







_______________________________________________
netconf mailing list
[e-mail] <mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/netconf