Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-artwork-folding-09: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

On Thu, Sep 05, 2019 at 10:02:03PM +, Kent Watsen wrote:
> Hi Ben,
> 
> Thank you for your review.  Comments below.
> 
> Update @ https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-10 
> 
> 
> Kent // as co-author
> 
> 
> > On Sep 5, 2019, at 2:07 AM, Benjamin Kaduk via Datatracker 
> >  wrote:
> > 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-netmod-artwork-folding-09: Discuss
> > 
> > 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-artwork-folding/
> > 
> > 
> > 
> > --
> > DISCUSS:
> > --
> > 
> > I think the procedures described herein are incomplete without a footer
> > to terminate the un-folding process.  Otherwise, it seems that the
> > described algorithms would leave the two-line header for the second and
> > subsequent instances of folded text in a single document.  (If we tried
> > to just blindly remove all instances of the header without seeking
> > boundaries, then we would misreconstruct content when different folding
> > algorithms are used in the same document with the single-backslash
> > algorithm occurring first.)
> 
> Are you referring to when an RFC contains multiple inclusions and one is
> trying to unfold them all at once?   That's not the intention here, as

Yes, that was what I was thinking; sorry for missing or misinterpreting the
notes in Sections 7.2/8.2.

> noted in paragraph 3 in both sections 7.2 and 8.2.  FWIW, this sounds
> like the framing problem that the WG discussed with the conclusion that
> extracting from plain-text is dead, now that XML is the required
> submission format, and XML provides a superior framing mechanism than any
> footer we could add.
> 
> BTW, yes, each text inclusion in a single RFC may independently be folded
> using either the '\' or '\\' strategy, with the recommendation that '\'
> always be tried first and '\\' only used when '\' fails.
> 
> If referring to a single text content instance, could you provide an
> example illustrating the concern?
> 
> 
> 
> 
> > I don't think it's proper to refer to a script that requires bash
> > specifically as a "POSIX shell script".  I did not attmept to check
> > whether any bash-specific features are used or this requirements stems
> > solely from the shebang line, though.
> 
> I just changed "POSIX" to "Bash" in the title for Appendix A.
> 
> Not that it matters, but "--posix" is passed into `bash` on the first
> line of the script  ;)
> 
> 
> 
> > I think the shell script does need to use double-quotes around some
> > variable expansions, especially "$infile" and "$outfile", to work
> > properly for filenames containing spaces.  We do quote "$infile" when
> > we're checking that it exists, just not (most of the time) when we
> > actually use it!
> 
> Updated.
> 
> 
> 
> > In addition to the above, I also share Alissa's (and Mirja's) concerns,
> > but feel that Discuss is more appropriate than Abstain, so we can
> > discuss what the best way to get this content published is.  For it's
> > fine content, and we should see it published; it's just not immediately
> > clear to me what the right way to do so is.
> 
> Agreed.   For now, I've changed it to Informational, but I think there
> remains a discussion around if the draft should be re-rerun through the
> IAB stream.   My responses today to Alissa's Abstain and Suresh Discuss
> dig into this.  Is it okay to use those threads for this item?

Please do; this point was mostly intended to make sure that we didn't
inadvertently approve the document while those discussions were still going
on.

> 
> > --
> > COMMENT:
> > --
> > 
> > Section 4.1
> > 
> >   Automated folding of long lines is needed in order to support draft
> >   compilations that entail a) validation of source input files (e.g.,
> >   XML, JSON, ABNF, ASN.1) and/or b) dynamic generation of output, using
> >   a tool that doesn't observe line lengths, that is stitched into the
> >   final document to be submitted.
> > 
> > I don't think the intended meaning of "source input files" will be
> > clear to all readers just from this text.  Some discussion of how RFCs
> > can consider source code, data structures, generated output, etc., that
> > have standalone representations and natural formats, and

[netmod] I-D Action: draft-ietf-netmod-factory-default-03.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   : Factory Default Setting
Authors : Qin Wu
  Balazs Lengyel
  Ye Niu
Filename: draft-ietf-netmod-factory-default-03.txt
Pages   : 11
Date: 2019-09-10

Abstract:
   This document defines a method to reset a server to its factory-
   default content.  The reset operation may be used e.g. during initial
   zero-touch configuration or when the existing configuration has major
   errors, so re-starting the configuration process from scratch is the
   best option.

   A new factory-reset RPC is defined.  Several methods of documenting
   the factory-default content are specified.

   Optionally a new "factory-default" read-only datastore is defined,
   that contains the data that will be copied over to the running
   datastore at reset.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-factory-default/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-factory-default-03
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-factory-default-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-factory-default-03


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] I-D Action: draft-ietf-netmod-factory-default-03.txt

[Qin Wu]

v-03 is posted, the main change is to update security section to address 
comments raised in last IETF meeting.
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-factory-default-03

-Qin
-邮件原件-
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 internet-dra...@ietf.org
发送时间: 2019年9月11日 8:59
收件人: i-d-annou...@ietf.org
抄送: netmod@ietf.org
主题: [netmod] I-D Action: draft-ietf-netmod-factory-default-03.txt


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   : Factory Default Setting
Authors : Qin Wu
  Balazs Lengyel
  Ye Niu
Filename: draft-ietf-netmod-factory-default-03.txt
Pages   : 11
Date: 2019-09-10

Abstract:
   This document defines a method to reset a server to its factory-
   default content.  The reset operation may be used e.g. during initial
   zero-touch configuration or when the existing configuration has major
   errors, so re-starting the configuration process from scratch is the
   best option.

   A new factory-reset RPC is defined.  Several methods of documenting
   the factory-default content are specified.

   Optionally a new "factory-default" read-only datastore is defined,
   that contains the data that will be copied over to the running
   datastore at reset.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-factory-default/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-factory-default-03
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-factory-default-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-factory-default-03


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
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] 答复: Please clarify implementation about ‘when’

[Fengchong (frank)]

Andy,

Whether different result would occur according different process order?
According 8.3.2
if server process ‘a= 3’ firstly, b will be deleted by system and becomes a 
non-exist schema node, and then  when ‘b=5’ is processed , server will report a 
‘unknown-element’ error.
But if server process ‘b=5’ firstly, it will be accepted by server, and then 
when ‘a=3’ is processed, b will be deleted by system, but report OK.

If sec 8.3.2 is not right. What is the right?
When node a and node b in the same request, and b tagged when condition, a’s 
value will cause b’s condition is evaluated to false, which is more prior?
According you and Rob’s interpretation , maybe node ’a’ is more prior? If yes, 
why node ‘b’ should be processed later?

I think whether in edit-config processing phase the configuration tagged when 
should not be evaluated and be delayed to commit or validate?
When commit or validate operation is issued,  the data node tagged when will be 
evaluated, and if it’s evaluated to false, this data will be deleted by system 
immediately, server should not report any error.



华为技术有限公司 Huawei Technologies Co., Ltd.
[Company_logo]
个人签名：冯冲
手　　机：13776612983
电子邮件：frank.fengch...@huawei.com
公司网址：www.huawei.com

 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!

发件人: Andy Bierman [mailto:a...@yumaworks.com]
发送时间: 2019年9月10日 10:56
收件人: Fengchong (frank) 
抄送: Rob Wilton (rwilton) ; netmod@ietf.org; Yangang 

主题: Re: [netmod] Please clarify implementation about ‘when’



On Mon, Sep 9, 2019 at 7:40 PM Fengchong (frank) 
mailto:frank.fengch...@huawei.com>> wrote:
Andy,
Whether all constraints on content in  parameter will not be evaluated 
in payload parsing phase, for example, a leaf’s value exceed range?
Netconf server should treat it as a block data?


Field validation and datastore validation are 2 different things.
when-stmt processing is neither. It is by far the hardest part of an automated 
server to get right.

Another question:

In edit-config processing phase, whether constraints on content in  
parameter needs be evaluated?
If yes, when  configuration modification cause when condition is evaluated to 
false, the node tagged when will be automatically deleted by system.
Then, in scene 2, whether different result would occur according different 
process order?


Since the  parameter is anyxml, the YANG constraints defined on 
datastore contents
are not enforced as part of RPC input validation.

It would be nice if NETCONF defined behavior for providing  data that 
will get deleted
immediately by the server.  We have a CLI parameter for this since some vendors 
want to
treat this as an error and other just silently delete nodes.  Note that 
when-stmt can silently
delete existing nodes not included in the edit. (Lada does not agree this is 
how it should work,
so we need yang-next to decide. Maybe NETCONF needs a --force parameter for 
this purpose.)


Andy




华为技术有限公司 Huawei Technologies Co., Ltd.
[Company_logo]
个人签名：冯冲
手　　机：13776612983
电子邮件：frank.fengch...@huawei.com
公司网址：www.huawei.com

 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!

发件人: Andy Bierman [mailto:a...@yumaworks.com]
发送时间: 2019年9月10日 10:19
收件人: Fengchong (frank) 
mailto:frank.fengch...@huawei.com>>
抄送: Rob Wilton (rwilton) mailto:rwil...@cisco.com>>; 
netmod@ietf.org; Yangang 
mailto:yang...@huawei.com>>
主题: Re: [netmod] Please clarify implementation about ‘when’



On Mon, Sep 9, 2019 at 7:10 PM Fengchong (frank) 
mailto:frank.fengch...@huawei.com>> wrote:
Hi andy,

You only talk about the constraints on rpc operation’s parameter?

Do you have any opinion about my question?

8.3.1 does not apply to leaf 'b'.
The RPC paramet

[netmod] 答复: 答复: Please clarify implementation about ‘when’

[Qin Wu]

Why processing order matter? My interpretation is both leaf node values 
(i.e.,leaf a, leaf b) should be validated together and commit as a whole,
RFC6241 said:
“
If the device is unable to commit all of the changes in the
 candidate configuration datastore, then the running
 configuration MUST remain unchanged.
”
So validate the leaf node value in the edit-config request (message content 
validation) is not important, validate the leaf node value that is applied to 
 (datastore validation) is the key.


I think what you want to raise is the server should hold on to send reply with 
an "unknown-element"  in the  during payload parsing 
phase and NETCONF 

Processing until all validation complete, otherwise it seems server will

Send multiple rply with "unknown-element"  in the  which 
seems not reasonable.



-Qin
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Fengchong (frank)
发送时间: 2019年9月11日 9:29
收件人: Andy Bierman 
抄送: netmod@ietf.org; Yangang 
主题: [netmod] 答复: Please clarify implementation about ‘when’

Andy,

Whether different result would occur according different process order?
According 8.3.2
if server process ‘a= 3’ firstly, b will be deleted by system and becomes a 
non-exist schema node, and then  when ‘b=5’ is processed , server will report a 
‘unknown-element’ error.
But if server process ‘b=5’ firstly, it will be accepted by server, and then 
when ‘a=3’ is processed, b will be deleted by system, but report OK.

If sec 8.3.2 is not right. What is the right?
When node a and node b in the same request, and b tagged when condition, a’s 
value will cause b’s condition is evaluated to false, which is more prior?
According you and Rob’s interpretation , maybe node ’a’ is more prior? If yes, 
why node ‘b’ should be processed later?

I think whether in edit-config processing phase the configuration tagged when 
should not be evaluated and be delayed to commit or validate?
When commit or validate operation is issued,  the data node tagged when will be 
evaluated, and if it’s evaluated to false, this data will be deleted by system 
immediately, server should not report any error.



华为技术有限公司 Huawei Technologies Co., Ltd.
[Company_logo]
个人签名：冯冲
手　　机：13776612983
电子邮件：frank.fengch...@huawei.com
公司网址：www.huawei.com

 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!

发件人: Andy Bierman [mailto:a...@yumaworks.com]
发送时间: 2019年9月10日 10:56
收件人: Fengchong (frank) 
mailto:frank.fengch...@huawei.com>>
抄送: Rob Wilton (rwilton) mailto:rwil...@cisco.com>>; 
netmod@ietf.org; Yangang 
mailto:yang...@huawei.com>>
主题: Re: [netmod] Please clarify implementation about ‘when’



On Mon, Sep 9, 2019 at 7:40 PM Fengchong (frank) 
mailto:frank.fengch...@huawei.com>> wrote:
Andy,
Whether all constraints on content in  parameter will not be evaluated 
in payload parsing phase, for example, a leaf’s value exceed range?
Netconf server should treat it as a block data?


Field validation and datastore validation are 2 different things.
when-stmt processing is neither. It is by far the hardest part of an automated 
server to get right.

Another question:

In edit-config processing phase, whether constraints on content in  
parameter needs be evaluated?
If yes, when  configuration modification cause when condition is evaluated to 
false, the node tagged when will be automatically deleted by system.
Then, in scene 2, whether different result would occur according different 
process order?


Since the  parameter is anyxml, the YANG constraints defined on 
datastore contents
are not enforced as part of RPC input validation.

It would be nice if NETCONF defined behavior for providing  data that 
will get deleted
immediately by the server.  We have a CLI parameter for this since some vendors 
want to
treat this as an error and other just silently delete nodes.  Note that 
when-stmt can silently
delete existing nodes not included in the edit. (Lada does not agree this is 
how it should work,
so we need yang-next to decide. Maybe NETCONF needs a --force parameter for 
this purpose.)


Andy




华为技术有限公司 Huawei Technologies Co., Ltd.
[Company_logo]
个人签名：冯冲
手　　机：13776612983
电子邮件：frank.fengch...@huawei.com
公司网址：www.huawei.com