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

[Andy Bierman <[e-mail]>]

On Fri, Jun 14, 2024 at 2:20 AM Benoit Claise <[e-mail]>
wrote:

> Dear all,
>
> On 6/14/2024 4:34 AM, Andy Bierman wrote:
>
>
>
> 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
>
> An interim for which content?
>

I don't think an interim is required vs. email discussion.


> We started with an adoption call on notif-yang-04 and it seems that
> discussion went in all directions. From the below message
>     - new fields in notification header
>     - binary encoding
>
> Maybe we should focus just on notif-yang issue, to start with?
>
>
What is the notif-yang issue, exactly?
YANG does not support abstract elements like XSD.
It is not possible to use YANG to define the NotificationContent element.



Regards, Benoit
>

Andy


> 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]
>>
>
> _______________________________________________
> netconf mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>
>