date:20200427

Re: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-factory-default-14: (with COMMENT)

2020-04-27 Thread Qin Wu

Thanks Ben.

-Qin
-邮件原件-
发件人: Benjamin Kaduk [mailto:ka...@mit.edu] 
发送时间: 2020年4月28日 0:07
收件人: Qin Wu 
抄送: The IESG ; draft-ietf-netmod-factory-defa...@ietf.org; 
netmod-cha...@ietf.org; netmod@ietf.org; Kent Watsen 
主题: Re: Benjamin Kaduk's No Objection on draft-ietf-netmod-factory-default-14: 
(with COMMENT)

Hi Qin,

The new updates look good, thanks.

-Ben

On Sun, Apr 26, 2020 at 02:52:15AM +, Qin Wu wrote:
> Hi, Ben:
> -邮件原件-
> 发件人: Benjamin Kaduk [mailto:ka...@mit.edu]
> 发送时间: 2020年4月25日 3:37
> 收件人: Qin Wu 
> 抄送: The IESG ; 
> draft-ietf-netmod-factory-defa...@ietf.org; netmod-cha...@ietf.org; 
> netmod@ietf.org; Kent Watsen 
> 主题: Re: Benjamin Kaduk's No Objection on 
> draft-ietf-netmod-factory-default-14: (with COMMENT)
> 
> On Thu, Apr 23, 2020 at 04:54:37AM +, Qin Wu wrote:
> > Hi, Ben:
> > Thanks for your valuable comments, see reply inline below.
> > -邮件原件-
> > 发件人: Benjamin Kaduk via Datatracker [mailto:nore...@ietf.org]
> > 发送时间: 2020年4月23日 9:39
> > 收件人: The IESG 
> > 抄送: draft-ietf-netmod-factory-defa...@ietf.org;
> > netmod-cha...@ietf.org; netmod@ietf.org; Kent Watsen 
> > ; kent+i...@watsen.net
> > 主题: Benjamin Kaduk's No Objection on
> > draft-ietf-netmod-factory-default-14: (with COMMENT)
> > 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-netmod-factory-default-14: No Objection
> > 
> > When responding, please keep the subject line intact and reply to 
> > all email addresses included in the To and CC lines. (Feel free to 
> > cut this introductory paragraph, however.)
> > 
> > 
> > Please refer to
> > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> > 
> > 
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-netmod-factory-default/
> > 
> > 
> > 
> > 
> > --
> > COMMENT:
> > 
> > --
> > 
> > While many of the secdir reviewer's complaints stem from the YANG security 
> > considerations boilerplate, it still seems like it would be worth some form 
> > of response to the review.
> > 
> > [Qin]: You are correct, we authors also bring up the discussion on 
> > sec-review comment on YANG security consideration boilerplate to netmod 
> > list. I have sent my response to the sec-review, Thanks for kindly reminder.
> > 
> > Section 1
> > 
> >This document defines a method to reset a server to its factory
> >default content.  The reset operation may be used, e.g., when the
> >existing configuration has major errors so re-starting the
> >configuration process from scratch is the best option.
> > 
> >A "factory-reset" RPC is defined.  When resetting a device, all
> >previous configuration settings will be lost and replaced by the
> >factory default content.
> > 
> > nit: these two paragraphs talk about the same thing, but the next paragraph 
> > is a different thing.  It may be better to combine these two in to a single 
> > paragraph.
> > [Qin]:The format of this section is to first introduce what method we 
> > proposed? And then introduce what this method look like, or two key 
> > components for this method, i.e., one new factory-reset RPC and one new 
> > factory datastore.
> 
> If the first pargaraph is trying to introduce everything, then it should 
> mention both the RPC and the datastore.  Right now, I only see it talking 
> about the RPC (well, the "reset operation"), and thus it does not seem like a 
> general introduction as opposed to an introduction specific to the RPC.
> 
> [Qin]: I see your point, a few clarification: YANG data model will include 
> RPC definition and datastore definition and A device MAY implement the 
> "factory-reset" RPC without
>implementing the "factory-default" datastore. In addition, we want to 
> avoid duplicated text in both abstraction and introduction. Based on this 
> clarification, I propose the following change:
> OLD TEXT:
> "
>This document defines a method to reset a server to its factory
>default content.  The reset operation may be used, e.g., when the
>existing configuration has major errors so re-starting the
>configuration process from scratch is the best option.
> 
>A "factory-reset" RPC is defined.  When resetting a device, all
>previous configuration settings will be lost and replaced by the
>factory default content.
> 
>A "factory-default" read-only datastore is defined, that contains the
>data to replace the contents of implemented read-write conventional
>configuration datastores at reset.  This datastore can also be used
>in the  operation.
> "
> NEW TEXT:
> "
>This document defines a YANG data model and associated mechanism to
>reset a server to its factory default content.  This mechanism may be
>used,

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

2020-04-27 Thread Mahesh Jethanandani

+1.

> On Apr 24, 2020, at 12:39 PM, Sterne, Jason (Nokia - CA/Ottawa) 
>  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;
>  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

Re: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-factory-default-14: (with COMMENT)

2020-04-27 Thread Benjamin Kaduk

Hi Qin,

The new updates look good, thanks.

-Ben

On Sun, Apr 26, 2020 at 02:52:15AM +, Qin Wu wrote:
> Hi, Ben:
> -邮件原件-
> 发件人: Benjamin Kaduk [mailto:ka...@mit.edu] 
> 发送时间: 2020年4月25日 3:37
> 收件人: Qin Wu 
> 抄送: The IESG ; draft-ietf-netmod-factory-defa...@ietf.org; 
> netmod-cha...@ietf.org; netmod@ietf.org; Kent Watsen 
> 主题: Re: Benjamin Kaduk's No Objection on 
> draft-ietf-netmod-factory-default-14: (with COMMENT)
> 
> On Thu, Apr 23, 2020 at 04:54:37AM +, Qin Wu wrote:
> > Hi, Ben:
> > Thanks for your valuable comments, see reply inline below.
> > -邮件原件-
> > 发件人: Benjamin Kaduk via Datatracker [mailto:nore...@ietf.org]
> > 发送时间: 2020年4月23日 9:39
> > 收件人: The IESG 
> > 抄送: draft-ietf-netmod-factory-defa...@ietf.org; 
> > netmod-cha...@ietf.org; netmod@ietf.org; Kent Watsen 
> > ; kent+i...@watsen.net
> > 主题: Benjamin Kaduk's No Objection on 
> > draft-ietf-netmod-factory-default-14: (with COMMENT)
> > 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-netmod-factory-default-14: No Objection
> > 
> > When responding, please keep the subject line intact and reply to all 
> > email addresses included in the To and CC lines. (Feel free to cut 
> > this introductory paragraph, however.)
> > 
> > 
> > Please refer to 
> > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> > 
> > 
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-netmod-factory-default/
> > 
> > 
> > 
> > --
> > COMMENT:
> > --
> > 
> > While many of the secdir reviewer's complaints stem from the YANG security 
> > considerations boilerplate, it still seems like it would be worth some form 
> > of response to the review.
> > 
> > [Qin]: You are correct, we authors also bring up the discussion on 
> > sec-review comment on YANG security consideration boilerplate to netmod 
> > list. I have sent my response to the sec-review, Thanks for kindly reminder.
> > 
> > Section 1
> > 
> >This document defines a method to reset a server to its factory
> >default content.  The reset operation may be used, e.g., when the
> >existing configuration has major errors so re-starting the
> >configuration process from scratch is the best option.
> > 
> >A "factory-reset" RPC is defined.  When resetting a device, all
> >previous configuration settings will be lost and replaced by the
> >factory default content.
> > 
> > nit: these two paragraphs talk about the same thing, but the next paragraph 
> > is a different thing.  It may be better to combine these two in to a single 
> > paragraph.
> > [Qin]:The format of this section is to first introduce what method we 
> > proposed? And then introduce what this method look like, or two key 
> > components for this method, i.e., one new factory-reset RPC and one new 
> > factory datastore.
> 
> If the first pargaraph is trying to introduce everything, then it should 
> mention both the RPC and the datastore.  Right now, I only see it talking 
> about the RPC (well, the "reset operation"), and thus it does not seem like a 
> general introduction as opposed to an introduction specific to the RPC.
> 
> [Qin]: I see your point, a few clarification: YANG data model will include 
> RPC definition and datastore definition and A device MAY implement the 
> "factory-reset" RPC without
>implementing the "factory-default" datastore. In addition, we want to 
> avoid duplicated text in both abstraction and introduction. Based on this 
> clarification, I propose the following change:
> OLD TEXT:
> "
>This document defines a method to reset a server to its factory
>default content.  The reset operation may be used, e.g., when the
>existing configuration has major errors so re-starting the
>configuration process from scratch is the best option.
> 
>A "factory-reset" RPC is defined.  When resetting a device, all
>previous configuration settings will be lost and replaced by the
>factory default content.
> 
>A "factory-default" read-only datastore is defined, that contains the
>data to replace the contents of implemented read-write conventional
>configuration datastores at reset.  This datastore can also be used
>in the  operation.
> "
> NEW TEXT:
> "
>This document defines a YANG data model and associated mechanism to
>reset a server to its factory default content.  This mechanism may be
>used, e.g., when the existing configuration has major errors so re-
>starting the configuration process from scratch is the best option.
> 
>A "factory-reset" RPC is defined within the YANG data model.  When
>resetting a device, all previous configuration settings will be lost
>and replaced by the factory default

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

2020-04-27 Thread Reshad Rahman (rrahman)

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

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

2020-04-27 Thread Rob Wilton (rwilton)

Thanks.  I’ll wait until Friday for any further comments.

Thanks,
Rob

From: Kent Watsen 
Sent: 24 April 2020 22:09
To: Rob Wilton (rwilton) 
Cc: netmod@ietf.org
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

Yes, better, thanks!

K.

On Apr 24, 2020, at 3:33 PM, Rob Wilton (rwilton) 
mailto:rwil...@cisco.com>> wrote:

Hi Kent,

Thanks for creating the issue.

I think that errata falls under section 7 of 
https://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 
mailto:j.schoenwael...@jacobs-university.de>>;
 Martin Björklund mailto:mbj+i...@4668.se>>; 
netmod@ietf.org; Rob Wilton (rwilton) 
mailto:rwil...@cisco.com>>
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 
mailto:a...@yumaworks.com>> 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 
mailto:rkre...@cesnet.cz>> wrote:
Hi,
Dne 09. 04. 20 v 17:26 Kent Watsen napsal(a):

On Apr 6, 2020, at 3:42 AM, Juergen Schoenwaelder 
mailto: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 
mailto:mbj+i...@4668.se>> 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

Re: [netmod] "uint24" in rfc6991-bis?

2020-04-27 Thread tom petch

From: netmod  on behalf of Martin Björklund 

Sent: 23 April 2020 10:57

"Rob Wilton \(rwilton\)"  wrote:
> [As an individual contributor]
>
> > -Original Message-
> > From: netmod  On Behalf Of Juergen
> > Schoenwaelder
> > Sent: 22 April 2020 23:09
> > To: Robert Varga 
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] "uint24" in rfc6991-bis?
> >
> > On Wed, Apr 22, 2020 at 11:17:26PM +0200, Robert Varga wrote:
> > > Hello,
> > >
> > > a number of IETF protocols-and-whatnots are operating on unsigned
> > > 24bit (or 3-octet) entities. For example:
> > >
> > > https://tools.ietf.org/html/rfc7471#section-4.1.5
> > > https://tools.ietf.org/html/rfc7471#section-4.4.5
> > > SRGB range start/length in https://tools.ietf.org/html/rfc8669
> >
> > For these use cases, it might be also a good idea to define types that
> > capture the additional semantics. SRGB seems to consist of two 24-bit
> > values - I can't tell whether it makes sense to model this 6-octet
> > value
> > as two 3-octet values in YANG.
> >
> > > I wonder whether it would make sense to provide something like:
> > >
> > > type uint24 {
> > >type uint32;
> > >range 0..16777215;
> > > }
> > >
> > > in ietf-inet-types as a common base type for such definitions.
> >
> > If we add such a definition, it likely should go into ietf-yang-types.
> [RW]
>
> I would find this type somewhat confusing in the sense that it mixing
> the underlying YANG datatype with the range of the value space,

I agree.

> e.g., I don't think of uint8 as
> type uint8 {
>type uint32;
>range 0..255;
> }
>
> because the encoding is allowed to be different.  Perhaps having a
> slightly different name would help avoid possible confusion with the
> built in types?

Then the question is if it really is so common so that we need a type
in ietf-yang-types for this.



I think not.  As Juergen said, where there is a 24 bit quantity, there are 
probably other semantics e.g. meaning of the maximum and minimum values comes 
to mind - and so a more specific type for that application seems a better idea.

Tom Petch
 
/martin


>
> Regards,
> Rob
>
>
> >
> > /js
> >
> > --
> > 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
>
> ___
> 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

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

Re: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-factory-default-14: (with COMMENT)

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

Re: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-factory-default-14: (with COMMENT)

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

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

Re: [netmod] "uint24" in rfc6991-bis?

6 matches

Site Navigation

Mail list logo

Footer information