Re: [netmod] Query about invalid XPATH paths in YANG

[William Ivory]

Hi Martin,

Thanks for the confirmation.

Regards,

William

-Original Message-
From: Martin Bjorklund [mailto:m...@tail-f.com] 
Sent: 23 January 2017 18:17
To: William Ivory 
Cc: netmod@ietf.org
Subject: Re: [netmod] Query about invalid XPATH paths in YANG

William Ivory  wrote:
> Hi,
> 
> I'd appreciate clarification on whether a YANG path in an XPATH 
> statement in a must or when statement must point to a valid YANG path 
> or not.  You might wonder why we'd have an invalid path (as opposed to 
> one that's simply not configured right now) but it is occasionally 
> helpful when sharing groupings.  (Possibly we should remodel the YANG 
> but that's another matter!).
> 
> As a simple example, is the following allowed?
> 
> Container foo {
> Leaf bar {
> Type string;
> Must "not(../nonExistentSiblingNode)";
> }
> }

Yes this is allowed.  Many YANG compilers give warnings for this kind of 
expression, but it is legal.

> I don't see that this should be any different to a must statement path 
> pointing to an unconfigured node, returning an empty nodeset in both 
> cases.
> 
> The reason I ask is that we are seeing a NETCONF client 
> differentiating between unconfigured (ok) and non-existent (error) 
> cases.  It would be useful to know one way or the other, ideally with 
> a pointer to the relevant part of the spec that makes this clear.

It follows from how XPath works, and the fact that there is no text in RFC 7950 
(or 6020) that limits XPath to something non-standard.


/martin

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

Re: [netmod] Query about invalid XPATH paths in YANG

[Martin Bjorklund]

William Ivory  wrote:
> Hi,
> 
> I'd appreciate clarification on whether a YANG path in an XPATH
> statement in a must or when statement must point to a valid YANG path
> or not.  You might wonder why we'd have an invalid path (as opposed to
> one that's simply not configured right now) but it is occasionally
> helpful when sharing groupings.  (Possibly we should remodel the YANG
> but that's another matter!).
> 
> As a simple example, is the following allowed?
> 
> Container foo {
> Leaf bar {
> Type string;
> Must "not(../nonExistentSiblingNode)";
> }
> }

Yes this is allowed.  Many YANG compilers give warnings for this kind
of expression, but it is legal.

> I don't see that this should be any different to a must statement path
> pointing to an unconfigured node, returning an empty nodeset in both
> cases.
> 
> The reason I ask is that we are seeing a NETCONF client
> differentiating between unconfigured (ok) and non-existent (error)
> cases.  It would be useful to know one way or the other, ideally with
> a pointer to the relevant part of the spec that makes this clear.

It follows from how XPath works, and the fact that there is no text in
RFC 7950 (or 6020) that limits XPath to something non-standard.


/martin

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

Re: [netmod] example modules in 6087bis

[Benoit Claise]

On 1/18/2017 7:00 PM, Andy Bierman wrote:



On Wed, Jan 18, 2017 at 9:12 AM, Benoit Claise > wrote:


Martin,

Hi,

It turns out that the recommendations on example modules are a bit
unclear.  Different drafts do very different things.  Some examples:


https://tools.ietf.org/html/draft-ietf-i2rs-yang-l3-topology-08#section-6.1.2



This example module really looks like a real module.  It uses an
IANA-controlled namespace, and the meta-statements indicate that this
is a normative modules.  But the module does not use the  tags.


https://tools.ietf.org/html/draft-ietf-netconf-restconf-18#appendix-C.1


This module is better, but it is written to follow RFC 6087 rules
(pass pyang --ietf), with the result that it contains a bit of "noise"

It takes a lot of YANG experience to be able to distinguish what
is noise or not. 

I agree.  I see Martin's point though -- maintenance clauses like 
contact and organization

are not really needed for examples.


with some meaningless descriptions and meta-statements.  It also does
not use  tags.


A good example (IMO) is found in
https://tools.ietf.org/html/rfc8022#appendix-C


It uses descriptions when necessary (high s/n), no fake
meta-statements etc.

However, it might be a good idea to require example modules to have a
"description" statement that explains what the module examplifies.
For example, the example-rip could have:

   description
 "This example module demonstrates how the core routing data model
  can be extended to support a new control-plane protocol.  It is
  intended as an illustration rather than a real definition of a
  data model for the Routing Information Protocol (RIP).";



I think that 6087bis is clear when it says:

   The guidelines in this document refer mainly to a normative complete
   module or submodule, but may be applicable to example modules and
   YANG fragments as well.

I think this states that example modules do not have to pass pyang
--ietf.


In order to make this more clear, I suggest the following changes to
draft-ietf-netmod-rfc6087bis-09

In the Terminology section 2.4:

NEW:

   o  Example module:  A complete YANG module or submodule that is
  intended to illustrate some specific aspect, but not intended for
  actual use.

It doesn't solve this issue, because
https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-09#section-4.2.1

says:

  The  convention SHOULD be used for complete example
  modules, but not YANG fragments.

That implies to me that we have 3 types: 1. _complete _example
modules => I read it that they must pass pyang -ietf, SHOULD have
 If there is , it's because people
will want to extract it, and play with it. So the tools chain must
work 2. the other example modules. No . I guess they
don't pass pyang 3. YANG fragments. No . I guess they
don't pass pyang In practice, 2 and 3 are the same. So we need
just two definition Scrap "complete" would help but that's not
enough:

  The  convention SHOULD be used for example
  modules, but not YANG fragments.

We only need to clarify 3 points , yes/no
pyang, yes/no pyang --ietf yes/no I guess we want, putting all

this together:

   o  Example module:  A complete YANG module or submodule that is
  intended to illustrate some specific aspect, but not intended for
  actual use. Example module MUST be valid according to RFC 7950,
  except when they are used to illustrate some illegal constructs.
  Example module MAY be valid according to the rules in this document.

   o  YANG fragment:  A incomplete YANG module or submodule that is
  intended to illustrate some specific aspect, but not intended for
  actual use. YANG fragments MUST be valid according to RFC 7950,
  except when they are used to illustrate some illegal constructs.

This is good
I prefer:
   - MUST use CODE BEGINS for a real module
   - MUST NOT use CODE BEGINS for an example module
   - MUST pass pyang --ietf for a real module
   - MUST pass pyang for example module
Fine with me. Consistency is key here. Is it time to conclude this 
discussion? Regards, Benoit
I have already received private emails about implementing the 
example-jukebox

module in RESTCONF as part of the standard.  We already have operational
experience that people can be confused by the example modules, and
think they are supposed to be implemented for RFC compliance.

  T

Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?

[Lou Berger]

I think we need something.  BTW I'm fine with obsoletes ;-)


On 1/23/2017 12:08 PM, Juergen Schoenwaelder wrote:
> Lou,
>
> RFC 7950 does not update anything in RFC 6020.
>
> In hindsight, the proper tag would have been 'Obsoletes: RFC 6020' but
> that was considered too 'aggressive' at that time and now it is too
> late to put it in.
>
> I suggest to leave it alone. People who simply google 'yang rfc' will
> hopefully find the latest version. ;-)
>
> /js
>
> On Mon, Jan 23, 2017 at 11:09:53AM -0500, Lou Berger wrote:
>> How do you feel about an errata on 1.0 that it should be considered to
>> be updated by 1.1?
>>
>> Lou
>>
>>
>> On 1/23/2017 6:08 AM, Benoit Claise wrote:
>>> On 1/23/2017 11:46 AM, Juergen Schoenwaelder wrote:
 Benoit,

 RFC 6020 is ambiguous and this is just how it is. The solution for
 YANG 1 is simply to give advice to module writers to avoid ambiguous
 character sequences (and avoiding ambiguity can be easily done).

 YANG 1.1 fixes the ambiguity in YANG 1 but backporting this fix to
 YANG 1 is a change of YANG 1, i.e., it might turn a conforming
 implementation into a non-conforming implementation. Hence, this may
 go beyond the scope of an errata.

 If tools generate proper warnings, I think we are fine and we do not
 need to change YANG 1. These kind of issues are caught by tools, not
 by humans reading language specifications.

 If you feel strongly that an errata is needed, then the errata should
 simply clearly spell out that certain backslahs sequences are
 ambiguous and provide advice that they should not be used.
>>> That would work.
>>> Can we modify the errata this way.
>>>
>>> Regards, Benoit
 This is
 backwards compatible. Making them illegal is not backwards compatible.

 /js

 PS: This is also my recollection of the discussion of issue Y06 when
  YANG 1.1 was put together.

 On Mon, Jan 23, 2017 at 11:29:25AM +0100, Benoit Claise wrote:
> Dear all,
>
> Let me summarize the situation.
>  - The RFC 6020 spec is clearly ambiguous.
>  - The solution is to use YANG 1.1
>  - RFC 7950 doesn't update or obsolete RFC 6020 (*)
>  - We should stop this problem from spreading further: updating 
> tooling
> is one good aspect, we should update the spec. too to at least warn the
> users.
>
> There is no perfect solution.
> Because of (*), I believe I should accept this errata.
> Any strong objections? If you have, propose a better plan. And I don't
> believe that "do nothing" is sufficient.
>
> Regarding the "update" solution, see the RFC 7950 writeup at 
> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/shepherdwriteup/
>
> (16) Will publication of this document change the status of any
> existing RFCs? Are those RFCs listed on the title page header, listed
> in the abstract, and discussed in the introduction? If the RFCs are 
> not
> listed in the Abstract and Introduction, explain why, and point to the
> part of the document where the relationship of this document to the
> other RFCs is discussed. If this information is not in the document,
> explain why the WG considers it unnecessary.
>
>No. YANG 1.0 [RFC6020] is not expected to change its status since
>there are data models on the standards-track that conform to YANG
>1.0. YANG 1.0 may be considered for retirement once all data models
>have naturally been updated to a future version of YANG.
>
> Regards, Benoit
>> The following errata report has been submitted for RFC6020,
>> "YANG - A Data Modeling Language for the Network Configuration Protocol 
>> (NETCONF)".
>>
>> --
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=4911
>>
>> --
>> Type: Technical
>> Reported by: Ladislav Lhotka 
>>
>> Section: 6.1.3
>>
>> Original Text
>> -
>> Within a double-quoted string (enclosed within " "), a backslash
>> character introduces a special character, which depends on the
>> character that immediately follows the backslash:
>>
>>\n  new line
>>\t  a tab character
>>\"  a double quote
>>\  a single backslash
>>
>>
>> Corrected Text
>> --
>> Within a double-quoted string (enclosed within " "), a backslash
>> character introduces a special character, which depends on the
>> character that immediately follows the backslash:
>>
>>\n  new line
>>\t  a tab character
>>\"  a double quote
>>\  a single backslash
>>
>> The backslash MUST NOT be followed by a

[netmod] Query about invalid XPATH paths in YANG

[William Ivory]

Hi,

I'd appreciate clarification on whether a YANG path in an XPATH statement in a 
must or when statement must point to a valid YANG path or not.  You might 
wonder why we'd have an invalid path (as opposed to one that's simply not 
configured right now) but it is occasionally helpful when sharing groupings.  
(Possibly we should remodel the YANG but that's another matter!).

As a simple example, is the following allowed?

Container foo {
Leaf bar {
Type string;
Must "not(../nonExistentSiblingNode)";
}
}

I don't see that this should be any different to a must statement path pointing 
to an unconfigured node, returning an empty nodeset in both cases.

The reason I ask is that we are seeing a NETCONF client differentiating between 
unconfigured (ok) and non-existent (error) cases.  It would be useful to know 
one way or the other, ideally with a pointer to the relevant part of the spec 
that makes this clear.

Thanks,

William

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

Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?

[Benoit Claise]

On 1/23/2017 5:26 PM, Ladislav Lhotka wrote:

On 23 Jan 2017, at 16:51, Robert Wilton  wrote:

I would suggest tweaking the order of the words slightly:

Old:

The interpretation of any other character then the ones listed above
following a backslash is undefined. Authors are advised to avoid using
such backslash sequences in double-quoted strings in their YANG
modules.

New:

The interpretation of any character other than the ones listed above
following a backslash is undefined. Authors are advised to avoid using
such backslash sequences in double-quoted strings in their YANG
modules.

+1

Otherwise I like the text.

Good.
Errata approved.

Regards, B.


Lada

  


Thanks,
Rob


On 23/01/2017 15:41, Benoit Claise wrote:

On 1/23/2017 4:33 PM, Martin Bjorklund wrote:

Benoit Claise  wrote:

On 1/23/2017 3:00 PM, Ladislav Lhotka wrote:

On 23 Jan 2017, at 14:39, Juergen Schoenwaelder
 wrote:

On Mon, Jan 23, 2017 at 01:37:30PM +0100, Ladislav Lhotka wrote:

Juergen Schoenwaelder  writes:


Benoit,

RFC 6020 is ambiguous and this is just how it is. The solution for
YANG 1 is simply to give advice to module writers to avoid ambiguous
character sequences (and avoiding ambiguity can be easily done).

YANG 1.1 fixes the ambiguity in YANG 1 but backporting this fix to
YANG 1 is a change of YANG 1, i.e., it might turn a conforming
implementation into a non-conforming implementation. Hence, this may
go beyond the scope of an errata.

But it is not really the case here because it cannot be decided what
conforming means. I chose YANG 1.1 behaviour for my JS parser, and I
don't think it is less conforming than any other.

Exactly. But other interpretations are legal as well. We can not
retroactively turn so far conforming implementations of the RFC into
non-conforming implementations (via an errata that introduces a MUST
that was not there in the beginning).


This would be fine for the "Notes" part but RFC Errata require also
"Original Text" and "Corrected Text". Any suggestion for this?

Corrected Text
-
Within a double-quoted string (enclosed within " "), a backslash
character introduces a special character, which depends on the
character that immediately follows the backslash:

\n  new line
\t  a tab character
\"  a double quote
\\  a single backslash

The interpretation of any other character then the ones listed above
following a backslash is undefined. Authors are advised to avoid using
such backslash sequences in double-quoted strings in their YANG
modules.

OK, this looks good. Benoit, will you first reject the existing
errata?

Instead of rejected, I modified the errata 4911.
A final check please before I approve it.
https://www.rfc-editor.org/errata_search.php?eid=4911

Hmm, I still just see the orignal errata text when I follow this link.

Now saved :-)

B.


/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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67





.



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

[netmod] [Errata Verified] RFC6020 (4911)

[RFC Errata System]

The following errata report has been verified for RFC6020,
"YANG - A Data Modeling Language for the Network Configuration Protocol 
(NETCONF)". 

--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=4911

--
Status: Verified
Type: Technical

Reported by: Ladislav Lhotka 
Date Reported: 2017-01-18
Verified by: Benoit Claise (IESG)

Section: 6.1.3

Original Text
-
Within a double-quoted string (enclosed within " "), a backslash
character introduces a special character, which depends on the
character that immediately follows the backslash:

 \n  new line
 \t  a tab character
 \"  a double quote
 \  a single backslash


Corrected Text
--
Within a double-quoted string (enclosed within " "), a backslash
character introduces a special character, which depends on the
character that immediately follows the backslash:

 \n  new line
 \t  a tab character
 \"  a double quote
 \  a single backslash


The interpretation of any character other than the ones listed above
following a backslash is undefined. Authors are advised to avoid using
such backslash sequences in double-quoted strings in their YANG
modules.

Notes
-
The text doesn't state whether other characters may follow the backslash, and 
if yes, what it means. Existing implementations have used three approaches:

1. report an error if another character follows the backslash
2. keep only the character following the backslash, i.e., for example, "\x" is 
the same as "x".
3. keep both the backslash and the character following it.

This ambiguity is undesirable and YANG 1.1 [RFC 7950] explicitly adopted option 
#1. However, many modules are still being written using YANG version 1.0, so it 
is important to clarify this issue in RFC 6020 as well.

--
RFC6020 (draft-ietf-netmod-yang-13)
--
Title   : YANG - A Data Modeling Language for the Network 
Configuration Protocol (NETCONF)
Publication Date: October 2010
Author(s)   : M. Bjorklund, Ed.
Category: PROPOSED STANDARD
Source  : NETCONF Data Modeling Language
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG

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

Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?

[Juergen Schoenwaelder]

Lou,

RFC 7950 does not update anything in RFC 6020.

In hindsight, the proper tag would have been 'Obsoletes: RFC 6020' but
that was considered too 'aggressive' at that time and now it is too
late to put it in.

I suggest to leave it alone. People who simply google 'yang rfc' will
hopefully find the latest version. ;-)

/js

On Mon, Jan 23, 2017 at 11:09:53AM -0500, Lou Berger wrote:
> How do you feel about an errata on 1.0 that it should be considered to
> be updated by 1.1?
> 
> Lou
> 
> 
> On 1/23/2017 6:08 AM, Benoit Claise wrote:
> > On 1/23/2017 11:46 AM, Juergen Schoenwaelder wrote:
> >> Benoit,
> >>
> >> RFC 6020 is ambiguous and this is just how it is. The solution for
> >> YANG 1 is simply to give advice to module writers to avoid ambiguous
> >> character sequences (and avoiding ambiguity can be easily done).
> >>
> >> YANG 1.1 fixes the ambiguity in YANG 1 but backporting this fix to
> >> YANG 1 is a change of YANG 1, i.e., it might turn a conforming
> >> implementation into a non-conforming implementation. Hence, this may
> >> go beyond the scope of an errata.
> >>
> >> If tools generate proper warnings, I think we are fine and we do not
> >> need to change YANG 1. These kind of issues are caught by tools, not
> >> by humans reading language specifications.
> >>
> >> If you feel strongly that an errata is needed, then the errata should
> >> simply clearly spell out that certain backslahs sequences are
> >> ambiguous and provide advice that they should not be used.
> > That would work.
> > Can we modify the errata this way.
> >
> > Regards, Benoit
> >> This is
> >> backwards compatible. Making them illegal is not backwards compatible.
> >>
> >> /js
> >>
> >> PS: This is also my recollection of the discussion of issue Y06 when
> >>  YANG 1.1 was put together.
> >>
> >> On Mon, Jan 23, 2017 at 11:29:25AM +0100, Benoit Claise wrote:
> >>> Dear all,
> >>>
> >>> Let me summarize the situation.
> >>>  - The RFC 6020 spec is clearly ambiguous.
> >>>  - The solution is to use YANG 1.1
> >>>  - RFC 7950 doesn't update or obsolete RFC 6020 (*)
> >>>  - We should stop this problem from spreading further: updating 
> >>> tooling
> >>> is one good aspect, we should update the spec. too to at least warn the
> >>> users.
> >>>
> >>> There is no perfect solution.
> >>> Because of (*), I believe I should accept this errata.
> >>> Any strong objections? If you have, propose a better plan. And I don't
> >>> believe that "do nothing" is sufficient.
> >>>
> >>> Regarding the "update" solution, see the RFC 7950 writeup at 
> >>> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/shepherdwriteup/
> >>>
> >>> (16) Will publication of this document change the status of any
> >>> existing RFCs? Are those RFCs listed on the title page header, listed
> >>> in the abstract, and discussed in the introduction? If the RFCs are 
> >>> not
> >>> listed in the Abstract and Introduction, explain why, and point to the
> >>> part of the document where the relationship of this document to the
> >>> other RFCs is discussed. If this information is not in the document,
> >>> explain why the WG considers it unnecessary.
> >>>
> >>>No. YANG 1.0 [RFC6020] is not expected to change its status since
> >>>there are data models on the standards-track that conform to YANG
> >>>1.0. YANG 1.0 may be considered for retirement once all data models
> >>>have naturally been updated to a future version of YANG.
> >>>
> >>> Regards, Benoit
>  The following errata report has been submitted for RFC6020,
>  "YANG - A Data Modeling Language for the Network Configuration Protocol 
>  (NETCONF)".
> 
>  --
>  You may review the report below and at:
>  http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=4911
> 
>  --
>  Type: Technical
>  Reported by: Ladislav Lhotka 
> 
>  Section: 6.1.3
> 
>  Original Text
>  -
>  Within a double-quoted string (enclosed within " "), a backslash
>  character introduces a special character, which depends on the
>  character that immediately follows the backslash:
> 
> \n  new line
> \t  a tab character
> \"  a double quote
> \  a single backslash
> 
> 
>  Corrected Text
>  --
>  Within a double-quoted string (enclosed within " "), a backslash
>  character introduces a special character, which depends on the
>  character that immediately follows the backslash:
> 
> \n  new line
> \t  a tab character
> \"  a double quote
> \  a single backslash
> 
>  The backslash MUST NOT be followed by any other character.
> 
>  Notes
>  -
>  The text doesn't state whether other characters may follow the 
>  backslash,

Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?

[Ladislav Lhotka]

> On 23 Jan 2017, at 16:51, Robert Wilton  wrote:
> 
> I would suggest tweaking the order of the words slightly:
> 
> Old:
> 
> The interpretation of any other character then the ones listed above
> following a backslash is undefined. Authors are advised to avoid using
> such backslash sequences in double-quoted strings in their YANG
> modules. 
> 
> New:
> 
> The interpretation of any character other than the ones listed above
> following a backslash is undefined. Authors are advised to avoid using
> such backslash sequences in double-quoted strings in their YANG
> modules.

+1

Otherwise I like the text.

Lada

>  
> 
> Thanks,
> Rob
> 
> 
> On 23/01/2017 15:41, Benoit Claise wrote:
>> On 1/23/2017 4:33 PM, Martin Bjorklund wrote: 
>>> Benoit Claise  wrote: 
 On 1/23/2017 3:00 PM, Ladislav Lhotka wrote: 
>> On 23 Jan 2017, at 14:39, Juergen Schoenwaelder 
>>  wrote: 
>> 
>> On Mon, Jan 23, 2017 at 01:37:30PM +0100, Ladislav Lhotka wrote: 
>>> Juergen Schoenwaelder  writes: 
>>> 
 Benoit, 
 
 RFC 6020 is ambiguous and this is just how it is. The solution for 
 YANG 1 is simply to give advice to module writers to avoid ambiguous 
 character sequences (and avoiding ambiguity can be easily done). 
 
 YANG 1.1 fixes the ambiguity in YANG 1 but backporting this fix to 
 YANG 1 is a change of YANG 1, i.e., it might turn a conforming 
 implementation into a non-conforming implementation. Hence, this may 
 go beyond the scope of an errata. 
>>> But it is not really the case here because it cannot be decided what 
>>> conforming means. I chose YANG 1.1 behaviour for my JS parser, and I 
>>> don't think it is less conforming than any other. 
>> Exactly. But other interpretations are legal as well. We can not 
>> retroactively turn so far conforming implementations of the RFC into 
>> non-conforming implementations (via an errata that introduces a MUST 
>> that was not there in the beginning). 
>> 
>>> This would be fine for the "Notes" part but RFC Errata require also 
>>> "Original Text" and "Corrected Text". Any suggestion for this? 
>> Corrected Text 
>> - 
>> Within a double-quoted string (enclosed within " "), a backslash 
>> character introduces a special character, which depends on the 
>> character that immediately follows the backslash: 
>> 
>>\n  new line 
>>\t  a tab character 
>>\"  a double quote 
>>\\  a single backslash 
>> 
>> The interpretation of any other character then the ones listed above 
>> following a backslash is undefined. Authors are advised to avoid using 
>> such backslash sequences in double-quoted strings in their YANG 
>> modules. 
> OK, this looks good. Benoit, will you first reject the existing 
> errata? 
 Instead of rejected, I modified the errata 4911. 
 A final check please before I approve it. 
 https://www.rfc-editor.org/errata_search.php?eid=4911 
>>> Hmm, I still just see the orignal errata text when I follow this link. 
>> Now saved :-) 
>> 
>> B. 
>>> 
>>> 
>>> /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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67





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

Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?

[Lou Berger]

How do you feel about an errata on 1.0 that it should be considered to
be updated by 1.1?

Lou


On 1/23/2017 6:08 AM, Benoit Claise wrote:
> On 1/23/2017 11:46 AM, Juergen Schoenwaelder wrote:
>> Benoit,
>>
>> RFC 6020 is ambiguous and this is just how it is. The solution for
>> YANG 1 is simply to give advice to module writers to avoid ambiguous
>> character sequences (and avoiding ambiguity can be easily done).
>>
>> YANG 1.1 fixes the ambiguity in YANG 1 but backporting this fix to
>> YANG 1 is a change of YANG 1, i.e., it might turn a conforming
>> implementation into a non-conforming implementation. Hence, this may
>> go beyond the scope of an errata.
>>
>> If tools generate proper warnings, I think we are fine and we do not
>> need to change YANG 1. These kind of issues are caught by tools, not
>> by humans reading language specifications.
>>
>> If you feel strongly that an errata is needed, then the errata should
>> simply clearly spell out that certain backslahs sequences are
>> ambiguous and provide advice that they should not be used.
> That would work.
> Can we modify the errata this way.
>
> Regards, Benoit
>> This is
>> backwards compatible. Making them illegal is not backwards compatible.
>>
>> /js
>>
>> PS: This is also my recollection of the discussion of issue Y06 when
>>  YANG 1.1 was put together.
>>
>> On Mon, Jan 23, 2017 at 11:29:25AM +0100, Benoit Claise wrote:
>>> Dear all,
>>>
>>> Let me summarize the situation.
>>>  - The RFC 6020 spec is clearly ambiguous.
>>>  - The solution is to use YANG 1.1
>>>  - RFC 7950 doesn't update or obsolete RFC 6020 (*)
>>>  - We should stop this problem from spreading further: updating tooling
>>> is one good aspect, we should update the spec. too to at least warn the
>>> users.
>>>
>>> There is no perfect solution.
>>> Because of (*), I believe I should accept this errata.
>>> Any strong objections? If you have, propose a better plan. And I don't
>>> believe that "do nothing" is sufficient.
>>>
>>> Regarding the "update" solution, see the RFC 7950 writeup at 
>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/shepherdwriteup/
>>>
>>> (16) Will publication of this document change the status of any
>>> existing RFCs? Are those RFCs listed on the title page header, listed
>>> in the abstract, and discussed in the introduction? If the RFCs are not
>>> listed in the Abstract and Introduction, explain why, and point to the
>>> part of the document where the relationship of this document to the
>>> other RFCs is discussed. If this information is not in the document,
>>> explain why the WG considers it unnecessary.
>>>
>>>No. YANG 1.0 [RFC6020] is not expected to change its status since
>>>there are data models on the standards-track that conform to YANG
>>>1.0. YANG 1.0 may be considered for retirement once all data models
>>>have naturally been updated to a future version of YANG.
>>>
>>> Regards, Benoit
 The following errata report has been submitted for RFC6020,
 "YANG - A Data Modeling Language for the Network Configuration Protocol 
 (NETCONF)".

 --
 You may review the report below and at:
 http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=4911

 --
 Type: Technical
 Reported by: Ladislav Lhotka 

 Section: 6.1.3

 Original Text
 -
 Within a double-quoted string (enclosed within " "), a backslash
 character introduces a special character, which depends on the
 character that immediately follows the backslash:

\n  new line
\t  a tab character
\"  a double quote
\  a single backslash


 Corrected Text
 --
 Within a double-quoted string (enclosed within " "), a backslash
 character introduces a special character, which depends on the
 character that immediately follows the backslash:

\n  new line
\t  a tab character
\"  a double quote
\  a single backslash

 The backslash MUST NOT be followed by any other character.

 Notes
 -
 The text doesn't state whether other characters may follow the backslash, 
 and if yes, what it means. Existing implementations have used three 
 approaches:

 1. report an error if another character follows the backslash
 2. keep only the character following the backslash, i.e., for example, 
 "\x" is the same as "x".
 3. keep both the backslash and the character following it.

 This ambiguity is undesirable and YANG 1.1 [RFC 7950] explicitly adopted 
 option #1. However, many modules are still being written using YANG 
 version 1.0, so it is important to clarify this issue in RFC 6020 as well.

 Instructions:
 -
 This erratum i

Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?

[Robert Wilton]

I would suggest tweaking the order of the words slightly:

Old:

The interpretation of any *other character then* the ones listed above
following a backslash is undefined. Authors are advised to avoid using
such backslash sequences in double-quoted strings in their YANG
modules.

New:

The interpretation of any *character other than* the ones listed above
following a backslash is undefined. Authors are advised to avoid using
such backslash sequences in double-quoted strings in their YANG
modules.

Thanks,
Rob


On 23/01/2017 15:41, Benoit Claise wrote:

On 1/23/2017 4:33 PM, Martin Bjorklund wrote:

Benoit Claise  wrote:

On 1/23/2017 3:00 PM, Ladislav Lhotka wrote:

On 23 Jan 2017, at 14:39, Juergen Schoenwaelder
 wrote:

On Mon, Jan 23, 2017 at 01:37:30PM +0100, Ladislav Lhotka wrote:

Juergen Schoenwaelder  writes:


Benoit,

RFC 6020 is ambiguous and this is just how it is. The solution for
YANG 1 is simply to give advice to module writers to avoid 
ambiguous

character sequences (and avoiding ambiguity can be easily done).

YANG 1.1 fixes the ambiguity in YANG 1 but backporting this fix to
YANG 1 is a change of YANG 1, i.e., it might turn a conforming
implementation into a non-conforming implementation. Hence, this 
may

go beyond the scope of an errata.

But it is not really the case here because it cannot be decided what
conforming means. I chose YANG 1.1 behaviour for my JS parser, and I
don't think it is less conforming than any other.

Exactly. But other interpretations are legal as well. We can not
retroactively turn so far conforming implementations of the RFC into
non-conforming implementations (via an errata that introduces a MUST
that was not there in the beginning).


This would be fine for the "Notes" part but RFC Errata require also
"Original Text" and "Corrected Text". Any suggestion for this?

Corrected Text
-
Within a double-quoted string (enclosed within " "), a backslash
character introduces a special character, which depends on the
character that immediately follows the backslash:

   \n  new line
   \t  a tab character
   \"  a double quote
   \\  a single backslash

The interpretation of any other character then the ones listed above
following a backslash is undefined. Authors are advised to avoid 
using

such backslash sequences in double-quoted strings in their YANG
modules.

OK, this looks good. Benoit, will you first reject the existing
errata?

Instead of rejected, I modified the errata 4911.
A final check please before I approve it.
https://www.rfc-editor.org/errata_search.php?eid=4911

Hmm, I still just see the orignal errata text when I follow this link.

Now saved :-)

B.



/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] [Technical Errata Reported] RFC6020 (4911) - what next?

[Benoit Claise]

On 1/23/2017 4:33 PM, Martin Bjorklund wrote:

Benoit Claise  wrote:

On 1/23/2017 3:00 PM, Ladislav Lhotka wrote:

On 23 Jan 2017, at 14:39, Juergen Schoenwaelder
 wrote:

On Mon, Jan 23, 2017 at 01:37:30PM +0100, Ladislav Lhotka wrote:

Juergen Schoenwaelder  writes:


Benoit,

RFC 6020 is ambiguous and this is just how it is. The solution for
YANG 1 is simply to give advice to module writers to avoid ambiguous
character sequences (and avoiding ambiguity can be easily done).

YANG 1.1 fixes the ambiguity in YANG 1 but backporting this fix to
YANG 1 is a change of YANG 1, i.e., it might turn a conforming
implementation into a non-conforming implementation. Hence, this may
go beyond the scope of an errata.

But it is not really the case here because it cannot be decided what
conforming means. I chose YANG 1.1 behaviour for my JS parser, and I
don't think it is less conforming than any other.

Exactly. But other interpretations are legal as well. We can not
retroactively turn so far conforming implementations of the RFC into
non-conforming implementations (via an errata that introduces a MUST
that was not there in the beginning).


This would be fine for the "Notes" part but RFC Errata require also
"Original Text" and "Corrected Text". Any suggestion for this?

Corrected Text
-
Within a double-quoted string (enclosed within " "), a backslash
character introduces a special character, which depends on the
character that immediately follows the backslash:

   \n  new line
   \t  a tab character
   \"  a double quote
   \\  a single backslash

The interpretation of any other character then the ones listed above
following a backslash is undefined. Authors are advised to avoid using
such backslash sequences in double-quoted strings in their YANG
modules.

OK, this looks good. Benoit, will you first reject the existing
errata?

Instead of rejected, I modified the errata 4911.
A final check please before I approve it.
https://www.rfc-editor.org/errata_search.php?eid=4911

Hmm, I still just see the orignal errata text when I follow this link.

Now saved :-)

B.



/martin
.



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

Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?

[Martin Bjorklund]

Benoit Claise  wrote:
> On 1/23/2017 3:00 PM, Ladislav Lhotka wrote:
> >> On 23 Jan 2017, at 14:39, Juergen Schoenwaelder
> >>  wrote:
> >>
> >> On Mon, Jan 23, 2017 at 01:37:30PM +0100, Ladislav Lhotka wrote:
> >>> Juergen Schoenwaelder  writes:
> >>>
>  Benoit,
> 
>  RFC 6020 is ambiguous and this is just how it is. The solution for
>  YANG 1 is simply to give advice to module writers to avoid ambiguous
>  character sequences (and avoiding ambiguity can be easily done).
> 
>  YANG 1.1 fixes the ambiguity in YANG 1 but backporting this fix to
>  YANG 1 is a change of YANG 1, i.e., it might turn a conforming
>  implementation into a non-conforming implementation. Hence, this may
>  go beyond the scope of an errata.
> >>> But it is not really the case here because it cannot be decided what
> >>> conforming means. I chose YANG 1.1 behaviour for my JS parser, and I
> >>> don't think it is less conforming than any other.
> >> Exactly. But other interpretations are legal as well. We can not
> >> retroactively turn so far conforming implementations of the RFC into
> >> non-conforming implementations (via an errata that introduces a MUST
> >> that was not there in the beginning).
> >>
> >>> This would be fine for the "Notes" part but RFC Errata require also
> >>> "Original Text" and "Corrected Text". Any suggestion for this?
> >> Corrected Text
> >> -
> >> Within a double-quoted string (enclosed within " "), a backslash
> >> character introduces a special character, which depends on the
> >> character that immediately follows the backslash:
> >>
> >>   \n  new line
> >>   \t  a tab character
> >>   \"  a double quote
> >>   \\  a single backslash
> >>
> >> The interpretation of any other character then the ones listed above
> >> following a backslash is undefined. Authors are advised to avoid using
> >> such backslash sequences in double-quoted strings in their YANG
> >> modules.
> > OK, this looks good. Benoit, will you first reject the existing
> > errata?
> Instead of rejected, I modified the errata 4911.
> A final check please before I approve it.
> https://www.rfc-editor.org/errata_search.php?eid=4911

Hmm, I still just see the orignal errata text when I follow this link.


/martin

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

Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?

[Benoit Claise]

On 1/23/2017 3:00 PM, Ladislav Lhotka wrote:

On 23 Jan 2017, at 14:39, Juergen Schoenwaelder 
 wrote:

On Mon, Jan 23, 2017 at 01:37:30PM +0100, Ladislav Lhotka wrote:

Juergen Schoenwaelder  writes:


Benoit,

RFC 6020 is ambiguous and this is just how it is. The solution for
YANG 1 is simply to give advice to module writers to avoid ambiguous
character sequences (and avoiding ambiguity can be easily done).

YANG 1.1 fixes the ambiguity in YANG 1 but backporting this fix to
YANG 1 is a change of YANG 1, i.e., it might turn a conforming
implementation into a non-conforming implementation. Hence, this may
go beyond the scope of an errata.

But it is not really the case here because it cannot be decided what
conforming means. I chose YANG 1.1 behaviour for my JS parser, and I
don't think it is less conforming than any other.

Exactly. But other interpretations are legal as well. We can not
retroactively turn so far conforming implementations of the RFC into
non-conforming implementations (via an errata that introduces a MUST
that was not there in the beginning).


This would be fine for the "Notes" part but RFC Errata require also
"Original Text" and "Corrected Text". Any suggestion for this?

Corrected Text
-
Within a double-quoted string (enclosed within " "), a backslash
character introduces a special character, which depends on the
character that immediately follows the backslash:

  \n  new line
  \t  a tab character
  \"  a double quote
  \\  a single backslash

The interpretation of any other character then the ones listed above
following a backslash is undefined. Authors are advised to avoid using
such backslash sequences in double-quoted strings in their YANG
modules.

OK, this looks good. Benoit, will you first reject the existing errata?

Instead of rejected, I modified the errata 4911.
A final check please before I approve it.
https://www.rfc-editor.org/errata_search.php?eid=4911

Regards, Benoit



Lada


/js

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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67





.



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

Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?

[Ladislav Lhotka]

> On 23 Jan 2017, at 14:39, Juergen Schoenwaelder 
>  wrote:
> 
> On Mon, Jan 23, 2017 at 01:37:30PM +0100, Ladislav Lhotka wrote:
>> Juergen Schoenwaelder  writes:
>> 
>>> Benoit,
>>> 
>>> RFC 6020 is ambiguous and this is just how it is. The solution for
>>> YANG 1 is simply to give advice to module writers to avoid ambiguous
>>> character sequences (and avoiding ambiguity can be easily done).
>>> 
>>> YANG 1.1 fixes the ambiguity in YANG 1 but backporting this fix to
>>> YANG 1 is a change of YANG 1, i.e., it might turn a conforming
>>> implementation into a non-conforming implementation. Hence, this may
>>> go beyond the scope of an errata.
>> 
>> But it is not really the case here because it cannot be decided what
>> conforming means. I chose YANG 1.1 behaviour for my JS parser, and I
>> don't think it is less conforming than any other.
> 
> Exactly. But other interpretations are legal as well. We can not
> retroactively turn so far conforming implementations of the RFC into
> non-conforming implementations (via an errata that introduces a MUST
> that was not there in the beginning).
> 
>> This would be fine for the "Notes" part but RFC Errata require also
>> "Original Text" and "Corrected Text". Any suggestion for this?
> 
> Corrected Text
> -
> Within a double-quoted string (enclosed within " "), a backslash
> character introduces a special character, which depends on the
> character that immediately follows the backslash:
> 
>  \n  new line
>  \t  a tab character
>  \"  a double quote
>  \\  a single backslash
> 
> The interpretation of any other character then the ones listed above
> following a backslash is undefined. Authors are advised to avoid using
> such backslash sequences in double-quoted strings in their YANG
> modules.

OK, this looks good. Benoit, will you first reject the existing errata?

Lada

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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67





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

Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?

[Juergen Schoenwaelder]

On Mon, Jan 23, 2017 at 01:37:30PM +0100, Ladislav Lhotka wrote:
> Juergen Schoenwaelder  writes:
> 
> > Benoit,
> >
> > RFC 6020 is ambiguous and this is just how it is. The solution for
> > YANG 1 is simply to give advice to module writers to avoid ambiguous
> > character sequences (and avoiding ambiguity can be easily done).
> >
> > YANG 1.1 fixes the ambiguity in YANG 1 but backporting this fix to
> > YANG 1 is a change of YANG 1, i.e., it might turn a conforming
> > implementation into a non-conforming implementation. Hence, this may
> > go beyond the scope of an errata.
> 
> But it is not really the case here because it cannot be decided what
> conforming means. I chose YANG 1.1 behaviour for my JS parser, and I
> don't think it is less conforming than any other.

Exactly. But other interpretations are legal as well. We can not
retroactively turn so far conforming implementations of the RFC into
non-conforming implementations (via an errata that introduces a MUST
that was not there in the beginning).

> This would be fine for the "Notes" part but RFC Errata require also
> "Original Text" and "Corrected Text". Any suggestion for this?
 
Corrected Text
-
Within a double-quoted string (enclosed within " "), a backslash
character introduces a special character, which depends on the
character that immediately follows the backslash:

  \n  new line
  \t  a tab character
  \"  a double quote
  \\  a single backslash

The interpretation of any other character then the ones listed above
following a backslash is undefined. Authors are advised to avoid using
such backslash sequences in double-quoted strings in their YANG
modules.

/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] [Technical Errata Reported] RFC6020 (4911) - what next?

[Ladislav Lhotka]

Juergen Schoenwaelder  writes:

> Benoit,
>
> RFC 6020 is ambiguous and this is just how it is. The solution for
> YANG 1 is simply to give advice to module writers to avoid ambiguous
> character sequences (and avoiding ambiguity can be easily done).
>
> YANG 1.1 fixes the ambiguity in YANG 1 but backporting this fix to
> YANG 1 is a change of YANG 1, i.e., it might turn a conforming
> implementation into a non-conforming implementation. Hence, this may
> go beyond the scope of an errata.

But it is not really the case here because it cannot be decided what
conforming means. I chose YANG 1.1 behaviour for my JS parser, and I
don't think it is less conforming than any other.

>
> If tools generate proper warnings, I think we are fine and we do not
> need to change YANG 1. These kind of issues are caught by tools, not
> by humans reading language specifications.
>
> If you feel strongly that an errata is needed, then the errata should
> simply clearly spell out that certain backslahs sequences are
> ambiguous and provide advice that they should not be used. This is
> backwards compatible. Making them illegal is not backwards compatible.

This would be fine for the "Notes" part but RFC Errata require also
"Original Text" and "Corrected Text". Any suggestion for this?

Lada

>
> /js
>
> PS: This is also my recollection of the discussion of issue Y06 when
> YANG 1.1 was put together.
>
> On Mon, Jan 23, 2017 at 11:29:25AM +0100, Benoit Claise wrote:
>> Dear all,
>> 
>> Let me summarize the situation.
>> - The RFC 6020 spec is clearly ambiguous.
>> - The solution is to use YANG 1.1
>> - RFC 7950 doesn't update or obsolete RFC 6020 (*)
>> - We should stop this problem from spreading further: updating tooling
>> is one good aspect, we should update the spec. too to at least warn the
>> users.
>> 
>> There is no perfect solution.
>> Because of (*), I believe I should accept this errata.
>> Any strong objections? If you have, propose a better plan. And I don't
>> believe that "do nothing" is sufficient.
>> 
>> Regarding the "update" solution, see the RFC 7950 writeup at 
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/shepherdwriteup/
>> 
>>(16) Will publication of this document change the status of any
>>existing RFCs? Are those RFCs listed on the title page header, listed
>>in the abstract, and discussed in the introduction? If the RFCs are not
>>listed in the Abstract and Introduction, explain why, and point to the
>>part of the document where the relationship of this document to the
>>other RFCs is discussed. If this information is not in the document,
>>explain why the WG considers it unnecessary.
>> 
>>   No. YANG 1.0 [RFC6020] is not expected to change its status since
>>   there are data models on the standards-track that conform to YANG
>>   1.0. YANG 1.0 may be considered for retirement once all data models
>>   have naturally been updated to a future version of YANG.
>> 
>> Regards, Benoit
>> > The following errata report has been submitted for RFC6020,
>> > "YANG - A Data Modeling Language for the Network Configuration Protocol 
>> > (NETCONF)".
>> > 
>> > --
>> > You may review the report below and at:
>> > http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=4911
>> > 
>> > --
>> > Type: Technical
>> > Reported by: Ladislav Lhotka 
>> > 
>> > Section: 6.1.3
>> > 
>> > Original Text
>> > -
>> > Within a double-quoted string (enclosed within " "), a backslash
>> > character introduces a special character, which depends on the
>> > character that immediately follows the backslash:
>> > 
>> >   \n  new line
>> >   \t  a tab character
>> >   \"  a double quote
>> >   \  a single backslash
>> > 
>> > 
>> > Corrected Text
>> > --
>> > Within a double-quoted string (enclosed within " "), a backslash
>> > character introduces a special character, which depends on the
>> > character that immediately follows the backslash:
>> > 
>> >   \n  new line
>> >   \t  a tab character
>> >   \"  a double quote
>> >   \  a single backslash
>> > 
>> > The backslash MUST NOT be followed by any other character.
>> > 
>> > Notes
>> > -
>> > The text doesn't state whether other characters may follow the backslash, 
>> > and if yes, what it means. Existing implementations have used three 
>> > approaches:
>> > 
>> > 1. report an error if another character follows the backslash
>> > 2. keep only the character following the backslash, i.e., for example, 
>> > "\x" is the same as "x".
>> > 3. keep both the backslash and the character following it.
>> > 
>> > This ambiguity is undesirable and YANG 1.1 [RFC 7950] explicitly adopted 
>> > option #1. However, many modules are still being written using YANG 
>> > version 1.0, so it is important to clarify this issue in RFC 6020 as well.
>> > 
>> > Instructions:
>> > 

Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?

[Benoit Claise]

On 1/23/2017 11:46 AM, Juergen Schoenwaelder wrote:

Benoit,

RFC 6020 is ambiguous and this is just how it is. The solution for
YANG 1 is simply to give advice to module writers to avoid ambiguous
character sequences (and avoiding ambiguity can be easily done).

YANG 1.1 fixes the ambiguity in YANG 1 but backporting this fix to
YANG 1 is a change of YANG 1, i.e., it might turn a conforming
implementation into a non-conforming implementation. Hence, this may
go beyond the scope of an errata.

If tools generate proper warnings, I think we are fine and we do not
need to change YANG 1. These kind of issues are caught by tools, not
by humans reading language specifications.

If you feel strongly that an errata is needed, then the errata should
simply clearly spell out that certain backslahs sequences are
ambiguous and provide advice that they should not be used.

That would work.
Can we modify the errata this way.

Regards, Benoit

This is
backwards compatible. Making them illegal is not backwards compatible.

/js

PS: This is also my recollection of the discussion of issue Y06 when
 YANG 1.1 was put together.

On Mon, Jan 23, 2017 at 11:29:25AM +0100, Benoit Claise wrote:

Dear all,

Let me summarize the situation.
 - The RFC 6020 spec is clearly ambiguous.
 - The solution is to use YANG 1.1
 - RFC 7950 doesn't update or obsolete RFC 6020 (*)
 - We should stop this problem from spreading further: updating tooling
is one good aspect, we should update the spec. too to at least warn the
users.

There is no perfect solution.
Because of (*), I believe I should accept this errata.
Any strong objections? If you have, propose a better plan. And I don't
believe that "do nothing" is sufficient.

Regarding the "update" solution, see the RFC 7950 writeup at 
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/shepherdwriteup/

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

   No. YANG 1.0 [RFC6020] is not expected to change its status since
   there are data models on the standards-track that conform to YANG
   1.0. YANG 1.0 may be considered for retirement once all data models
   have naturally been updated to a future version of YANG.

Regards, Benoit

The following errata report has been submitted for RFC6020,
"YANG - A Data Modeling Language for the Network Configuration Protocol 
(NETCONF)".

--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=4911

--
Type: Technical
Reported by: Ladislav Lhotka 

Section: 6.1.3

Original Text
-
Within a double-quoted string (enclosed within " "), a backslash
character introduces a special character, which depends on the
character that immediately follows the backslash:

   \n  new line
   \t  a tab character
   \"  a double quote
   \  a single backslash


Corrected Text
--
Within a double-quoted string (enclosed within " "), a backslash
character introduces a special character, which depends on the
character that immediately follows the backslash:

   \n  new line
   \t  a tab character
   \"  a double quote
   \  a single backslash

The backslash MUST NOT be followed by any other character.

Notes
-
The text doesn't state whether other characters may follow the backslash, and 
if yes, what it means. Existing implementations have used three approaches:

1. report an error if another character follows the backslash
2. keep only the character following the backslash, i.e., for example, "\x" is the same 
as "x".
3. keep both the backslash and the character following it.

This ambiguity is undesirable and YANG 1.1 [RFC 7950] explicitly adopted option 
#1. However, many modules are still being written using YANG version 1.0, so it 
is important to clarify this issue in RFC 6020 as well.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--
RFC6020 (draft-ietf-netmod-yang-13)
--
Title   : YANG - A Data Modeling Language for the Network 
Configuration Protocol (NETCONF)
Publication Date: October 2010
Author(s)   : M. Bjorklund, Ed.
Category: PROPOSED STANDARD
Source  : NETCONF Data Mod

Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?

[Martin Bjorklund]

Hi,

I agree with what Juergen writes below.

Also, if we *really* wanted to change RFC 6020 in this regard (which I
don't think we should!), I think the change should be the equivalent
of Y06-01:

  Clarify that "\x" means the two characters '\' and 'x', i.e.,
  "\x" is equivalent to '\x'.

  This is how several known implementations have interpreted the text.

I think that this was the original intention of the text.  (Yes, I
know that there are issues with this design, but that's not the point
here).


/martin


Juergen Schoenwaelder  wrote:
> Benoit,
> 
> RFC 6020 is ambiguous and this is just how it is. The solution for
> YANG 1 is simply to give advice to module writers to avoid ambiguous
> character sequences (and avoiding ambiguity can be easily done).
> 
> YANG 1.1 fixes the ambiguity in YANG 1 but backporting this fix to
> YANG 1 is a change of YANG 1, i.e., it might turn a conforming
> implementation into a non-conforming implementation. Hence, this may
> go beyond the scope of an errata.
> 
> If tools generate proper warnings, I think we are fine and we do not
> need to change YANG 1. These kind of issues are caught by tools, not
> by humans reading language specifications.
> 
> If you feel strongly that an errata is needed, then the errata should
> simply clearly spell out that certain backslahs sequences are
> ambiguous and provide advice that they should not be used. This is
> backwards compatible. Making them illegal is not backwards compatible.
> 
> /js
> 
> PS: This is also my recollection of the discussion of issue Y06 when
> YANG 1.1 was put together.
> 
> On Mon, Jan 23, 2017 at 11:29:25AM +0100, Benoit Claise wrote:
> > Dear all,
> > 
> > Let me summarize the situation.
> > - The RFC 6020 spec is clearly ambiguous.
> > - The solution is to use YANG 1.1
> > - RFC 7950 doesn't update or obsolete RFC 6020 (*)
> > - We should stop this problem from spreading further: updating tooling
> > is one good aspect, we should update the spec. too to at least warn the
> > users.
> > 
> > There is no perfect solution.
> > Because of (*), I believe I should accept this errata.
> > Any strong objections? If you have, propose a better plan. And I don't
> > believe that "do nothing" is sufficient.
> > 
> > Regarding the "update" solution, see the RFC 7950 writeup at 
> > https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/shepherdwriteup/
> > 
> >(16) Will publication of this document change the status of any
> >existing RFCs? Are those RFCs listed on the title page header, listed
> >in the abstract, and discussed in the introduction? If the RFCs are not
> >listed in the Abstract and Introduction, explain why, and point to the
> >part of the document where the relationship of this document to the
> >other RFCs is discussed. If this information is not in the document,
> >explain why the WG considers it unnecessary.
> > 
> >   No. YANG 1.0 [RFC6020] is not expected to change its status since
> >   there are data models on the standards-track that conform to YANG
> >   1.0. YANG 1.0 may be considered for retirement once all data models
> >   have naturally been updated to a future version of YANG.
> > 
> > Regards, Benoit
> > > The following errata report has been submitted for RFC6020,
> > > "YANG - A Data Modeling Language for the Network Configuration Protocol 
> > > (NETCONF)".
> > > 
> > > --
> > > You may review the report below and at:
> > > http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=4911
> > > 
> > > --
> > > Type: Technical
> > > Reported by: Ladislav Lhotka 
> > > 
> > > Section: 6.1.3
> > > 
> > > Original Text
> > > -
> > > Within a double-quoted string (enclosed within " "), a backslash
> > > character introduces a special character, which depends on the
> > > character that immediately follows the backslash:
> > > 
> > >   \n  new line
> > >   \t  a tab character
> > >   \"  a double quote
> > >   \  a single backslash
> > > 
> > > 
> > > Corrected Text
> > > --
> > > Within a double-quoted string (enclosed within " "), a backslash
> > > character introduces a special character, which depends on the
> > > character that immediately follows the backslash:
> > > 
> > >   \n  new line
> > >   \t  a tab character
> > >   \"  a double quote
> > >   \  a single backslash
> > > 
> > > The backslash MUST NOT be followed by any other character.
> > > 
> > > Notes
> > > -
> > > The text doesn't state whether other characters may follow the backslash, 
> > > and if yes, what it means. Existing implementations have used three 
> > > approaches:
> > > 
> > > 1. report an error if another character follows the backslash
> > > 2. keep only the character following the backslash, i.e., for example, 
> > > "\x" is the same as "x".
> > > 3. keep both the backslash and the character following it.

Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> Hi,
> 
> I wonder when we use 'state' and when 'status' - is there a subtle
> distinction or should be just consistently use lets say 'state', i.e.,
> changed to alalarm-status to alarm-state and standby-status to
> standby-state?

The reason in this case is that we just used the MIB names.  This
said, I agree that "standby-state" and "alarm-state" are better.

BTW, RFC 4268, which defines the original objects, says:

   The terms "state" and "status" are used interchangeably in this memo.


> I also wonder about the mapping of the MIB object names to YANG leaf
> names:
> 
>+-+-+
>| YANG data node in /hardware-| ENTITY-SENSOR-MIB object|
>| state/component/sensor-data | |
>+-+-+
>| data-type   | entPhySensorType|
>| data-scale  | entPhySensorScale   |
>| precision   | entPhySensorPrecision   |
>| value   | entPhySensorValue   |
>| oper-status | entPhySensorOperStatus  |
>| sensor-units-display| entPhySensorUnitsDisplay|
>| value-timestamp | entPhySensorValueTimeStamp  |
>| value-update-rate   | entPhySensorValueUpdateRate |
>+-+-+
> 
> Is the 'data-' prefix needed? If so, why is the a prefix not used for
> 'precision' (scale and precision really go hand in hand).

Unclear.  I think I'm the one to blame for this inconsistency, and it
goes back to the very first commit, but I can't remeber why.

> Why is it
> 'sensor-units-display' and not just 'units-display'? One option could
> be:
> 
>   value-type
>   value-scale
>   value-precision
>   value
>   oper-status
>   units-display
>   value-timestamp
>   value-update-rate

Yes this is better.

> RFC 3433 points out that entPhySensorType and entPhySensorScale and
> entPhySensorPrecision SHOULD NOT change during operation. What about
> the YANG objects? I actually do not know what the SHOULD buys a client
> since you can't rely on it. To be robust, you have to fetch an n-tuple
> anyway and be prepared that a sensor may have changed its properties.
> Should there be explicit text providing guidance that it is better to
> fetch the whole n-tuple?

This is certainly the simplest solution.   Any comments?

> Or alternatively, if supporting caching of
> values is a goal, we may need to provide a
> 'sensor-data/properties-last-changed' object that allows to make
> caching of value properties robust.


/martin

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

Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?

[Juergen Schoenwaelder]

Benoit,

RFC 6020 is ambiguous and this is just how it is. The solution for
YANG 1 is simply to give advice to module writers to avoid ambiguous
character sequences (and avoiding ambiguity can be easily done).

YANG 1.1 fixes the ambiguity in YANG 1 but backporting this fix to
YANG 1 is a change of YANG 1, i.e., it might turn a conforming
implementation into a non-conforming implementation. Hence, this may
go beyond the scope of an errata.

If tools generate proper warnings, I think we are fine and we do not
need to change YANG 1. These kind of issues are caught by tools, not
by humans reading language specifications.

If you feel strongly that an errata is needed, then the errata should
simply clearly spell out that certain backslahs sequences are
ambiguous and provide advice that they should not be used. This is
backwards compatible. Making them illegal is not backwards compatible.

/js

PS: This is also my recollection of the discussion of issue Y06 when
YANG 1.1 was put together.

On Mon, Jan 23, 2017 at 11:29:25AM +0100, Benoit Claise wrote:
> Dear all,
> 
> Let me summarize the situation.
> - The RFC 6020 spec is clearly ambiguous.
> - The solution is to use YANG 1.1
> - RFC 7950 doesn't update or obsolete RFC 6020 (*)
> - We should stop this problem from spreading further: updating tooling
> is one good aspect, we should update the spec. too to at least warn the
> users.
> 
> There is no perfect solution.
> Because of (*), I believe I should accept this errata.
> Any strong objections? If you have, propose a better plan. And I don't
> believe that "do nothing" is sufficient.
> 
> Regarding the "update" solution, see the RFC 7950 writeup at 
> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/shepherdwriteup/
> 
>(16) Will publication of this document change the status of any
>existing RFCs? Are those RFCs listed on the title page header, listed
>in the abstract, and discussed in the introduction? If the RFCs are not
>listed in the Abstract and Introduction, explain why, and point to the
>part of the document where the relationship of this document to the
>other RFCs is discussed. If this information is not in the document,
>explain why the WG considers it unnecessary.
> 
>   No. YANG 1.0 [RFC6020] is not expected to change its status since
>   there are data models on the standards-track that conform to YANG
>   1.0. YANG 1.0 may be considered for retirement once all data models
>   have naturally been updated to a future version of YANG.
> 
> Regards, Benoit
> > The following errata report has been submitted for RFC6020,
> > "YANG - A Data Modeling Language for the Network Configuration Protocol 
> > (NETCONF)".
> > 
> > --
> > You may review the report below and at:
> > http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=4911
> > 
> > --
> > Type: Technical
> > Reported by: Ladislav Lhotka 
> > 
> > Section: 6.1.3
> > 
> > Original Text
> > -
> > Within a double-quoted string (enclosed within " "), a backslash
> > character introduces a special character, which depends on the
> > character that immediately follows the backslash:
> > 
> >   \n  new line
> >   \t  a tab character
> >   \"  a double quote
> >   \  a single backslash
> > 
> > 
> > Corrected Text
> > --
> > Within a double-quoted string (enclosed within " "), a backslash
> > character introduces a special character, which depends on the
> > character that immediately follows the backslash:
> > 
> >   \n  new line
> >   \t  a tab character
> >   \"  a double quote
> >   \  a single backslash
> > 
> > The backslash MUST NOT be followed by any other character.
> > 
> > Notes
> > -
> > The text doesn't state whether other characters may follow the backslash, 
> > and if yes, what it means. Existing implementations have used three 
> > approaches:
> > 
> > 1. report an error if another character follows the backslash
> > 2. keep only the character following the backslash, i.e., for example, "\x" 
> > is the same as "x".
> > 3. keep both the backslash and the character following it.
> > 
> > This ambiguity is undesirable and YANG 1.1 [RFC 7950] explicitly adopted 
> > option #1. However, many modules are still being written using YANG version 
> > 1.0, so it is important to clarify this issue in RFC 6020 as well.
> > 
> > Instructions:
> > -
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > can log in to change the status and edit the report, if necessary.
> > 
> > --
> > RFC6020 (draft-ietf-netmod-yang-13)
> > --
> > Title   : YANG - A Data Modeling Language for the Network 
> > Configur

Re: [netmod] [Technical Errata Reported] RFC6020 (4911) - what next?

[Benoit Claise]

Dear all,

Let me summarize the situation.
- The RFC 6020 spec is clearly ambiguous.
- The solution is to use YANG 1.1
- RFC 7950 doesn't update or obsolete RFC 6020 (*)
- We should stop this problem from spreading further: updating 
tooling is one good aspect, we should update the spec. too to at least 
warn the users.


There is no perfect solution.
Because of (*), I believe I should accept this errata.
Any strong objections? If you have, propose a better plan. And I don't 
believe that "do nothing" is sufficient.


Regarding the "update" solution, see the RFC 7950 writeup at 
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/shepherdwriteup/


   (16) Will publication of this document change the status of any
   existing RFCs? Are those RFCs listed on the title page header, listed
   in the abstract, and discussed in the introduction? If the RFCs are not
   listed in the Abstract and Introduction, explain why, and point to the
   part of the document where the relationship of this document to the
   other RFCs is discussed. If this information is not in the document,
   explain why the WG considers it unnecessary.

  No. YANG 1.0 [RFC6020] is not expected to change its status since
  there are data models on the standards-track that conform to YANG
  1.0. YANG 1.0 may be considered for retirement once all data models
  have naturally been updated to a future version of YANG.

Regards, Benoit

The following errata report has been submitted for RFC6020,
"YANG - A Data Modeling Language for the Network Configuration Protocol 
(NETCONF)".

--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=4911

--
Type: Technical
Reported by: Ladislav Lhotka 

Section: 6.1.3

Original Text
-
Within a double-quoted string (enclosed within " "), a backslash
character introduces a special character, which depends on the
character that immediately follows the backslash:

  \n  new line
  \t  a tab character
  \"  a double quote
  \  a single backslash


Corrected Text
--
Within a double-quoted string (enclosed within " "), a backslash
character introduces a special character, which depends on the
character that immediately follows the backslash:

  \n  new line
  \t  a tab character
  \"  a double quote
  \  a single backslash

The backslash MUST NOT be followed by any other character.

Notes
-
The text doesn't state whether other characters may follow the backslash, and 
if yes, what it means. Existing implementations have used three approaches:

1. report an error if another character follows the backslash
2. keep only the character following the backslash, i.e., for example, "\x" is the same 
as "x".
3. keep both the backslash and the character following it.

This ambiguity is undesirable and YANG 1.1 [RFC 7950] explicitly adopted option 
#1. However, many modules are still being written using YANG version 1.0, so it 
is important to clarify this issue in RFC 6020 as well.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--
RFC6020 (draft-ietf-netmod-yang-13)
--
Title   : YANG - A Data Modeling Language for the Network 
Configuration Protocol (NETCONF)
Publication Date: October 2010
Author(s)   : M. Bjorklund, Ed.
Category: PROPOSED STANDARD
Source  : NETCONF Data Modeling Language
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG
.



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

Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt

[Juergen Schoenwaelder]

Hi,

I wonder when we use 'state' and when 'status' - is there a subtle
distinction or should be just consistently use lets say 'state', i.e.,
changed to alalarm-status to alarm-state and standby-status to
standby-state?

I also wonder about the mapping of the MIB object names to YANG leaf
names:

   +-+-+
   | YANG data node in /hardware-| ENTITY-SENSOR-MIB object|
   | state/component/sensor-data | |
   +-+-+
   | data-type   | entPhySensorType|
   | data-scale  | entPhySensorScale   |
   | precision   | entPhySensorPrecision   |
   | value   | entPhySensorValue   |
   | oper-status | entPhySensorOperStatus  |
   | sensor-units-display| entPhySensorUnitsDisplay|
   | value-timestamp | entPhySensorValueTimeStamp  |
   | value-update-rate   | entPhySensorValueUpdateRate |
   +-+-+

Is the 'data-' prefix needed? If so, why is the a prefix not used for
'precision' (scale and precision really go hand in hand). Why is it
'sensor-units-display' and not just 'units-display'? One option could
be:

  value-type
  value-scale
  value-precision
  value
  oper-status
  units-display
  value-timestamp
  value-update-rate

RFC 3433 points out that entPhySensorType and entPhySensorScale and
entPhySensorPrecision SHOULD NOT change during operation. What about
the YANG objects? I actually do not know what the SHOULD buys a client
since you can't rely on it. To be robust, you have to fetch an n-tuple
anyway and be prepared that a sensor may have changed its properties.
Should there be explicit text providing guidance that it is better to
fetch the whole n-tuple? Or alternatively, if supporting caching of
values is a goal, we may need to provide a
'sensor-data/properties-last-changed' object that allows to make
caching of value properties robust.

/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] [OPSAWG] Question on draft-ietf-netmod-yang-model-classification

[Tianran Zhou]

To add more comments: 

On the L2SM meeting, several people (4 or more) believed the 3 service delivery 
model examples ([I-D.dhjain-bess-bgp-l3vpn-yang], [I-D.ietf-bess-l2vpn-yang] 
and [I-D.ietf-bess-evpn-yang]) are actually device models.

I think both of the two I-Ds ([draft-ietf-netmod-yang-model-classification] and 
[draft-wu-opsawg-service-model-explained]) can check if those YANG models are 
device models or service models.

Regards,
Tianran

> -Original Message-
> From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Adrian Farrel
> Sent: Friday, January 20, 2017 12:25 AM
> To: netmod@ietf.org
> Cc: ops...@ietf.org;
> draft-ietf-netmod-yang-model-classificat...@ietf.org
> Subject: [OPSAWG] Question on draft-ietf-netmod-yang-model-classification
> 
> Hi,
> 
> We've been trying to ensure that draft-wu-opsawg-service-model-explained
> is consistent with the latest version of
> draft-ietf-netmod-yang-model-classification. In discussions with Tianran
> a question has come up.
> 
> In section 2 you have a nice definition of Network Service YANG Modules
> and this definition maps nicely to our definition of "service delivery
> models".
> Furthermore, your figure 1 shows Network Service YANG Modules on the
> interface between OSS/BSS and the various network services.
> 
> We have further defined "customer service models" at a higher layer still.
> That is, on the interface to the customer. This (of course?) assumes that
> the OSS/BSS is not customer code :-)
> 
> However, your discussion of Network Service YANG Modules in section 2.1
> seems slightly at odds, although this may be just ambiguity.
> 
> For example, when you say, "Network Service YANG Modules describe the
> characteristics of a service, as agreed upon with consumers of that service,"
> this is not the same as, "This model is used in the discussion between a
> customer and a service provide to describe the characteristics of a service."
> That is, the former case could be arrived at after processing based on the
> latter case - processing that we have called "service orchestration" but
> might (of course) be what leads to the operator poking the OSS/BSS.
> 
> This might all be fine and good, but later in the same section you say 
> "Network
> Service YANG Modules define service models to be consumed by external
> systems.
> These modules are commonly designed, developed and deployed by network
> infrastructure teams." And there you introduce two terms that are previously
> undefined and only server to add ambiguity. Specifically "external to what?"
> I could make and argument that the OSS is developed and deployed by network
> infrastructure teams, ad also that the OSS is external to the network itself.
> 
> And, in between these two quoted pieces of text, you have...
> 
>As an example, the Network Service YANG Module defined in
>[YANG-Data-Model-for-L3VPN-service-delivery] provides an abstract
>model for Layer 3 IP VPN service configuration.
> 
> Per my other email, this reference needs to be fixed. But I struggle to
> see the L3SM module as consistent with your figure. It may or may not be
> consistent with your text dependent on the interpretation.
> 
> In draft-wu-opsawg-service-model-explained Figure 4 we have tried to show
> how we (the authors) think L3SM fits into your classification. Here we place
> L3SM further up the layering stack.
> 
> [Apologies for not spotting this sooner. The citation
> "YANG-Data-Model-for-L3VPN-service-delivery" includes the term "service
> delivery" which I took to imply a different module.]
> 
> Thanks,
> Adrian
> 
> ___
> OPSAWG mailing list
> ops...@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg

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

Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt

[Martin Bjorklund]

Hi,

The main changes in this version of the hardware model is that
pre-provisioning is supported according to the ML discussion.  Also,
the leaf-list "contained-in" is changed to a leaf "parent", in order
to match "parent-rel-pos".

With this version, the authors believe that all known issues are
resolved, and that the document is ready for WGLC.


/martin



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 NETCONF Data Modeling Language of the IETF.
> 
> Title   : A YANG Data Model for Hardware Management
> Authors : Andy Bierman
>   Martin Bjorklund
>   Jie Dong
>   Dan Romascanu
>   Filename: draft-ietf-netmod-entity-02.txt
>   Pages   : 40
>   Date: 2017-01-23
> 
> Abstract:
>This document defines a YANG data model for the management of
>hardware on a single server.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-netmod-entity-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-02
> 
> 
> 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-entity-02.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the NETCONF Data Modeling Language of the IETF.

Title   : A YANG Data Model for Hardware Management
Authors : Andy Bierman
  Martin Bjorklund
  Jie Dong
  Dan Romascanu
Filename: draft-ietf-netmod-entity-02.txt
Pages   : 40
Date: 2017-01-23

Abstract:
   This document defines a YANG data model for the management of
   hardware on a single server.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-entity-02

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


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