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

[[e-mail]]

Dear Andy,

AB> I think the module name "ietf-restconf" is used for JSON.
AB> Not a problem.

I believe you are refering to RFC 8040 section 6.4 correct?

https://datatracker.ietf.org/doc/html/rfc8040#section-6.4

I highlight the paragraph in question

   The structure of the event data is based on the <notification>
   element definition in Section 4 of [RFC5277]<https://datatracker.ietf.org/doc/html/rfc5277#section-4>.  It MUST conform to the
   schema for the <notification> element in Section 4 of [RFC5277]<https://datatracker.ietf.org/doc/html/rfc5277#section-4>,
   using the XML namespace as defined in the XSD as follows:

   Two child nodes within the "notification" container are expected,
   representing the event time and the event payload.  The "eventTime"
   node is defined within the same XML namespace as the <notification>
   element.  It is defined to be within the "ietf-restconf" module
   namespace for JSON-encoding purposes.

Here an example from that paragraph with highlighted notification statement.

   In the following example, the YANG module "example-mod" is used:

     module example-mod {
       namespace http://example.com/event/1.0;
       prefix ex;

       organization "Example, Inc.";
       contact "support at example.com";
       description "Example Notification Data Model Module.";
       revision "2016-07-07" {
         description "Initial version.";
         reference "example.com document 2-9976.";
       }

       notification event {
         description "Example notification event.";
         leaf event-class {
           type string;
           description "Event class identifier.";
         }
         container reporting-entity {
           description "Event specific information.";
           leaf card {
             type string;
             description "Line card identifier.";
           }
         }
         leaf severity {
           type string;
           description "Event severity description.";
         }
       }
     }

No YANG module specified in RFC 8040. Same problem as in RFC 8639 with YANG-Push. Therefore my statement still holds true that from a schema perspective, JSON and CBOR encoding is not implementable.

Best wishes
Thomas

From: Andy Bierman <[e-mail]>
Sent: Friday, June 14, 2024 3:18 PM
To: Graf Thomas, INI-NET-VNC-HCS <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [netconf] Re: Adoption call for notif-yang-04


Be aware: This is an external email.




On Fri, Jun 14, 2024 at 3:45 AM <[e-mail]<mailto:[e-mail]>> wrote:
Dear Andy,

AB> What is the notif-yang issue, exactly?

TG> Med posted the following concern and objection: https://mailarchive.ietf.org/arch/msg/netconf/Abw9mRHZos_yK9-x1HWHCVyv_xM/
TG> Kent raised the question wherever YANG notifications can be encoded in JSON. I described my reasoning why today it cannot be encoded in JSON and CBOR here: https://mailarchive.ietf.org/arch/msg/netconf/e_PsL-RK0f7jXKpeQSPdiHxgRno/


I think the module name "ietf-restconf" is used for JSON.
Not a problem.

AB> YANG does not support abstract elements like XSD.
AB> It is not possible to use YANG to define the NotificationContent element.

TG> I requested a problem description here on the mailing list: https://mailarchive.ietf.org/arch/msg/netconf/B3CML33wZJ0h6pSnB3S88HSh8O4/. Your reply https://mailarchive.ietf.org/arch/msg/netconf/g7KomEpdr2bthjuGTaAMZfyFvcg/ did not answer my question. I would appreciate a more detailed problem description with concrete references to existing documents and paragraphs describing reasoning.


I incorrectly commented on the Message Broker work.
That is outside the scope of this notif structure draft.
The notif structure is not useful for validation of the notification element.

Best wishes
Thomas

Andy


From: Andy Bierman <[e-mail]<mailto:[e-mail]>>
Sent: Friday, June 14, 2024 11:34 AM
To: Benoit Claise <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [netconf] Re: Adoption call for notif-yang-04


Be aware: This is an external email.




On Fri, Jun 14, 2024 at 2:20 AM Benoit Claise <[e-mail]<mailto:[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]<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
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]<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]>


_______________________________________________

netconf mailing list -- [e-mail]<mailto:[e-mail]>

To unsubscribe send an email to [e-mail]<mailto:[e-mail]>