Subject: [netconf] JSON encoding of events in draft-ietf-netconf-https-notif

From: Kent Watsen <[email-masked]>
Date: Tue, 7 Apr 2020 12:08:13 +0000

Moving to “netconf” (“netmod” in BCC)

K. 

Sent from my iPhone
>> On Apr 7, 2020, at 4:35 AM, Balázs Lengyel <balazs.lengyel=[email-masked]> wrote:
> 
> Hello Mahesh, Kent,
> I was wondering how the JSON encoding of event would look like in your draft. (I intend to propose something similar to 3GPP so I am most interested.)
> The part below push-update or push-change-update is well defined in YANG however the part outside is not. In Restconf (https://trac.tools.ietf.org/html/rfc8040#section-6.4) I see the following example:
>  
> {
> "ietf-restconf:notification" : {
>   "eventTime" : "2013-12-21T00:01:00Z",
>   "example-mod:event" : {
>     "event-class" : "fault",
>     "reporting-entity" : { "card" : "Ethernet0" },
>     "severity" : "major"
>   } } }
>  
> However how would the first 2 lines look here? IMHO keeping restconf as a module name seems wrong.
> So maybe we should define it here in this draft :
> {
>  "json-yang-notification:notification" : {
>   "eventTime" : "2013-12-21T00:01:00Z",
>   "push-change-update" : {
>     ...
>   } } }
>  
> How to define this wrapper (the first 2 lines, I am unsure. As far as I know it is not possible to describe this in YANG.  Maybe just some text like:
> The YANG encoding of the notification SHALL be wrapped in a JSON object as illustrated below
>  
> "json-yang-notification:notification" : {
>   "eventTime" : "2013-12-21T00:01:00Z",
>  
>  
> Also I would definitely need an example of a notification sent.
> Regards Balazs
>  
> --
> Balazs Lengyel                    Senior Specialist                       Ericsson Hungary Ltd.
> Mobile: +36-70-330-7909              email: [email-masked]

---

From: Kent Watsen <[email-masked]>
Date: Tue, 7 Apr 2020 20:31:19 +0000

Hi Balazs,

>> The part below push-update or push-change-update is well defined in YANG however the part outside is not. In Restconf (https://trac.tools..ietf.org/html/rfc8040#section-6.4 <https://trac.tools.ietf.org/html/rfc8040#section-6.4>) I see the following example:
>>  
>> {

Agreed, because https-notif is on HTTP (not RESTCONF).

Note that RFC 8040 defined the "ietf-restconf” prefix only because RFC 5277 defines notifications using XSD (not YANG), so there was no better YANG module name to use...

>> Also I would definitely need an example of a notification sent.

Given that there still isn’t a base YANG module for notifications, I propose we copy/paste the entirety of https://tools.ietf.org/html/rfc8040#section-6.4 <https://tools.ietf.org/html/rfc8040#section-6.4> with the following substitution:

OLD:
   For JSON-encoding purposes, the module name for the "notification"
   element is "ietf-restconf".

NEW:
   For JSON-encoding purposes, the module name for the "notification"
   element is “ietf-https-notif".

Kent // contributor

---

From: Balázs Lengyel <[email-masked]>
Date: Wed, 8 Apr 2020 07:29:25 +0000

From: Kent Watsen <[email-masked]> 
Sent: 2020. április 7., kedd 22:31
To: Balázs Lengyel <[email-masked]>
Cc: Oskar Malm <[email-masked]>; [email-masked]
Subject: Re: [netconf] JSON encoding of events in draft-ietf-netconf-https-notif

Hi Balazs,

The part below push-update or push-change-update is well defined in YANG however the part outside is not. In Restconf ( <https://trac.tools.ietf.org/html/rfc8040#section-6.4> https://trac.tools..ietf.org/html/rfc8040#section-6.4) I see the following example:

{

  "example-mod:event" : {

    "event-class" : "fault",

    "severity" : "major"

  } } }

{

  "push-change-update" : {

    ...

  } } }

 

Given that there still isn’t a base YANG module for notifications, I propose we copy/paste the entirety of https://tools.ietf.org/html/rfc8040#section-6.4 with the following substitution:

OLD:

NEW:

Kent // contributor

BALAZS2: Do we want to make this transport specific by using “ietf-https-notif" as a prefix or better make it transport independent like "json-yang-notification:notification" ?

I would prefer transport independent, but can live with your proposal too.