[netmod] 答复: pls clarify get operation

2019-06-27 Thread Fengchong (frank)
Hi all,

 Pls clarify this question. I have been confused for a long time.


华为技术有限公司 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!

发件人: Fengchong (frank)
发送时间: 2019年6月27日 9:59
收件人: 'netc...@ietf.org' ; netmod@ietf.org
抄送: Yangshouchuan ; Zhangwei (SS) 

主题: pls clarify get operation

Hi all,
In RFC6241, get operation is defined as:
7.7.  

   Description:  Retrieve running configuration and device state

  information.
This description is too simply, so I think it should be clarified.

The case is: a data node modelled by one yang can be configured by user, but 
also can be created/modified by system or other protocols. If client issues get 
operation to retrieve this node,
  The data is created/modified by system or other protocols SHOULD be 
returned?
  For example:
  Rib can be configured by user and also can be created by routing 
protocols. In RFC 8349, the rib list is defined as:



  +--rw ribs

 +--rw rib* [name]

+--rw name  string

+--rw address-family?   identityref

+--ro default-rib?  boolean {multiple-ribs}?

+--ro routes

|  +--ro route*

|...

+---x active-route

|  +---w input

|  |  +---w v4ur:destination-address?   inet:ipv4-address

|  |  +---w v6ur:destination-address?   inet:ipv6-address

|  +--ro output

|...

+--rw description?  string



   If client issued get operation to retrieve ribs from non-NMDA device, 
rib instance created by routing protocols should be returned?

   Another associated question: If client issued get-config operation from 
non-NMDA device, only user-controlled rib instance should be returned?

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


Re: [netmod] I-D Action: draft-ietf-netmod-artwork-folding-06.txt

2019-06-27 Thread Erik Auerswald
Hi,

whilst missing the original IPR poll [1], as a recently acknowledged
contributor:

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

[1] https://mailarchive.ietf.org/arch/msg/netmod/s1TKbSLXvlJG8Q9MgqFm4197r88

Thanks,
Erik

On Thu, Jun 27, 2019 at 09:35:28PM +, Kent Watsen wrote:
> 
> This update primarily regards the non-normative script:
> 
> - renamed to "rfcfold"
> - now only uses sed one-liners
> - auto-detects if platforms `[g]sed` and `pcregrep` are present and
>suitable, outputting an error message if not.
> - cleans up the temporary directory if exits for any reason
> - improved error message around the script not implementing the
>   force-fold logic.
> 
> Special thanks to Eric Auerswald for supplying the pull requests 
> for much of the above!
> 
> 
> Outside the updates to the script:
> 
> - renamed 9.3:
>   OLD: Example Showing Smart Folding
>   NEW: Example Showing "Smart" Folding
> 
> - renamed Appendix A:
>   OLD: POSIX Shell Script: rfcfold
>   NEW: POSIX Shell Script
> 
> 
> My only comments are:
> 
> 1) the script itself doesn't name itself "rfcfold" anywhere.
> - albeit, the "name" attribute in the XML is set to "rfcfold".
> 
> 2) if the script is expected to be distributed, we may want/need to
> add a copyright statement and/or a pointer to its GitHub repo.
> 
> 
> Thanks,
> Kent
> 
> 
> > On Jun 27, 2019, at 5:20 PM, internet-dra...@ietf.org wrote:
> > 
> > 
> > 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   : Handling Long Lines in Inclusions in 
> > Internet-Drafts and RFCs
> >Authors : Kent Watsen
> >  Adrian Farrel
> >  Qin Wu
> > Filename: draft-ietf-netmod-artwork-folding-06.txt
> > Pages   : 26
> > Date: 2019-06-27
> > 
> > Abstract:
> >   This document defines two strategies for handling long lines in
> >   width-bounded text content.  One strategy is based on the historic
> >   use of a single backslash ('\') character to indicate where line-
> >   folding has occurred, with the continuation occurring with the first
> >   non-space (' ') character on the next line.  The second strategy
> >   extends the first strategy by adding a second backslash character to
> >   identify where the continuation begins and thereby able to handle
> >   cases not supported by the first strategy.  Both strategies use a
> >   self-describing header enabling automated reconstitution of the
> >   original content.
> > 
> > 
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/
> > 
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-06
> > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-artwork-folding-06
> > 
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-artwork-folding-06
> > 
> > 
> > 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-artwork-folding-06.txt

2019-06-27 Thread Kent Watsen

This update primarily regards the non-normative script:

- renamed to "rfcfold"
- now only uses sed one-liners
- auto-detects if platforms `[g]sed` and `pcregrep` are present and
   suitable, outputting an error message if not.
- cleans up the temporary directory if exits for any reason
- improved error message around the script not implementing the
  force-fold logic.

Special thanks to Eric Auerswald for supplying the pull requests 
for much of the above!


Outside the updates to the script:

- renamed 9.3:
  OLD: Example Showing Smart Folding
  NEW: Example Showing "Smart" Folding

- renamed Appendix A:
  OLD: POSIX Shell Script: rfcfold
  NEW: POSIX Shell Script


My only comments are:

1) the script itself doesn't name itself "rfcfold" anywhere.
- albeit, the "name" attribute in the XML is set to "rfcfold".

2) if the script is expected to be distributed, we may want/need to
add a copyright statement and/or a pointer to its GitHub repo.


Thanks,
Kent


> On Jun 27, 2019, at 5:20 PM, internet-dra...@ietf.org wrote:
> 
> 
> 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   : Handling Long Lines in Inclusions in Internet-Drafts 
> and RFCs
>Authors : Kent Watsen
>  Adrian Farrel
>  Qin Wu
>   Filename: draft-ietf-netmod-artwork-folding-06.txt
>   Pages   : 26
>   Date: 2019-06-27
> 
> Abstract:
>   This document defines two strategies for handling long lines in
>   width-bounded text content.  One strategy is based on the historic
>   use of a single backslash ('\') character to indicate where line-
>   folding has occurred, with the continuation occurring with the first
>   non-space (' ') character on the next line.  The second strategy
>   extends the first strategy by adding a second backslash character to
>   identify where the continuation begins and thereby able to handle
>   cases not supported by the first strategy.  Both strategies use a
>   self-describing header enabling automated reconstitution of the
>   original content.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-06
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-artwork-folding-06
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-artwork-folding-06
> 
> 
> 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] I-D Action: draft-ietf-netmod-artwork-folding-06.txt

2019-06-27 Thread 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   : Handling Long Lines in Inclusions in Internet-Drafts 
and RFCs
Authors : Kent Watsen
  Adrian Farrel
  Qin Wu
Filename: draft-ietf-netmod-artwork-folding-06.txt
Pages   : 26
Date: 2019-06-27

Abstract:
   This document defines two strategies for handling long lines in
   width-bounded text content.  One strategy is based on the historic
   use of a single backslash ('\') character to indicate where line-
   folding has occurred, with the continuation occurring with the first
   non-space (' ') character on the next line.  The second strategy
   extends the first strategy by adding a second backslash character to
   identify where the continuation begins and thereby able to handle
   cases not supported by the first strategy.  Both strategies use a
   self-describing header enabling automated reconstitution of the
   original content.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-06
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-artwork-folding-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-artwork-folding-06


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] 答复: FW: a question about ietf-hardware yang module

2019-06-27 Thread Juergen Schoenwaelder
On Thu, Jun 27, 2019 at 10:04:50PM +0200, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Thu, Jun 27, 2019 at 09:52:56PM +0200, Martin Bjorklund wrote:
> > > > Yes, good point, I think the phrase "by a different hardware
> > > > component" should be removed. It seems last-change should change when
> > > > I unplug a component and I plug it back shortly after, i.e., a
> > > > component is replaced by itself. So we have:
> > > > 
> > > > "The last time a new hardware component has been added to the
> > > >  '/hardware/component' list, or a hardware component has been
> > > >  removed from the '/hardware/component' list, or a hardware
> > > >  component in the '/hardware/component' list has been
> > > >  replaced."
> > > 
> > > I think that this is still not clear what it means that a component
> > > has been replaced.  Do you mean "replaced by a different hardware
> > > component"?
> > > 
> > > Otherwise (unplug then plug in the same component), the system either
> > > detects the removal and thus updates last-change, or it doesn't detect
> > > the quick removal/insertion, and then it can't do anything.  Thus, I
> > > don't think this case needs special treatment, and the text could be
> > > just:
> > > 
> > >  "The last time a new hardware component has been added to the
> > >   '/hardware/component' list, or a hardware component has been
> > >   removed from the '/hardware/component' list."
> > >
> > 
> > The question is whether every implementor will figure out that if the
> > component found in some slot x-y-z is different from what is expected
> > to be in slot x-y-z, this must be seen as a remove + add combination.
> > If we include 'replace', then it may be clearer that even in the case
> > where what is in slot x-y-z has changed, the last-change must be
> > updated. (That is, the list element with the same name still exists
> > but it is different from what was there before with the same name.)
> 
> But then we're back to where we started - what exactly does "different
> from what was there before" mean?  Presumably that some leaf's value
> is different...?
>

Go back some emails, I have removed the 'different' phrase.

/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


Re: [netmod] 答复: FW: a question about ietf-hardware yang module

2019-06-27 Thread Martin Bjorklund
Juergen Schoenwaelder  wrote:
> On Thu, Jun 27, 2019 at 09:52:56PM +0200, Martin Bjorklund wrote:
> > > Yes, good point, I think the phrase "by a different hardware
> > > component" should be removed. It seems last-change should change when
> > > I unplug a component and I plug it back shortly after, i.e., a
> > > component is replaced by itself. So we have:
> > > 
> > > "The last time a new hardware component has been added to the
> > >  '/hardware/component' list, or a hardware component has been
> > >  removed from the '/hardware/component' list, or a hardware
> > >  component in the '/hardware/component' list has been
> > >  replaced."
> > 
> > I think that this is still not clear what it means that a component
> > has been replaced.  Do you mean "replaced by a different hardware
> > component"?
> > 
> > Otherwise (unplug then plug in the same component), the system either
> > detects the removal and thus updates last-change, or it doesn't detect
> > the quick removal/insertion, and then it can't do anything.  Thus, I
> > don't think this case needs special treatment, and the text could be
> > just:
> > 
> >  "The last time a new hardware component has been added to the
> >   '/hardware/component' list, or a hardware component has been
> >   removed from the '/hardware/component' list."
> >
> 
> The question is whether every implementor will figure out that if the
> component found in some slot x-y-z is different from what is expected
> to be in slot x-y-z, this must be seen as a remove + add combination.
> If we include 'replace', then it may be clearer that even in the case
> where what is in slot x-y-z has changed, the last-change must be
> updated. (That is, the list element with the same name still exists
> but it is different from what was there before with the same name.)

But then we're back to where we started - what exactly does "different
from what was there before" mean?  Presumably that some leaf's value
is different...?


/martin

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


Re: [netmod] 答复: FW: a question about ietf-hardware yang module

2019-06-27 Thread Juergen Schoenwaelder
On Thu, Jun 27, 2019 at 09:52:56PM +0200, Martin Bjorklund wrote:
> > Yes, good point, I think the phrase "by a different hardware
> > component" should be removed. It seems last-change should change when
> > I unplug a component and I plug it back shortly after, i.e., a
> > component is replaced by itself. So we have:
> > 
> > "The last time a new hardware component has been added to the
> >  '/hardware/component' list, or a hardware component has been
> >  removed from the '/hardware/component' list, or a hardware
> >  component in the '/hardware/component' list has been
> >  replaced."
> 
> I think that this is still not clear what it means that a component
> has been replaced.  Do you mean "replaced by a different hardware
> component"?
> 
> Otherwise (unplug then plug in the same component), the system either
> detects the removal and thus updates last-change, or it doesn't detect
> the quick removal/insertion, and then it can't do anything.  Thus, I
> don't think this case needs special treatment, and the text could be
> just:
> 
>  "The last time a new hardware component has been added to the
>   '/hardware/component' list, or a hardware component has been
>   removed from the '/hardware/component' list."
>

The question is whether every implementor will figure out that if the
component found in some slot x-y-z is different from what is expected
to be in slot x-y-z, this must be seen as a remove + add combination.
If we include 'replace', then it may be clearer that even in the case
where what is in slot x-y-z has changed, the last-change must be
updated. (That is, the list element with the same name still exists
but it is different from what was there before with the same name.)

/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


Re: [netmod] 答复: FW: a question about ietf-hardware yang module

2019-06-27 Thread Martin Bjorklund
Juergen Schoenwaelder  wrote:
> On Thu, Jun 27, 2019 at 04:59:08PM +0200, Martin Bjorklund wrote:
> > 
> > Sounds reasonable.  But what exactly does "replaced by a different
> > component" mean?  Presumably it has the same name, but something else
> > is different.
> >
> 
> Yes, good point, I think the phrase "by a different hardware
> component" should be removed. It seems last-change should change when
> I unplug a component and I plug it back shortly after, i.e., a
> component is replaced by itself. So we have:
> 
> "The last time a new hardware component has been added to the
>  '/hardware/component' list, or a hardware component has been
>  removed from the '/hardware/component' list, or a hardware
>  component in the '/hardware/component' list has been
>  replaced."

I think that this is still not clear what it means that a component
has been replaced.  Do you mean "replaced by a different hardware
component"?

Otherwise (unplug then plug in the same component), the system either
detects the removal and thus updates last-change, or it doesn't detect
the quick removal/insertion, and then it can't do anything.  Thus, I
don't think this case needs special treatment, and the text could be
just:

 "The last time a new hardware component has been added to the
  '/hardware/component' list, or a hardware component has been
  removed from the '/hardware/component' list."


/martin

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


Re: [netmod] 答复: FW: a question about ietf-hardware yang module

2019-06-27 Thread Juergen Schoenwaelder
On Thu, Jun 27, 2019 at 04:59:08PM +0200, Martin Bjorklund wrote:
> 
> Sounds reasonable.  But what exactly does "replaced by a different
> component" mean?  Presumably it has the same name, but something else
> is different.
>

Yes, good point, I think the phrase "by a different hardware
component" should be removed. It seems last-change should change when
I unplug a component and I plug it back shortly after, i.e., a
component is replaced by itself. So we have:

"The last time a new hardware component has been added to the
 '/hardware/component' list, or a hardware component has been
 removed from the '/hardware/component' list, or a hardware
 component in the '/hardware/component' list has been
 replaced."

/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


Re: [netmod] 答复: FW: a question about ietf-hardware yang module

2019-06-27 Thread Martin Bjorklund
Juergen Schoenwaelder  wrote:
> On Thu, Jun 27, 2019 at 02:13:03AM +, Fengchong (frank) wrote:
> > > 
> > > I think the ambiguity is 'list changed' - does this mean that list 
> > > entries are added/removed or does it include also the case where a 
> > > property of a list entry has changed.
> > 
> > Ok.  Yes it is supposed to mean entry added/removed/modified.
> > 
> > But I can see another unclear thing - suppose I augment in an addtional 
> > leaf from my own model into this list.  Should last-change be updated if 
> > this new leaf is changed?
> > 
> 
> A reasonable interpretation in my view is that hardware/last-change is
> updated whenever
> 
> (1) a hardware component has been added
> (2) a hardware component has been removed
> (3) a hardware component has been replaced by a different hardware component
> 
> Here is an attempt for a new description:
> 
>  "The last time a new hardware component has been to the
   ^
added


>   '/hardware/component' list, or a hardware component has
> been removed from the '/hardware/component' list, or a
>   hardware component in the '/hardware/component' list has
>   been replaced by a different hardware component."
> 
> The point is to define this based on the events that cause the set of
> components to change instead of discussing leaf value changes.

Sounds reasonable.  But what exactly does "replaced by a different
component" mean?  Presumably it has the same name, but something else
is different.


/martin

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