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

[[e-mail]]

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.

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.

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.

Best wishes
Thomas

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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/netconf

_______________________________________________
netconf mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>