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

[Andy Bierman <[e-mail]>]

On Mon, Jan 27, 2020 at 4:19 PM Mahesh Jethanandani <[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 4 of RFC-5277
<https://tools.ietf.org/html/rfc5277#section-4>.  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.



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)


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?  The mandatory info
like subscription-id
is redundant since the payload already has this info.

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.



Cheers.
>
> Mahesh and Kent (as co-chairs).
>
>

Andy


> On Jan 15, 2020, at 12:23 PM, Eric Voit (evoit) <[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
> draft-ietf-netconf-notification-messages
> <https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-messages/?include_text=1>.
> 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 draft-ietf-netconf-notification-messages
> <https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-messages/?include_text=1>
>  *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 draft-ietf-netconf-https-notif
> <https://tools.ietf.org/html/draft-ietf-netconf-https-notif-01> 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]
>
>
>
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>