Re: [netmod] Modeling of veth pairs

[Scott Mansfield]

Could we add this case to the intf-ext work?

We could use this as an example.  If a new module is what is desired, I will 
support that too.

Regards,
-scott.

From: Rob Wilton (rwilton) 
Sent: Tuesday, February 27, 2024 8:55 AM
To: Florian Kauer ; netmod@ietf.org
Cc: Scott Mansfield 
Subject: Re: Modeling of veth pairs

Hi Florian,

Some very quick thoughts on this:

I'm assuming that these Virtual Ethernet interfaces are really only Ethernet 
emulations at layer 2 rather than layer 1.  I.e., I presume that there is no 
configuration for speed, duplex, flow-control, etc?  But they would each have 
their own a MAC address?   I think that this would mean that these interfaces 
are probably more ethernet-like as defined in 
draft-ietf-netmod-intf-ext-yang-13 - Common Interface Extension YANG Data 
Models<https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang/>.

I suspect that you will want to define a new IANA iftype for these interfaces.  
The alternative would be ethernetCsmacd that is used for all physical Ethernet 
interfaces but not LAG.  But using that IANA iftype would then mean that you 
would likely pickup the configuration for physical Ethernet interfaces that I 
don't think that you really want.

You could use an Interface naming convention to represent the binding, e.g., 
veth1-left, veth1-right, but it may be better to be more flexible, in which 
case, I would probably recommend having new configuration under each v-eth 
interface with a leaf-ref to indicate what its peer interface is.

So, yes, I think that you would need to a new model to define these, but it 
should be pretty small and simple.  And if you did want to do something like 
this in the IETF, then I suspect that NETMOD is probably the best WG.

Regards,
Rob
// As a contributor/author of draft-ietf-netmod-intf-ext-yang.


From: Florian Kauer 
mailto:florian.ka...@linutronix.de>>
Date: Tuesday, 27 February 2024 at 09:02
To: netmod@ietf.org<mailto:netmod@ietf.org> 
mailto:netmod@ietf.org>>
Cc: Rob Wilton (rwilton) mailto:rwil...@cisco.com>>, 
scott.mansfi...@ericsson.com<mailto:scott.mansfi...@ericsson.com> 
mailto:scott.mansfi...@ericsson.com>>
Subject: Modeling of veth pairs
Hi,
I would like to model a veth pair in YANG, preferrably without proprietary 
models.
In Linux, these veth pairs are basically just this:

  +--+   +--+
  |Socket|   |Socket|
  +--+   +--+
 |  |
  +--+   +--+
  |Stack |   |Stack |
  +--+   +--+
 |  |
  +--+   +--+
  |veth1 |   |veth2 |
  +--+   +--+
 |  |
 +--+

So all packets that egress veth1, appear at the ingress of veth2 and vice versa,
i.e. similar to two physical interfaces of the same device directly connected 
via a cable.
Also see https://man7.org/linux/man-pages/man4/veth.4.html

The only thing I specifically found regarding veths and YANG was
https://doc.6wind.com/turbo-router-2.x/user-guide/cli/network-interface/types/veth.html<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-00890e5f712ca52f=1=b797b9fa-a764-402f-bcce-ceb3cfffca50=https%3A%2F%2Fdoc.6wind.com%2Fturbo-router-2.x%2Fuser-guide%2Fcli%2Fnetwork-interface%2Ftypes%2Fveth.html>
where they seem to use a proprietary model that provides "link-interface" to 
link
the two interfaces together.

The other option I thought about was to represent the "virtual cable" as
Internal LAN, i.e. IANA type 247 (ILAN). This would look like this:

  +--+   +--+
  |Socket|   |Socket|
  +--+   +--+
 |  |
  +--+   +--+
  |Stack |   |Stack |
  +--+   +--+
 |  |
  +--+   +--+
  |veth1 |   |veth2 |
  +--+   +--+
 |  |
  +-+
  |  ilan0  |
  +-+

However, that would still require to specify the link between the veth1 and 
ilan0
as well as veth2 and ilan0 with some kind of parent/child or higher/lower layer 
interface link.
The higher-layer-if and lower-layer-if of RFC 8343 is only ro and
while draft-ietf-netmod-intf-ext-yang provides "parent-interface", it would
not work here because ilan0 has two parents (i.e. we would need a 
"child-interface"
or a way to specify multiple parent interfaces).

Also, what could be the interface type of veth1 and veth2?

Any ideas on this? Or do we need to specify something new to support this?

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

Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?

[Scott Mansfield]

Respectively submitted for your consideration,

Having listened to the pros/cons of this issue at IETF 117, the mailing list, 
and some of the calls...
IMHO... Option 1 is the option that best reflects current practice in several 
standards bodies and provides a way forward that is the least disruptive.  
Since there is a bis of 8407 being considered, extra warnings could be added 
there if the editor/community thought that helpful.  This is not to encourage 
NBC, but simply acknowledge that NBC is a fact in some cases.  Like has been 
pointed out in some threads, something can be allowed but not encouraged.

Regards,
-scott.



From: netmod  On Behalf Of Jason Sterne (Nokia)
Sent: Monday, July 17, 2023 1:52 PM
To: netmod@ietf.org
Subject: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 
& YANG 1.1 or not?

Hi all,

At the request of the NETMOD chairs, and on behalf of the YANG Versioning 
weekly call group, here's a summary of Key Issue #1 for the versioning work 
(i.e. for the Module Versioning and YANG Semver WGLC).

We'd like to suggest that the WG has a strong focus on deciding on this 
specific issue first. Then we'll move on to tackle other key issues. The idea 
is to try and avoid getting tangled in a web of multiple intertwined issues.

Key Issue #1 is the following:  Allow NBC changes in YANG 1.0 & YANG 1.1 or not?

For now please avoid debating other issues in this thread (e.g. multiple vs 
single label schemes, whether YANG semver is a good scheme, etc). Let's focus 
on K1 and work towards a WG decision.

###
K1) Allow NBC changes in YANG 1.0 & YANG 1.1 or not?

Option 1 - Update RFC7950 to Allow NBC Changes
---
- Module Versioning modifies 7950 to allow NBC changes
- guidance that NBC changes SHOULD NOT be done (impact to user base)
- rev:non-backwards-compatible is a YANG extension
- introduction in published YANG does not impact current tooling (ignored 
until recognized)
PROS:
- address fundamental requirement of this versioning work (requirements doc)
- allows gradual adoption in the industry. YANG authors can immeditately start 
publishing with the new extensions.
- move faster to produce modules in the IETF (accept some errors/iteration)
- address the liaison from external standards bodies in a reasonable timeframe
- authors believe work is ready
- broad vendor support
- rough alignment with OpenConfig (use YANG 1.0 + OC Semver)
CONS:
- perception that we're "cheating" by not bumping our own spec's version
- Not fundamentally mandatory for clients or servers using YANG (mandatory for 
YANG claiming conformance to Module Versioning).

Option 2 - RFC7950-bis: Publish a new version of the YANG language to allow NBC 
changes
---
- NBC changes only allowed in a new (future) version of YANG
- TBD: YANG 1.2 vs 2.0 (note YANG 1.1 isn't BC with YANG 1.0)
- Content = Module Versioning + YANG Semver + very limited YANG NEXT items
- rev:non-backwards-compatible tag is a language keyword
- consequence: any use of it breaks all YANG 1.0/1.1 tooling that hasn't 
been updated
- TBD how to handle small NBC changes in IETF in the short term (i.e. non 
conformance to 7950)?
- RFC6991 bis - change the use/meaning of ip-address (or change datetime)
  - YANG date-and-time (because of SEDATE date string changes)

PROS:
- address fundamental requirement of this versioning work (requirements doc)
- clear delineation of changes in the YANG language
- consistent with philosophy that version number changes for significant 
changes in a spec (avoids concern that YANG is changing without bumping the 
version of YANG)
- can do this with mandatory YANG keywords which helps increase conformance to 
the new rules
CONS:
- difficult to roll out in the industry. Tools need upgrading before they won't 
error on a YANG 1.2 module.
- Authors can't publish YANG 1.2 until their users have upgraded their tools. 
Everyone has to move at once.
- likely large delay in producing the work (unclear what would go into YANG 
1.2, may not reach concensus easily on N items)
- delay in follow up work (Packages, Schema Comparison, Version Selection)
- continue dominating WG effort for longer (opportunity cost)

Option 3 - Strict Adherence to Current RFC7950 Rules
---
- IESG will be unable to approve any RFCs that make any changes to IETF YANG 
modules that don't strictly conform to those rules
- RFC6991 bis would not be allowed to change the use/meaning of ip-address 
(or change datetime)
  - YANG date-and-time couldn't change (related to SEDATE date 
string changes)
PROS:
- clear rules for entire industry including IETF
CONS:
- doesn't address agreed/adopted requirements of YANG versioning work
- incorrect assumption in tool chains, etc that NBC 

Re: [netmod] Lines too long in YANG tree diagrams

[Scott Mansfield]

My reading is that it is recommended.  Not required.
But what I do for readability and to avoid lint issues is use rfcfold on trees 
or examples that have long lines.  For the examples that are xml or json based, 
the consumer of the RFC needs to reverse the fold so that the example works in 
yanglint or other tools.

I could editorialize about how in 2023 we are still hindered by a limit imposed 
by a VT100 from 1978, but I have said enough.

Regards,
-scott.

From: CCAMP  On Behalf Of Italo Busi
Sent: Wednesday, July 5, 2023 5:59 PM
To: netmod@ietf.org
Cc: cc...@ietf.org; TEAS WG 
Subject: [CCAMP] Lines too long in YANG tree diagrams

RFC8340 suggests to use the "--tree-line-length 69" option to produce YANG tree 
diagrams to be included into an Internet-Draft or RFC.

Although this option works well in many cases, there are few cases where pyang 
produces YANG tree diagram with lines too long even with the 
"--tree-line-length 69" option and in this case it is not fully clear what 
could be done when including those YANG tree diagram into Internet-Drafts or 
RFCs

Section 5.2 of RFC8792 says:

It is RECOMMENDED that authors do as much as possible within the selected 
format to avoid long lines.

My interpretation of the RECOMMENDED key word and of "as much as possible" is 
that we MUST always use the "--tree-line-length 69" option to generate the YANG 
tree diagrams to be included into Internet-Drafts or RFCs and that we MAY use 
RFC8792 tool to fold the YANG tree diagrams when they contain lines too long

Is my interpretation correct?

Thanks, Italo


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

Re: [netmod] IETF 115 Slot Requests

[Scott Mansfield]

I would like to request a slot for draft-ietf-netmod-intf-ext-yang.txt.  I will 
upload a revision by the cut-off date (24 Oct).  This is to provide an update 
on restarting the work on the interface extension work and the plan for 
sub-intf-vlan-yang.

Interface Extension Yang Update
Scott Mansfield (remote)
10 mins

Regards,
-scott.

-Original Message-
From: netmod  On Behalf Of Lou Berger
Sent: Monday, October 10, 2022 3:29 PM
To: NetMod WG 
Cc: NetMod WG Chairs 
Subject: [netmod] IETF 115 Slot Requests

WG,

The *draft* agenda for IETF115 has been posted - 
https://datatracker.ietf.org/meeting/115/agenda

The NetMod session information is scheduled to be held:

Tuesday, November 8, 2022
09:30-11:30 Tuesday Session I
Richmond 4
https://datatracker.ietf.org/meeting/115/sessions/netmod.ics

This will be a (new) normal in-person with remote participation meeting.

Please send slot requests to netmod-cha...@ietf.org before the end of the day 
Monday October 24 (any TZ, but earlier is appreciated).  Please include draft 
names(s), presenter, desired slot length.  Also, please let us know if you 
think the topic would be better covered in a Virtual Interim to be held at a 
future date.

Thank you!

Lou (Kent and Joel)

Important dates:

IETF 115
2022-11-05, London, GB
DateWeekday Description
2022-10-12  Wednesday   Cut-off date for requests to reschedule
 Working Group or BOF meetings UTC 23:59
2022-10-14  Friday  Final agenda to be published
2022-10-24  Monday  Internet Draft submission cut-off (for all
 drafts, including -00) by UTC 23:59 Upload
 using the ID Submission Tool.
2022-10-24  Monday  Standard rate registration and payment cut-off
 at UTC 23:59.
2022-10-26  Wednesday   Draft Working Group agendas due by UTC
 23:59 Upload using the Meeting Materials
 Management Tool.
2022-10-31  Monday  Registration cancellation cut-off at UTC 23:59
2022-10-31  Monday  Revised Working Group agendas due by UTC 23:59
 Upload using the Meeting Materials Management
 Tool.
2022-12-02  Friday  Proceedings submission cutoff date by UTC 23:59
 Upload using the Meeting Materials Management
 Tool.
2022-12-26  Monday  Proceedings submission corrections cutoff date
 by UTC 23:59

___
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] Another comment/question on appendix B.2 of draft-ietf-netmod-yang-module-versioning-05

[Scott Mansfield]

I don't want to re-litigate what backward compatible means.

In my case...

I have two modules:  Module A and Module A'

I have instance data that works with module A and also with module A'  (so the 
new yang will support my current configuration).
When I leverage the new capabilities of module A', I can start from my 
instances made for Module A and just add the stuff, that instance file will 
only work if Module A' is supported (obviously).

But that has nothing to do with whether or not the YANG itself is considered BC 
or NBC.

If mandatory is added, I understand that would be NBC, because there could be 
working instance data that now no longer works because it is missing a 
mandatory leaf.  I also see the issue you bring up with the tree changing 
depending on where the choice is used.

I think the exercise is to just get used to the terminology, and the draft does 
a good job of clearly pointing out when something needs to be marked NBC.

Regards,
-scott.


From: Sterne, Jason (Nokia - CA/Ottawa) 
Sent: Monday, June 6, 2022 6:56 PM
To: Scott Mansfield ; italo.busi 
; netmod@ietf.org
Cc: 'cc...@ietf.org' 
Subject: RE: Another comment/question on appendix B.2 of 
draft-ietf-netmod-yang-module-versioning-05

Another reason just occurred to me why moving the old leaf inside a "choice" is 
NBC: it may not affect the data tree path to that element of instance data, but 
it does affect the schema path to that element.

So if it was a container, for example, and some other module was augmenting 
that container, the augmentation path would be broken if it was moved inside a 
choice.  I'm not certain that maintaining compatibility with an augmenting 
module is a fundamental criteria but it certain is an impact to an ecosystem of 
modules.

Of course all the above is for a fairly "strict" manner of defining backwards 
compatibility. The actual impacts to a client of moving an old leaf into a new 
"choice" (where other cases of the choice contain purely new elements that 
didn't exist before) are often going to be minor to nothing. But the users of 
the module would need to take a look at it.

This discussion is also making me realize that our text in B.2.3.1 may have a 
mistake. An author can't stick the old leaf into a "choice" and be 100% BC so 
we should probably remove that option.

Jason

From: Scott Mansfield 
mailto:scott.mansfi...@ericsson.com>>
Sent: Friday, June 3, 2022 3:06 PM
To: Sterne, Jason (Nokia - CA/Ottawa) 
mailto:jason.ste...@nokia.com>>; italo.busi 
mailto:italo.b...@huawei.com>>; 
netmod@ietf.org<mailto:netmod@ietf.org>
Cc: 'cc...@ietf.org' mailto:cc...@ietf.org>>
Subject: RE: Another comment/question on appendix B.2 of 
draft-ietf-netmod-yang-module-versioning-05


So basically, deprecating a leaf and adding a new leaf/container that replaces 
the deprecated leaf will always be NBC.

Still the guidance in B.2 has the least impact and is easy to explain, and has 
the added benefit that the tree doesn't change and existing (old schema) 
instance data will work with the new schema.

-scott.

From: CCAMP mailto:ccamp-boun...@ietf.org>> On Behalf 
Of Sterne, Jason (Nokia - CA/Ottawa)
Sent: Thursday, June 2, 2022 5:03 PM
To: Italo Busi 
mailto:Italo.Busi=40huawei@dmarc.ietf.org>>;
 netmod@ietf.org<mailto:netmod@ietf.org>
Cc: 'cc...@ietf.org' mailto:cc...@ietf.org>>
Subject: Re: [CCAMP] Another comment/question on appendix B.2 of 
draft-ietf-netmod-yang-module-versioning-05

Hi Italo,

One problem I see with this change is that in the old data model, the leaf 
"mode" had to exist in the instance data. But with the new model, it is valid 
to have instance data with no "mode" leaf at all. That instance data would not 
validate against the old YANG model.

I do see your point that any valid data that could be generated using the old 
model is still accepted in the new model. But for the YANG versioning work 
we've been pretty hesitant to diverge far from RFC 7950 for the list of what is 
NBC vs BC (mainly just cleanup of the status deprecated & obsolete), and 
clarifying

There are other possible cases that might meet a definition of "any old config 
would be accepted by the new model" but we still don't label them as BC in our 
YANG versioning work, e.g.:
- moving a pre-existing leaf into a new choice along with new elements in other 
cases (like yours below but without any additional complications of "mandatory" 
statements)
- changing the type of a uint8 to a union of uint8 and other types

Jason

From: netmod mailto:netmod-boun...@ietf.org>> On 
Behalf Of Italo Busi
Sent: Wednesday, June 1, 2022 6:07 PM
To: netmod@ietf.org<mailto:netmod@ietf.org>
Cc: 'cc...@ietf.org' mailto:cc...@ietf.org>>
Subject: [netmod] Another comment/question on appendix B.2 of 
draft-ietf-netmod-yang-module-versioning-05

The example (in particular in point 3

Re: [netmod] Question about tooling for YANG Instance Data

[Scott Mansfield]

That is very useful information.  Thanks, I will try that.  I’ll create a small 
script to do that and then run yanglint.

Regards,
-scott.

From: Kent Watsen 
Sent: Monday, June 6, 2022 9:13 PM
To: Scott Mansfield 
Cc: Michal Vasko ; netmod@ietf.org
Subject: Re: [netmod] Question about tooling for YANG Instance Data

For structure (and rc:yang-data), my validation scripts hack the YANG module to 
convert the "structure" to a "container" and then do the validation against the 
hacked-YANG module.

Kent



On Jun 6, 2022, at 6:50 AM, Scott Mansfield 
mailto:scott.mansfield=40ericsson@dmarc.ietf.org>>
 wrote:

Thank you Michal for the information.  I appreciate the work on yanglint and 
look forward to future updates.

Then my question is, what tool was used to validate the examples in RFC 9195?  
Is there any tooling that can be used to validate the instance data?

thanks,
-scott.



From: Michal Vasko
Sent: Monday, June 6, 2022 1:59 AM
To: Scott Mansfield; Kent Watsen
Cc: netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: [netmod] Question about tooling for YANG Instance Data

Hi Scott,
the main developer of libyang commenting. In your example there is a 
"structure" extension instance, which we do not support currently so you will 
not be able to validate it no matter what you do. I have already looked at this 
extension recently and think that we can support it without much trouble but I 
am currently swamped by lots of other issues so I have no idea when I will get 
to this.
Regards,
Michal
On 5. 6. 2022 1:35, Scott Mansfield wrote:
Excellent ideas.  I will package up a tiny example and post to libyang.


I am using yanglint 2.0.200.


Since I’m starting from an example that is in RFC 9195, it is easy to build a 
small example and package up an expect script to show the issue.


Regards,
-scott.


From: Kent Watsen <mailto:k...@watsen.net>
Sent: Saturday, June 4, 2022 5:22 PM
To: Scott Mansfield 
<mailto:scott.mansfi...@ericsson.com>
Cc: netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: [netmod] Question about tooling for YANG Instance Data


Hi Scott,


I consider myself a heavy `yanglint` user, as all examples in all my drafts are 
validated each time I "make" each draft, and I have several other projects that 
make heavy use of `yanglint` validation.   I have run into a number of 
validation issues over years and generally first try to validate that my 
understanding of YANG is correct  and, if unsure, I'll ping the NETMOD list 
(note: there are many YANG subtleties, such as the recent discovery that a 
module needs to be "implemented" in order for its features to be defined).   
Otherwise, I submit an Issue to the `libyang` GitHub issue tracker, typically 
containing the smallest possible module (or number of modules) demonstrating 
the issue, while also pointing out all relevant facts (e.g., foo is 
implemented, bar is defined, RFC 7950 Section X says this, etc.).  Radek and 
Michal are pretty good with providing a response in 1-2 business days.   
Sometimes my YANG-understanding is challenged, at which point we bring it to 
the NETMOD list.


FWIW, `yanglint` recently switched from the 1.x to the 2.x code base.   A 
number of regressions were introduced at this time (resolved now, at least the 
ones affecting me) but, nicely, the 2.x code catches some issues that the 1.x 
code never did (it's a better validator).  The CLI changed some, and I'm now 
very careful to ensure all modules that need to be implemented are, and that 
all features that need to be defined are.  I now explicitly disable all 
features for implemented modules when no features from it are needed.   I find 
that the new 2.x is picky, in a good way and that, after painstakingly working 
through each issue, all my validation tests are passing now.


Best of luck,
Kent



On Jun 3, 2022, at 3:35 PM, Scott Mansfield 
mailto:scott.mansfield=40ericsson@dmarc.ietf.org>>
 wrote:


I am trying to use two of the examples found in RFC 9195 
https://www.rfc-editor.org/rfc/rfc9195.html#name-preloading-default-configur<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-092ccfe7a6702a7c=1=4e9d6ab0-63b7-4e40-965d-5d89b0208d6e=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc9195.html%23name-preloading-default-configur>
 and 
https://www.rfc-editor.org/rfc/rfc9195.html#name-storing-diagnostics-data<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-4510ebc746564af0=1=4e9d6ab0-63b7-4e40-965d-5d89b0208d6e=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc9195.html%23name-storing-diagnostics-data>
 to test out how to validate that instance data is formatted correctly.


Using yanglint, I load all the yang necessary and then load the data from 
either the xml file (read-only-acm-rules) or the json file 
(acme-router-netconf-diagnostics).  I get a similar error for bo

Re: [netmod] Question about tooling for YANG Instance Data

[Scott Mansfield]

Thank you Michal for the information.  I appreciate the work on yanglint and 
look forward to future updates.

Then my question is, what tool was used to validate the examples in RFC 9195?  
Is there any tooling that can be used to validate the instance data?

thanks,
-scott.



From: Michal Vasko
Sent: Monday, June 6, 2022 1:59 AM
To: Scott Mansfield; Kent Watsen
Cc: netmod@ietf.org
Subject: Re: [netmod] Question about tooling for YANG Instance Data


Hi Scott,

the main developer of libyang commenting. In your example there is a 
"structure" extension instance, which we do not support currently so you will 
not be able to validate it no matter what you do. I have already looked at this 
extension recently and think that we can support it without much trouble but I 
am currently swamped by lots of other issues so I have no idea when I will get 
to this.

Regards,
Michal

On 5. 6. 2022 1:35, Scott Mansfield wrote:

Excellent ideas.  I will package up a tiny example and post to libyang.



I am using yanglint 2.0.200.



Since I’m starting from an example that is in RFC 9195, it is easy to build a 
small example and package up an expect script to show the issue.



Regards,

-scott.



From: Kent Watsen <mailto:k...@watsen.net>
Sent: Saturday, June 4, 2022 5:22 PM
To: Scott Mansfield 
<mailto:scott.mansfi...@ericsson.com>
Cc: netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: [netmod] Question about tooling for YANG Instance Data



Hi Scott,



I consider myself a heavy `yanglint` user, as all examples in all my drafts are 
validated each time I "make" each draft, and I have several other projects that 
make heavy use of `yanglint` validation.   I have run into a number of 
validation issues over years and generally first try to validate that my 
understanding of YANG is correct  and, if unsure, I'll ping the NETMOD list 
(note: there are many YANG subtleties, such as the recent discovery that a 
module needs to be "implemented" in order for its features to be defined).   
Otherwise, I submit an Issue to the `libyang` GitHub issue tracker, typically 
containing the smallest possible module (or number of modules) demonstrating 
the issue, while also pointing out all relevant facts (e.g., foo is 
implemented, bar is defined, RFC 7950 Section X says this, etc.).  Radek and 
Michal are pretty good with providing a response in 1-2 business days.   
Sometimes my YANG-understanding is challenged, at which point we bring it to 
the NETMOD list.



FWIW, `yanglint` recently switched from the 1.x to the 2.x code base.   A 
number of regressions were introduced at this time (resolved now, at least the 
ones affecting me) but, nicely, the 2.x code catches some issues that the 1.x 
code never did (it's a better validator).  The CLI changed some, and I'm now 
very careful to ensure all modules that need to be implemented are, and that 
all features that need to be defined are.  I now explicitly disable all 
features for implemented modules when no features from it are needed.   I find 
that the new 2.x is picky, in a good way and that, after painstakingly working 
through each issue, all my validation tests are passing now.



Best of luck,

Kent





On Jun 3, 2022, at 3:35 PM, Scott Mansfield 
mailto:scott.mansfield=40ericsson@dmarc.ietf.org>>
 wrote:



I am trying to use two of the examples found in RFC 9195 
https://www.rfc-editor.org/rfc/rfc9195.html#name-preloading-default-configur<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-092ccfe7a6702a7c=1=4e9d6ab0-63b7-4e40-965d-5d89b0208d6e=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc9195.html%23name-preloading-default-configur>
 and 
https://www.rfc-editor.org/rfc/rfc9195.html#name-storing-diagnostics-data<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-4510ebc746564af0=1=4e9d6ab0-63b7-4e40-965d-5d89b0208d6e=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc9195.html%23name-storing-diagnostics-data>
 to test out how to validate that instance data is formatted correctly.



Using yanglint, I load all the yang necessary and then load the data from 
either the xml file (read-only-acm-rules) or the json file 
(acme-router-netconf-diagnostics).  I get a similar error for both...

data -t data -f xml acme-router-netconf-diagnostics.json

libyang[0]: Node "instance-data-set" not found in the "ietf-yang-instance-data" 
module. (path: Line number 2.)

YANGLINT[E]: Failed to parse input data file 
"acme-router-netconf-diagnostics.json".



What is the best tooling to use to validate the instance data?  What tooling 
was used to validate the contents used in the examples?  I'm trying to 
determine if this a yanglint issue, user error, or I'm just using the wrong 
tool.



Here is a link to a github with my testing:  
https://github.com/samans/testing-yang/tree/main/ieee-60802/60802<https:

Re: [netmod] Question about tooling for YANG Instance Data

[Scott Mansfield]

Excellent ideas.  I will package up a tiny example and post to libyang.

I am using yanglint 2.0.200.

Since I'm starting from an example that is in RFC 9195, it is easy to build a 
small example and package up an expect script to show the issue.

Regards,
-scott.

From: Kent Watsen 
Sent: Saturday, June 4, 2022 5:22 PM
To: Scott Mansfield 
Cc: netmod@ietf.org
Subject: Re: [netmod] Question about tooling for YANG Instance Data

Hi Scott,

I consider myself a heavy `yanglint` user, as all examples in all my drafts are 
validated each time I "make" each draft, and I have several other projects that 
make heavy use of `yanglint` validation.   I have run into a number of 
validation issues over years and generally first try to validate that my 
understanding of YANG is correct  and, if unsure, I'll ping the NETMOD list 
(note: there are many YANG subtleties, such as the recent discovery that a 
module needs to be "implemented" in order for its features to be defined).   
Otherwise, I submit an Issue to the `libyang` GitHub issue tracker, typically 
containing the smallest possible module (or number of modules) demonstrating 
the issue, while also pointing out all relevant facts (e.g., foo is 
implemented, bar is defined, RFC 7950 Section X says this, etc.).  Radek and 
Michal are pretty good with providing a response in 1-2 business days.   
Sometimes my YANG-understanding is challenged, at which point we bring it to 
the NETMOD list.

FWIW, `yanglint` recently switched from the 1.x to the 2.x code base.   A 
number of regressions were introduced at this time (resolved now, at least the 
ones affecting me) but, nicely, the 2.x code catches some issues that the 1.x 
code never did (it's a better validator).  The CLI changed some, and I'm now 
very careful to ensure all modules that need to be implemented are, and that 
all features that need to be defined are.  I now explicitly disable all 
features for implemented modules when no features from it are needed.   I find 
that the new 2.x is picky, in a good way and that, after painstakingly working 
through each issue, all my validation tests are passing now.

Best of luck,
Kent



On Jun 3, 2022, at 3:35 PM, Scott Mansfield 
mailto:scott.mansfield=40ericsson@dmarc.ietf.org>>
 wrote:

I am trying to use two of the examples found in RFC 9195 
https://www.rfc-editor.org/rfc/rfc9195.html#name-preloading-default-configur<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-092ccfe7a6702a7c=1=4e9d6ab0-63b7-4e40-965d-5d89b0208d6e=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc9195.html%23name-preloading-default-configur>
 and 
https://www.rfc-editor.org/rfc/rfc9195.html#name-storing-diagnostics-data<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-4510ebc746564af0=1=4e9d6ab0-63b7-4e40-965d-5d89b0208d6e=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc9195.html%23name-storing-diagnostics-data>
 to test out how to validate that instance data is formatted correctly.

Using yanglint, I load all the yang necessary and then load the data from 
either the xml file (read-only-acm-rules) or the json file 
(acme-router-netconf-diagnostics).  I get a similar error for both...
data -t data -f xml acme-router-netconf-diagnostics.json
libyang[0]: Node "instance-data-set" not found in the "ietf-yang-instance-data" 
module. (path: Line number 2.)
YANGLINT[E]: Failed to parse input data file 
"acme-router-netconf-diagnostics.json".

What is the best tooling to use to validate the instance data?  What tooling 
was used to validate the contents used in the examples?  I'm trying to 
determine if this a yanglint issue, user error, or I'm just using the wrong 
tool.

Here is a link to a github with my testing:  
https://github.com/samans/testing-yang/tree/main/ieee-60802/60802<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-20ec105f5d2f3377=1=4e9d6ab0-63b7-4e40-965d-5d89b0208d6e=https%3A%2F%2Fgithub.com%2Fsamans%2Ftesting-yang%2Ftree%2Fmain%2Fieee-60802%2F60802>
If interested t.in in the expect script for the 
acme-router-netconf-diagnostics.json example and x.in is the expect script for 
the read-only-acm-rules.xml example.

regards,
-scott.

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

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

[netmod] Question about tooling for YANG Instance Data

[Scott Mansfield]

I am trying to use two of the examples found in RFC 9195 
https://www.rfc-editor.org/rfc/rfc9195.html#name-preloading-default-configur 
and https://www.rfc-editor.org/rfc/rfc9195.html#name-storing-diagnostics-data 
to test out how to validate that instance data is formatted correctly.

Using yanglint, I load all the yang necessary and then load the data from 
either the xml file (read-only-acm-rules) or the json file 
(acme-router-netconf-diagnostics).  I get a similar error for both...

data -t data -f xml acme-router-netconf-diagnostics.json

libyang[0]: Node "instance-data-set" not found in the "ietf-yang-instance-data" 
module. (path: Line number 2.)

YANGLINT[E]: Failed to parse input data file 
"acme-router-netconf-diagnostics.json".


What is the best tooling to use to validate the instance data?  What tooling 
was used to validate the contents used in the examples?  I'm trying to 
determine if this a yanglint issue, user error, or I'm just using the wrong 
tool.

Here is a link to a github with my testing:  
https://github.com/samans/testing-yang/tree/main/ieee-60802/60802
If interested t.in in the expect script for the 
acme-router-netconf-diagnostics.json example and x.in is the expect script for 
the read-only-acm-rules.xml example.

regards,
-scott.

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

Re: [netmod] Another comment/question on appendix B.2 of draft-ietf-netmod-yang-module-versioning-05

[Scott Mansfield]

So basically, deprecating a leaf and adding a new leaf/container that replaces 
the deprecated leaf will always be NBC.

Still the guidance in B.2 has the least impact and is easy to explain, and has 
the added benefit that the tree doesn't change and existing (old schema) 
instance data will work with the new schema.

-scott.

From: CCAMP  On Behalf Of Sterne, Jason (Nokia - 
CA/Ottawa)
Sent: Thursday, June 2, 2022 5:03 PM
To: Italo Busi ; netmod@ietf.org
Cc: 'cc...@ietf.org' 
Subject: Re: [CCAMP] Another comment/question on appendix B.2 of 
draft-ietf-netmod-yang-module-versioning-05

Hi Italo,

One problem I see with this change is that in the old data model, the leaf 
"mode" had to exist in the instance data. But with the new model, it is valid 
to have instance data with no "mode" leaf at all. That instance data would not 
validate against the old YANG model.

I do see your point that any valid data that could be generated using the old 
model is still accepted in the new model. But for the YANG versioning work 
we've been pretty hesitant to diverge far from RFC 7950 for the list of what is 
NBC vs BC (mainly just cleanup of the status deprecated & obsolete), and 
clarifying

There are other possible cases that might meet a definition of "any old config 
would be accepted by the new model" but we still don't label them as BC in our 
YANG versioning work, e.g.:
- moving a pre-existing leaf into a new choice along with new elements in other 
cases (like yours below but without any additional complications of "mandatory" 
statements)
- changing the type of a uint8 to a union of uint8 and other types

Jason

From: netmod mailto:netmod-boun...@ietf.org>> On 
Behalf Of Italo Busi
Sent: Wednesday, June 1, 2022 6:07 PM
To: netmod@ietf.org
Cc: 'cc...@ietf.org' mailto:cc...@ietf.org>>
Subject: [netmod] Another comment/question on appendix B.2 of 
draft-ietf-netmod-yang-module-versioning-05

The example (in particular in point 3.1), assumes that it is possible to put 
the old deprecated leaf and the new leaf within a choice to ensure that the new 
node is not used when the old node is used

In the context of an update to RFC8561 (-00 I-D still under preparation) we 
have found a similar care where the choice could also be beneficial to express 
the requirement that the new node is mandatory when the old node is not used 
(in other words either the old node or the new node MUST be configured)

You can find a simplified example of the change we were considering here:

https://github.com/samans/testing-yang/tree/main/mw-option

The original (using the old style mode) is in 
mw-opt...@2022-04-01.yang. the new version of 
mode (rlt-mode) is in 
mw-opt...@2022-05-26.yang

However, when we use pyang to check backward compatibility we get an error 
message (see the nbc.out file in github):


mw-opt...@2022-05-26.yang:47: error: the 
leaf 'mode', defined at 
mw-opt...@2022-04-01.yang:40 is illegally 
removed
mw-opt...@2022-05-26.yang:50: error: the 
mandatory node mode-option is illegally added

However, we have checked that the xml file mw-option.xml, which uses the 
deprecated style of mode, works fine also with the new 
mw-opt...@2022-05-26.yang. We therefore think 
this type of change can be considered backward compatible since an old client 
would not break when trying to configure a new server which implements the 
deprecated node

We are therefore not sure whether this is a tooling issue or a specification 
issue

Reviewing clause 11 of RFC7950 and draft-ietf-netmod-yang-module-versioning-05, 
it seems that moving an existing leaf under a choice is not listed as a 
backward compatible change

We are wondering whether draft-ietf-netmod-yang-module-versioning-05 could 
clarify that this type of change can be considered backward compatible

We would appreciated any clarification by Netmod WG expert about whether this 
change can be considered backward compatible or not

Thanks, Italo (on behalf of co-authors working on a new I-D for updating 
RFC8561)


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

Re: [netmod] Liaison statement to ORAN - v2

[Scott Mansfield]

Thanks Balázs, 

 

Editorial:  The group is call O-RAN Alliance and should be abbreviated O-RAN.

 

So..  suggestions including boiler plate…

 



>From Groups netmod

>From Contact Scott Mansfield

To Group O-RAN Alliance (SDFG, WG1, WG4, WG5, WG9)

To ContactsBrian Daly: brian.k.d...@att.com 
<mailto:brian.k.d...@att.com> ; Xiaofei Xu: xuxiao...@chinamobile.com 
<mailto:xuxiao...@chinamobile.com> ; Paul Smith, ps7...@att.com 
<mailto:ps7...@att.com> ; Jinri Huang, huangji...@chinamobile.com 
<mailto:huangji...@chinamobile.com> ; Anil Umesh ume...@nttdocomo.com 
<mailto:ume...@nttdocomo.com> ; Shankar Venkataraman 
shankar.venkatra...@verizonwireless.com 
<mailto:shankar.venkatra...@verizonwireless.com> ; Mohamad Yassin 
mohamad.yas...@orange.com <mailto:mohamad.yas...@orange.com> ; Kunihiko Teshima 
kunihiko.teshima...@nttdocomo.com <mailto:kunihiko.teshima...@nttdocomo.com> ; 
Elena Myhre elena.my...@ericsson.com <mailto:elena.my...@ericsson.com> ; 
Abdellah Tazi at8...@att.com <mailto:at8...@att.com> ; Dechao Zhang 
zhangdec...@chinamobile.com <mailto:zhangdec...@chinamobile.com> ; Reza 
Vaez-Ghaemi reza.vaezgha...@viavisolutions.com 
<mailto:reza.vaezgha...@viavisolutions.com> 

Cc OPS ad, netmod wg

Response Contactscott.mansfi...@ericsson.com

Technical Contact scott.mansfi...@ericsson.com

Purpose   For information

Attachments  

Body

IETF NETMOD working group requests O-RAN avoid using deviations as part of its 
specification. When O-RAN plans to reuse specifications from other standard 
bodies or industry groups it should not remove or change functionality.  If 
variations are needed compared to a base model, O-RAN should ask the original 
group to include feature statements in the original YANG module.

 

As documented in https://tools.ietf.org/html/rfc7950#section-7.20.3  “... 
deviations MUST never be part of a published standard, since they are the 
mechanism for learning how implementations vary from the standards.”

As documented in  
<https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01#section-5.8.1> 
https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01#section-5.8.1 
the usage of deviations would prevent:

*   Vendors to claim conformance to both O-RAN and 3GPP specifications 
(which are in some cases used as a base for the O-RAN YANG models)
*   Vendors to implement their own deviations for the same YANG schema nodes

 

Note: The problems with deviations exists even if YANG modules are used without 
YANG packages.

 



 

Regards,

-scott.

 

From: netmod  On Behalf Of Balázs Lengyel
Sent: Tuesday, November 24, 2020 11:04 AM
To: Jan Lindblad (jlindbla) ; Balázs 
Lengyel 
Cc: Robert Petersen ; Jacqueline Beaulac S 
; netmod@ietf.org
Subject: Re: [netmod] Liaison statement to ORAN - v2

 

Hello, 

Based on discussion here is version2 of the proposed liaison text:

 

Liaison text v2:

 

IETF NETMOD working group requests ORAN to avoid using deviations as part of 
its specification. When ORAN plans to reuse specifications from other standard 
bodies or industry groups it should not remove or change functionality.  If 
variations are needed compared to a base model, ORAN should ask the original 
group to include feature statements in the original YANG module.

 

As documented in https://tools.ietf.org/html/rfc7950#section-7.20.3  “... 
deviations MUST never be part of a published standard, since they are the 
mechanism for learning how implementations vary from the standards.”

As documented in  
<https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01#section-5.8.1> 
https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01#section-5.8.1 
the usage of deviations would prevent:

*   Vendors to claim conformance to both ORAN and 3GPP specifications 
(which are in some cases used as a base for the ORAN YANG models)
*   Vendors to implement their own deviations for the same YANG schema nodes
*

Note: The problems with deviations exists even if YANG modules are used without 
using YANG packages.

 

 

Regards Balazs

 

From: netmod mailto:netmod-boun...@ietf.org> > On 
Behalf Of Jan Lindblad (jlindbla)
Sent: 2020. november 19., csütörtök 11:00
To: Balázs Lengyel mailto:balazs.lengyel=40ericsson@dmarc.ietf.org> >
Cc: Robert Petersen mailto:robert.peter...@ericsson.com> >; Jacqueline Beaulac S 
mailto:jacqueline.s.beau...@ericsson.com> 
>; netmod@ietf.org <mailto:netmod@ietf.org> 
Subject: Re: [netmod] Liaison statement to ORAN

 

Balázs, 

 

+1

I think this is an important message to O-RAN, and I know similar ideas have 
been up for discussions in other SDOs as well. I think your proposed way of 
conveying the message is good.  

 

Best Regards,

/jan

 

 

On 18 Nov 2020, at 09:09, Balázs Lengyel 
mailto:balazs.lengyel=40ericsson..

Re: [netmod] hex-string as built-in type in future versions of YANG

[Scott Mansfield]

The licensing information for IEEE YANG models can be found here...
https://github.com/YangModels/yang  (YANG Catalog's github repository)

If you scroll down there is the text of the README.md file, there you will 
find...

In the Models Directory Structure section:
yang/standard/ieee: standard modules (published or drafts) intended for IEEE 
submission [3]

is this information:
[3] IEEE License:

- All files contained within this sub-directory are considered to be intended 
as IEEE Contributions.

- All issues entered into the trouble ticket system for this directory are 
considered to be intended as IEEE Contributions.

- All pull requests submitted for this directory are considered to be intended 
as IEEE Contributions.

- All contributions to IEEE standards development (whether for an individual 
or entity standard) shall meet the requirements outlined in the IEEE-SA 
Copyright
Policy (https://standards.ieee.org/develop/policies/bylaws/sect6-7.html#7)

- Copyright release for YANG modules: Users may freely reproduce the YANG 
modules contained under /standard/ieee/ so that they can be used for their 
intended purpose.

If you really want the official YANG, you can extract the YANG out of the IEEE 
Standard document (yang is included as a txt attachment to pdf).  But the
copyright release is the same.  See 
https://ieeexplore.ieee.org/browse/standards/get-program/page/series?id=68 for 
a place to freely download 802 Standards.

Hope this helps.

Regards,
-scott.



-Original Message-
From: netmod  On Behalf Of Vladimir Vassilev
Sent: Wednesday, November 6, 2019 8:30 AM
To: tom petch ; netmod@ietf.org
Subject: [netmod] hex-string as built-in type in future versions of YANG

Moving a netmod relevant topic from a thread on the bmwg mailing list
https://mailarchive.ietf.org/arch/msg/bmwg/GwkVykKmOX7DFokCFynJVy_ZwZ8

On 29/10/2019 13.32, tom petch wrote:
> Picking up the point below about vlan, this is where the IETF is not
> doing the job it might.  'vlan' appears in many YANG modules with
> several flavours thereof; yes, we might get a better resolution on the
> netmod list but really, apart from our IEEE liaison, I do not know
> where to go for the best advice on this.  I saw this issue surface
> recently on I2RS which, thinking about it, makes sense and there, the 
> outcome was
>   import ieee802-dot1q-types {...  reference
>  "IEEE Std 802.1Qcp-2018: Bridges and Bridged
>   Networks - Amendment: YANG Data Model."; i.e. anything vlan
> we import from the IEEE module.  I did query making an IETF module
> normatively dependent on an IEEE module and the ADs said that that was
> fine so that is the direction in which I think that the IETF should
> go.

I can think of at least 2 issues with importing ieee802-dot1q-types.yang in 
IETF modules. 1. the unclear license under which third party organizations can 
distribute it. 2. Its design

[1] The IETF has liaison with IEEE but the IETF modules are distributed under 
Simplified BSD License while the IEEE ones are not.  It is not clear to me 
what is the effective IEEE license for third party organizations that need to 
distribute the IEEE modules together with the importing IETF ones. If the cost 
of the 5 simple ethernet frame field types - ethertype, vlanid, tpid, pcp, cfi 
is embedding dependency on the conservative IEEE licensing policies I think 
the cost is too high.

[2] Some of the types are based on strings with complex lexical representation 
with canonical form specified in description statement which is neither 
scalable nor automation friendly. For example the "ethertype-type" type (just 
getting started):

 from ieee802-dot1q-ty...@2018-03-07.yang

   typedef ethertype-type {
 type string {
   pattern "[0-9a-fA-F]{2}-[0-9a-fA-F]{2}";
 }
 description
   "The EtherType value represented in the canonical order defined
   by IEEE 802. The canonical representation uses uppercase
   characters.";
 reference
   "9.2 of IEEE Std 802-2014";
   }


IMO typedefs (not types) with constrains specified in a description statement 
especially if they are not part of ietf-yang-types (RFC6991) should be 
avoided. Those types are bad enough even when they are defined in 
ietf-yang-types e.g. "mac-address" AA:BB:CC:DD:EE:FF which is valid for rpc 
"input" data has to be treated as aa:bb:cc:dd:ee:ff (which is the canonical 
representation). The difference comes from the fact that "mac-address" is 
seamlessly converted to lowercase in many tools (not all). Those tools do not 
support the types defined in ieee802-dot1q-types in the same way. So there is 
no "to uppercase"
seamless conversion for ethertype-type and "aB-cD" and "AA-CD" are treated as 
different values and you will have to figure out how your implementation can 
fix this on your own.

IMO ietf-yang-types:mac-address (and many others 
ieee802-dot1q-types:ethertype-type included) can be derived from 
ietf-yang-types:hex-string 

[netmod] YANG and TimeFilter

[Scott Mansfield]

Hello Netmod,

 

I'm looking at using a feature like the TimeFilter textual convention
(RFC2021 -> RFC 4502) found for RMON2 MIB in a NETCONF/YANG context.  I
searched the YangCatalog for such a thing and didn't find anything like
TimeFilter.  Has there been any work related to this type of filter?  I am
working on a YANG module that would like to return a subset of remote system
data filtered by time.

 

Any thoughts?  Apologies if this has been asked before. I did look through
the netmod list archive and grepped the modules here
(https://github.com/YangModels/yang/tree/master/experimental/ietf-extracted-
YANG-modules) and here
(https://github.com/YangModels/yang/tree/master/standard/ietf/RFC).

 

Thanks,

-scott.



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] UML to YANG mapping

[Scott Mansfield]

Hello Netmod!

https://tools.ietf.org/html/draft-mansfield-netmod-uml-to-yang-00 has been 
posted.  This draft is attempting to open a discussion on how best to translate 
from a UML model to a YANG model.  If you are interested in such things, please 
take a look at the content, but please pay particular attention to where the 
draft is missing content.  The authors would like to hear from experts on how 
to interpret the various UML artefacts in order to help provide guidelines on 
how to leverage UML as a part of a model-driven development lifecycle.

A note about the format of the draft.  I write using the XML template.  There 
are .jpeg image files that are included in some artwork tags.  I used the 
rfc2629xslt tool to translate to HTML and then to PDF (so that the image files 
are included).  I then submitted the TXT, XML, and PDF (there is no option 
upload the HTML in the submit tool).  So, the only version of the draft that 
shows the image files is the PDF (because the HTML file was generated from the 
TXT file).  I know this isn't the group to discuss how to get the formats to 
work out (I'll work on that), but I wanted the readers to know where to find 
the image files for this -00 draft.

Regards,
-scott.

Scott Mansfield
Ericsson Inc.
+1 724 931 9316

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