[netmod] YANG Versioning weekly meeting (not a VI!)

[Kent Watsen]

For those interested in participating in discussions on the YANG Versioning set 
of drafts, the following weekly 1-hour meeting has been created by request of 
the authors for that purpose.

ICS file attached (includes a 15-minute alarm)

PS: this is NOT a virtual interim!

Kent // as co-chair




YANG Versioning
Scheduled: Apr 14, 2020 at 9:00 AM to 10:00 AM
Location: https://ietf.webex.com/ietf
Invitees: NETMOD Working Group


JOIN WEBEX MEETING
https://ietf.webex.com/ietf/j.php?MTID=m2c561452450cf19d54e91c84b70c14cc
Meeting number (access code): 617 633 719
Meeting password: Pm2SJHakZ23


JOIN BY PHONE
1-650-479-3208 Call-in toll number (US/Canada) 
Tap here to call (mobile phones only, hosts not supported): 
tel:%2B1-650-479-3208,,*01*617633719%23%23*01*

1-877-668-4493 Call-in toll free number (US/Canada) 
Tap here to call (mobile phones only, hosts not supported): 
tel:1-877-668-4493,,*01*617633719%23%23*01*

Global call-in numbers:
https://ietf.webex.com/ietf/globalcallin.php?MTID=m760b4453ad872ad0c59799278e28ae64

Toll-free dialing restrictions: 
https://www.webex.com/pdf/tollfree_restrictions.pdf


JOIN FROM A VIDEO SYSTEM OR APPLICATION
Dial sip:617633...@ietf.webex.com
You can also dial 173.243.2.68 and enter your meeting number.


Join using Microsoft Lync or Microsoft Skype for Business
Dial sip:617633719.i...@lync.webex.com



Can't join the meeting? Contact support here:
https://ietf.webex.com/ietf/mc


IMPORTANT NOTICE: Please note that this Webex service allows audio and other 
information sent during the session to be recorded, which may be discoverable 
in a legal matter. You should inform all meeting attendees prior to recording 
if you intend to record the meeting.




BEGIN:VCALENDAR
CALSCALE:GREGORIAN
VERSION:2.0
X-WR-CALNAME:YANG Versioning
METHOD:PUBLISH
PRODID:-//Apple Inc.//Mac OS X 10.14.6//EN
BEGIN:VTIMEZONE
TZID:America/Scoresbysund
BEGIN:DAYLIGHT
TZOFFSETFROM:-0100
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
DTSTART:19820328T00
TZNAME:GMT
TZOFFSETTO:+
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
DTSTART:19961027T01
TZNAME:GMT-1
TZOFFSETTO:-0100
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
ATTENDEE;CN="NETMOD Working Group";CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPAN
 T;RSVP=TRUE:MAILTO:netmod-cha...@ietf.org
DTEND;TZID=America/Scoresbysund:20200414T14
TRANSP:OPAQUE
ORGANIZER;CN="Cisco Webex";SCHEDULE-AGENT=CLIENT:MAILTO:messenger@webex.
 com
UID:7be01da1-3f37-458e-ba86-6f8014452267
DTSTAMP:20200421T13Z
LOCATION:https://ietf.webex.com/ietf
X-APPLE-TRAVEL-ADVISORY-BEHAVIOR:AUTOMATIC
DESCRIPTION:\n\nJOIN WEBEX MEETING\nhttps://ietf.webex.com/ietf/j.php?MT
 ID=m2c561452450cf19d54e91c84b70c14cc\nMeeting number (access code): 617 
 633 719\n\nHost key: 504671\n\nMeeting password: Pm2SJHakZ23\n\n\n\nJOIN
  BY PHONE\n1-650-479-3208 Call-in toll number (US/Canada) \nTap here to 
 call (mobile phones only\, hosts not supported): tel:%2B1-650-479-3208\,
 \,*01*617633719%23%23*01*\n\n1-877-668-4493 Call-in toll free number (US
 /Canada) \nTap here to call (mobile phones only\, hosts not supported): 
 tel:1-877-668-4493\,\,*01*617633719%23%23*01*\n\nGlobal call-in numbers:
 \nhttps://ietf.webex.com/ietf/globalcallin.php?MTID=m760b4453ad872ad0c59
 799278e28ae64\n\nToll-free dialing restrictions: \nhttps://www.webex.com
 /pdf/tollfree_restrictions.pdf\n\n\nJOIN FROM A VIDEO SYSTEM OR APPLICAT
 ION\nDial sip:617633...@ietf.webex.com\nYou can also dial 173.243.2.68 a
 nd enter your meeting number.\n\n\nJoin using Microsoft Lync or Microsof
 t Skype for Business\nDial sip:617633719.i...@lync.webex.com\n\n\n\nCan'
 t join the meeting? Contact support here:\nhttps://ietf.webex.com/ietf/m
 c\n\n\nIMPORTANT NOTICE: Please note that this Webex service allows audi
 o and other information sent during the session to be recorded\, which m
 ay be discoverable in a legal matter. You should inform all meeting atte
 ndees prior to recording if you intend to record the meeting.\n
PRIORITY:5
SEQUENCE:1586881774
CLASS:PUBLIC
X-ALT-DESC;FMTTYPE=text/html:* {padding: 0\; 
margin: 0\;}table {	border-collapse: separate\; width =100%\;	border:
  0\;	border-spacing: 0\;}tr {	line-height: 18px\;}a, td {	font-size: 14p
 x\;	font-family: Arial\;	color: #333\;	word-wrap: break-word\;	word-brea
 k: normal\;	padding: 0\;}.title {	font-size: 28px\;}.image {	width: auto
 \;	max-width: auto\;}.footer {	width: 604px\;}.main {}@media screen and 
 (max-device-width: 800px) {	.title {		font-size: 22px !important\;	}	.im
 age {		width: auto !important\;		max-width: 100% !important\;	}	.footer 
 {		width: 100% !important\;		max-width: 604px !important	}	.main {		widt
 h: 100% !important\;		max-width: 604px !important	}}	\;When it's ti
 me, join the Webex meeting here.	\;	
 		Meeting number
  (access code): 617 633 719		Hos
 t key: 504671			Meeting password:Pm2SJHakZ23	\;		

Re: [netmod] Presentation on YANG and Netconf usage in 3GPP

[Balázs Lengyel]

Hello Qin,

RFC6095 never gained traction, I don’t know any toolset that supports it.

Just now I don’t expect anything from IETF. Some 3GPP constructs like
invariant, system-created, initial-value were proposed to the YANG language
development earlier, but not accepted.

 

I am trying to map the object oriented models of 3GPP into the mainstream
YANG.

Regards Balazs

 

From: Qin Wu  
Sent: 2020. április 2., csütörtök 15:12
To: Balázs Lengyel ; netmod@ietf.org
Subject: Presentation on YANG and Netconf usage in 3GPP

 

Hi, Balazs:

Thanks for the update for what 3GPP is doing related to YANG and NETCONF. I
have a few comments to your slides which I haven’t got time to raise in the
virtual interim meeting:

1.  Mapping UML to YANG may is not lossless mapping, you may loss a lot
of information, for lossless mapping, Why you don’t use complex type defined
in RFC6095?

2.  What do you expect IETF to do for the gap identified in 3GPP?

 

-Qin



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

[Andy Bierman]

Hi,

I agree with Juergen that this errata should be rejected and the issue
resolved in yang-next.
No IETF module should use this construct. It is easy to convert to an
equivalent form that is not under dispute.


Andy


On Tue, Apr 14, 2020 at 6:40 AM Radek Krejci  wrote:

> Hi,
>
> Dne 09. 04. 20 v 17:26 Kent Watsen napsal(a):
>
>
>
> On Apr 6, 2020, at 3:42 AM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
>
> The definition I found in RFC 8639 is this:
>
>leaf stream {
>  type stream-ref {
>require-instance false;
>  }
>  mandatory true;
>  description
>"Indicates the event stream to be considered for
> this subscription.";
>}
>
> This could be changed to:
>
>leaf stream {
>  type leafref {
> path "/sn:streams/sn:stream/sn:name";
>require-instance false;
>  }
>  mandatory true;
>  description
>"Indicates the event stream to be considered for
> this subscription.";
>}
>
>
> I can confirm that `yanglint` validates the module cleanly after this
> change.
>
>
>
> On Apr 6, 2020, at 7:38 AM, Martin Björklund  wrote:
>
> I think the correct fix is to change the text so that
> "require-instance" is not classified as a restriction and keep the
> default.
>
>
> Agreed.
>
>
> Also, I think that it would be easiest (for backwards
> compatibility w/ existing models) to allow "require-inetance" to be
> changed in derived types.
>
> However, this cannot imo be done in an errata.
>
>
> While I appreciate Radek and Michal’s perspective, I also think that is
> would be best for the community for `yanglint` to support this, as they are
> published modules doing it.
>
>
> I don't feel as an expert for IETF processes, so I don't know if this
> issue can be solved in errata or not (and I'm not sure there is a consensus
> on this in mailing list). For the implementation, I would appreciate at
> least a consensus on a solution. So far I saw opinions to allow it, to
> disallow and also to make it implementation-specific (which means in fact
> to disallow from the authors perspective, since there can be a tool
> disallowing it and we are saying that such a tool is ok). So, there is no
> clear way for implementors, which means problems for interoperability -
> there will be always someone unhappy and so far I don't know what is the
> major opinion to go.
>
> So far, I tend to allow it (accept by libyang), but print warning to warn
> authors about possible problems (some tool can refuse such a module). Is it
> ok?
>
> Radek
>
>
> As an aside, I feel that all modules should be tested against all
> available validation tools during the publication process, but to find
> issues in the modules and well as possibly improve the tools.
>
> Sadly, I only have `yanglint` and `yangson` available to me.  I just
> checked for the “yang validator” project, but both www.yangvalidator.com
>  and https://www.yangcatalog.org/yangvalidator seem to be down.
>
>
> Kent // contributor
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

[Radek Krejci]

Hi,

Dne 09. 04. 20 v 17:26 Kent Watsen napsal(a):
>
>
>> On Apr 6, 2020, at 3:42 AM, Juergen Schoenwaelder
>> > > wrote:
>>
>> The definition I found in RFC 8639 is this:
>>
>>    leaf stream {
>>  type stream-ref {
>>    require-instance false;
>>  }
>>  mandatory true;
>>  description
>>    "Indicates the event stream to be considered for
>> this subscription.";
>>    }
>>
>> This could be changed to:
>>
>>    leaf stream {
>>  type leafref {
>> path "/sn:streams/sn:stream/sn:name";
>>    require-instance false;
>>  }
>>  mandatory true;
>>  description
>>    "Indicates the event stream to be considered for
>> this subscription.";
>>    }
>>
>
> I can confirm that `yanglint` validates the module cleanly after this
> change.
>
>
>
>> On Apr 6, 2020, at 7:38 AM, Martin Björklund > > wrote:
>>
>> I think the correct fix is to change the text so that
>> "require-instance" is not classified as a restriction and keep the
>> default.  
>
> Agreed.
>
>
>> Also, I think that it would be easiest (for backwards
>> compatibility w/ existing models) to allow "require-inetance" to be
>> changed in derived types.
>>
>> However, this cannot imo be done in an errata.
>
> While I appreciate Radek and Michal’s perspective, I also think that
> is would be best for the community for `yanglint` to support this, as
> they are published modules doing it.
>

I don't feel as an expert for IETF processes, so I don't know if this
issue can be solved in errata or not (and I'm not sure there is a
consensus on this in mailing list). For the implementation, I would
appreciate at least a consensus on a solution. So far I saw opinions to
allow it, to disallow and also to make it implementation-specific (which
means in fact to disallow from the authors perspective, since there can
be a tool disallowing it and we are saying that such a tool is ok). So,
there is no clear way for implementors, which means problems for
interoperability - there will be always someone unhappy and so far I
don't know what is the major opinion to go.

So far, I tend to allow it (accept by libyang), but print warning to
warn authors about possible problems (some tool can refuse such a
module). Is it ok?

Radek


> As an aside, I feel that all modules should be tested against all
> available validation tools during the publication process, but to find
> issues in the modules and well as possibly improve the tools.
>
> Sadly, I only have `yanglint` and `yangson` available to me.  I just
> checked for the “yang validator” project, but
> both www.yangvalidator.com
>  and https://www.yangcatalog.org/yangvalidator 
> seem
> to be down.
>
>
> Kent // contributor
>



smime.p7s
Description: Elektronicky podpis S/MIME
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] I-D Action: draft-ietf-netmod-yang-instance-file-format-12.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

Title   : YANG Instance Data File Format
Authors : Balazs Lengyel
  Benoit Claise
Filename: draft-ietf-netmod-yang-instance-file-format-12.txt
Pages   : 28
Date: 2020-04-14

Abstract:
   There is a need to document data defined in YANG models when a live
   server is unavailable.  Data is often needed at design or
   implementation time or needed when a live running server is
   unavailable.  This document specifies a standard file format for YANG
   instance data, which follows the syntax and semantics of existing
   YANG models, and annotates it with metadata.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-12
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-instance-file-format-12


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Shepherd review on draft-ietf-netmod-yang-instance-file-format-10

[Balázs Lengyel]

See below as BALAZS2. Removed previously agreed issues. Uploaded as -12.

Balazs

 

P.S. Kent, if further edits are needed, shall I do them via new uploaded 
versions, or shall I just send the update for checking to you?

 

From: Kent Watsen  
Sent: 2020. április 9., csütörtök 22:11
To: Balázs Lengyel 
Cc: netmod@ietf.org
Subject: Re: [netmod] Shepherd review on 
draft-ietf-netmod-yang-instance-file-format-10

 

Hi Balazs,

 

On Apr 8, 2020, at 8:06 AM, Balázs Lengyel mailto:balazs.leng...@ericsson.com> > wrote:

 

Hello Kent,
Thanks for the review. See answers below.
I tried to address all you comments, sorry if I missed something. 
I updated the draft and uploaded a -11 version. Please check/advance it.

One question I could not settle: XML2RFC does not accept
   
Only
   
Why ? Please help.

 

Because it’s a working group document now and so uses the “ietf” prefix.  Try 
this:

 

   

BALAZS2: OK, thanks


Structural Issues:

- S5 contains an mix of important and unimportant information.   I think that 
the most important thing to state that the module defines an offline format 
that MAY contain security sensitive information, and thus safe handling is 
advised.  Maybe also say something about because the YANG module only defines a 
“structure”,  the Security Considerations doesn’t follow the template specified 
in https://tools.ietf.org/html/rfc8407#section-3.7.1).  For instance: s/is 
designed as a wrapper specifying a format and a metadata header for YANG 
instance data defined by the content-schema/specifies an offline format/
BALAZS: Most of text was required to be put there by earlier reviewers (Mostly 
Juergen and Acee Lindem) and sent to the mailing list.
I added that we do not follow the security template for YANG models.

 

Please add the reference to https://tools.ietf.org/html/rfc8407#section-3.7.1 
per above.

BALAZS2: OK

 

 - S8.1: agreed that RFC8525 is Normative, but the only place it it referenced 
is in a non-normative section…please add a ref to it from a normative section.
BALAZS: It is referenced from the YANG module which is normative.

 

You just added that reference, but not correctly:

  1) the “reference” doesn’t follow the standard format

  2) the paragraph at the top of 3.2 doesn’t also list RFC 8525

BALAZS2: OK, corrected


Editorial Issues:

 - Appendix B:
- s/For instance data/Instance data/

BALAZS: Sorry, that would make the sentence incorrect.

 

Do you mean it to be “For instance, data” then?   If “instance data” is 
supposed to be read together, maybe use a hyphen or quotes?

BALAZS2: OK, added quotes

- the syntax grammar used in S3, P8 doesn’t make sense - use ABNF?

BALAZS: 

 

Please fix the grammar.

 

BALAZS2: OK, Updated grammar.





- In S3, P8: “the semicolons and the decimal point, if present, shall be 
replaced by underscores” - why are they not escaped?

BALAZS: This is a file name. Escaping in file names does not always work 
(depending on the filesystem and tools used). This is more simple and 
understandable

 

No, this is a special case CLR and we never do this.  I see this idea has been 
in the document since -03, so it must’ve bee discussed, can you point me to the 
discussion? 

 

FWIW, my OS doesn’t even require escaping colons.  BTW, they’re “colons” (not 
semicolons).

BALAZS2: Windows doesn’t allow colons in the filename. Although it’s not 
everyone’s favorite OS, it is pretty widespread. 

For Ubuntu Linux and a bash shell the colon is allowed, but tab extension does 
not work properly.

Sorry, I don’t remember any discussion on this. Timestamps were discussed, but 
I don’t find any arguments about this substitution.

Changed semicolon->colon





- It is unclear how the "inline-content-schema” feature could ever be used.  
I.e., there are no protocol-accessible nodes in the module…

BALAZS: The system can declare in supported/not-supported in design 
documentation. E.g. in UC2, Preloading Default Configuration the designer 
preparing instance data, can decide to use or not use the inline-content-schema 
based on this.

 

When I make statements like this, please see it as an opportunity to improve 
the document.  In this case, please modify the inline-content-schema’s 
“description” statement to indicate that the feature is never supported by a 
server, and that it is intended to be enabled via out-of-band documentation.  
BTW, was this discussed by the WG?

BALAZS2: It was discussed that this inline-content-schema seems complicated, so 
it should not be mandatory. After this I introduced the feature. AFAIK no 
discussion after this.

Actually it might be supported by a server: 

*   preloading configuration data: the server may or may not be able the 
inline-content-schema. The designers preparing the instance data sets to be 
loaded onto the server may use this declaration as a design guide
*   if a server also produces instance data files (e.g. UC5  Storing 
diagnostics data), and I am