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

[Andy Bierman <[e-mail]>]

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

> Dear Andy,
>
>
>
> AB> It does not say there is a YANG module.
>
>    It is defined to be within the "ietf-restconf" module
>
>    namespace for JSON-encoding purposes.
>
> AB> This is normative text. This provides the XML namespace and JSON
> module-name assignments instead of a real YANG module.
>
>
>
> TG> I interpret your answer that the specification describes the schema in
> plain text but misses the definition in a YANG resp. misses a machine
> readable definition. Would that be an appropriate assessment?
>
>
>


I guess.

YANG is incapable of modeling the notification container correctly.
It intentionally models only the 2nd element in the sequence

<xs:complexType name="NotificationType">
        <xs:sequence>
            <xs:element name="eventTime" type="xs:dateTime">
              <xs:annotation>
                <xs:documentation>
                The time the event was generated by the event source.
                </xs:documentation>
              </xs:annotation>
            </xs:element>

*            <xs:element ref="notificationContent"/>*        </xs:sequence>
    </xs:complexType>

The protocol specification is not required to provide a YANG model for
every message.
In this case, the message pre-dates YANG.



> Best wishes
>
> Thomas
>

Andy


>
> *From:* Andy Bierman <[e-mail]>
> *Sent:* Friday, June 14, 2024 4:00 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 6:47 AM <[e-mail]> wrote:
>
> 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.
>
>
>
>
>
> It does not say there is a YANG module.
>
>
>
>    It is defined to be within the "ietf-restconf" module
>
>    namespace for JSON-encoding purposes.
>
>
>
> This is normative text.
>
> This provides the XML namespace and JSON module-name assignments instead
> of a real YANG module.
>
>
>
>
>
>
>
> Best wishes
>
> Thomas
>
>
>
> Andy
>
>
>
>
>
> *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]> 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]>
> *Sent:* Friday, June 14, 2024 11:34 AM
> *To:* Benoit Claise <[e-mail]>
> *Cc:* [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]>
> 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]
>
>
>
>