Re: [netmod] RE I-D Action: draft-ietf-netmod-node-tags-11.txt

[Adrian Farrel]

Thanks Qin,

I checked against your proposed resolution of my review comments and I don't 
see any issues.

Cheers,
Adrian

-Original Message-
From: netmod  On Behalf Of Qin Wu
Sent: 23 October 2023 11:28
To: NETMOD Group 
Subject: [netmod] RE I-D Action: draft-ietf-netmod-node-tags-11.txt

v-11 addresses comments during WGLC, the main changes include:
1. Remove all specific metrics from both terminology section and section 9.2 on 
IETF YANG Data Node Tags Registry based on WGLC discussion.
2. Align with Open Telemetry and Open Metrics open source implementation 
specification, introduce traces, log for data nodes classification.
3.Fix normative reference issues in section 9.2.

-Qin
-邮件原件-
发件人: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] 代表 
internet-dra...@ietf.org
发送时间: 2023年10月21日 17:56
收件人: i-d-annou...@ietf.org
抄送: netmod@ietf.org
主题: I-D Action: draft-ietf-netmod-node-tags-11.txt

Internet-Draft draft-ietf-netmod-node-tags-11.txt is now available. It is a 
work item of the Network Modeling (NETMOD) WG of the IETF.

   Title:   Node Tags in YANG Modules
   Authors:  Qin Wu
Benoit Claise
Mohamed Boucadair
Peng Liu
Zongpeng Du
   Name:draft-ietf-netmod-node-tags-11.txt
   Pages:   30
   Dates:   2023-10-21

Abstract:

   This document defines a method to tag nodes that are associated with
   the operation and management data in YANG modules.  This method for
   tagging YANG nodes is meant to be used for classifying either data
   nodes or instances of data nodes from different YANG modules and
   identifying their characteristic data.  Tags may be registered as
   well as assigned during the definition of the module, assigned by
   implementations, or dynamically defined and set by users.

   This document also provides guidance to future YANG data model
   writers; as such, this document updates RFC 8407.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-node-tags/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-11

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-node-tags-11

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce

___
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] WG adoption call: draft-boucadair-netmod-rfc8407bis-02

[Adrian Farrel]

Hi Lou,

Yes, it is totally appropriate that we revisit this guidance. A lot has been
learned in the five years since 8407 and the long list of updates already in
this draft show that there is work to be done.

Adopt and work.

Cheers,
Adrian

-Original Message-
From: netmod  On Behalf Of Lou Berger
Sent: Monday, September 11, 2023 11:22 PM
To: NETMOD Group 
Cc: NetMod WG Chairs 
Subject: [netmod] WG adoption call: draft-boucadair-netmod-rfc8407bis-02

Hello,

This email begins a 2-week adoption poll for: 
https://datatracker.ietf.org/doc/draft-boucadair-netmod-rfc8407bis/

Please voice your support or technical objections to adoption on the
list by the end of the day (any time zone) Sept 25.

Thank you,
Lou (as Co-chair)

___
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] Broadband Forum Liaison concerning: New Project for Addressing ONU Management at Scale

[Adrian Farrel]

Please copy CCAMP into these discussions as the WG actively writing YANG models 
for optical elements in the network.

 

Cheers,

Adrian

 

From: netmod  On Behalf Of David Sinicrope
Sent: 24 July 2023 22:11
To: netmod@ietf.org
Cc: david.sinicr...@ericsson.com
Subject: [netmod] Broadband Forum Liaison concerning: New Project for 
Addressing ONU Management at Scale

 

 

Hi All,

As noted during the NETMOD session today, the BBF has sent a liaison regarding 
their new project for Addressing ONU Management at Scale.

While not yet posted to IETF Statements  
, the liaison has the content below and as noted in the meeting today, should 
have a response.  

In the coming days, I'll be drafting the response on behalf of the Chairs. 
Input is welcome.

Please let me know if you have questions

Thanks,

Dave Sinicrope
IETF Liaison Manager for the Broadband Forum

 

 

>From the Chair's slides:

Liaisons and Communications

Incoming:
– From:Broadband Forum
– Received: 2023-03-09
– Title: New Project for Addressing ONU Management at Scale
– The Broadband Forum Fiber Access Networks (FAN) Work Area recently
agreed to initiate a new project for the optimization of management of
Optical Network Units (ONU) at scale. This project, called WT-505: ONU
Management at Scale, is intended to be an enhancement of the existing
specification, TR-385: ITU-T xPON YANG Modules. The following describes
the issues and considerations that led to the need for the new project.
– See list for attachment

Liaison content:

 

Broadband Forum Liaison To: 

Kent Watsen, IETF NETMOD WG Co-Chair,   
 

Lou Berger, IETF NETMOD WG Co-Chair,   
 

Scott Mansfield, ITU-T Q14/15 Rapporteur,  
  

Liping Chen, ITU-T Q14/15 Associate Rapporteur,   


Paul Nikolich, IEEE 802 Chair,   


Glenn Parsons, IEEE 802.1 Chair,   
 

Jessy Rouyer, IEEE 802.1 Vice Chair,   


David Law, IEEE 802.3 Chair,    

Adam Healey, IEEE 802.3 Vice Chair,   
 

 

From:

Lincoln Lavoie
Broadband Forum Technical Committee Chair   
  

 

Liaison Communicated By:

Ken Ko

Broadband Forum Managing Director   


 

Date: 8th June 2023

 

Subject: For Information: New Project for Addressing ONU Management at Scale

 

The Broadband Forum Fiber Access Networks (FAN) Work Area recently agreed to 
initiate a new project for the optimization of management of Optical Network 
Units (ONU) at scale. This project, called WT-505: ONU Management at Scale, is 
intended to be an enhancement of the existing specification, TR-385: ITU-T xPON 
YANG Modules. The following describes the issues and considerations that led to 
the need for the new project.

 

In contrast to many other transport technologies, a single PON interface can 
multiplex as many as 128 ONUs. It is also typical for a single Optical Line 
Termination (OLT) to contain many such PON interfaces.  

 

At this level of dimensioning, the OLT YANG modeled configuration data becomes 
very large due to the high number of ONUs to be managed. With current TR-385 
and TR-383 Broadband Forum YANG models, the management of large OLTs suffers 
severe performance degradation. Examples of such degradation are:

*   Time to validate YANG constraints when configuring ONU data nodes 
(e.g., due to very large OLT interface and hardware component lists)

*   Time to delete an ONU (time to retrieve all data nodes of the ONU)

*   Time to perform a  of a full OLT configuration.

 

Many Broadband Forum contributions have been submitted and discussed that 
demonstrate ONU management needs to be optimized to keep the OLT manageable. It 
has been determined that efficient optimization of ONU management requires the 
following measures: 

*   Collocate ONU data nodes per ONU, rather than have them interleaved 
with OLT data nodes (e.g., in the same interface or hardware component list) as 
per TR-385. This involves defining a list of ONUs in the OLT where each ONU 
entry contains all ONU data nodes.

*   Bring a strong reduction of the configuration data size per ONU. This 
will be achieved using ONU templates combined with the use of shared ONU 
profiles.

 

IETF schema mount was considered as a solution for collocating ONU data nodes. 
There were drawbacks to this approach, however. The size of the datastore was 
not improved as the same data nodes are mounted per ONU. There is also a known 
lack of tooling that supports schema mount making it difficult for this 
solution to be broadly implemented in a timely manner. The following 
alternative has been agreed upon.

 

Complement current standard YANG models with new models that implement 
optimization measures 

Re: [netmod] WGLC on node-tags-09

[Adrian Farrel]

Briefly in line with [AF2]
Tl;dr  All is good.
Adrian

-Original Message-
From: Qin Wu  
Sent: 05 July 2023 05:14
To: adr...@olddog.co.uk; 'Kent Watsen' ; netmod@ietf.org
Subject: RE: [netmod] WGLC on node-tags-09

Hi, Adrian:
-邮件原件-
发件人: Adrian Farrel [mailto:adr...@olddog.co.uk] 
发送时间: 2023年6月28日 23:25
收件人: Qin Wu ; 'Kent Watsen' ; 
netmod@ietf.org
主题: RE: [netmod] WGLC on node-tags-09

Thanks Qin,

In line...

Adrian

== Discussion ==

Section 7.

I'm not completely comfortable with the way you use the base identity 
node-tag-type to capture the variants defined in the IANA registry shown in 
9.2. What happens when another document defines a new IETF tag type?
Is it necessary to also write a new YANG module that augments this one?
Or to respin this document? Those feel to me to be very ugly!

The alternatives might be:

1. You simply use the tag as a string (i.e., using the typedef tag) and
   rely on implementations to know what the tag type means.

2. You change the identity to an Integer, and you include an integer in
   the IANA registry so that new tags are just new entries.

3. You move the base identity into an IANA-managed YANG module that is
   updated by IANA automatically in lockstep with the IETF tags registry

[Qin Wu] Good comment, Andy also raised similar comment, the motivation of 
introducing node-tag-type identities is to address Jurgen's comment and try to 
make the node tag mechanism generic enough and allow future extension, we did 
provide an example in Appendix A which allow you add additional Auxiliary Data 
Property in the module extension.

one thing I want to clarify is
node-tag-type identities did capture the variants defined in the IANA registry, 
but node-tag-type identities will not be registered together with IETF YANG 
Data Node Tags. Secondly, we did use tag as a string, we choose to use the same 
typedef tag used for module tag, now for node tag. 
We have two ways to address this comment:
1. we completely remove identities from this module, the downside is it doesn't 
allow any future module extension.
2. we keep some of these identities for second level data node classification, 
e.g., summary, counter, gauge, unknown, etc but remove packet loss ,jitter 
,delay identities from this draft since it seems to  duplicate with what has 
already been defined in IANA registry, in addition, we remove some of IETF yang 
data node tags including summary, counter, gauge and unknown, which is 
redundant with identities  for second level data node classification.

[AF] I support the motivation. I would like the node tag mechanism to be 
extensible.
I didn't notice the purpose of Appendix A (perhaps it could use a little more 
explanation?).
I think your option 1 would only work if we move the identities to a new module 
(possibly under IANA control - my option 3) Your option 2 looks worthy of 
consideration, but it is a big change at this stage in the process - I don't 
want to cause disruption to the WG process as I am not an implementer of this 
technology.
I wonder whether my options 1 and 2 wouldn't be simpler.

[Qin Wu-1] My proposal. Removing identityref type from YANG module is aimed at 
avoiding duplication with IETF node tag. In addition, I prefer to align with 
module tag RFC8819 for simplicity. The idea is to use YANG extension to provide 
extensibility,
I will update the draft to reflect this.

[AF2] Simplicity is good. Avoiding duplication is good. Aligning with published 
RFCs is good.

--

I think that Section 1, in introducing the concept of tags, should spend a 
sentence describing YANG Module Tags [RFC8819] so that we can see how the YANG 
tags already exist, and how this work develops the idea.

[Qin Wu] I think we have already done this, see relevant text in section 1 as 
follows:
"
   To that aim, this document defines a YANG module [RFC7950] that
   augments the YANG Module Tags ([RFC8819]) to provide a list of node
   entries to add or remove node tags as well as to view the set of node
   tags associated with specific data nodes or instance of data nodes
   within YANG modules.
"

[AF] Hmmm. It's true that you provide the pointer to RFC 8819. I just wondered 
about a quick description of what it does.
But I don't insist on this change.

[Qin Wu-1] Here is the proposed change to introduction section
OLD TEXT:
"
For the specific case of YANG data models, a module tag is defined as a string 
that is associated with a module name at the module level
"
NEW TEXT:
"
For the specific case of YANG data models, a module tag has already been 
defined as a string that is associated with a module name at the module level 
for YANG modules classification.
"

[AF2] OK

--

Apart from being able to deduce it from Section 4.3, it is not absolutely clear 
from Section 4 that the colon has special meaning. That is that all prefixes 
now and in the future are delimited by the colon.
(This is important because, absent a colon, 

Re: [netmod] WGLC on node-tags-09

[Adrian Farrel]

Thanks Qin,

In line...

Adrian

== Discussion ==

Section 7.

I'm not completely comfortable with the way you use the base identity
node-tag-type to capture the variants defined in the IANA registry shown in
9.2. What happens when another document defines a new IETF tag type?
Is it necessary to also write a new YANG module that augments this one?
Or to respin this document? Those feel to me to be very ugly!

The alternatives might be:

1. You simply use the tag as a string (i.e., using the typedef tag) and
   rely on implementations to know what the tag type means.

2. You change the identity to an Integer, and you include an integer in
   the IANA registry so that new tags are just new entries.

3. You move the base identity into an IANA-managed YANG module that is
   updated by IANA automatically in lockstep with the IETF tags registry

[Qin Wu] Good comment, Andy also raised similar comment, the motivation of
introducing
node-tag-type identities is to address Jurgen's comment and try to make the
node tag mechanism 
generic enough and allow future extension, we did provide an example in
Appendix A which allow you add additional Auxiliary Data Property in the
module extension.

one thing I want to clarify is
node-tag-type identities did capture the variants defined in the IANA
registry, but 
node-tag-type identities will not be registered together with IETF YANG Data
Node Tags. Secondly, we did use tag as a string, we choose to use the same
typedef tag used for module tag, now for node tag. 
We have two ways to address this comment:
1. we completely remove identities from this module, the downside is it
doesn't allow any future module extension.
2. we keep some of these identities for second level data node
classification, e.g., summary, counter, gauge, unknown, etc but remove
packet loss ,jitter ,delay identities from this draft since it seems to
 duplicate with what has already been defined in IANA registry, in addition,
we remove some of IETF yang data node tags including summary, counter, gauge
and unknown, which is redundant with identities
 for second level data node classification.

[AF] I support the motivation. I would like the node tag mechanism to be
extensible.
I didn't notice the purpose of Appendix A (perhaps it could use a little
more explanation?).
I think your option 1 would only work if we move the identities to a new
module (possibly under IANA control - my option 3)
Your option 2 looks worthy of consideration, but it is a big change at this
stage in the process - I don't want to cause disruption to the WG process as
I am not an implementer of this technology.
I wonder whether my options 1 and 2 wouldn't be simpler.

--

I think that Section 1, in introducing the concept of tags, should spend a
sentence describing YANG Module Tags [RFC8819] so that we can see how the
YANG tags already exist, and how this work develops the idea.

[Qin Wu] I think we have already done this, see relevant text in section 1
as follows:
"
   To that aim, this document defines a YANG module [RFC7950] that
   augments the YANG Module Tags ([RFC8819]) to provide a list of node
   entries to add or remove node tags as well as to view the set of node
   tags associated with specific data nodes or instance of data nodes
   within YANG modules.
"

[AF] Hmmm. It's true that you provide the pointer to RFC 8819. I just
wondered about a quick description of what it does.
But I don't insist on this change.

--

Apart from being able to deduce it from Section 4.3, it is not absolutely
clear from Section 4 that the colon has special meaning. That is that all
prefixes now and in the future are delimited by the colon.
(This is important because, absent a colon, there is no way to distinguish
an non-colon user prefix from any registered prefix.) This means that:
- Future definitions of tag values might not realise that they are
  supposed to use a colon - you should clarify that all prefixes end
  with a colon noting that the colon is not a separator but is part of
  the prefix. This does beg the question about separators in the
  prefixes and in the tag values
  - Prefixes that contain colons will cause confusion and so you should
probably make it a 'MUST NOT'
  - Tag values (after the prefix) that contain colons may cause 
confusion so you should probably make this a RECOMMENDation, 
although 4.2 suggests the use of colons as further separators.

An alternative to all this is that you define the colon as the separator,
and change the tag names to not include colons.

But 9.1 makes it pretty clear that you expect all registered prefixes to end
with a colon.

[Qin Wu] That's really a good comment, so Tag = Tag prefix+ Tag Value,
Colon is part of Tag prefix if you expect all registered prefix to end with
a colon.
The question is whether we see colon as separator or portion of the tag
prefix.
Do we need to make tag prefix is mandatory to have for a tag?

[AF] I don't really mind.
The closest to what you have is...

Re: [netmod] WGLC on node-tags-09

[Adrian Farrel]

Hi,

I have reviewed this draft during the normal working group process, and
I just re-read it as part of working group last call. I believe the
function defined is useful, and I think the draft is ready to advance 
towards publication once my list of small points have been addressed.

Cheers,
Adrian

== Discussion ==

Section 7.

I'm not completely comfortable with the way you use the base identity
node-tag-type to capture the variants defined in the IANA registry shown
in 9.2. What happens when another document defines a new IETF tag type?
Is it necessary to also write a new YANG module that augments this one?
Or to respin this document? Those feel to me to be very ugly!

The alternatives might be:

1. You simply use the tag as a string (i.e., using the typedef tag) and
   rely on implementations to know what the tag type means.

2. You change the identity to an Integer, and you include an integer in
   the IANA registry so that new tags are just new entries.

3. You move the base identity into an IANA-managed YANG module that is
   updated by IANA automatically in lockstep with the IETF tags registry

== Minor ==

idnits reports some minor issues...

  ** There are 4 instances of too long lines in the document, the longest
one
 being 7 characters in excess of 72.

  == Unused Reference: 'RFC6022' is defined on line 834, but no explicit
 reference was found in the text

  == Unused Reference: 'RFC8641' is defined on line 871, but no explicit
 reference was found in the text

  == Unused Reference: 'RFC9195' is defined on line 880, but no explicit
 reference was found in the text

  == Unused Reference: 'RFC9196' is defined on line 884, but no explicit
 reference was found in the text

--

I think that Section 1, in introducing the concept of tags, should spend
a sentence describing YANG Module Tags [RFC8819] so that we can see how
the YANG tags already exist, and how this work develops the idea.

--

Apart from being able to deduce it from Section 4.3, it is not 
absolutely clear from Section 4 that the colon has special meaning. That
is that all prefixes now and in the future are delimited by the colon.
(This is important because, absent a colon, there is no way to 
distinguish an non-colon user prefix from any registered prefix.)
This means that:
- Future definitions of tag values might not realise that they are
  supposed to use a colon - you should clarify that all prefixes end
  with a colon noting that the colon is not a separator but is part of
  the prefix. This does beg the question about separators in the
  prefixes and in the tag values
  - Prefixes that contain colons will cause confusion and so you should
probably make it a 'MUST NOT'
  - Tag values (after the prefix) that contain colons may cause 
confusion so you should probably make this a RECOMMENDation, 
although 4.2 suggests the use of colons as further separators.

An alternative to all this is that you define the colon as the separator,
and change the tag names to not include colons.

But 9.1 makes it pretty clear that you expect all registered prefixes to
end with a colon.

--

4.1

9.2 constrains these tags by saying that they must "conform to Net-
Unicode as defined in [RFC5198], and shall not need normalization".  I
think you should state this in this section using BCP 14 language.

--

4.2

   These tags are defined by the vendor that implements the module, and
   are not registered with IANA.  However, it is RECOMMENDED that the
   vendor includes extra identification in the tag to avoid collisions,
   such as using the enterprise or organization name following the
   "vendor:" prefix (e.g., vendor:entno:vendor-defined-classifier).

Surely you have to go further than recommending? How will interop work
unless you require 'entno' to be present?

But here you have said "enterprise or organization name" and then used
a field called 'entno' which looks very much like an Enterprise Number 
as registered by IANA (RFC2578) which would, IMHO, be a good solution.

--

4.4 looks reasonable to me, but I think you need to add text to talk 
about how an implementation is supposed to handle a tag prefix it 
doesn't know (for example, one that is defined and added to the registry
after the code was released). I suspect the intention is that all tags
can be processed as opaque strings, and the prefixes are there in order
to achieve uniqueness of the strings, but do not need to be processed.
Thus all implementations should be able to process all tags regardless
of their prefixes.

--

5.2

   An implementation MAY include additional tags associated with data
   nodes within a YANG module.  These tags SHOULD be IETF ((i.e.,
   registered) ) or vendor tags.

It would be good to:
- Expand on the "MAY" to say why an implementation might do that
- Add an alternative to the "SHOULD" and an indication of why an
  implementation might vary from the "SHOULD".

--


8.1 is intended as a new section of RFC 8407 so I think 

[netmod] What's the plan with draft-ietf-netmod-node-tags

[Adrian Farrel]

Hi,

Discussion of this document seemed to fizzle out in August, and the last
email seems to be Qin saying "I'm happy to make no change if no change is
needed."

Where does that leave us with regards to the WG last call comments and the
discussion at IETF-114?

Thanks,
Adrian

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

Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

[Adrian Farrel]

Hi Qin,

 

Very good. Thanks for this. Almost perfect convergence.

 

Just one point left.

 

9.1

 

   This registry allocates tag prefixes.  All YANG Data Object Tags

   should begin with one of the prefixes in this registry.

 

That's not quite true, is it? 

 

[Qin Wu] I think this is recommendation for all YANG data node tags
beginning with one of prefixed in this registry,

Maybe we should use RFC2119 language,e.g., replace 'should'with 'SHOULD'?

 

Ah, sorry, I wasn't clear.

The user tags are Data Objects Tags, but they don't have to begin with a
prefix. 

Since this section is IANA instructions, it isn't really appropriate to use
2119 language.

 

I think, re-reading the whole of Section 9.1 again, maybe this paragraph
isn't actually necessary at all. It doesn't tell IANA anything they need to
know, and it doesn't cover anything that isn't already covered elsewhere in
the document.

 

Best,

Adrian

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

Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

[Adrian Farrel]

Hi,

 

I had previously provided a review of this document (at revision -04),

and the authors worked to address my comments through the subsequent

revisions.

 

I have now re-read this document during WG last call. Most of my 

comments are nits, but there are a few suggestions of substance.

 

Once these are all resolved the document will, in my opinion, be

ready for publication.

 

Best,

Adrian

 



 

The document needs a note somewhere near the top.

 

[RFC Editor Note: Please replace  in the text with the RFC number

assigned to this document, and remove this note.]

 

---

 

Abstract

 

s/characteristics/characteristic/

s/the module definition/the definition of the module/

 

---

 

Introduction

 

s/represent a portion/represent only a portion/

 

OLD

   there is no consistent classification criteria or

   representation

NEW

   there are no consistent classification criteria or

   representations

END

 

   This document defines self-describing data object tags and associates

   them with data objects within a YANG module, which:

I think that may be s/associates them/shows how they may be associated/

 

s/by the NETCONF/by a NETCONF/

 

---

 

4.

 

   All data object tags SHOULD begin with a prefix indicating who owns

   their definition.  An IANA registry (Section 9.1) is used to register

   data object tag prefixes.  Initially, three prefixes are defined.

 

I'm not sure who you are binding with this use of uppercase SHOULD or

what variance you are allowing.

 

I think you are probably giving instructions to the authors of future

documents that define new tags (since the ones you define do all have

a prefix - ietf:, vendor:, and user:).

 

But the reason you have "SHOULD" not "MUST" is because of the text in

4.3 (and see below for a comment on that).

 

So how about being more explicit with something like:

 

   All data object tags (except in some cases of user tags as described

   in Section 4.3) begin with a prefix indicating who owns their

   definition.  An IANA registry (Section 9.1) is used to register data

   object tag prefixes.  Initially, three prefixes are defined.

 

---

 

4.2

 

   These tags are defined by the vendor that implements the module, and

   are not registered with IANA.  However, it is RECOMMENDED that the

   vendor includes extra identification in the tag to avoid collisions,

   such as using the enterprise or organization name following the

   "vendor:" prefix (e.g., vendor:example.com:vendor-defined- 

   classifier).

 

I'm still not really happy with the disambiguation achieved using "the

enterprise or organization name". There is no registry of enterprise or 

organisation names, so there is no way to be sure of uniqueness. But if

you recommended the use of an enterprise number (possibly with the 

secondary prefix entno:) then things would be cleaner.

 

This would also enable you to have an example that did not use a URN

which is not really an example of an enterprise name or organization

name. (There is an enterprise number reserved for documentation - 32743)

 

---

 

4.3

 

The ambiguity in this section needs to be sorted out. It's clear to me 

that you:

- prefer user tags to have the prefix "user:"

- you allow user tags without that prefix provided they do not contain

  a colon

 

However, you have...

 

   A user tag is any tag that has the prefix "user:".  For the avoidance

   of confusion, the colon (":") when it appears for the first time, is

   always assumed to be the separator between a prefix and the rest of

   the tag.  And so, when a user tag does not have a prefix, it MUST NOT

   contain a colon.

 

   These tags are defined by a user/administrator and are not meant to

   be registered with IANA.  Users are not required to use the "user:"

   prefix; however, doing so is RECOMMENDED as it helps avoid

   collisions.

 

The first sentence defines a user tag to have the prefix "user:" which

is then contradicted. Further, I don't think that there will be

collisions because of the no-colon rule. 

 

Maybe this could be sorted out by replacing the text as:

 

   User tags are defined by a user/administrator and are not registered

   by IANA.   

 

   Any tag with the prefix "user:" is a user tag.  Furthermore, any 

   tag that does not contain a colon (":", i.e., has no prefix) is also

   a user tag.  Users are not required to use the "user:"

   prefix; however, doing so is RECOMMENDED.

 

---

 

4.4 conflicts with 4.3. That is, 4.3 says that tags can start without

any of those three prefixes without being reserved.

 

I don't think "reserved in the context of specifications" has a clear

meaning.

 

I think you need...

 

4.4.  Reserved Prefixes

 

   Section 9.1 describes the IANA registry of tag prefixes.  Any prefix

   not included in that registry is reserved for future use, but tags

   starting with such a prefix are still valid tags.

 

Re: [netmod] A review of draft-ietf-netmod-node-tags

[Adrian Farrel]

Hi again, Qin.

Just closing on the one remaining point.

Adrian

>>There is some contradiction between and within sections 4.3 and 4.4
>>
>>1. If a user tag is defined as any tag that has the prefix "user:"
>>   how can you then say that users are not required to use the "user:"
>>   prefix? That would mean that a user tag is any tag that does or
>>   does not have the prefix "user:"
> [Qin Wu] Correct.
>>2. If any tag not starting with "ietf:", "vendor:", or "user:" is 
>>   reserved, how can a user create a tag that doesn't start with
>>   "user:"?
> [Qin Wu] :I understand your concern, but my understanding on reserved tag,
upon such reserved tag is allocated, it should start with "xxx:",
> Therefore such reserved tag can not be seen as user tag. It seems
unlikely there is contraction if my understanding is correct.
> Correct me if I am wrong.
>
> [AF] Ah, I missed the point!

>A user tag is:
>- any tag with the prefix "user" 
>or
>- any tag that has no prefix at all

>Thus, and for the avoidance of confusion, the colon (":") when it appears
for the first time, is always assumed to be the separator between a prefix
and the rest of the tag. And so, when a user tag does not have a prefix, it
MUST NOT contain a colon. 
[Qin Wu] Your understanding is correct, if you think I should add some text
to make this more clear, I am happy to do so.

Maybe just a sentence. I know that my confusion is not indicative of the
state of the average reader, but maybe there are others who would be just as
confused.



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

Re: [netmod] A review of draft-ietf-netmod-node-tags

[Adrian Farrel]

Thanks Qin,

Good convergence. Edited down to just the remaining points.

Best,
Adrian

>There is some contradiction between and within sections 4.3 and 4.4
>
>1. If a user tag is defined as any tag that has the prefix "user:"
>   how can you then say that users are not required to use the "user:"
>   prefix? That would mean that a user tag is any tag that does or
>   does not have the prefix "user:"
[Qin Wu] Correct.
>2. If any tag not starting with "ietf:", "vendor:", or "user:" is 
>   reserved, how can a user create a tag that doesn't start with
>   "user:"?
[Qin Wu] :I understand your concern, but my understanding on reserved tag,
upon such reserved tag is allocated, it should start with "xxx:",
 Therefore such reserved tag can not be seen as user tag. It seems
unlikely there is contraction if my understanding is correct.
 Correct me if I am wrong.

[AF] Ah, I missed the point!

A user tag is:
- any tag with the prefix "user" 
or
- any tag that has no prefix at all

Thus, and for the avoidance of confusion, the colon (":") when it appears
for the first time, is always assumed to be the separator between a prefix
and the rest of the tag. And so, when a user tag does not have a prefix, it
MUST NOT contain a colon. 

---

>Section 9.1 reasonably uses the "Specification Required" assignment policy.
But, according to 8126, that policy requires the appointment of a designated
expert. According to section 5.3 of 8126...

>   When a designated expert is used, the documentation should give clear
>   guidance to the designated expert, laying out criteria for performing
>   an evaluation and reasons for rejecting a request.

>So you need to add a section to cover this. It can be simple if the rule is
"read the specification, check it is permanent and readily available, and
watch for inappropriate use of language." Or it might be more complex if you
want the DE to check more stuff.
[Qin Wu] Thanks for the reference, I re-read section 5.3 of RFC8126, it also
said:
"
   In the case where
   there are no specific documented criteria, the presumption should be
   that a code point should be granted unless there is a compelling
   reason to the contrary (and see also Section 5.4).
"
My understanding is documented criteria is not mandatory, if you have code
point value (i.e., prefix value in section 9.1)that needs to be allocated
based on IANA request.
I think section 9.1 may fall into this case. 

[AF] I agree with your reading of 8126, but also that it is hard for someone
in 5 years' time to know whether you left out guidance for the DE by mistake
or intended that this "no specific criteria" clause should apply.

[AF] Therefore, if you have no specific criteria, I think it is good to say
so as...

There is no specific guidance for the Designated Expert and there is a 
presumption that a code point should be granted unless there is a
compelling reason to the contrary.

[Qin] For section 9.2, I agree to add one rule, i.e., "IANA assigned tags
must conform to Net-Unicode as defined in [RFC5198], and they shall not need
normalization". I believe this is the guidance given to the designated
expert.

[AF] That's great. Can you make that...
"The Designated Expert is expected to verify that IANA assigned tags conform
to "

Hope this address your comment.

>Section 5 has
>   As the main consumer of
>   data object tags are users, users may also remove any tag from a live
>   server, no matter how the tag became associated with a data object
>   within a YANG module.
>
>Suppose there are two users accessing the same YANG data objects on a live
server. This doesn't seem unreasonable in the case of different users or
monitoring tools reading data about the network or devices.
>
>Doesn't this text lead to "warring tag removal" where one user adds a tag,
and another user removes it?
>
>Maybe this is limited to user tags so that each user may have their own
tags. But, in this case, it needs to be clearer what a user tag contains and
how it is used. 
>
>It would still be pretty annoying is Benoit added user:benoit to some data
objects, and I went and removed them.

[Qin Wu] Yes, I believe it is limited to user tags, since IETF tags are
design time tags, so does implementation tags. It is unlikely to face the
situation "warring tag removal".
But for user tag, your are right, user has its own tags and each user may
have different privilege therefore. User with low privilege can not remove
the tag owned by high privilege user.
But I am not sure this is the scope of this document, It seems to me
implementation specific and should not in the scope of this document, agree?
(See also section 5.3)

[AF] Agree about implementation. But maybe, "An implementation MAY include
mechanisms to stop users' removing each other's tags or to apply privilege
levels to different users."

>Should section 10 talk about the risks associated with an attacker adding
or removing tags so that a requester gets the wrong data?

[netmod] A review of draft-ietf-netmod-node-tags

[Adrian Farrel]

Hi,

Thanks for this document which I found clear and easy to read. I think
you have defined a small, but particularly valuable feature.

I have a few comments and a large number of nits (sorry).

Best,
Adrian

== Major ==

There is some contradiction between and within sections 4.3 and 4.4

1. If a user tag is defined as any tag that has the prefix "user:"
   how can you then day that users are not required to use the "user:"
   prefix? That would mean that a user tag is any tag that does or
   does not have the prefix "user:"

2. If any tag not starting with "ietf:", "vendor:", or "user:" is 
   reserved, how can a user create a tag that doesn't start with
   "user:"?

3. Section 4.4 could usefully point at Section 9.1 and say that
   "further tags may be assigned by future specifications".

---

Section 9.1 reasonably uses the "Specification Required" assignment 
policy. But, according to 8126, that policy requires the appointment of
a designated expert. According to section 5.3 of 8126...

   When a designated expert is used, the documentation should give clear
   guidance to the designated expert, laying out criteria for performing
   an evaluation and reasons for rejecting a request.

So you need to add a section to cover this. It can be simple if the rule
is "read the specification, check it is permanent and readily available,
and watch for inappropriate use of language." Or it might be more 
complex if you want the DE to check more stuff.

== Minor ==

The Abstract need to explicitly call out "This document updates RFC 8407
by 

The Introduction should repeat that statement and add some detail. In fact
we don't even find a mention of 8407 until Section 8, and even then there
is no hint about what the "update" is. Although, in Section 1 you have

   Section 8 provides guidelines for authors of YANG data models.

That would be the ideal place to describe the update.

---

Figure 1 and its text are a little confusing.

1. It would help to lift the top Object Tag one line so there is a pipe
   ('|') to separate it from Data Object 1

2. The term "have" is not explained. Given the direction of the arrow,
   I think this means "is contained by".

3. The text says "In Figure 1, data objects can contain other data
   objects called subobjects." That's fine, but it would be easier to
   read the figure is data objects 2, 3, and 4 were marked as 
   sub-objects.

4. The text has:

   A data object may contain one single object tag, or one single
   property tag, or one single metric tag.  In many cases, a data object
   only contains one single metric tag.  
   
   That's a bit odd. I mean, the first sentence says, "A, B, or C", and
   the second sentence says "In many cases C". How does the second
   sentence add anything?

5. The text has:
   
   the data object tagged
   with the metric tag also can have one or multiple MetricType tags
   and/or one single multi-source tag.

   These additional tags are not shown on the figure.

---

Section 5 has
   As the main consumer of
   data object tags are users, users may also remove any tag from a live
   server, no matter how the tag became associated with a data object
   within a YANG module.

Suppose there are two users accessing the same YANG data objects on a 
live server. This doesn't seem unreasonable in the case of different
users or monitoring tools reading data about the network or devices.

Doesn't this text lead to "warring tag removal" where one user adds a
tag, and another user removes it?

Maybe this is limited to user tags so that each user may have their 
own tags. But, in this case, it needs to be clearer what a user tag
contains and how it is used. 

It would still be pretty annoying is Benoit added user:benoit to some
data objects, and I went and removed them.

(See also section 5.3)

...Reading the YANG module itself, I wonder whether "add" and "remove"
are ambiguous. Sometimes you may mean adding or removing a tag to/from
a data object. Sometimes you may mean adding or removing to/from a 
filter.

---

9.1

OLD
   Other standards organizations (SDOs) wishing to allocate their own
   set of tags should allocate a prefix from this registry.
NEW
   Other standards organizations (SDOs) wishing to allocate their own
   set of tags should request the allocation of a prefix from this
   registry.
END

---

9.2

   Each YANG data object can have one 'opm' tag, zero or one metric-type
   tag, zero or one multi-source tag.

Is this an instruction for IANA for the management of the registry? I 
don't think it is, and so it should be removed from this section.

---

9.3 and 9.4

These sections include the text "the following registration has been
made:", but it hasn't been (yet). You just need to phrase this text as a
request.

---

Should section 10 talk about the risks associated with an attacker 
adding or removing tags so that a requester gets the wrong data?

Should the section also talk about how the presence of tags may reveal
information 

Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

[Adrian Farrel]

Thanks Juergen and Randy,

There's plenty here to chew on. Happy New Year's Eve reading 

Cheers,
Adrian

-Original Message-
From: Juergen Schoenwaelder  
Sent: 29 December 2020 18:56
To: Adrian Farrel 
Cc: 'NETMOD Group' 
Subject: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

Adrian,

some key issues when it comes to policy-based management systems:

 - What is an adequate abstraction level to express policies and intent?

   This question has no simple answer. I believe policies need to be
   readable and hence they need to be expressed at a high level of
   abstraction and in a suitable _language_. High-level policy
   expression may be compiled down into more verbose primitive
   representations that are closer to an execution abstraction. A
   common pitfall is to start somewhere in the middle of several
   layers of abstraction and then getting stuck with something awkward
   to put a clean higher layer abstract onto and to compile things
   down to _efficient_ instrumentations.

 - Where are policies executed?

   This can range from a logically centralized policy execution
   engine, which is part of what people call an orchestrator these
   days, to fully distributed policy execution models. In reality, you
   likely want to distribute functions dynamically but this makes
   solutions technically much more complicated. Given today's scalable
   computing and networking capabilities, logically centralized
   solutions are on the rise and have replaced the distributed
   approaches of the 90s.

 - When to detect and resolve policy conflicts?

   Detecting and resolving conflicts in larger collections of policies
   is non-trivial. This includes problems ranging from micro timescale
   atomicity issues to larger timescale stability issues (interacting
   policy control loops). If policy execution is distributed (or the
   event / information sources are distributed), this ultimately
   resolves to problems such as taking consistent snapshots or finding
   ways to work with inconsistent observations of a distributed system
   that are guaranteed to converge to stable states (self-stabilizing
   algorithms).

 - Who is interested in interoperable policy representations / languages?

   The IETF is about interoperability. What are the business models
   that push for interoperable policy based management standards? Who
   benefits from having an interoperable standard and how much effort
   are organizations willing to invest into engineering a reasonable
   solution addressing the other (non-trivial) questions raised above?
   Will they be implementing the solution in their products?

My position is that there are way too many difficult technical issues
to resolve for this work to be viable for the IETF. Instead, I suggest
that people go and work out solutions and once the silver bullet has
been found, bring it to the IETF. (Historically, all attempts to cast
policies into existing data models such as MIB modules or LDAP schema
led to something awkward and unusable. I believe YANG modules are no
different.)

/js

Some relevant RFCs (there may be more):

3052 Service Management Architectures Issues and Review. M. Eder, S. Nag.
 January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI:
 10.17487/RFC3052)

3084 COPS Usage for Policy Provisioning (COPS-PR). K. Chan, J. Seligson,
 D. Durham, S. Gai, K. McCloghrie, S. Herzog, F. Reichmeyer, R.
 Yavatkar, A. Smith. March 2001. (Format: TXT, HTML) (Status:
 HISTORIC) (DOI: 10.17487/RFC3084)

3159 Structure of Policy Provisioning Information (SPPI). K. McCloghrie,
 M. Fine, J. Seligson, K. Chan, S. Hahn, R. Sahita, A. Smith, F.
 Reichmeyer. August 2001. (Format: TXT, HTML) (Status: HISTORIC)
 (DOI: 10.17487/RFC3159)

3318 Framework Policy Information Base. R. Sahita, Ed., S. Hahn, K. Chan,
 K. McCloghrie. March 2003. (Format: TXT, HTML) (Status: HISTORIC)
 (DOI: 10.17487/RFC3318)

3460 Policy Core Information Model (PCIM) Extensions. B. Moore, Ed..
 January 2003. (Format: TXT, HTML) (Updates RFC3060) (Status:
 PROPOSED STANDARD) (DOI: 10.17487/RFC3460)

3644 Policy Quality of Service (QoS) Information Model. Y. Snir, Y.
 Ramberg, J. Strassner, R. Cohen, B. Moore. November 2003. (Format:
 TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3644)

3198 Terminology for Policy-Based Management. A. Westerinen, J.
 Schnizlein, J. Strassner, M. Scherling, B. Quinn, S. Herzog, A.
 Huynh, M. Carlson, J. Perry, S. Waldbusser. November 2001. (Format:
 TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3198)

4011 Policy Based Management MIB. S. Waldbusser, J. Saperia, T. Hongal.
 March 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI:
 10.17487/RFC4011)

4104 Policy Core Extension Lightweight Directory Access Protocol Schema
 (PCELS). M. Pana, Ed., A. Reyes, A. Barba, D. Moron, M. Brunner.
 June 2005. (Format: TXT, HTML) (Updates RFC3703

Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

[Adrian Farrel]

Hi Juergen,

What you say about learning lessons from the past is wise and valuable.

Sadly (well, it's a good thing, really) we have new people in the IETF and
the memory of events over the last 20 years are not immediately accessible
to them. Others, who are old and grey, have been around that long but were
not necessarily involved in previous ECA discussions.

Since "intent-based networking" is a big thing once again (see recent
reports of acquisitions in this sector) the excitement about ECA may be
forgiven, but it would help to ground the discussions if those who can
remember previous efforts would share their experiences or at least some
pointers.

Best,
Adrian

-Original Message-
From: netmod  On Behalf Of Juergen Schoenwaelder
Sent: 23 December 2020 18:09
To: Andy Bierman 
Cc: NetMod WG Chairs ; NETMOD Group

Subject: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

On Wed, Dec 23, 2020 at 07:05:44AM -0800, Andy Bierman wrote:
> On Wed, Dec 23, 2020 at 3:14 AM tom petch  wrote:
> 
> > From: netmod  on behalf of Dhruv Dhody <
> > dhruv.i...@gmail.com>
> > Sent: 21 December 2020 17:12
> >
> > Hi Lou, WG,
> >
> > I find the motivation in the Introduction to be focused on ECA at the
> > network devices (with all the talk about issues with Centralized
> > network management).
> >
> > I see the value of ECA on the controller as well, say a customer
> > network controller or an orchestrator can set the ECA on a central
> > controller (reference ACTN in TEAS WG). Perhaps you would consider
> > adding a sentence to describe this as well. The client-server
> > terminology in the rest of the document covers it already.
> >
> > And I do see value in this and support adoption.
> >
> > 
> > My take is that the I-D is unclear on what ECA is.
> >
> > ECA has been worked on in at least two IETF WG AFAICT.  It cropped up in
> > I2RS but as I recall, it was along the lines of 'This is ECA'  'No It is
> > not'  'Yes it is' which gave me the impression that ECA is not a
> > well-defined, or well-understood, term.
> >
> > More recently, I2NSF have produced a YANG capability-data-model which is
> > 55 pages of ECA.  Lacking a definition in this netmod I-D, I am unclear
> > what the relationship is between the I2NSF I-D and the netmod I-D,
whether
> > or not they are using ECA in the same sense.
> >
> >
> Hi Tom,
> 
> It usually helps to agree on the problem-space before focusing on the
> solution-space.
> ECA seems like a methodology (ala MVC) more than anything else.
> The problem statement seems to be that some client tasks need to be
handled
> on the
> server using ECA methodology, instead of on the client.
> Which tasks? Seems to be any task of arbitrary purpose or complexity.
> And now the scope is supposed to include controllers (just another
client),
> so the problem-stmt
> is even less clear.
> 
> The traditional approach is to pick specific client tasks to move to the
> server.
> The example of detecting and reporting route-flaps has been used.
> (No ECA example of this complexity has been provided yet).
> The traditional approach would be to write a route-flap-detection YANG
> module with some
> configuration, monitoring data, and notification events.
> 
> The generalized approach is likely to be extremely complex to standardize
> and implement.
>

ECA work has a long 20+ year tradition in the IETF and several
specifications have been published over the years by various working
groups. As far as I can tell, none of them got traction in terms of
signifiant deployment of interoperable implementations.

I would have hoped that the next iteration of ECA work would have
started with a deep reflection about why all the previous attempts
failed to gain traction and some genuine insights how to design things
differently in order to improve the likelihood to have impact.

/js

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

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

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

Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

[Adrian Farrel]

Hi,

I have generally been sceptical about Intention-based network operations within 
the IETF, and I was ambivalent about this document at the first adoption poll. 

However, I think that some good work has been done since then and the document 
has reached a level where the WG could adopt it and further refine it. There is 
clearly a body of people who want to work on it, and it seems to be within the 
WG scope, so I support adoption.

I also think that splitting this piece off the larger body of Intention-based 
work is a wise first step.

Here are a few comments for the authors based on a quick reading...

Abstract.
I appreciate the brevity of the Abstract, but I don't find it very clear. 
Specifically, what is "the server" and what role would it play absent this YANG 
model? Conversely, who/what is delegating some of the network management 
functions? And lastly, is the choice of which network management functions to 
delegate well known (I assume it is) or up to an implementation?

---

Introduction
The first mention of "ECA" comes in...
   This document defines an ECA Policy management YANG data model.
I think you need to:
- Expand the abbreviation
- Explain in one or two sentences what ECA is

---

Section 2.1
You need to update to the more recent boilerplate that mentions RFC 8174

---

Section 2.1
You use the term "Event Stream" without defining it

Cheers,
Adrian

-Original Message-
From: netmod  On Behalf Of Lou Berger
Sent: 07 December 2020 22:28
To: NETMOD Group 
Cc: NetMod WG Chairs 
Subject: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

This email begins a 2-week adoption poll for:

https://tools.ietf.org/html/draft-wwx-netmod-event-yang-10

Please voice your support or technical objections on list before the end 
of December 21, any time zone.

Thank you!

Netmod Chairs

PS Note the IPR poll is running concurrently as the private response all 
indicated that no IPR exists.  The draft will not be formally adopted 
until both the IPR and WG polls are complete.


___
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] Question on how to design a Yang model to reflect auto-asignment of a give leaf

[Adrian Farrel]

Isn’t it possible to handle case b) by defining a value to have the meaning
“no value has been assigned” and then the user an explicitly set that value?

 

Adrian

 

From: netmod  On Behalf Of Oscar González de Dios
Sent: 11 February 2020 02:40
To: ops...@ietf.org; netmod@ietf.org
Subject: [netmod] Question on how to design a Yang model to reflect
auto-asignment of a give leaf

 

Dear OPSAWG and Netmod colleagues,

 

During last IETF Opsawg meeting we raised a question (and
there was some discussion during the meeting) that we have found yet no good
answer and we would like to discuss it with operations and Yang experts.

 

The use case is the following:  We have a yang module which
holds certain optional leafs. The behaviors that we would like to have (and
distinguish between them) are:

 

a.  The user does not provide the value and such value is auto-assigned
by the system (a  device (if it is a device module) or a controller (if it
is a network/service module)). 
b.  The user does not provide a value and wants that such value IS NOT
set by the system (as assigning a value has implications). That is,
intentionally it is aimed at being left “empty” and should not be expanded.
So, either the value is set or should remain empty

 

What is the best way to model this behavior? I see that some yang modules
have added an “auto-assignment” leaf to express if auto-assignment is
desired or not. (hence, auto-assignment false, and leaf not set, would  do
not assign). 

 

Which is the “default” rule for a leaf that is not set? It is that the
system is free to create it (via template or any means of auto-assignment)
or should leave it as is, that is, empty? 

 

In NMDA, the system is allowed to expand a given configuration. This fact,
in my personal view,  implies that by “default” any system could implement
the “auto-assignment” behavior being compliant with Neconf/Restconf/NMDA
rules (but I am not sure if the interpretation is correct).

 

Best Regards,

 

Óscar 

 

  _  


Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
puede contener información privilegiada o confidencial y es para uso
exclusivo de la persona o entidad de destino. Si no es usted. el
destinatario indicado, queda notificado de que la lectura, utilización,
divulgación y/o copia sin autorización puede estar prohibida en virtud de la
legislación vigente. Si ha recibido este mensaje por error, le rogamos que
nos lo comunique inmediatamente por esta misma vía y proceda a su
destrucción.

The information contained in this transmission is privileged and
confidential information intended only for the use of the individual or
entity named above. If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If you have received
this transmission in error, do not read it. Please immediately reply to the
sender that you have received this communication in error and then delete
it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
pode conter informação privilegiada ou confidencial e é para uso exclusivo
da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
indicado, fica notificado de que a leitura, utilização, divulgação e/ou
cópia sem autorização pode estar proibida em virtude da legislação vigente.
Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
imediatamente por esta mesma via e proceda a sua destruição

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

Re: [netmod] Barry Leiba's No Objection on draft-ietf-netmod-artwork-folding-08: (with COMMENT)

[Adrian Farrel]

Thanks for the review, Barry.

These look like good comments to me, and I think we should fix them all.

Best,
Adrian

-Original Message-
From: Barry Leiba via Datatracker  
Sent: 22 August 2019 05:41
To: The IESG 
Cc: draft-ietf-netmod-artwork-fold...@ietf.org; Lou Berger ; 
netmod-cha...@ietf.org; lber...@labn.net; netmod@ietf.org
Subject: Barry Leiba's No Objection on draft-ietf-netmod-artwork-folding-08: 
(with COMMENT)

Barry Leiba has entered the following ballot position for
draft-ietf-netmod-artwork-folding-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/



--
COMMENT:
--

— Section 4.1 —

I find the BCP 14 “SHOULD” in this section to be odd, and would lower-case
 them.

   When needed, this effort again
   SHOULD be automated to reduce effort and errors resulting from manual
   processing.

This sentence is really awkward: “when needed”, the use of “effort” twice, and
the uncertainty of whether the clause “resulting from manual processing”
applies to both effort and errors, or only to the latter.  I would say it this
way:

NEW
This work should also be automated to reduce the effort and to reduce errors
resulting from manual processing. END

— Section 6 —

 assumes that the continuation begins at the character that is
 not a space character (' ') on the following line.

Should be “at the first character”.

— Section 7.1.1 —

   The second line is a blank line.

The code in the appendix generates an *empty* line (no text).  Is that what you
mean by “blank line”?  Will a line that contains only space characters (*looks*
the same) work also?  The code in the appendix appears to discard the second
line without checking its content at all.  I think you should be clearer about
what qualifies as a “blank line”.  (This also applies to Section 8.1.1.)

— Section 7.2.1 —

   If this text content needs to and can be folded, insert the header
   described in Section 7.1.1, ensuring that any additional printable
   characters surrounding the header does not result in a line exceeding
   the desired maximum.

Should be “do not result” (to match the plural “printable characters”).


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

Re: [netmod] YANG next

[Adrian Farrel]

>> I hope a summary of the meeting is posted to the WG mailing list.
>
> I think so, minutes were taken.

I scribbled.
So did Dan King.
We sent our scribbles to Geng Liang and Qin Wu. 
They will process.

It was a side meeting. 
As Lou says, it was not part of any existing WG. Nor was it a BoF.

How and where and if the minutes are published is not a question for me to
answer.

Adrian

PS I don't think this was a debate about creating a new version of the YANG
language, and I don't think extensions or modifications to the YANG language
were high on the list of "fixes" to the questions raised in the meeting.
That doesn't mean that debate shouldn't/cannot happen, just that it is not
(highly) relevant to the discussion at hand.


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

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

[Adrian Farrel]

Thanks Kent.

 

Good change. I also think this is now ready to proceed.

 

Adrian

 

From: netmod  On Behalf Of Kent Watsen
Sent: 20 June 2019 14:07
To: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-artwork-folding-05.txt

 

This update incorporates Adrian's suggestion from the 17th.

 

There are no pending changes.  Publication may proceed as the chairs see
fit.

 

Kent // author 

 

 





On Jun 20, 2019, at 9:03 AM, internet-dra...@ietf.org
<mailto:internet-dra...@ietf.org>  wrote:

 


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

   Title   : Handling Long Lines in Inclusions in
Internet-Drafts and RFCs
   Authors : Kent Watsen
     Adrian Farrel
 Qin Wu
   Filename: draft-ietf-netmod-artwork-folding-05.txt
   Pages   : 26
   Date: 2019-06-20

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


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

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

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


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

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

[Adrian Farrel]

OK, we’re agreed on what we want to achieve, just not on the wording to 
describe it 

 

How about…

 

   1.  Determine where the fold will occur.  This location MUST be

   before or at the desired maximum column, and MUST NOT be chosen

   such that the character immediately after the fold is a space

   (' ') character.  If no such location can be found, then exit

   (this text content cannot be folded)

 

Best,

Adrian

 

From: Kent Watsen  
Sent: 17 June 2019 19:53
To: Adrian Farrel 
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-artwork-folding-03.txt

 

Hi Adrian,

 

Text suggestions welcomed.   

 

What needs to be expressed is that a space character cannot occupy the column 
where the end-of-line '\' is to placed, as doing so would push that space 
character to the beginning of the next line, which the unfolding logic would 
subsequently delete, thinking that it was part of a user-placed "indent".  
Makes sense?

 

Kent

 





On Jun 17, 2019, at 2:16 PM, Adrian Farrel mailto:adr...@olddog.co.uk> > wrote:

 

Kent, 

Thanks for the work.

 

I had a clear understanding of what “precede a space” means.

I struggle to understand what “on top of” means in a stream of characters. I 
wondered whether you were referring to vertical placement on the page (the text 
is talking about columns), but that seems crazy!

Do you mean that the fold must not be occupied by a space character?

I think the question is whether it is easier to describe a fold happening 
between characters or at a character slot.

The original text used the “between characters” approach. If you prefer to say 
you fold at a column, that’s fine, but probably “on top of” isn’t as clear as 
“the column at which we fold must not contain a space”.

 

Best,

Adrian

 

 

From: netmod mailto:netmod-boun...@ietf.org> > On 
Behalf Of Kent Watsen
Sent: 17 June 2019 18:39
To: netmod@ietf.org <mailto:netmod@ietf.org> 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-artwork-folding-03.txt

 

 

I just posted an Editorial update that only touches the non-normative script to 
add a -q (quiet) flag.  Here's the diff:  
<https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-artwork-folding-04.txt> 
https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-artwork-folding-04.txt.

 

Separately, it's been more than two weeks since the below message.   There has 
been no comments on #2 below, and so the chairs can more forward with the 
publishing request now?

 

Kent // author (recused chair)

 

 






On May 30, 2019, at 10:41 AM, Kent Watsen < <mailto:k...@watsen.net> 
k...@watsen.net> wrote:

 

 

This update reflects the changes discussed during the Last Call plus the 
following additional changes:

 

  1) s/see if any/ensure at least one/  (EDITORIAL: sounded too casual before)

  2) s/MUST NOT precede a space (' ') character/MUST NOT be on top of a space 
(' ') character/  (TECHNICAL: see below)

  3) wrapped the script with  and  (EDITORIAL, per 
idnits)

 

Regarding #2, this change was made after I examined the algorithm more 
carefully.  It would be good for others to confirm this rather critical change.

 

Thanks,

Kent // contributor

 

 






On May 30, 2019, at 10:30 AM,  <mailto:internet-dra...@ietf.org> 
internet-dra...@ietf.org wrote:

 


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

   Title   : Handling Long Lines in Inclusions in Internet-Drafts 
and RFCs
   Authors     : Kent Watsen
 Adrian Farrel
 Qin Wu
   Filename: draft-ietf-netmod-artwork-folding-03.txt
   Pages   : 25
   Date: 2019-05-30

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


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

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

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

[Adrian Farrel]

Kent, 

Thanks for the work.

 

I had a clear understanding of what "precede a space" means.

I struggle to understand what "on top of" means in a stream of characters. I
wondered whether you were referring to vertical placement on the page (the
text is talking about columns), but that seems crazy!

Do you mean that the fold must not be occupied by a space character?

I think the question is whether it is easier to describe a fold happening
between characters or at a character slot.

The original text used the "between characters" approach. If you prefer to
say you fold at a column, that's fine, but probably "on top of" isn't as
clear as "the column at which we fold must not contain a space".

 

Best,

Adrian

 

 

From: netmod  On Behalf Of Kent Watsen
Sent: 17 June 2019 18:39
To: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-artwork-folding-03.txt

 

 

I just posted an Editorial update that only touches the non-normative script
to add a -q (quiet) flag.  Here's the diff:
https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-artwork-folding-04.txt
..

 

Separately, it's been more than two weeks since the below message.   There
has been no comments on #2 below, and so the chairs can more forward with
the publishing request now?

 

Kent // author (recused chair)

 

 





On May 30, 2019, at 10:41 AM, Kent Watsen mailto:k...@watsen.net> > wrote:

 

 

This update reflects the changes discussed during the Last Call plus the
following additional changes:

 

  1) s/see if any/ensure at least one/  (EDITORIAL: sounded too casual
before)

  2) s/MUST NOT precede a space (' ') character/MUST NOT be on top of a
space (' ') character/  (TECHNICAL: see below)

  3) wrapped the script with  and  (EDITORIAL, per
idnits)

 

Regarding #2, this change was made after I examined the algorithm more
carefully.  It would be good for others to confirm this rather critical
change.

 

Thanks,

Kent // contributor

 

 





On May 30, 2019, at 10:30 AM, internet-dra...@ietf.org
<mailto:internet-dra...@ietf.org>  wrote:

 


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

   Title   : Handling Long Lines in Inclusions in
Internet-Drafts and RFCs
   Authors : Kent Watsen
 Adrian Farrel
 Qin Wu
   Filename: draft-ietf-netmod-artwork-folding-03.txt
   Pages   : 25
   Date: 2019-05-30

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


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

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

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


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

 

___
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

Re: [netmod] WG Last Call: draft-ietf-netmod-artwork-folding-02

[Adrian Farrel]

Thanks Lou,

[speaking as an author]

This draft represents the coming together of two different approaches to the
same problem. The authors worked hard to merge and reach consensus, and the
current revision contains the product.

This document certainly addresses my personal requirement which is to
provide a common human-readable notation for use in XML examples in drafts
and RFCs so that artificial line-wraps can be disambiguated. And so I
support its publication.

Best,
Adrian

-Original Message-
From: netmod  On Behalf Of Lou Berger
Sent: 12 May 2019 22:20
To: NetMod WG 
Cc: NetMod WG Chairs 
Subject: [netmod] WG Last Call: draft-ietf-netmod-artwork-folding-02


All,

This starts a two-week working group last call for
draft-ietf-netmod-artwork-folding-02

The working group last call ends on May 27.
Please send your comments to the working group mailing list.

Positive comments, e.g., "I've reviewed this document
and believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Thank you,
NetMod Chairs



___
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] Regarding IPR on draft-ietf-netmod-artwork-folding-02

[Adrian Farrel]

Hi,

Noting that the draft (and hence the draft alias) has my email address correct.

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

Thanks,
Adrian

-Original Message-
From: Lou Berger  
Sent: 12 May 2019 22:18
To: Kent Watsen ; adr...@olddog.co.uk; 
bill...@huawei.com; afar...@juniper.net
Cc: NetMod WG Chairs ; NetMod WG 
Subject: Regarding IPR on draft-ietf-netmod-artwork-folding-02

Authors, Contributors, WG,

As part of WG Last Call

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author and listed
contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
NetMod WG Chairs

PS Please include all listed in the headers of this message in your
response.




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

Re: [netmod] artwork folding: dual support modes?

[Adrian Farrel]

>> Now that IETF has officially moved to XML as the sole format
>
> I'm not sure what you mean, can you provide a pointer?  AFAICT,
> the latest published RFC is still only available as txt and pdf.
>
> If the only format was XML, why bother with any line breaking at all?

I think maybe the IETF is moving towards the XML being the definitive
version of drafts and RFCs. But, it is never going to be the case that
people go to the XML to read a document. They will pick HTML or text or PDF.


So the reader will see folded lines. And the reader needs to know what a
folded line means and how to map it to reality.

Adrian

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

Re: [netmod] artwork folding: dual support modes?

[Adrian Farrel]

>> The days of scraping from plain-text RFCs are over [1].  Extracting,
>> if needed at all, should be from the XML, where there are no such
>> issues. Extracting from the plain-text output makes about as much
>> sense as extracting from the HTML or PDF outputs.
>
> I am confused.  Are you saying that the unfolding algorithm only is
> supposed to work on data extracted from the XML version of the I-D or
> RFC?  If so, I think this needs to be clarified in the draft.

Quite!
If the problem is to extract from XML then there is no problem because
wrapping is not needed in the XML (unless manual wrapping has been done).
The problem to be addressed when Qin and I started this work was that
human-readable copies needed to include some form of wrapping, and we wanted
a format that made it abundantly clear that the wrapped version was not
normative, and told the reader how to unwrap in order to make valid
examples.

I fear we are losing touch with the problem statement.

Adrian

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

Re: [netmod] artwork folding: dual support modes?

[Adrian Farrel]

We can go round and round 

How do I fold
  foo bar baz buzz
so that it can be unfolded?

Clearly a possibility is
  foo bar baz \
  buzz

But what if the line length would break in the white space?
You could solve it as 
  foo bar \
  baz buzz
which requires slightly more complex folding.

Actually, this case arises more often than you might think when the line length 
would cause a fold before a single space.
Thus, if the line length is 11
foo bar baz buzz
..would fold as...
foo bar baz\
 buzz
...and unfold as...
foo bar bazbuzz
...if leading spaces are stripped.

And if leading spaces are not stripped then we cannot handle manual padding for 
reasons of visual formatting. For example...
foo bar baz\
   buzz

Personally, I am *really* struggling to understand why we cannot use the 
two-slash approach only. 

Cheers,
Adrian


-Original Message-
From: Martin Bjorklund  
Sent: 04 March 2019 11:49
To: rwil...@cisco.com
Cc: adr...@olddog.co.uk; joe...@bogus.com; netmod@ietf.org
Subject: Re: [netmod] artwork folding: dual support modes?

"Rob Wilton (rwilton)"  wrote:
> But this behaviour is still different from the frequently used meaning
> of ‘\’ today in programming languages, which as I know it just splits
> lines and preserves whitespace.

Right, but we're not doing a programming language, we try to fit long
lines in examples into the format required by RFCs, including
indentation.  For example, suppose you have:

  Here's an example:

  foo bar baz \
  buzz

Unfolded, do you think this is:

  foo bar baz buzz

or

  foo bar bazbuzz


> YANG requires a separator character between a keyword and its
> argument.  What happens if the tool happens to split the line between
> the two of them.
> 
> 
> 
> E.g
> 
>container\
> 
>   test
> 
> 
> 
> After the artwork folding, this would become
> 
>containertest
> 
> 
> 
> This could be mitigated by a smarter folding tool (e.g. split before
> the ‘r’ or after the first space).


1.  Don't use a tool to add line breaks - remember the goal was to
have a readable example.

2.  Don't use this alg. for YANG modules, since YANG has builtin /
native support for splitting long lines.


> Or, what if the tool was being used to fold a table that was using
> whitespace to align the columns.  This could easily break if
> whitespace is stripped.

Don't use this alg for tables (or ascii art in general) -- it won't
help readers.


/martin





> 
> 
> 
> Thanks,
> Rob
> 
> 
> 
> 
> 
> -Original Message-
> From: Martin Bjorklund 
> Sent: 04 March 2019 08:40
> To: Rob Wilton (rwilton) 
> Cc: adr...@olddog.co.uk; joe...@bogus.com; netmod@ietf.org
> Subject: Re: [netmod] artwork folding: dual support modes?
> 
> 
> 
> "Rob Wilton (rwilton)" mailto:rwil...@cisco.com>>
> wrote:
> 
> > Hi Adrian,
> 
> >
> 
> > I mostly agree with your last sentence.
> 
> >
> 
> > I think that if you always preserve whitespace then a single slash is
> 
> > fine.  I.e. the single slash just breaks the line, and I think that
> 
> > this matches how editors, programming languages, etc normally behave.
> 
> >
> 
> > What I’m not keen on is using a single slash, and then automatically
> 
> > stripping leading whitespace on the line following a slash.
> 
> 
> 
> And this is the solution that I prefer.  The reason for this is that I
> view examples as something that is there to illustrate some point to
> the reader, and I think that a prettier formatted example with less
> noise helps the reader.  I also think that is most cases, this works
> well; i.e., most cases are _not_ on the form:
> 
> 
> 
>12345  78990
> 
>   ^-- I need a line break here
> 
> 
> 
> 
> 
> For this problem, I prefer a solution that is intuitive and has less
> noise and works for 90% of the cases, than a less intuitive solution
> with more noise that works for 100% of the cases.
> 
> 
> 
> 
> 
> /martin
> 
> 
> 
> 
> 
> 
> 
> >
> 
> > If we want to have control of layout and be able to strip extra
> 
> > whitespace then my argument is that it is better to be explicit, and
> 
> > using two slashes is one way of achieving this.
> 
> >
> 
> > Thanks,
> 
> > Rob
> 
> >
> 
> >
> 
> >
> 
> > From: netmod mailto:netmod-boun...@ietf.org>>
> > On Behalf Of Adrian Farrel
> 
> > Sent: 27 February 2019 09:41
> 
> > To: 'Joel Jaeggli' mailto:joe...@bogus.com>>
> 
> > Cc: netmod@ietf.org<mailto:netmod@ietf.

Re: [netmod] artwork folding: dual support modes?

[Adrian Farrel]

Complete agreement, Joel.

 

What follows may look better in proportional fonts.

 

With a single slash we can wrap as follows

 

12345679012345

 

Goes to…

 

1234567\

9012345

 

…and unwrapping is easy.

 

However, if I want to manually wrap the line with indentation

 

The quick brown fox jumps over the lazy dog

 

...going to…

 

The quick brown fox\

  jumps over the lazy dog

 

…I am going to unfold as…

 

The quick brown fox  jumps over the lazy dog

 

 

Conversely, if I resolve this second case by stripping leading spaces I get…

 

The quick brown foxjumps over the lazy dog

 

So I have to fold as…

 

The quick brown fox \

  jumps over the lazy dog

 

But this causes the first case to unfold as

 

12345679012345

 

…i.e., with missing spaces.

 

This is what caused the use of the second slash so…

 

1234567\

\9012345

 

…and…

 

The quick brown fox\

 \ jumps over the lazy dog

 

 

So, my point is, if and only if we do not care about these “spaces on the fold” 
cases, we can operate with a single slash.

 

Cheers,

Adrian

 

From: Joel Jaeggli  
Sent: 27 February 2019 06:31
To: Adrian Farrel 
Cc: Kent Watsen ; netmod@ietf.org
Subject: Re: [netmod] artwork folding: dual support modes?

 

 





On Feb 26, 2019, at 14:26, Adrian Farrel mailto:adr...@olddog.co.uk> > wrote:

 

Hey.

 

I’ve been having this discussion with Kent off-line, but thought it should come 
to the list.

 

I don’t think it is a good idea to have two approaches. While it would be 
relatively easy to code for both approaches, it seems to add a degree of 
confusion if both have to be handled by the same code (consider deciding 
whether leading space characters are to be retained or not, something that can 
only be decided when the first non-space character is found), or by having 
different code for the two different cases.

 

It doesn’t seem to me that both cases are needed. We can pick one or the other.

 

A single slash has been used to wrap long lines in editors and shells for 
decades at this point.

 

and yeah whatever it is one method seems better than two.





 

And *if* we want to allow manual folding so that indents can be made to make 
the document more human-readable then we have to use a leading ‘\’ on 
continuation lines to show which spaces should be stripped and which retained.

 

Cheers,

Adrian

 

From: netmod mailto:netmod-boun...@ietf.org> > On 
Behalf Of Kent Watsen
Sent: 25 February 2019 22:22
To: netmod@ietf.org <mailto:netmod@ietf.org> 
Subject: [netmod] artwork folding: dual support modes?

 

 

I had a chat with the tools team recently and, in the course of things, it was 
implied

that the double backslash approach we have now was both surprising and 
non-intuitive. 

 

This got me thinking that we may have thrown the proverbial baby out with the 
bathwater.

That is, currently we have a header that reads:

 

  NOTE: '\\' line wrapping per BCP XX (RFC )

 

So why not *also* support a header that reads (note the singe slash):

 

  NOTE: '\' line wrapping per BCP XX (RFC )

 

Whereby this second form only supports the folded line continuing on column 1 
(no indents).

 

Thoughts?

 

Kent // contributor

 

 

___
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

Re: [netmod] artwork folding: dual support modes?

[Adrian Farrel]

Hey.

 

I've been having this discussion with Kent off-line, but thought it should
come to the list.

 

I don't think it is a good idea to have two approaches. While it would be
relatively easy to code for both approaches, it seems to add a degree of
confusion if both have to be handled by the same code (consider deciding
whether leading space characters are to be retained or not, something that
can only be decided when the first non-space character is found), or by
having different code for the two different cases.

 

It doesn't seem to me that both cases are needed. We can pick one or the
other.

 

And *if* we want to allow manual folding so that indents can be made to make
the document more human-readable then we have to use a leading '\' on
continuation lines to show which spaces should be stripped and which
retained.

 

Cheers,

Adrian

 

From: netmod  On Behalf Of Kent Watsen
Sent: 25 February 2019 22:22
To: netmod@ietf.org
Subject: [netmod] artwork folding: dual support modes?

 

 

I had a chat with the tools team recently and, in the course of things, it
was implied

that the double backslash approach we have now was both surprising and
non-intuitive. 

 

This got me thinking that we may have thrown the proverbial baby out with
the bathwater.

That is, currently we have a header that reads:

 

  NOTE: '\\' line wrapping per BCP XX (RFC )

 

So why not *also* support a header that reads (note the singe slash):

 

  NOTE: '\' line wrapping per BCP XX (RFC )

 

Whereby this second form only supports the folded line continuing on column
1 (no indents).

 

Thoughts?

 

Kent // contributor

 

 

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

Re: [netmod] Eric Rescorla's No Objection on draft-ietf-netmod-schema-mount-12: (with COMMENT)

[Adrian Farrel]

Thanks!

Was a useful Discuss, and good to be moving the cluster forward.

Adrian

> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Eric Rescorla
> Sent: 08 November 2018 04:28
> To: The IESG
> Cc: netmod-cha...@ietf.org; netmod@ietf.org; joe...@gmail.com; draft-ietf-
> netmod-schema-mo...@ietf.org
> Subject: [netmod] Eric Rescorla's No Objection on draft-ietf-netmod-schema-
> mount-12: (with COMMENT)
> 
> Eric Rescorla has entered the following ballot position for
> draft-ietf-netmod-schema-mount-12: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Thank you for addressing my DISCUSS
> 
> 
> ___
> 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] WG adoption poll draft-kwatsen-netmod-artwork-folding-08

[Adrian Farrel]

Nicely said, Martin.
The intention is that if, like Ladislav, you like to work in some long-line
format, then it works as documented and the tools can wrap.
If, like me, and maybe like Martin, you think pretty formatting is something
that improves readability, the draft also lets you do that.

A

> -Original Message-
> From: Martin Bjorklund [mailto:m...@tail-f.com]
> Sent: 23 October 2018 17:04
> To: lho...@nic.cz
> Cc: adr...@olddog.co.uk; netmod@ietf.org
> Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-
> 08
> 
> Ladislav Lhotka  wrote:
> > On Tue, 2018-10-23 at 16:27 +0200, Martin Bjorklund wrote:
> > > Ladislav Lhotka  wrote:
> > > > On Tue, 2018-10-23 at 14:45 +0100, Adrian Farrel wrote:
> > > > > Hi,
> > > > >
> > > > > 1. I think you miss the point. While example XML/JSON YANG is included
> in
> > > > > drafts, and while the authors are allowed to produce those drafts as
txt
> > > > > files,
> > > > > or while the authors want to achieve pretty-to-read formatting, this
work
> > > > > falls
> > > > > into the scope of those authors.
> > > >
> > > > The folding of long lines should be done as the very last (automatic)
step
> > > > before the document gets published. Doing it earlier means that the
source
> > > code
> > > > in this folded form can be (accidentally) further edited, which can lead
to
> > > > inconsistencies.
> > >
> > > I will use folding e.g. for instance document examples in XML and
> > > JSON.
> > >
> > > My plan is to keep the example files with manually added breaks in my
> > > repo, and as part of validation run a script that unfolds the
> > > examples, and then validate the result.  The reason for this is that I
> > > think readbility of the examples is important.
> >
> > This seems backwards to me. If you need to edit such an example, you may
> have to
> > remove the backslashes, reformat and insert them again.
> >
> > If it's not possible to fold lines according to the syntax of a given
language,
> > I'd prefer to keep the original lines as long as possible and rely on an
> > automatic procedure just before the final document is rolled out.
> 
> Fortunately, the draft allows us both to work the way we prefer.
> 
> 
> /martin
> 
> 
> >
> > Lada
> >
> > >
> > >
> > > /martin
> > >
> > >
> > >
> > > >
> > > > As long as the document is being moved around and edited, it would be
> better
> > > to
> > > > keep the source code untouched.
> > > >
> > > > Lada
> > > >
> > > > >
> > > > > 2. Yes, the authors discussed the  element and agreed that
> it
> > > will
> > > > > be in scope.
> > > > >
> > > > > However, we are all sort of waiting for xml2rfc v3 and pending
completion,
> > > we
> > > > > want to move this forward for v2 that is in use today.
> > > > >
> > > > > (More than) Happy to come back and revisit this issue when v3 is
> deployed.
> > > > >
> > > > > Thanks,
> > > > > Adrian
> > > > >
> > > > > > -Original Message-
> > > > > > From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Ladislav
> > > Lhotka
> > > > > > Sent: 23 October 2018 14:24
> > > > > > To: netmod@ietf.org
> > > > > > Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-
> artwork-
> > > folding-
> > > > > > 08
> > > > > >
> > > > > > On Tue, 2018-10-23 at 14:40 +0200, Ladislav Lhotka wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > I support the adoption.
> > > > > > >
> > > > > > > Comments:
> > > > > > >
> > > > > > > 1. My general feeling is that such technicalities should be
handled by
> > > > > > >the RFC editor and/or tools rather than YANG module and RFC
> > > authors.
> > > > > > >
> > > > > > > 2. xml2rfc v3 introduced a new element, , that is
> intended
> > > > > > >for source code inclusion. This document should therefore cover
> > > this
> > > > > > >eleme

Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08

[Adrian Farrel]

Hi,

1. I think you miss the point. While example XML/JSON YANG is included in
drafts, and while the authors are allowed to produce those drafts as txt files,
or while the authors want to achieve pretty-to-read formatting, this work falls
into the scope of those authors.

2. Yes, the authors discussed the  element and agreed that it will
be in scope.

However, we are all sort of waiting for xml2rfc v3 and pending completion, we
want to move this forward for v2 that is in use today.

(More than) Happy to come back and revisit this issue when v3 is deployed.

Thanks,
Adrian

> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Ladislav Lhotka
> Sent: 23 October 2018 14:24
> To: netmod@ietf.org
> Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-
> 08
> 
> On Tue, 2018-10-23 at 14:40 +0200, Ladislav Lhotka wrote:
> > Hi,
> >
> > I support the adoption.
> >
> > Comments:
> >
> > 1. My general feeling is that such technicalities should be handled by
> >the RFC editor and/or tools rather than YANG module and RFC authors.
> >
> > 2. xml2rfc v3 introduced a new element, , that is intended
> >for source code inclusion. This document should therefore cover this
> >element as well (primarily?). One problem with it is that the xml2rfc
> >tool automatically adds the  and  markers,
> >which interferes with YANG convention specified in RFC 8407,
> >sec. 3.2. I have already raised a question about this in the
> >xml2rfc-dev mailing list.
> 
> Update: using the "name" attribute with  does the right thing.
> 
> 
> ...
> 
> 
> results in
> 
>  file "ietf-...@2016-03-20.yang"
> ...
> 
> 
> Lada
> 
> >
> > Lada
> >
> > Lou Berger  writes:
> >
> > > All,
> > >
> > > This is start of a two week poll on making
> > > draft-kwatsen-netmod-artwork-folding-08 a working group
> > > document. Please send email to the list indicating "yes/support" or
> > > "no/do not support".  If indicating no, please state your reservations
> > > with the document.  If yes, please also feel free to provide comments
> > > you'd like to see addressed once the document is a WG document.
> > >
> > > The poll ends Oct 1.
> > >
> > > Thanks,
> > >
> > > Lou (and co-chairs)
> > >
> > > ___
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> ___
> 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] WG adoption poll draft-kwatsen-netmod-artwork-folding-08

[Adrian Farrel]

Hey Lou,

As an author, I support adoption and would particularly welcome feedback from
the WG to know whether this approach addresses the needs of those writing drafts
for YANG models.

Thanks,
Adrian

> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Lou Berger
> Sent: 18 October 2018 14:04
> To: NetMod WG
> Cc: NetMod WG Chairs
> Subject: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
> 
> All,
> 
> This is start of a two week poll on making
> draft-kwatsen-netmod-artwork-folding-08 a working group
> document. Please send email to the list indicating "yes/support" or
> "no/do not support".  If indicating no, please state your reservations
> with the document.  If yes, please also feel free to provide comments
> you'd like to see addressed once the document is a WG document.
> 
> The poll ends Oct 1.
> 
> Thanks,
> 
> Lou (and co-chairs)

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

Re: [netmod] Regarding IPR on draft-kwatsen-netmod-artwork-folding-08

[Adrian Farrel]

Hi Lou,

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

Thanks,
Adrian

> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Lou Berger
> Sent: 16 October 2018 21:26
> To: Kent Watsen; Benoit Claise; bill...@huawei.com; afar...@juniper.net
> Cc: NetMod WG Chairs; NetMod WG
> Subject: [netmod] Regarding IPR on draft-kwatsen-netmod-artwork-folding-08
> 
> Authors, Contributors, WG,
> 
> As part of preparation for WG Adoption
> 
> Are you aware of any IPR that applies to drafts identified above?
> 
> Please state either:
> 
> "No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draft"
> 
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
> 
> If yes to the above, please state either:
> 
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
> 
> If you answer no, please provide any additional details you think
> appropriate.
> 
> If you are listed as a document author or contributor please answer the
> above by responding to this email regardless of whether or not you are
> aware of any relevant IPR. This document will not advance to the next
> stage until a response has been received from each author and listed
> contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
> TO LINES.
> 
> If you are on the WG email list or attend WG meetings but are not listed
> as an author or contributor, we remind you of your obligations under
> the IETF IPR rules which encourages you to notify the IETF if you are
> aware of IPR of others on an IETF contribution, or to refrain from
> participating in any contribution or discussion related to your
> undisclosed IPR. For more information, please see the RFCs listed above
> and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
> 
> Thank you,
> NetMod WG Chairs
> 
> PS Please include all listed in the headers of this message in your
> response.
> 
> 
> 
> ___
> 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] Whitespace in XML encoding - allowed ?

[Adrian Farrel]

Hence why we go through so many hoops in the line-wrapping draft.

Adrian

> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Martin Bjorklund
> Sent: 09 October 2018 11:07
> To: balazs.leng...@ericsson.com
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Whitespace in XML encoding - allowed ?
> 
> Balázs Lengyel  wrote:
> > Hello,
> >
> > Recently we came up against a problem where a certain implementation
> > did not accept the following:
> >
> > 
> > report-all
> > 
> >
> > while it did accept
> >
> > report-all
> >
> > I am unsure whether YANG's XML encoding allows whitespace before and
> > after a leaf's value? In RFC7950 it does not say yes or no.
> 
> For example, RFC 7950 says about integers in 9.2.1:
> 
>An integer value is lexically represented as an optional sign ("+" or
>"-"), followed by a sequence of decimal digits.  If no sign is
>specified, "+" is assumed.
> 
> So, space characters (and other characters) are not allowed.  In XML,
> whitespace has meaning, so:
> 
>42
> 
> is not the same as
> 
> 42 
> 
> Since the string " 42 " is not a legal integer lexical representation
> according to 9.2.1,  42  is not a valid XML representation
> for the integer foo.
> 
> > I have
> > found the following examples that seem to allow preceding/following
> > whitespace:
> >
> > https://tools.ietf.org/html/rfc7950#section-4.2.9
> >
> >http://example.com/system;>
> >  The image example-fw-2.3 is being installed.
> >
> >
> > https://tools.ietf.org/html/rfc7950#section-7.16.3
> >
> >  
> >/ex:interface[ex:name='Ethernet0']
> >  
> >
> > https://tools.ietf.org/html/rfc6243#appendix-A.3.1
> >
> >  >  xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">
> >   report-all
> > 
> 
> Yes, to be strict, these examples should have had some text that
> explained that whitespace was added for readability.  New documents
> will hopefully use the new artwork draft's rules instead.
> 
> 
> 
> /martin
> 
> 
> > It is problematic that this is not clarified. IMHO this should be
> > clarified in an errata to rfc7950. Chose one:
> >
> > 1 It is not allowed to add preceding or following whitespace after the
> >   value of a leaf/leaf-list.
> >   Note that some text documents may add whitespace to Netconf examples
> >   to avoid long lines,
> >   however this extra whitespace MUST NOT be present in the actual
> >   Netconf encoding.
> >
> > 2 It is not allowed to add preceding or following whitespace after the
> >   value of a leaf/leaf-list.
> > 3 It is allowed to add preceding or following whitespace after the
> >   value of a leaf/leaf-list except
> >   for string based types, where the whitespace could be part of the
> >   leaf's value itself..
> >
> > What do you think?
> >
> > regards Balazs
> >
> > --
> > Balazs Lengyel   Ericsson Hungary Ltd.
> > Senior Specialist
> > Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com
> 
> ___
> 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] New Version Notification for draft-kwatsen-netmod-artwork-folding-07.txt

[Adrian Farrel]

All, the scope has become elastic over time.

When we first wrote draft-wu-netmod-yang-xml-doc-conventions we were addressing 
a very specific problem: drafts and RFCs contain fragments (examples) of YANG 
(not the YANG modules themselves, but examples with actual values). Those 
fragments often extend over 73 columns and so have to be wrapped from 
presentation in the draft/RFC, but this creates invalid YANG. So some form of 
documentation convention is needed to indicate that the examples should not be 
treated as valid YANG and to help someone map them to valid YANG.

Most documents that encountered this problem either dodged it (hoping a 
reviewer would not complain) or defined their own line wrapping rules. We 
thought it would be helpful to have a common approach and that was what we 
focused on.

We also noticed that (probably for formatting reasons) the examples were often 
being produced using the  construct in the source XML. So it seemed 
that there would be value in defining how that artwork could be automatically 
wrapped allowing the authors to not worry about line wrapping.

We recognised that wrapping figures would probably be confusing and 
counter-productive so we recommend against it. And we made it an explicit thing 
not a default.

Conversely, we noted that other "sample code" might benefit from wrapping, so 
we thought that should be in scope.

Then we merged our efforts with Kent's.

That's how we got here.


Now, to take it forward, I would like to constrain our efforts to solving the 
problem at hand. If our solution has wider applicability, that's great. But can 
we recognise that the overwhelming bulk of case we see today are in YANG 
documents and that's up to us to solve.

Thanks,
Adrian

> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen
> Sent: 28 September 2018 23:05
> To: tom petch
> Cc: netmod@ietf.org
> Subject: Re: [netmod] New Version Notification for draft-kwatsen-netmod-
> artwork-folding-07.txt
> 
> 
> Hi Tom,
> 
> As contributor, I agree with you.  The only reason that it is here
> now is because draft-wu-netmod-yang-xml-doc-conventions did.
> 
> As chair, let me discuss with my co-chairs.  Meanwhile, would love
> to hear others opinions.
> 
> Kent
> 
> 
> - Original Message -
> 
> Kent
> 
> Stepping back, I think that there is a problem of applicability.
> 
> You have labelled this I-D draft..netmod.. and are discussing it on the
> netmod WG list.  Therefore I apply it to YANG I-D - to me, that is the
> obvious connection - and the problem I keep seeing with YANG I-D is
> lines too long - comment, description - in the YANG module so that is
> the problem for which I want a solution (I see no problem with code
> snippets).  This has something to do with, I know not what, the
> processing cycle of YANG modules, of the module being generated outside
> the I-D/RFC process and then being inserted without the constraints that
> the I-D/RFC process normally apply; I recall Benoit giving an
> explanation.
> 
> However, when I ignore the I-D name and the list we are on, and take the
> text in isolation, then I wonder what are we doing here.  This should be
> on a different list, art perhaps or the main ietf list, since what you
> are proposing has nothing to do with netmod, YANG or any of the topics
> that this list discusses; rather it seeks to change the whole of the
> IETF.
> 
> So, put this up for adoption and I will oppose; this is outside our
> remit.
> 
> Tom Petch
> 
> 
> 
> ___
> 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] New Version Notification for draft-kwatsen-netmod-artwork-folding-07.txt

[Adrian Farrel]

Yeah :-Z

So my inclination is to say "tabs in artwork are evil" and move on.
Some folk like to use them when constructing text, but my suggestion is that 
they convert to spaces/LF before posting drafts.

If anyone wants to write another document tabs in json then, erm, knock 
yourselves out. But I would prefer to just exclude them from folding at this 
time.

Cheers,
Adrian

> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of tom petch
> Sent: 18 September 2018 10:54
> To: Carsten Bormann; Robert Wilton
> Cc: netmod@ietf.org
> Subject: Re: [netmod] New Version Notification for draft-kwatsen-netmod-
> artwork-folding-07.txt
> 
> - Original Message -
> From: "Carsten Bormann" 
> Sent: Friday, September 14, 2018 12:14 PM
> 
> > On Sep 14, 2018, at 13:05, Robert Wilton
>  wrote:
> > >
> > > If all input files that we might ever want to fold and include in an
> RFC are guaranteed to never contain tabs then I agree with the position
> that they can just be rejected.
> >
> > Yep.
> >
> > > But if there is some future file format that we want to fold that
> might contain tabs, then I wonder whether it would not be more robust to
> look at whether they could be handled in some way.
> >
> > VT characters (colloquially tabs) should not be significant in any
> file format designed in the last couple of decades (i.e., they should be
> replaceable by spaces).  If they (or any other characters not
> representable in RFCs) are, or preserving byte wise identity is
> important, follow the lead of RFC 6716 and base64-encode.
> 
> This confuses me.  This I-D references RFC7991 which clearly defines tab
> as  9, which RFC20 labels H(orizontal) T(ab).  V(ertical) T(ab) is 11.
> 
> I would not expect VT to appear in any recent document but when it does,
> then replacing it by spaces would be wrong, IMHO.  HT I do see, far too
> much of, because there is no metadata saying what the Horizontal Tab
> settings should be and while a  value of five is common, there are RFC
> where replacing tab characters with five spaces yields rubbish.
> 
> Tom Petch
> 
> 
> 
> 
> 
> 
> >
> > Grüße, Carsten
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

Re: [netmod] FW: New Version Notification for draft-kwatsen-netmod-artwork-folding-07.txt

[Adrian Farrel]

Speaking as a co-author, I agree with Kent that this version is ready for the WG
to pick up.

I think that discussions at f2f meetings indicated that there was interest in
the WG in addressing this issue, and after much back and forth, the authors have
come together with an approach that they agree on and it incorporates some
suggestions made in Montreal.

Thanks,
Adrian

> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen
> Sent: 07 September 2018 22:59
> To: netmod@ietf.org
> Subject: [netmod] FW: New Version Notification for draft-kwatsen-netmod-
> artwork-folding-07.txt
> 
> 
> An update to the "artwork-folding" draft has been posted.
>   - the solution is now using the "/.../" format.
>   - the included script has been updated as well.
> 
> We believe that this draft is ready for an adoption poll.
> 
> Kent (and Adrian and Qin)  // authors
> 
> 
> -Original Message-
> 
> A new version of I-D, draft-kwatsen-netmod-artwork-folding-07.txt
> has been successfully submitted by Kent Watsen and posted to the
> IETF repository.
> 
> Name: draft-kwatsen-netmod-artwork-folding
> Revision: 07
> Title:Handling Long Lines in Artwork in Internet-Drafts and
RFCs
> Document date:2018-09-05
> Group:Individual Submission
> Pages:16
> URL:https://www.ietf.org/id/draft-kwatsen-netmod-artwork-folding-
> 07.txt
> Status: https://datatracker.ietf.org/doc/draft-kwatsen-netmod-artwork-
> folding/
> Htmlized:
https://tools.ietf.org/html/draft-kwatsen-netmod-artwork-folding-
> 07
> Htmlized:   https://datatracker.ietf.org/doc/html/draft-kwatsen-netmod-
> artwork-folding
> Diff:
https://www.ietf.org/rfcdiff?url2=draft-kwatsen-netmod-artwork-
> folding-07
> 
> Abstract:
>This document introduces a simple and yet time-proven strategy for
>handling long lines in artwork in drafts using a backslash ('\')
>character where line-folding has occurred.  The strategy works on any
>text based artwork, but is primarily intended for sample text and
>formatted examples and code, rather than for graphical artwork.  The
>approach produces consistent results regardless of the content and
>uses a per-artwork header.  The strategy is both self-documenting and
>enables automated reconstitution of the original artwork.
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat
> 
> 
> 
> ___
> 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] L2SM working last call on draft-ietf-l2sm-l2vpn-service-model

[Adrian Farrel]

Hi Netmod,

draft-ietf-l2sm-l2vpn-service-model is going through working group last call in
L2SM.

Please send your comments to the L2SM list. In exceptional circumstances you may
send your comments via the L2SM chairs.

Thanks,
Adrian

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

[netmod] Summary for the busy : draft-wu-netmod-yang-xml-doc-conventions-00.txt

[Adrian Farrel]

Hi,

Just a summary for those of you who are busy...

May YANG module documents include examples in XML.

Sometimes there are line length problems caused by the 73 character limit.

Different documents have adopted different ways around this as special cases.

It would be useful to have a generic approach so that all documents have the 
same look and feel. It has also been suggested that this might ease 
auto-verification of examples, but that might be a challenge for other reasons.

We have not included JSON in this document. JSON is somewhat more compact, but 
the same issue could arise, so we do plan to look at this in the future.

Thoughts would be most welcome.

Adrian

> A new version of I-D, draft-wu-netmod-yang-xml-doc-conventions-00.txt
> has been successfully submitted by Qin Wu and posted to the IETF repository.
> 
> Name: draft-wu-netmod-yang-xml-doc-conventions
> Revision: 00
> Title:Documentation Conventions for Expressing YANG in XML
> Document date:2018-01-26
> Group:Individual Submission
> Pages:9
> URL:https://www.ietf.org/internet-drafts/draft-wu-netmod-yang-xml-
> doc-conventions-00.txt
> Status: https://datatracker.ietf.org/doc/draft-wu-netmod-yang-xml-doc-
> conventions/
> Htmlized:   https://tools.ietf.org/html/draft-wu-netmod-yang-xml-doc-
> conventions-00
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-wu-netmod-yang-xml-
> doc-conventions-00
> 
> 
> Abstract:
>Many documents that define YANG modules also include examples
>presented in XML.
> 
>IETF documentation has specific limits on line length and some XML
>examples have to include line wraps that would not normally be
>allowed according to the XML representation rules of RFC7950 and
>RFC7952.
> 
>This document lays out documentation conventions that allow YANG
>examples to be presented in IETF documentation when leaf node
>encoding would otherwise exceed the maximum line length.  There are
>no implications in this document for YANG parsers: this document does
>not change the rules for presenting YANG models or for encoding YANG
>in data files or in the wire.

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

Re: [netmod] [OPSAWG] Cross-post to Netmod for LC comments//FW: WG LC for Service Models Explained

[Adrian Farrel]

Hi Carl,

I'm in the process of updating the document and wanted to let you know what 
changes are being made.

>>>  - The term “Network Service Model” in RFC 8199 is intended to cover both
>>>"Customer Service Model” as well as “Service Delivery Model” as defined
>>>in draft-ietf-opsawg-service-model-explained. At the time of the first
>>>revision of what was
>>> draft-bogdanovic-netmod-yang-model-classification
>>>we discussed further splitting "Network Service Model” into smaller
>>>components, but decided against it since we did not see a consensus on
>>>what that split would look like. I believe the authors here is
>>>suggesting such a further split.
>>
>> I think that an "issue" with RFC 8199 is that is appears to imply that the
>> "Network Service Module" (sic) it defines is used on a specific interface 
>> rather
>> than simply being the classification of "all modules used north of this 
>> point". This
>> our draft is doing slightly more than partitioning the classification. The 
>> last couple
>> of rounds of edits to what became 8199 were working with Dean to slightly
>> soften thee language used to make this more consistent.
> 
> Right, and the reason why we took the "all modules used north of this point” 
> is
> that we have not seen any sign of convergence around abstractions into smaller
> components. In short: implementations of “YANG for services” is currently all
> over the map.
> 
>> But see below...
>>
>>>There is one specific passage in this draft that I would suggest could
>>>use rephrasing if the authors agree to the above:
>>>
>>> """
>>>   As previously noted, [I-D.ietf-netmod-yang-model-classification]
>>>   provides a classification of YANG data models.  It introduces the
>>>   term "Network Service YANG Module" to identify the type of model used
>>>   to "describe the configuration, state data, operations and
>>>   notifications of abstract representations of services implemented on
>>>   one or multiple network elements."  These are service delivery models
>>>   as described in this document, that is, they are the models used on
>>>   the interface between the Service Orchestrator or OSS/BSS and the
>>>   Network Orchestrator as shown in Figure 3.
>>> """
>>
>> You suggest this could be rephrased, but don't suggest how:-)
>> I just checked 8199 and I see that the quote we have is still accurate.
>>
>> I am wondering what it is specifically about this text that worries you. 
>> Again, this
>> may come back to the use of a module on a functional interface. I read 8199 
>> as
>> saying that the "Network Service YANG Modules are used by the OSS/BSS in
>> talking to the network elements (o perhaps Controllers?) to configure the
>> network to deliver the service. Am I wrong?
>>
>> If I'm right in my reading we are not "splitting" the classification, but 
>> introducing
>> a new class that lives further north (where the atmosphere is thinner and the
>> temperature colder)
> 
>  I think at the core of the feedback (and sorry that it took two rounds of 
> email to
> make it shorter :-) is that in 8199 the Service Orchestrator is assumed to be 
> an
> integral part of OSS/BSS. More below.

OK. This is much clearer to me now, and leads into the stuff below.

>>> - And this gets to my second point of feedback. Figure 4. in the draft
>>>   seems to suggest that the "Service Orchestrator" is an entity separate
>>>   from the "Operations and Business Support Systems (OSS/BSS)".
>>
>> I want to jump into this paragraph at once just to say "no, no, no!"
>> This figure (like most I draw in ASCII these days) displays functional 
>> components
>> not physical entities.
>> How you choose to implement is entirely up to you.
>> It seems likely (to me) that the interface between customer and operator is
>> externally exposed (but not necessarily realised using RESTconf).
> 
>  This is perhaps also at the core of the feedback. I have never seen an
> implementation/architecture with a functionally distinct Service Orchestrator
> (outside of OSS/BSS) exposed directly to customers. There is usually at least
> something like an order manager (as part of the OSS/BSS) between the customer
> and the service orchestrator. Even in the instances of self-service portals 
> (which
> are naturally located very close to the network) there is at least some 
> notion of
> pricing and billing involved.

Funny that I find I agree and disagree :-)
You are completely right about the status quo. Also about the importance of 
commercial tools as part of the system.
On the other hand, we (well, I) don't want to inhibit developmental approaches. 
For example, a customer might (within some pre-established bounds) be allowed 
to request and modify services directly and have the commercial repercussions 
follow on.

All that said we converge below...

>> It does not seem obvious to me that the Service Orchestrator and the OSS/BSS
>> are separate blobs, except to note that the OSS/BSS deployed 

Re: [netmod] [OPSAWG] Cross-post to Netmod for LC comments//FW: WG LC for Service Models Explained

[Adrian Farrel]

Hi Carl,

>   - The term “Network Service Model” in RFC 8199 is intended to cover both
> "Customer Service Model” as well as “Service Delivery Model” as defined
> in draft-ietf-opsawg-service-model-explained. At the time of the first
> revision of what was
> draft-bogdanovic-netmod-yang-model-classification
> we discussed further splitting "Network Service Model” into smaller
> components, but decided against it since we did not see a consensus on
> what that split would look like. I believe the authors here is
> suggesting such a further split.

I think that an "issue" with RFC 8199 is that is appears to imply that the 
"Network Service Module" (sic) it defines is used on a specific interface 
rather than simply being the classification of "all modules used north of this 
point". This our draft is doing slightly more than partitioning the 
classification. The last couple of rounds of edits to what became 8199 were 
working with Dean to slightly soften thee language used to make this more 
consistent.

But see below...

> There is one specific passage in this draft that I would suggest could
> use rephrasing if the authors agree to the above:
>
> """
>As previously noted, [I-D.ietf-netmod-yang-model-classification]
>provides a classification of YANG data models.  It introduces the
>term "Network Service YANG Module" to identify the type of model used
>to "describe the configuration, state data, operations and
>notifications of abstract representations of services implemented on
>one or multiple network elements."  These are service delivery models
>as described in this document, that is, they are the models used on
>the interface between the Service Orchestrator or OSS/BSS and the
>Network Orchestrator as shown in Figure 3.
> """

You suggest this could be rephrased, but don't suggest how:-)
I just checked 8199 and I see that the quote we have is still accurate.

I am wondering what it is specifically about this text that worries you. Again, 
this may come back to the use of a module on a functional interface. I read 
8199 as saying that the "Network Service YANG Modules are used by the OSS/BSS 
in talking to the network elements (o perhaps Controllers?) to configure the 
network to deliver the service. Am I wrong?

If I'm right in my reading we are not "splitting" the classification, but 
introducing a new class that lives further north (where the atmosphere is 
thinner and the temperature colder)

>  - And this gets to my second point of feedback. Figure 4. in the draft
>seems to suggest that the "Service Orchestrator" is an entity separate
>from the "Operations and Business Support Systems (OSS/BSS)".

I want to jump into this paragraph at once just to say "no, no, no!"
This figure (like most I draw in ASCII these days) displays functional 
components not physical entities.
How you choose to implement is entirely up to you.
It seems likely (to me) that the interface between customer and operator is 
externally exposed (but not necessarily realised using RESTconf).
It does not seem obvious to me that the Service Orchestrator and the OSS/BSS 
are separate blobs, except to note that the OSS/BSS deployed today does not 
support the Customer Service YANG Modules and so the extent to which it 
provides "service orchestration" is limited.
I might also claim that an OSS/BSS possibly operates on a single network where 
the orchestration of a service *might* involve the coordination of more than 
one network.

> And also that
>Customers (as defined) in Section 2 interface directly with that entity.
>This is a very unusual construct, in the sense that:
> o The common taxonomomy from e.g. TMForum would classify a service
>   orchestrator as a part of the OSS/BSS stack, since...
> o The successful activation of a service includes many parts of the
>   OSS/BSS-stack including operational readiness (are there physical
>   ports available), billing management (is the customer allowed to 
>   perform e.g. this resource expansion), and assurance (changed
>   services require new assurance parameters). This makes it hard
>   to separate out a Customer interface to service orchestration
>   only, separate from the OSS/BSS stack.

I am not (overly) familiar with the TMF work, however, your text "TMForum would 
classify a service orchestrator as a part of the OSS/BSS stack" suggests the 
acceptance of service orchestration as "a thing". If you were writing code, you 
*might* write a separate module (even library) to handle service orchestration, 
and maintain that as a separate module from billing management, etc. That does 
not make them completely separate, but does result in them showing as separate 
functional components in the "OSS/BSS stack."

>  This an informational draft and as such is for general information, and
> not  necessarily intended to represent community consensus or
> 

Re: [netmod] Migrating existing RFCs to NMDA

[Adrian Farrel]

Thanks,
That is helpful.
Adrian

> -Original Message-
> From: Robert Wilton [mailto:rwil...@cisco.com]
> Sent: 20 July 2017 10:39
> To: adr...@olddog.co.uk; netmod@ietf.org; Martin Bjorklund; Kent Watsen; Phil
> Shafer; j.schoenwael...@jacobs-university.de
> Subject: Re: [netmod] Migrating existing RFCs to NMDA
> 
> Hi Adrian,
> 
> My understanding of the current plan is:

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

Re: [netmod] Last Call: (YANG Module Classification) to Informational RFC

[Adrian Farrel]

Hi,

I've been reading, reviewing, and discussing this document for a number of
revisions. Of special concern was the relationship to RFC 8049 and
draft-wu-opsawg-service-model-explained.

The last two revisions have captured the essence of these discussions, and I am
happy with the document as it stands. I think it should be published as an
Informational RFC.

Thanks,
Adrian

> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of The IESG
> Sent: 01 May 2017 03:32
> To: IETF-Announce
> Cc: netmod-cha...@ietf.org; war...@kumari.net; draft-ietf-netmod-yang-
> model-classificat...@ietf.org; netmod@ietf.org
> Subject: [netmod] Last Call:

> (YANG Module Classification) to Informational RFC
> 
> 
> The IESG has received a request from the NETCONF Data Modeling Language
> WG (netmod) to consider the following document:
> - 'YANG Module Classification'
>as Informational
> RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> i...@ietf.org mailing lists by 2017-05-14. Exceptionally, comments may be
> sent to i...@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>The YANG data modeling language is currently being considered for a
>wide variety of applications throughout the networking industry at
>large.  Many standards-defining organizations (SDOs), open source
>software projects, vendors and users are using YANG to develop and
>publish YANG modules for a wide variety of applications.  At the same
>time, there is currently no well-known terminology to categorize
>various types of YANG modules.
> 
>A consistent terminology would help with the categorization of YANG
>modules, assist in the analysis of the YANG data modeling efforts in
>the IETF and other organizations, and bring clarity to the YANG-
>related discussions between the different groups.
> 
>This document describes a set of concepts and associated terms to
>support consistent classification of YANG modules.
> 
> 
> 
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-
> classification/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> 
> 
> ___
> 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] Progress of draft-ietf-netmod-yang-model-classification and draft-wu-opsawg-service-model-explained

[Adrian Farrel]

Hi,

As just stated at the mic in the OPS Area meeting, I met with Dean Bogdanovic
today to discuss the overlap/underlap between these two drafts.

1. We went through the text changes to
draft-ietf-netmod-yang-model-classification and I am happy that changes in the
-05 revision address the questions I have been asking. I do see two nits:
a. draft-ietf-l3sm-l3vpn-service-model is now RFC 8049
b. The paragraph that references that document is perfect and correct, but may
be slightly out of place as its current position suggests that it is a "Network
Service model" where I think that Dean and I have agreed that it is actually one
level higher (a business service model in his language) and so basically out of
scope of this document.
I would suggest moving this paragraph to be the last paragraph in Section 2.1.

2. draft-wu-opsawg-service-model-explained
We will revise this document to align a little more closely with the language in
draft-ietf-netmod-yang-model-classification and (more important) to not re-state
(even in different language) what is in
draft-ietf-netmod-yang-model-classification.
I believe this will address all open worries in the document that have been
expressed on the list.

Thanks,
Adrian

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

Re: [netmod] Question on draft-ietf-netmod-yang-model-classification

[Adrian Farrel]

Hi Tianran,

Nice summary.

I think some of the confusion may be that 
draft-ietf-netmod-yang-model-classification shows "Network Service YANG 
Modules" on the interface between OSS/BSS and the network. But the "customer 
service model" is at a different place in the hierarchy as shown in Figure 4 of 
draft-wu-opsawg-service-model-explained.

To attend to your specific questions:
> 1. Whether it's necessary to further classify the "Network Service YANG
> Module"?

I'm not particularly interested in doing that except so far as is necessary to 
avoid conflict between the two I-Ds. In draft-wu-opsawg-service-model-explained 
we introduced "customer service module" and "service delivery module" because 
it seemed (to us) that there were two different groups of people using the term 
"service model" to describe very different modules.

> 2. What's the well definition of "Network Service YANG Module", "customer
> service module", "service delivery module"?

Since draft-wu-opsawg-service-model-explained introduces the terms "customer 
service module" and "service delivery module" I am going to say that I am happy 
with the definitions in that document. I can say that "customer service module" 
is used consistently with the L3SM and L2SM work and so it is probably a stable 
definition. "Service delivery module" is a term we invented to match the 
definition in draft-wu-opsawg-service-model-explained: I don't think the term 
is used anywhere else, so maybe a better question is "is this a 
useful/meaningful term?"

If the answer to Q1 is that draft-wu-opsawg-service-model-explained should not 
try to resolve any overlap with draft-ietf-netmod-yang-model-classification, 
then I think the definition of "Network Service YANG Module" in 
draft-ietf-netmod-yang-model-classification is fine (with the few tweaks Dean 
and I discussed on the list).

> 3. What's the well position of the above terms in the management architecture?

Ah, I like that question. But it makes me ask: where should I look for the 
definitive, state-of-the art management architecture?

Thanks for continuing to drive this issue.

Adrian

> -Original Message-
> From: Tianran Zhou [mailto:zhoutian...@huawei.com]
> Sent: 14 February 2017 09:54
> To: Carl Moberg (camoberg); adr...@olddog.co.uk
> Cc: ops...@ietf.org; draft-ietf-netmod-yang-model-classificat...@ietf.org;
> netmod@ietf.org; Dean Bogdanovic
> Subject: RE: Question on draft-ietf-netmod-yang-model-classification
> 
> Hi,
> 
> Based on the discussion, here I try to clean up the confusion of the two I-Ds.
> 
> [draft-ietf-netmod-yang-model-classification] classifies the yang modules into
> "Network Service YANG Module" and the "Network Element YANG Module".
> And usually, it uses "service module" to imply the "Network Service YANG
> Module", i.e., "Network" here only want to limit the scope to network related
> modules. One example of "Network Service YANG Module" is [draft-ietf-l3sm-
> l3vpn-service-model].
> The authors do not want to further classify the service module into more 
> layers,
> until more operational practice comes.
> 
> [draft-wu-opsawg-service-model-explained] further classifies the service 
> module
> into "customer service module" and the "service delivery module". I think 
> this is
> based on the chair work on L3SM and L2SM WG and discussion with operators.
> But the document think the "Network Service YANG Module" defined in [draft-
> ietf-netmod-yang-model-classification] is "service delivery module" not 
> include
> the "customer service module". The [draft-ietf-l3sm-l3vpn-service-model] is
> actually the "customer service module".
> 
> Here comes the question:
> 1. Whether it's necessary to further classify the "Network Service YANG
> Module"?
> 2. What's the well definition of "Network Service YANG Module", "customer
> service module", "service delivery module"?
> 3. What's the well position of the above terms in the management architecture?
> 
> Good to see if we can solve the conflicts, these two I-Ds can complement each
> other.
> 
> Best,
> Tianran
> 
> > -Original Message-
> > From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Carl Moberg
> > (camoberg)
> > Sent: Thursday, February 09, 2017 12:48 AM
> > To: adr...@olddog.co.uk
> > Cc: ops...@ietf.org;
> > draft-ietf-netmod-yang-model-classificat...@ietf.org; netmod@ietf.org;
> > Dean Bogdanovic
> > Subject: Re: [netmod] Question on
> > draft-ietf-netmod-yang-model-classificat

Re: [netmod] Question on draft-ietf-netmod-yang-model-classification

[Adrian Farrel]

Hi Dean,

I've been processing your response and the continuing thread with you and 
Tianran.

> > 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.
> 
> Adrian, I can see the ambiguity. The point of service module is to be 
> consumed by
> the customer and there can be some modifications of the service module to
> adapt to the customer specifics.

So far I agree with your email and therefore not with your document. The 
OSS/BSS is not, IMHO, a tool used by the customer.

Please see Figure 3 in draft-wu-opsawg-service-model-explained-05.txt that 
shows the customer distinct from 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.
> 
> Agree that external systems are not defined and this text has to be 
> clarified. The
> external systems can be OSS and BSS.

If we relabelled our "Service Delivery Model" as "Network Service Model" would 
that be consistent?

That is, in any case, to say that the OSS/BSS does not talk directly to the 
devices.

> > 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.
> 
> My question is where do you see the L3SM model
> above or below OSS?

Well, look at the figure in section 5 of 
draft-ietf-l3sm-l3vpn-service-model-19.txt

It is logically higher, but OSS/BSS are not "in the flow" as they are legacy 
components in a softwarized world.
However, per our pictures, OSS/BSS should use the same set of models/modules as 
used by the "service orchestrator".

> Because there are some nuances in the service module, but at the end we
> decided not to do sub classification

Mutter, mutter.
In the document, you talk about "network service modules" not "service modules" 
and only trim to "service module" in the text implying that you always actually 
mean "network service module".

> one is the business and one technical service.
> 
> When i read the YANG-Data-Model-for-L3VPN-service-delivery, it looked to me
> much more like a technical model, then the business model, as didn’t see SLA
> definitions to track the business parameters of the service use.

It is certainly not a business model and does not include SLAs. Other people 
have far more experience working on these things (TMF, MEF, ...) and it is not 
an IETF core competence. Our intention is that our module can be augmented or 
accompanied by other modules in order to create a business model, acknowledging 
that commercial details (even including SLAs) will vary from one operator to 
another, but that the core technical description of the service can be (and, it 
turns out, is) common across multiple providers.

We even wrote text in Section 5 of draft-wu-opsawg-service-model-explained to 
help with this.

> > 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.
> 
> Sure, 

[netmod] Question on draft-ietf-netmod-yang-model-classification

[Adrian Farrel]

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

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

[netmod] Reference error in draft-ietf-netmod-yang-model-classification

[Adrian Farrel]

Hi,

I think [YANG-Data-Model-for-L3VPN-service-delivery] should point to
draft-ietf-l3sm-l3vpn-service-model not (the old) draft-l3vpn-service-yang.

Indeed, in general, if you end up having to point to a tools copy of an I-D not
a datatracker version, this is usually an indication that you are pointing to an
expired draft.

Thanks,
Adrian

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

[netmod] Formation of another YANG-related WG

[Adrian Farrel]

Hi YANG-fiends,

Please note that the L2SM working group has been formed and will meet in Seoul
on Thursday at 9:30.

The focus is the development of a YANG model for the provision of L2VPN services
on the interface between operator and customer.

Thanks,
Adrian

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

Re: [netmod] New revision of draft-wu-opsawg-service-model-explained

[Adrian Farrel]

Hi Michael,

Thanks for the helpful email.

> In general, I believe that distinguishing between different terms for "service
> model" is useful.
> 
> Actually, I would suggest to align the terminology in
draft-ietf-l3sm-l3vpn-service-
> model accordingly, e.g., by using the term "Customer Service Model" in the
L3SM
> WG. For instance, the title of draft-ietf-l3sm-l3vpn-service-model-12 "YANG
Data
> Model for L3VPN service delivery" is quite inconsistent with the use of the
term
> "service delivery" in draft-wu-opsawg-service-model-explained. It would be
> good to avoid confusion.

Yes.
Although we added text to draft-wu-opsawg-service-model-explained to explain the
terminology mapping, I think you're right that it would be even better to avoid
the need.

So that is an issue to take to L3SM (or the IETF last call of
draft-ietf-l3sm-l3vpn-service-model)

> Despite the discussion in https://www.ietf.org/mail-
> archive/web/opsawg/current/msg04486.html, the draft still contains the wording
> "all of the parameters". I continue to believe that a wording such as "the
> parameters" would be more consistent with the rest of the document talking
> about operator-specific augmentations etc.

My bad dropping that email.
I'll go back and respond on that thread.

> The document, in particular in Section 6.1, could better distinguish between
the
> terms "module" and "model", if an alignment with draft-ietf-netmod-yang-
> model-classification is the objective. One example where the terminology is
not
> entirely consistent is the sentence "add an additional example of a Network
> Service YANG model as shown in Figure 4". That figure actually shows modules.

Nice point. Does anyone have a reference for the definition of model and module
in the YANG context (or I can search :-)

> Apparently Section 6.4 refers to MEF 55. I wonder why the specification MEF 55
is
> not referenced. Also, I believe the terminology in Section 6.4 may have to be
> reviewed. For instance, MEF apparently uses the term reference points
> ("Management Interface Reference Point") instead of "interface" in MEF 55.

Thanks for the pointer. It is hard to search all of the MEF documents (public
and private) to find a figure.
I will add the reference and clear up the language.

> Editorial nit: s/to/two/ in "The service model may divided into to categories"

Ack

Cheers,
Adrian

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

[netmod] New revision of draft-wu-opsawg-service-model-explained

[Adrian Farrel]

Hi,

[Copying NETMOD, but suggest all discussions are held on OPSAWG list]

We updated our document to (hopefully) make some stuff clearer...

- We are not trying to piss on draft-ietf-netmod-yang-model-classification!
   Actually, that is an important reference, but its approach is slightly 
   different. We have beefed up our discussion of the relationship with that
   draft. Our belief is that the two drafts are complementary and that our
   work should not delay the completion of the NETMOD draft.

- The distinction between a "service model" and a "service model" (sic) has
   become unclear. We have introduced the terms "customer service model"
   and "service delivery model", explained what these are, and shown mappings
   of other work to these terms. We would propose, if these terms are clear 
   and acceptable, that new work adopt these terms, but we do not suggest
   that it is necessary to go and change existing mature work.

- There was some discussion around "what do you mean by a service?" We
   have tried to tidy our text about this, but could probably use help.

As always, comments, rotten fruit, and constructive input would be welcome.

Cheers,
Adrian (for the authors)
--
Support an author and your imagination.
Tales from the Wood - Eighteen new fairy tales.
More Tales from the Wood - Eighteen more new fairy tales.
https://www.feedaread.com/profiles/8604/
http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924
Or buy from me direct.

> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> 
> Title   : Service Models Explained
> 
> Abstract:
>The IETF has produced a considerable number of data models in the
>YANG modelling language.  The majority of these are used to model
>devices and they allow access for configuration and to read
>operational status.
> 
>A small number of YANG models are used to model services (for
>example, the Layer Three Virtual Private Network Service Model
>produced by the L3SM working group).
> 
>This document briefly sets out the scope of and purpose of an IETF
>service model, and it shows where a service model might fit into a
>Software Defined Networking architecture or deployment.
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-wu-opsawg-service-model-explained/

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