[netconf] Re: Adoption call for notif-yang-04

[Andy Bierman <[e-mail]>]

On Fri, Jun 14, 2024 at 3:57 AM <[e-mail]> wrote:

> Dear Andy,
>
>
>
>    - I think YANG Push can be simplified and improved. (But not in this
>    WG)
>
>
>
> I agree with your assessment that YANG-Push defined in RFC 8639 and RFC
> 8641 can be simplified. I already had several interactions with
> implementors working on running code in the last few weeks. They are
> raising potential improvements. However I disagree with your assessment
> that this can't be managed at the netconf working group.
>

oops. You are right. NETCONF WG did these RFCs not NETMOD WG.



>
>
> I agree with Benoits assessment. We need to structure this discussion.
>
>
>
> First, making YANG-Push from a schema and for configured subscription from
> a transport perspective work. These are the documents already being adopted
> or soon will be discussed for adoption at netconf.
>
>
>


Not sure what these tasks mean, but interested in reading the drafts.

There seems to be some desire to consume YANG modules as needed, based on
PUSH updates received.
Normally, a YANG-aware application consumes the entire YANG library from
the server, using the correct
revisions, features, and deviations.  (The augments get added without any
special handling).

In our implementation, the southbound layer (YANG Push collector) is fully
YANG-aware.
The northbound layer (subscriber) needs no YANG knowledge at all.
The application subscribes to YANG data, not YANG Push updates.
No YANG Push complexity is passed on to the application at all.



> Second, and here Kent already raised the question, what are the potential
> points to be addressed. I am looking forward to start this discussion
> during IETF 120 in the hallways. I like to hear more from other vendors and
> operators implementing and using YANG-Push.
>

See you there.


>
>
> Best wishes
>
> Thomas
>


Andy


>
>
> *From:* Andy Bierman <[e-mail]>
> *Sent:* Thursday, June 13, 2024 10:34 PM
> *To:* Kent Watsen <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* [netconf] Re: Adoption call for notif-yang-04
>
>
>
> *Be aware:* This is an external email.
>
>
>
>
>
>
>
> On Thu, Jun 13, 2024 at 9:32 AM Kent Watsen <[e-mail]> wrote:
>
> Dear WG,
>
> This adoption call was unsuccessful.
>
> There is obviously a lot of interest, but the solution doesn’t seem
> adequate, given the comments made on the list.  Not to disparage the
> effort, but the problem is rather intractable!
>
> Andy mentioned that an Interim may be needed, which seems right (+1 if you
> agree), but I wonder if there isn’t more that can be done in preparation
> first.  Specifically, as this effort challenges fundamentals, it would help
> to clarify the motivation and expected outcomes.
>
>
>
> +1 to a better functional specification
>
>
>
> IMO there are no implementation problems caused by the RFC 5277 XSD for
> the notification element.
>
> YANG is incapable of validating this element, but it is a trivial
> structure, easy to validate.
>
>
>
> It is not clear to me that any new fields are needed in the notification
> header.
>
> The NETCONF WG discussed multiple timestamps pre-5277 and decided against
> it.
>
> Same for 'sequence-id'. IMO these are OK for YANG Push augments.
>
>
>
> I supported this draft as a way to get 2 SID assignments.
>
>
>
> IMO the NETCONF WG needs to make Binary YANG Push a top priority.
>
> This needs to be protocol-independent as possible (not UDP-specific).
>
> I think YANG Push can be simplified and improved. (But not in this WG)
>
>
>
>
>
> One high-level question I have, is there anything wrong with the
> “notification” statement in RFC 7950?  That is, is this at all a YANG-next
> issue for the NETMOD WG, or is to purely NETCONF WG issue?
>
> Kent
>
>
>
> Andy
>
>
>
>
> > On Apr 6, 2024, at 6:14 PM, Kent Watsen <[e-mail]> wrote:
> >
> > NETCONF WG,
> >
> > This message starts a two week poll on adopting the following document:
> >
> >       YANG model for NETCONF Event Notifications
> >
> https://datatracker.ietf.org/doc/html/draft-ahuang-netconf-notif-yang-04
> >
> > The poll ends April 20.
> >
> > Please send email to the list indicating "yes/support” or "no/do not
> support".  If indicating no, please state your reservations with the
> document.  If yes, please also feel free to provide comments you'd like to
> see addressed once the document is a WG document.
> >
> > No IPR is known for this document:
> https://mailarchive.ietf.org/arch/msg/netconf/oQVZ6Pf_novNfMB4RsnDxQibHpM/
> >
> > PS: this document received strong support before, being very focused,
> providing just a module enabling validation of YANG “notification” messages.
> >
> > Kent and Per (as co-chairs)
> >
> >
> >
> >
> >
> > _______________________________________________
> > netconf mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netconf
>
> _______________________________________________
> netconf mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>