Re: [netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11

[Vladimir Vassilev]

On 18/02/2022 18.11, Andy Bierman wrote:



On Fri, Feb 18, 2022 at 8:39 AM Martin Björklund > wrote:


Hi,

I didn't find any discussion about the new percent types in the list
archives.  Do we really need three types for percent?  We can now
express 4294967295 percent, but not 10.5 percent.



IMO it is a mistake to have too many ways to do the same thing.
We already have the "units" statement to add details like "percent" 
and "centiseconds".

(And there are RFCs already that define types this way.)

uint8 and int32 and uint32 for percent? Plus the units approach?


+1

How about adding decimal64 as an option? Then 10.5 is solved.

/Vladimir

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

[netmod] The "resolve-system" parameter in the new "with-system" I-D

[Kent Watsen]

[As a contributor]

This message regards the value of the "resolve-system” parameter defined in the 
latest “with-system” draft.

The "resolve-system” parameter is defined in its own optional-to-implement 
module.  The question is if the WG believes the parameter is valuable or if the 
module should be removed from the draft before adoption call?

The "resolve-system” parameter is a convenience function, enabling clients to 
NOT have “manually” copy/paste referenced system-defined nodes into .  
Instead, by including this parameter in , , or 
equivalents, the client requests the server to itself copy/paste the missing 
system nodes into . 

It is true that this work began with a goal of never having to copy/paste 
system-defined nodes into .   The concern wasn’t about *how* the 
referenced system-defined nodes came to be in , but *if* they needed 
to be in  at all.   But now that the current draft says referenced 
system-nodes MUST be in , the only remaining question regards *how* 
they came to be in .  

Yes, there is convenience in using the “resolve-system” parameter, but there is 
also some implementation complexity.   Ultimately, the question is, is the 
convenience worth the complexity?   Thoughts?

Thanks,
Kent

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

[netmod] The new "with-system" I-D

[Kent Watsen]

[As a contributor]

This message merely provides some insight behind the latest update to the 
"with-system" draft.  [PS: “with-system” is now a misnomer, it is a holdover 
from when the solution mimicked the “with-defaults” RFC.]

The latest “with-system” draft is nearly the polar-opposite of the -00 version. 
 Whereas the -00 version was very much trying to negate the need for 
*referenced* system-defined nodes to be copied into , the latest 
version says that all referenced system-defined nodes MUST be copied into 
.

For -aware clients, both the existence and the definition of 
system-defined nodes are known by querying the  datastore (using the 
NC/RC NMDA-extensions defined in RFC 8526 and RFC 8527).

For -unaware clients (e.g., "legacy" clients), there are two kinds: 1) 
those that never configure system-defined resources and 2) those that intend to 
configure system-defined resources.

For 1st kind of legacy client, no special access needs to be provided.  The 
solution only needs to ensure that system-defined resources exist in  
so these clients don’t have offline-validation errors.  This is exactly what 
the current version of this draft ensures, as opposed to the -00 version.

For the 2nd kind of legacy client, the draft says: "How clients unaware of the 
 datastore can find appropriate configurations is beyond the scope of 
this document.”, but one imagines servers exposing proprietary equivalents to 
querying the  datastore.   But since this draft states that servers 
MUST support NMDA, any proprietary mechanism would be redundant to the 
NMDA-equivalent.  Further, the effort to modify a client to use the proprietary 
mechanism seems nearly equivalent to the effort to modify a client to use the 
NMDA mechanism.  Combined, it begs the question if servers would ever expose a 
proprietary mechanism or, instead, assume “legacy” clients would actually 
become -aware.

That’s enough of a primer for now, cheers!

Kent


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

Re: [netmod] Regarding IPR on Regarding IPR on draft-ietf-netmod-yang-semver-06

[Balázs Lengyel]

"No, I'm not aware of any IPR that applies to this draft"

Regards, Balazs

-Original Message-
From: Benoit Claise  
Sent: Tuesday, 1 February, 2022 08:16
To: Lou Berger ; jcla...@cisco.com; rwil...@cisco.com; 
res...@yahoo.com; Balázs Lengyel ; 
jason.ste...@nokia.com
Cc: NetMod WG ; NetMod WG Chairs 
Subject: Re: Regarding IPR on Regarding IPR on draft-ietf-netmod-yang-semver-06

"No, I'm not aware of any IPR that applies to this draft"

Regards, Benoit

On 1/31/2022 10:57 PM, Lou Berger wrote:
>
>
> Authors, Contributors, WG,
>
> As part of WG Last Call:
>
> Are you aware of any IPR that applies to drafts identified above?
>
> Please state either:
>
> "No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draft"
>
> If so, has this IPR been disclosed in compliance with IETF IPR rules 
> (see RFCs 3669, 5378 and 8179 for more details)?
>
> If yes to the above, please state either:
>
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
>
> If you answer no, please provide any additional details you think 
> appropriate. If you are listed as a document author or contributor 
> please answer the above by responding to this email regardless of 
> whether or not you are aware of any relevant IPR. This document will 
> not advance to the next stage until a response has been received from 
> each author.
>
> NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.
>
> If you are on the WG email list or attend WG meetings but are not 
> listed as an author or contributor, we remind you of your obligations 
> under the IETF IPR rules which encourages you to notify the IETF if 
> you are aware of IPR of others on an IETF contribution, or to refrain 
> from participating in any contribution or discussion related to your 
> undisclosed IPR. For more information, please see the RFCs listed 
> above and 
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
>
> Thank you,
> Lou (Co-Chair)
>
> PS Please include all listed in the headers of this message in your 
> response.
>
>
> .
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11

[Andy Bierman]

On Fri, Feb 18, 2022 at 8:39 AM Martin Björklund  wrote:

> Hi,
>
> I didn't find any discussion about the new percent types in the list
> archives.  Do we really need three types for percent?  We can now
> express 4294967295 percent, but not 10.5 percent.
>
>

IMO it is a mistake to have too many ways to do the same thing.
We already have the "units" statement to add details like "percent" and
"centiseconds".
(And there are RFCs already that define types this way.)

uint8 and int32 and uint32 for percent? Plus the units approach?
I suppose the use-case for uint32 is "measurement of percentage over 2
billion percent".
IMO the units-stmt is sufficient, but there should be a documented
consistent approach
(maybe updating RFC 8407).



> The new tables look good.  s/6020/6021/g though.
>
>
>
> /martin
>

Andy


>
>
> Jürgen Schönwälder  wrote:
> > On Tue, Feb 15, 2022 at 12:12:04PM +, maqiufang (A) wrote:
> >
> > > I have only one comment: It seems that Table 2 doesn’t list all the
> > > types defined in “ietf-inet-types” YANG module, e.g.,
> > > protocol-number, ip-address-link-local, ip-address-and-prefix…
> > > Should this be fixed?
> >
> > Yes, this should be fixed. When the initial version was produced,
> > there was quite some concern about consistency with SMIv2 definitions
> > and this lead to the tables. Meanwhile, I assume the purpose of the
> > tables is more to provide a quick overview. Hence I propose to split
> > the tables into (i) tables that provide an overview of all types
> > defined in the YANG modules and (ii) tables that detail equivalent
> > SMIv2 types where they exist (short tables). For the overview tables,
> > I suggest to add some more information. I am thinking of overview
> > tables like these (keep scrolling, there is more text below):
> >
> > * ietf-yang-types
> >
> >   | Typedef   | Type  | Introduced |
> >   |---+---+|
> >   | counter32 | uint32| RFC 6021   |
> >   | zero-based-counter32  | uint32| RFC 6021   |
> >   | counter64 | uint64| RFC 6021   |
> >   | zero-based-counter64  | uint64| RFC 6021   |
> >   | gauge32   | uint32| RFC 6021   |
> >   | gauge64   | uint64| RFC 6021   |
> >   |---+---+|
> >   | object-identifier | string| RFC 6021   |
> >   | object-identifier-128 | object-identifier | RFC 6021   |
> >   |---+---+|
> >   | date-and-time | string| RFC 6021   |
> >   | date  | string| RFC    |
> >   | time  | string| RFC    |
> >   |---+---+|
> >   | hours32   | int32 | RFC XXX|
> >   | minutes32 | int32 | RFC XXX|
> >   | seconds32 | int32 | RFC XXX|
> >   | centiseconds32| int32 | RFC XXX|
> >   | milliseconds32| int32 | RFC XXX|
> >   | microseconds32| int32 | RFC XXX|
> >   | microseconds64| int64 | RFC XXX|
> >   | nanoseconds32 | int32 | RFC XXX|
> >   | nanoseconds64 | int64 | RFC XXX|
> >   | timeticks | int32 | RFC 6020   |
> >   | timestamp | timeticks | RFC 6020   |
> >   |---+---+|
> >   | phys-address  | string| RFC 6020   |
> >   | mac-address   | string| RFC 6020   |
> >   |---+---+|
> >   | xpath1.0  | string| RFC 6020   |
> >   | hex-string| string| RFC 6991   |
> >   | uuid  | string| RFC 6991   |
> >   | dotted-quad   | string| RFC 6991   |
> >   | yang-identifier   | string| RFC 6991   |
> >   | revision-identifier   | date  | RFC    |
> >   |---+---+|
> >   | percent-i32   | int32 | RFC    |
> >   | percent-u32   | uint32| RFC    |
> >   | percent   | uint8 | RFC    |
> >   |---+---+|
> >
> > * ietf-inet-types
> >
> >   | Typedef | Type | Introduced |
> >   |-+--+|
> >   | ip-version  | enum | RFC 6021   |
> >   | dscp| uint8| RFC 6021   |
> >   | ipv6-flow-label | uint32   | RFC 6021   |
> >   | port-number | uint16   | RFC 6021   |
> >   | protocol-number | 

Re: [netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11

[Martin Björklund]

Hi,

I didn't find any discussion about the new percent types in the list
archives.  Do we really need three types for percent?  We can now
express 4294967295 percent, but not 10.5 percent.

The new tables look good.  s/6020/6021/g though.



/martin


Jürgen Schönwälder  wrote:
> On Tue, Feb 15, 2022 at 12:12:04PM +, maqiufang (A) wrote:
> 
> > I have only one comment: It seems that Table 2 doesn’t list all the
> > types defined in “ietf-inet-types” YANG module, e.g.,
> > protocol-number, ip-address-link-local, ip-address-and-prefix…
> > Should this be fixed?
> 
> Yes, this should be fixed. When the initial version was produced,
> there was quite some concern about consistency with SMIv2 definitions
> and this lead to the tables. Meanwhile, I assume the purpose of the
> tables is more to provide a quick overview. Hence I propose to split
> the tables into (i) tables that provide an overview of all types
> defined in the YANG modules and (ii) tables that detail equivalent
> SMIv2 types where they exist (short tables). For the overview tables,
> I suggest to add some more information. I am thinking of overview
> tables like these (keep scrolling, there is more text below):
> 
> * ietf-yang-types
> 
>   | Typedef   | Type  | Introduced |
>   |---+---+|
>   | counter32 | uint32| RFC 6021   |
>   | zero-based-counter32  | uint32| RFC 6021   |
>   | counter64 | uint64| RFC 6021   |
>   | zero-based-counter64  | uint64| RFC 6021   |
>   | gauge32   | uint32| RFC 6021   |
>   | gauge64   | uint64| RFC 6021   |
>   |---+---+|
>   | object-identifier | string| RFC 6021   |
>   | object-identifier-128 | object-identifier | RFC 6021   |
>   |---+---+|
>   | date-and-time | string| RFC 6021   |
>   | date  | string| RFC    |
>   | time  | string| RFC    |
>   |---+---+|
>   | hours32   | int32 | RFC XXX|
>   | minutes32 | int32 | RFC XXX|
>   | seconds32 | int32 | RFC XXX|
>   | centiseconds32| int32 | RFC XXX|
>   | milliseconds32| int32 | RFC XXX|
>   | microseconds32| int32 | RFC XXX|
>   | microseconds64| int64 | RFC XXX|
>   | nanoseconds32 | int32 | RFC XXX|
>   | nanoseconds64 | int64 | RFC XXX|
>   | timeticks | int32 | RFC 6020   |
>   | timestamp | timeticks | RFC 6020   |
>   |---+---+|
>   | phys-address  | string| RFC 6020   |
>   | mac-address   | string| RFC 6020   |
>   |---+---+|
>   | xpath1.0  | string| RFC 6020   |
>   | hex-string| string| RFC 6991   |
>   | uuid  | string| RFC 6991   |
>   | dotted-quad   | string| RFC 6991   |
>   | yang-identifier   | string| RFC 6991   |
>   | revision-identifier   | date  | RFC    |
>   |---+---+|
>   | percent-i32   | int32 | RFC    |
>   | percent-u32   | uint32| RFC    |
>   | percent   | uint8 | RFC    |
>   |---+---+|
> 
> * ietf-inet-types
> 
>   | Typedef | Type | Introduced |
>   |-+--+|
>   | ip-version  | enum | RFC 6021   |
>   | dscp| uint8| RFC 6021   |
>   | ipv6-flow-label | uint32   | RFC 6021   |
>   | port-number | uint16   | RFC 6021   |
>   | protocol-number | uint8| RFC    |
>   | as-number   | uint32   | RFC 6021   |
>   |-+--+|
>   | ip-address  | union| RFC 6021   |
>   | ipv4-address| string   | RFC 6021   |
>   | ipv6-address| string   | RFC 6021   |
>   | ip-address-no-zone  | union| RFC 6991   |
>   | ipv4-address-no-zone| ipv4-address | RFC 6991   |
>   | ipv6-address-no-zone| ipv6-address | RFC 6991   |
>   | ip-address-link-local   | union| RFC    |
>   | ipv4-address-link-local | ipv4-address | RFC    |
>   | ipv6-address-link-local | ipv6-address | RFC    |
>   | ip-prefix   

Re: [netmod] Regarding IPR on draft-ietf-netmod-yang-module-versioning-05

[Balázs Lengyel]

"No, I'm not aware of any IPR that applies to this draft"

Thanks,
Balazs

-Original Message-
From: Rob Wilton (rwilton)  
Sent: Tuesday, 1 February, 2022 15:05
To: Lou Berger ; Joe Clarke (jclarke) ; 
res...@yahoo.com; Balázs Lengyel ; 
jason.ste...@nokia.com
Cc: NetMod WG ; NetMod WG Chairs 
Subject: RE: Regarding IPR on draft-ietf-netmod-yang-module-versioning-05

"No, I'm not aware of any IPR that applies to this draft"

Thanks,
Rob


-Original Message-
From: Lou Berger  
Sent: 31 January 2022 21:54
To: Joe Clarke (jclarke) ; res...@yahoo.com; Rob Wilton 
(rwilton) ; balazs.leng...@ericsson.com; 
jason.ste...@nokia.com
Cc: NetMod WG ; NetMod WG Chairs 
Subject: Regarding IPR on draft-ietf-netmod-yang-module-versioning-05



Authors, Contributors, WG,

As part of WG Last Call:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate. If you are listed as a document author or contributor
please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
Lou (Co-Chair)

PS Please include all listed in the headers of this message in your
response.


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

Re: [netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11

[Jürgen Schönwälder]

On Tue, Feb 15, 2022 at 12:12:04PM +, maqiufang (A) wrote:

> I have only one comment: It seems that Table 2 doesn’t list all the
> types defined in “ietf-inet-types” YANG module, e.g.,
> protocol-number, ip-address-link-local, ip-address-and-prefix…
> Should this be fixed?

Yes, this should be fixed. When the initial version was produced,
there was quite some concern about consistency with SMIv2 definitions
and this lead to the tables. Meanwhile, I assume the purpose of the
tables is more to provide a quick overview. Hence I propose to split
the tables into (i) tables that provide an overview of all types
defined in the YANG modules and (ii) tables that detail equivalent
SMIv2 types where they exist (short tables). For the overview tables,
I suggest to add some more information. I am thinking of overview
tables like these (keep scrolling, there is more text below):

* ietf-yang-types

  | Typedef   | Type  | Introduced |
  |---+---+|
  | counter32 | uint32| RFC 6021   |
  | zero-based-counter32  | uint32| RFC 6021   |
  | counter64 | uint64| RFC 6021   |
  | zero-based-counter64  | uint64| RFC 6021   |
  | gauge32   | uint32| RFC 6021   |
  | gauge64   | uint64| RFC 6021   |
  |---+---+|
  | object-identifier | string| RFC 6021   |
  | object-identifier-128 | object-identifier | RFC 6021   |
  |---+---+|
  | date-and-time | string| RFC 6021   |
  | date  | string| RFC    |
  | time  | string| RFC    |
  |---+---+|
  | hours32   | int32 | RFC XXX|
  | minutes32 | int32 | RFC XXX|
  | seconds32 | int32 | RFC XXX|
  | centiseconds32| int32 | RFC XXX|
  | milliseconds32| int32 | RFC XXX|
  | microseconds32| int32 | RFC XXX|
  | microseconds64| int64 | RFC XXX|
  | nanoseconds32 | int32 | RFC XXX|
  | nanoseconds64 | int64 | RFC XXX|
  | timeticks | int32 | RFC 6020   |
  | timestamp | timeticks | RFC 6020   |
  |---+---+|
  | phys-address  | string| RFC 6020   |
  | mac-address   | string| RFC 6020   |
  |---+---+|
  | xpath1.0  | string| RFC 6020   |
  | hex-string| string| RFC 6991   |
  | uuid  | string| RFC 6991   |
  | dotted-quad   | string| RFC 6991   |
  | yang-identifier   | string| RFC 6991   |
  | revision-identifier   | date  | RFC    |
  |---+---+|
  | percent-i32   | int32 | RFC    |
  | percent-u32   | uint32| RFC    |
  | percent   | uint8 | RFC    |
  |---+---+|

* ietf-inet-types

  | Typedef | Type | Introduced |
  |-+--+|
  | ip-version  | enum | RFC 6021   |
  | dscp| uint8| RFC 6021   |
  | ipv6-flow-label | uint32   | RFC 6021   |
  | port-number | uint16   | RFC 6021   |
  | protocol-number | uint8| RFC    |
  | as-number   | uint32   | RFC 6021   |
  |-+--+|
  | ip-address  | union| RFC 6021   |
  | ipv4-address| string   | RFC 6021   |
  | ipv6-address| string   | RFC 6021   |
  | ip-address-no-zone  | union| RFC 6991   |
  | ipv4-address-no-zone| ipv4-address | RFC 6991   |
  | ipv6-address-no-zone| ipv6-address | RFC 6991   |
  | ip-address-link-local   | union| RFC    |
  | ipv4-address-link-local | ipv4-address | RFC    |
  | ipv6-address-link-local | ipv6-address | RFC    |
  | ip-prefix   | union| RFC 6021   |
  | ipv4-prefix | string   | RFC 6021   |
  | ipv6-prefix | string   | RFC 6021   |
  | ip-address-and-prefix   | union| RFC    |
  | ipv4-address-and-prefix | string   | RFC    |
  | ipv6-address-and-prefix | string   | RFC    |
  |-+--+|
  | domain-name | string   | RFC 6021   |
  |