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

[Andy Bierman <[e-mail]>]

Hi Eric,

All these changes sound good to me.

How about changing the cited text:

OLD:
These RFCs MUST be updated to enable this draft.
These RFCs SHOULD be updated to provide examples

NEW:
These RFCs need to be updated to enable this draft and provide examples.


Andy



On Fri, Jan 31, 2020 at 10:04 AM Eric Voit (evoit) <[e-mail]> wrote:

> Hi Andy,
>
>
>
> *From:* Andy Bierman, January 28, 2020 1:13 PM
>
> 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.
>
>
>
> <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]> 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
>
>