Re: [netmod] yang-module-versioning: revision-label scheme

[Reshad Rahman (rrahman)]

The reason we're allowing for different versioning schemes is that no single 
versioning scheme has been unanimous.  The proposal is for IETF to use 
yang-semver. Some vendors and other publishers of YANG artifacts may use 
yang-semver, while some may define their own scheme.

While this in theory allows for an open ended number of versioning schemes, I 
don't believe this will be the case. No, I'm not taking over-under bets (

Regards,
Reshad.

On 2020-04-28, 12:02 PM, "Juergen Schoenwaelder" 
 wrote:

I may be naive and not understand things correctly but an open ended
set of versioning schemes scares me. I do not see how this leads to
interoperability.

Perhaps all the versioning work should be experimental until we know
what the winning solution is?

First semver was the solution, then we got semver plus extensions,
and now we move full speed ahead to support an open ended number of
versioning schemes?

/js (who probably should have kept silent)

On Mon, Apr 27, 2020 at 03:42:04PM +, Reshad Rahman (rrahman) wrote:
> Hi,
> 
> There was a 
discussion
 on the need to have an extension which specifies which versioning scheme a 
module is using.
> 
> The authors have identified 2 options:
> 
>   1.  One extension statement with a parameter which specifies the scheme 
being used. E.g. revision-label-schema(ietf-yang-semver), 
revision-label-schema(sdoX-yang). We’d need the parameter to be registered with 
IANA.
>   2.  One extension statement per revision-scheme. E.g. 
revision-label-scheme-ietf-yang-semver, revision-label-scheme-sdoX-yang.
> 
> The authors have  a preference for option 1, we believe it makes things 
simpler. We would like to hear from the WG if there’s any concerns, suggestions 
etc.
> 
> Regards,
> Reshad.

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


-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 


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

Re: [netmod] yang-module-versioning: revision-label scheme

[Juergen Schoenwaelder]

I may be naive and not understand things correctly but an open ended
set of versioning schemes scares me. I do not see how this leads to
interoperability.

Perhaps all the versioning work should be experimental until we know
what the winning solution is?

First semver was the solution, then we got semver plus extensions,
and now we move full speed ahead to support an open ended number of
versioning schemes?

/js (who probably should have kept silent)

On Mon, Apr 27, 2020 at 03:42:04PM +, Reshad Rahman (rrahman) wrote:
> Hi,
> 
> There was a 
> discussion
>  on the need to have an extension which specifies which versioning scheme a 
> module is using.
> 
> The authors have identified 2 options:
> 
>   1.  One extension statement with a parameter which specifies the scheme 
> being used. E.g. revision-label-schema(ietf-yang-semver), 
> revision-label-schema(sdoX-yang). We’d need the parameter to be registered 
> with IANA.
>   2.  One extension statement per revision-scheme. E.g. 
> revision-label-scheme-ietf-yang-semver, revision-label-scheme-sdoX-yang.
> 
> The authors have  a preference for option 1, we believe it makes things 
> simpler. We would like to hear from the WG if there’s any concerns, 
> suggestions etc.
> 
> Regards,
> Reshad.

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


-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] yang-module-versioning: revision-label scheme

[Reshad Rahman (rrahman)]

Hi,

On 2020-04-28, 11:25 AM, "netmod on behalf of Martin Björklund" 
 wrote:

Hi,

"Reshad Rahman \(rrahman\)"  wrote:
> Hi,
> 
> There was a
> 
discussion
> on the need to have an extension which specifies which versioning
> scheme a module is using.
> 
> The authors have identified 2 options:
> 
>   1.  One extension statement with a parameter which specifies the
>   scheme being used.

Ok, I understand what this means...

>   E.g. revision-label-schema(ietf-yang-semver),
>   revision-label-schema(sdoX-yang).

... but I don't understand these examples.   I expected something
like:

rev:revision-label-schema yang-semver;

rev:revision-label-schema semver-2.0;
You are correct. I was just using free-form, not the correct syntax.

>   We’d need the parameter to be
>   registered with IANA.

An alternative could be to use identities:

rev:revision-label-schema ysmever:yang-semver;

rev:revision-label-schema ex:semver-2.0;
Ack, identities also came up during our discussions also. I can't think of any 
reason not to use identities in this case.

>   2.  One extension statement per
>   revision-scheme. E.g. revision-label-scheme-ietf-yang-semver,
>   revision-label-scheme-sdoX-yang.

I prefer a single statement.
Good.

Regards,
Reshad.

> The authors have a preference for option 1, we believe it makes things
> simpler. We would like to hear from the WG if there’s any concerns,
> suggestions etc.


/martin
___
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] Erratum 5514 on NMDA [RFC 8342]

[Martin Björklund]

"Rob Wilton \(rwilton\)"  wrote:
> Hi,
> 
> There is one open erratum on NMDA from 2018 that I would like to
> process.
> 
> The erratum is here: https://www.rfc-editor.org/errata/eid5514
> 
> There has been quite a lot of discussion on this erratum previously on
> the NETMOD alias.  The last email in the thread was
> https://mailarchive.ietf.org/arch/msg/netmod/LHJZmf5gtESX6Nobwst0OwXbGG4/
> 
> >From my reading of the discussion, I don't think that there is clear
> >WG consensus between the two competing concerns:
> (1) The origin for any top-level configuration data nodes must be
> specified (section 7, YANG annotation definition).
> (2) The origin applies to all configuration nodes except non-presence
> containers (section 5.3.4).
> 
> Hence my proposal is to mark this as "Hold for Document Update" with
> Kent's proposed resolution of changing the description in the YANG
> model.
> 
> OLD:
> The origin for any top-level configuration data nodes must be
> specified.
> 
> NEW:
> The origin for any top-level configuration data nodes, except
> non-presence containers, must be specified.
> 
> For reference, this will mean that the extension [NEW] is defined as:
> 
>  md:annotation origin {
>type origin-ref;
>description
>  "The 'origin' annotation can be present on any configuration
>   data node in the operational state datastore.  It specifies
>   from where the node originated.  If not specified for a given
>   configuration data node, then the origin is the same as the
>   origin of its parent node in the data tree.  The origin for
>   any top-level configuration data nodes, except non-presence
>   containers,  must be specified.";
>  }
> 
> Please can you let me know if you support or object to this
> resolution.  I'll leave it a week to see if there is consensus before
> processing the erratum.

I think this is ok.


/martin



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

Re: [netmod] yang-module-versioning: revision-label scheme

[Martin Björklund]

Hi,

"Reshad Rahman \(rrahman\)"  wrote:
> Hi,
> 
> There was a
> discussion
> on the need to have an extension which specifies which versioning
> scheme a module is using.
> 
> The authors have identified 2 options:
> 
>   1.  One extension statement with a parameter which specifies the
>   scheme being used.

Ok, I understand what this means...

>   E.g. revision-label-schema(ietf-yang-semver),
>   revision-label-schema(sdoX-yang).

... but I don't understand these examples.   I expected something
like:

rev:revision-label-schema yang-semver;

rev:revision-label-schema semver-2.0;

>   We’d need the parameter to be
>   registered with IANA.

An alternative could be to use identities:

rev:revision-label-schema ysmever:yang-semver;

rev:revision-label-schema ex:semver-2.0;


>   2.  One extension statement per
>   revision-scheme. E.g. revision-label-scheme-ietf-yang-semver,
>   revision-label-scheme-sdoX-yang.

I prefer a single statement.


> The authors have a preference for option 1, we believe it makes things
> simpler. We would like to hear from the WG if there’s any concerns,
> suggestions etc.


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

[netmod] Erratum 5514 on NMDA [RFC 8342]

[Rob Wilton (rwilton)]

Hi,

There is one open erratum on NMDA from 2018 that I would like to process.

The erratum is here: https://www.rfc-editor.org/errata/eid5514

There has been quite a lot of discussion on this erratum previously on the 
NETMOD alias.  The last email in the thread was 
https://mailarchive.ietf.org/arch/msg/netmod/LHJZmf5gtESX6Nobwst0OwXbGG4/

>From my reading of the discussion, I don't think that there is clear WG 
>consensus between the two competing concerns:
(1) The origin for any top-level configuration data nodes must be specified 
(section 7, YANG annotation definition).
(2) The origin applies to all configuration nodes except non-presence 
containers (section 5.3.4).

Hence my proposal is to mark this as "Hold for Document Update" with Kent's 
proposed resolution of changing the description in the YANG model.

OLD:
The origin for any top-level configuration data nodes must be specified.

NEW:
The origin for any top-level configuration data nodes, except
non-presence containers, must be specified.

For reference, this will mean that the extension [NEW] is defined as:

 md:annotation origin {
   type origin-ref;
   description
 "The 'origin' annotation can be present on any configuration
  data node in the operational state datastore.  It specifies
  from where the node originated.  If not specified for a given
  configuration data node, then the origin is the same as the
  origin of its parent node in the data tree.  The origin for
  any top-level configuration data nodes, except non-presence
  containers,  must be specified.";
 }

Please can you let me know if you support or object to this resolution.  I'll 
leave it a week to see if there is consensus before processing the erratum.

Regards,
Rob


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

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

[Radek Krejci]

+1

Thanks Kent and Rob for moving this forward, we should release
libyang/yanglint with this change within 2 weeks.

Regards,
Radek


Dne 27. 04. 20 v 19:30 Mahesh Jethanandani napsal(a):
> +1.
>
>> On Apr 24, 2020, at 12:39 PM, Sterne, Jason (Nokia - CA/Ottawa)
>> mailto:jason.ste...@nokia.com>> wrote:
>>
>> That seems like a reasonable approach to me.
>> Jason
>>  
>> *From:* netmod > > *On Behalf Of *Rob Wilton (rwilton)
>> *Sent:* Friday, April 24, 2020 3:34 PM
>> *To:* Kent Watsen > >; netmod@ietf.org 
>> *Subject:* Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
>>  
>> Hi Kent,
>>  
>> Thanks for creating the issue.
>>  
>> I think that errata falls under section 7
>> ofhttps://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/,
>> and could be classified as “Hold for Document Update”.  I.e. “Changes
>> that modify the working of a protocol to something that might be
>> different from the intended consensus when the document was approved
>> should be either Hold for Document Update or Rejected. Deciding
>> between these two depends on judgment. Changes that are clearly
>> modifications to the intended consensus, or involve large textual
>> changes, should be Rejected. In unclear situations, small changes can
>> be Hold for Document Update.”
>>  
>> I think that the consensus of the long term fix (e.g. in YANG 1.2) is
>> that “require-instance” should be allowed under typedefs that refined
>> types that allow it.
>>  
>> Pragmatically, I think that we can mark this errata is a “Hold for
>> Document Update”, with the accompanying errata notes (derived from
>> Radek’s comments) changed to:
>>  
>> “The document does not specify whether the “require-instance” keyword
>> is allowed in typedef refinements derived from the “leafref” or
>> “instance-identifier” base types, but it is anticipated that a future
>> revision of YANG would allow this.   It is suggested that modules
>> using YANG language versions 1 [RFC 6020] and 1.1 [RFC 7950] avoid
>> using this construct, YANG module validation tools flag a warning if
>> this construct is used, but implementations allow this if possible.”
>>  
>> Does anyone object to this course of action (or wishes to refine my
>> errata notes)?
>>  
>> Regards,
>> Rob
>>  
>>  
>> *From:* Kent Watsen mailto:kent+i...@watsen.net>> 
>> *Sent:* 23 April 2020 17:59
>> *To:* Andy Bierman mailto:a...@yumaworks.com>>
>> *Cc:* Radek Krejci mailto:rkre...@cesnet.cz>>;
>> Juergen Schoenwaelder > >; Martin Björklund
>> mailto:mbj+i...@4668.se>>; netmod@ietf.org
>> ; Rob Wilton (rwilton) > >
>> *Subject:* Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
>>  
>> The consensus seems to be that:
>>   - the errata should be rejected
>>         - Rob, do you agree?
>>   - YANG-next should fix it later
>>         - I created https://github.com/netmod-wg/yang-next/issues/104
>>   - implementations should try to do the right thing now
>>         - Radek’s suggestion below LGTM!
>>  
>>  
>> Tallies:
>>    - for reject: Andy, Martin, Juergen, and Kent 
>>    - for accept: Radek, and Balazs
>>    - unclear: Lada, Rob, and Jason
>>  
>>  
>> Kent // as co-chair
>>  
>>
>>  
>>
>> On Apr 14, 2020, at 10:35 AM, Andy Bierman > > wrote:
>>  
>> 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
>> > > 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;
>>