Re: [netmod] WG Last Call: draft-ietf-netmod-artwork-folding-02
All, The WG LC is closed. Authors, Please continue resolving the raised issues on the list, and let the WG know once a version that addresses all raised issues has been uploaded/published. Also please also summarize any includes changes that were not otherwise discussed on-list. Thank you! Lou On 5/12/2019 5:19 PM, Lou Berger wrote: 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] WG Last Call: draft-ietf-netmod-artwork-folding-02
Hi Martin, >> When a larger document contains multiple instances of text content >> that may need to be folded or unfolded, it is assumed that another >> process inserts/extracts the individual text content instances to/ >> from the larger document prior to utilizing the algorithms described >> in this section. For example, the `xiax` utility [xiax] does this. > > Well, again I don't really understand why we need to assume _anything_ > about how the author decides to implement this format. removed the word "assumed", now text reads: When a larger document contains multiple instances of text content that may need to be folded or unfolded, another process must insert/ extract the individual text content instances to/from the larger document prior to utilizing the algorithms described in this section. For example, the `xiax` utility [xiax] does this. > I would just remove this paragraph. This paragraph and others like it were added by others that thought that this algorithm was intended to process an entire I-D or RFC. > On second thought, this text doesn't have to mention when SBS can't be > used. Okay, not changed. >>> o 7.2.1 >>> >>> I don't understand why there is a min limit of 46 characters for >>> folding to work. If the only reason is for the non-normative script >>> to be able to center the header line, then I think this limitation >>> should be removed. (I would even prefer less flexibility in the >>> header line syntax...) >> >> This is because we never defined how to handle folding the header >> itself. I wrote about this a while back and no-one seemed bothered by >> the limitation. The effort/value ration isn't there. The need to >> fold less than 69-characters is unlikely, and less than 46-characters >> seems even more so. > > IMO we could remove this arbitrary limitaion and still leave the > header alone. Not arbitrary, as explained, leaving as is. >>> o 7.2.1 / 7.2.2 >>> >>> I don't think the text should assume that folding/unfolding is >>> "automated". >> >> Both sections clearly state that authors may do the equivalent >> manually, or do you mean that the word "automated" in these sections >> isn't adding much value and could/should be removed? > > Right: > > OLD: > > Folding is assumed to be automated although authors may perform the > folding steps manually. > > Determine the desired maximum line length from input to the automated > line-wrapping process, > > NEW: > > Determine the desired maximum line length from input to the > line-wrapping process, Fixed (in 8.2.1 also) You supplied text for 7.2.1, but also mentioned 7.2.2 (and ~ 8.2.2) originally. For these sections, the appropriate change is to remove the first paragraph, which I did (in my local copy). Specifically: OLD: All unfolding is assumed to be automated although a reader will mentally perform the act of unfolding the text to understand the true nature of the original text content. NEW: Kent // author ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] [Teas] Key collision between configured and ephemeral list entries
Rob, Tarek, Thanks for following-up this discussion I like the suggestion to use a prefix string: those who prefers using one character (e.g., '#') could use a single character string Regarding the configuration, one possible issue that just jumped into my mind is what happens when the prefix is (re-)configured by the client after some ephemeral tunnels have been created ... An alternative solution could be to let the server decide which prefix to use (server implementation issue) and to provide a read-only YANG leaf to report this information to the client, such that the client knows it could not use this prefix for the configured tunnels My 2 cents Italo -Original Message- From: Tarek Saad [mailto:tsaad@gmail.com] Sent: mercoledì 29 maggio 2019 17:22 To: Rob Wilton (rwilton) ; tom petch ; Italo Busi ; netmod@ietf.org Cc: t...@ietf.org Subject: Re: [Teas] [netmod] Key collision between configured and ephemeral list entries Hi Rob, Inline.. On 5/29/19, 9:05 AM, "Teas on behalf of Rob Wilton (rwilton)" wrote: Are these ephemeral tunnels created and named by the device itself? [TS]: yes, some of those are auto-created by the device (e.g. triggered by some local event). Possibly using a human readable prefix (or suffix) might be better than using a symbol. E.g. perhaps a prefix of "sys-" as an abbreviation for system. [TS]: I tend to agree here. I had suggested making this prefix configurable - not sure if this brings more trouble. [TS]: On a similar note, on the controller, some tunnels from different ingress routers will be reported up to the controller. One way to avoid collision of same tunnel name existing on multiple ingress devices, we thought of is for that controller to (automatically) append the ingress router name (or IP address) before consuming the reported tunnel into the controller tunnel list. Thoughts? Regards, Tarek Thanks, Rob -Original Message- From: Teas On Behalf Of tom petch Sent: 29 May 2019 12:04 To: Italo Busi ; netmod@ietf.org Cc: t...@ietf.org Subject: Re: [Teas] [netmod] Key collision between configured and ephemeral list entries - Original Message - From: "Italo Busi" Sent: Wednesday, May 29, 2019 11:02 AM Hi Tom, Thanks for your reply It seems to me that the text you have quoted is from: https://tools.ietf.org/html/rfc7950#section-6.2 If I can understand correctly, especially for section 6.2.1, this constraints does not apply to name attributes whose syntax is defined as a string and used as key of a list, such as the tunnel list defined in the TE YANG model: | +--rw tunnel* [name] | | +--ro operational-state? identityref | | +--rw namestring My understanding is that a tunnel list entry with a name starting with '#' can exist in a YANG DS Italo Ah yes, my misunderstanding. 'string' type is a bit more flexible i.e. The string built-in type represents human-readable strings in YANG. Legal characters are the Unicode and ISO/IEC 10646 [ISO.10646] characters, including tab, carriage return, and line feed but excluding the other C0 control characters, the surrogate blocks, and the noncharacters. Plenty of scope there! If this approach is taken, then I agree that hash is a good choice as it stands out, unlike, say, underscore which vanishes in the line of text. Tom Petch Thanks, Italo -Original Message- From: tom petch [mailto:ie...@btconnect.com] Sent: mercoledì 29 maggio 2019 10:42 To: Italo Busi ; netmod@ietf.org Cc: t...@ietf.org Subject: Re: [netmod] Key collision between configured and ephemeral list entries Tom Petch - Original Message - From: "Italo Busi" To: Cc: Sent: Monday, May 27, 2019 2:16 PM Subject: [netmod] Key collision between configured and ephemeral list entries On Friday within the TEAS WG, we have discussed an issue which seems generic and therefore agreed to ask for guidelines to the Netmod WG In the TE YANG model we have defined a tunnel list with a name attribute used as a key: | +--rw tunnel* [name] | | +--ro operational-state? identityref | | +--rw namestring See: https://tools.ietf.org/html/draft-ietf-teas-yang-te-21 The issue we are facing is how to avoid name collision between configured and ephemeral tunnels. In other words, the issue we are trying to address is how to avoid the client to assign to a configured tunnel a name which have been already assigned by the server to another ephemeral tunnel and vice-versa, in particular
Re: [netmod] [Teas] Key collision between configured and ephemeral list entries
Hi Rob, Inline.. On 5/29/19, 9:05 AM, "Teas on behalf of Rob Wilton (rwilton)" wrote: Are these ephemeral tunnels created and named by the device itself? [TS]: yes, some of those are auto-created by the device (e.g. triggered by some local event). Possibly using a human readable prefix (or suffix) might be better than using a symbol. E.g. perhaps a prefix of "sys-" as an abbreviation for system. [TS]: I tend to agree here. I had suggested making this prefix configurable - not sure if this brings more trouble. [TS]: On a similar note, on the controller, some tunnels from different ingress routers will be reported up to the controller. One way to avoid collision of same tunnel name existing on multiple ingress devices, we thought of is for that controller to (automatically) append the ingress router name (or IP address) before consuming the reported tunnel into the controller tunnel list. Thoughts? Regards, Tarek Thanks, Rob -Original Message- From: Teas On Behalf Of tom petch Sent: 29 May 2019 12:04 To: Italo Busi ; netmod@ietf.org Cc: t...@ietf.org Subject: Re: [Teas] [netmod] Key collision between configured and ephemeral list entries - Original Message - From: "Italo Busi" Sent: Wednesday, May 29, 2019 11:02 AM Hi Tom, Thanks for your reply It seems to me that the text you have quoted is from: https://tools.ietf.org/html/rfc7950#section-6.2 If I can understand correctly, especially for section 6.2.1, this constraints does not apply to name attributes whose syntax is defined as a string and used as key of a list, such as the tunnel list defined in the TE YANG model: | +--rw tunnel* [name] | | +--ro operational-state? identityref | | +--rw namestring My understanding is that a tunnel list entry with a name starting with '#' can exist in a YANG DS Italo Ah yes, my misunderstanding. 'string' type is a bit more flexible i.e. The string built-in type represents human-readable strings in YANG. Legal characters are the Unicode and ISO/IEC 10646 [ISO.10646] characters, including tab, carriage return, and line feed but excluding the other C0 control characters, the surrogate blocks, and the noncharacters. Plenty of scope there! If this approach is taken, then I agree that hash is a good choice as it stands out, unlike, say, underscore which vanishes in the line of text. Tom Petch Thanks, Italo -Original Message- From: tom petch [mailto:ie...@btconnect.com] Sent: mercoledì 29 maggio 2019 10:42 To: Italo Busi ; netmod@ietf.org Cc: t...@ietf.org Subject: Re: [netmod] Key collision between configured and ephemeral list entries Tom Petch - Original Message - From: "Italo Busi" To: Cc: Sent: Monday, May 27, 2019 2:16 PM Subject: [netmod] Key collision between configured and ephemeral list entries On Friday within the TEAS WG, we have discussed an issue which seems generic and therefore agreed to ask for guidelines to the Netmod WG In the TE YANG model we have defined a tunnel list with a name attribute used as a key: | +--rw tunnel* [name] | | +--ro operational-state? identityref | | +--rw namestring See: https://tools.ietf.org/html/draft-ietf-teas-yang-te-21 The issue we are facing is how to avoid name collision between configured and ephemeral tunnels. In other words, the issue we are trying to address is how to avoid the client to assign to a configured tunnel a name which have been already assigned by the server to another ephemeral tunnel and vice-versa, in particular considering NMDA rules We believe that the issue is generic and apply to any configured and ephemeral list entries Has this issue been already discussed/resolved in Netmod WG? If not, what is the Netmod WG opinion/suggestion? We are currently considering the following option: Use a special character for ephemeral names - e.g. such names always are prepended by special character "#" Make the special character changeable by configuration - the default can be "#" and user can change if they desire.. If this is to conform with YANG 1.1, RFC7950, then the constraint is Identifiers are used to identify different kinds of YANG items by name. Each identifier starts with an uppercase or lowercase ASCII letter or an underscore character, followed by zero or more ASCII letters, digits, underscore characters, hyphens, and dots. No # (hash) anywhere so I suspect
Re: [netmod] WG Last Call: draft-ietf-netmod-artwork-folding-02
Kent Watsen wrote:
>
>
> Hi Martin,
>
> Thanks for your review.
>
>
> > I have reviewed draft-ietf-netmod-artwork-folding-02, and here are my
> > comments:
[...]
> > The algorithm talks specifically about space (' ') rather than
> > whitespace.
>
> True and, FWIW, this was the only instance of the word "whitespace" in
> the document.
>
> However, I wonder if there might be an issue lurking here. Already
> the algorithm eliminates the potential for TAB, and implicitly
> eliminates NL and CR through the use of the word "line", but I wonder
> if there are other characters that we wish to skip
> over... e.g. vertical tab?
No.
[...]
> > o 7.1.2 / 7.2
> >
> > I would prefer if the format is defined with descriptive text,
> > rather than with an algorithm. It is the end result that matters,
> > not which algorithm an implementation uses to get to the result.
> >
> > I suggest the algorithm is moved to an appendix, and/or a sentence
> > is added that explains that the algorithm is just an example.
>
> OLD:
>
>This section describes the process for folding and unfolding long
>lines when they are encountered in a single instance of text content.
>It is assumed that another process inserts/extracts the individual
>text content instances to/from an Internet-Draft or RFC. For
>example, the `xiax` utility [xiax] does this.
>
>
> NEW:
>
>This section describes a process for folding and unfolding long lines
>when they are encountered in text content.
>
>The steps are complete, but implementations MAY achieve the same
>result in other ways.
>
>When a larger document contains multiple instances of text content
>that may need to be folded or unfolded, it is assumed that another
>process inserts/extracts the individual text content instances to/
>from the larger document prior to utilizing the algorithms described
>in this section. For example, the `xiax` utility [xiax] does this.
Well, again I don't really understand why we need to assume _anything_
about how the author decides to implement this format.
I would just remove this paragraph.
> > Also expand the descriptive text in 7.1.2; I think that the text in
> > section 6 is probably enough. However, there are some important
> > details buried in the desciption of the algorithm; specifically the
> > cases where SBS can't be used.
>
> I looked at this for a little while, but didn't see how it could be
> improved. Can you provide some text?
NEW:
Lines that have a backslash ('\') occurring as the last character in
a line are considered "folded", which means that the line continues
at the first character that is not a space (' ') on the following line.
Really long lines may be folded multiple times.
On second thought, this text doesn't have to mention when SBS can't be
used.
> > o 7.2.1
> >
> > I don't understand why there is a min limit of 46 characters for
> > folding to work. If the only reason is for the non-normative script
> > to be able to center the header line, then I think this limitation
> > should be removed. (I would even prefer less flexibility in the
> > header line syntax...)
>
> This is because we never defined how to handle folding the header
> itself. I wrote about this a while back and no-one seemed bothered by
> the limitation. The effort/value ration isn't there. The need to
> fold less than 69-characters is unlikely, and less than 46-characters
> seems even more so.
IMO we could remove this arbitrary limitaion and still leave the
header alone.
> > o 7.2.1 / 7.2.2
> >
> > I don't think the text should assume that folding/unfolding is
> > "automated".
>
> Both sections clearly state that authors may do the equivalent
> manually, or do you mean that the word "automated" in these sections
> isn't adding much value and could/should be removed?
Right:
OLD:
Folding is assumed to be automated although authors may perform the
folding steps manually.
Determine the desired maximum line length from input to the automated
line-wrapping process,
NEW:
Determine the desired maximum line length from input to the
line-wrapping process,
/martin
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call: draft-ietf-netmod-artwork-folding-02
Kent Watsen wrote:
>
>
> > [RW]
> > Yes, I think that is better, and probably OK.
> >
> > I still slightly question “One strategy is based on the time-proven 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.” Because I don’t think that is how ‘\’
> > character works, at least in languages such as C. Specifically, it doesn’t
> > ignore leading whitespace on the following line, instead it is often used
> > where that whitespace is not significant to the compiler.
>
> Would s/time-proven/POSIX/ be better?
If you write POSIX I think you need a reference. Is there really a
POSIX standard for how a single backslash is used...?
I think "time-proven" is better.
/martin
>
> BTW, I also added this to Appendix A:
>
>Shell-level end-of-line backslash ('\') characters have been
>purposely added to the script so as to ensure that the script is
>itself not folded in this document, thus simplify the ability to
>copy/paste the script for local use. As should be evident by the
>lack of the mandatory header described in Section 7.1.1, these
>backslashes do not designate a folded line, such as described in
>Section 7.
>
>
>
>
> > [RW]
> > Perhaps “original text content” -> “exact original text content”? But I’m
> > also OK with your suggested text.
>
> I'm hesitant, because it seems redundant, but it doesn't cause harm, so I
> added it.
>
>
>
> > [RW]
> > According to RFC2119, RECOMMENDED is interpreted exactly the same way as
> > SHOULD.
>
> Yes, when composing my response before I was going to say that it's a
> downgrade "(in IMO)", but figured it would require more explanation, which I
> was hoping to avoid. But here we are now ;) While I'm aware that they
> carry the same RFC 2119 weight, RECOMMENDED reads softer to me, less
> commanding, hence my comment.
>
>
>
> > I still think that SHOULD/RECOMMENDED is too strong.
>
> I still disagree.Any tie-breakers out there?
>
>
>
> > Good point, how about this?
> >
> >Scan the text content to ensure no existing lines already end with a
> >backslash ('\') character while the subsequent line starts with a
> >backslash ('\') character as the first non-space (' ') character, as
> >this could lead to an ambiguous result. If such a line is found, and
> >its width is less than the desired maximum, then it SHOULD be flagged
> >for forced folding (folding even though unnecessary). If the folding
> >implementation doesn't support forced foldings, it MUST exit.
> >
> >
> >
> >For each line in the text content, from top-to-bottom, if the line
> >exceeds the desired maximum, or requires a forced folding, then fold
> >the line by:
> >
> >
> > [RW]
> > OK.
>
> Great. BTW, I also added this to Appendix A:
>
>This script does not implement the "forced folding" logic described
>in Section 8.2.1. In such cases the script will exit with the
>message:
>
> Error: infile has a line ending with a '\\' character
> followed by a '\\' character as the first non-space
> character on the next line. This file cannot be folded.
>
>
>
>
> Kent // author
>
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Key collision between configured and ephemeral list entries
Are these ephemeral tunnels created and named by the device itself? Possibly using a human readable prefix (or suffix) might be better than using a symbol. E.g. perhaps a prefix of "sys-" as an abbreviation for system. Thanks, Rob -Original Message- From: Teas On Behalf Of tom petch Sent: 29 May 2019 12:04 To: Italo Busi ; netmod@ietf.org Cc: t...@ietf.org Subject: Re: [Teas] [netmod] Key collision between configured and ephemeral list entries - Original Message - From: "Italo Busi" Sent: Wednesday, May 29, 2019 11:02 AM Hi Tom, Thanks for your reply It seems to me that the text you have quoted is from: https://tools.ietf.org/html/rfc7950#section-6.2 If I can understand correctly, especially for section 6.2.1, this constraints does not apply to name attributes whose syntax is defined as a string and used as key of a list, such as the tunnel list defined in the TE YANG model: | +--rw tunnel* [name] | | +--ro operational-state? identityref | | +--rw namestring My understanding is that a tunnel list entry with a name starting with '#' can exist in a YANG DS Italo Ah yes, my misunderstanding. 'string' type is a bit more flexible i.e. The string built-in type represents human-readable strings in YANG. Legal characters are the Unicode and ISO/IEC 10646 [ISO.10646] characters, including tab, carriage return, and line feed but excluding the other C0 control characters, the surrogate blocks, and the noncharacters. Plenty of scope there! If this approach is taken, then I agree that hash is a good choice as it stands out, unlike, say, underscore which vanishes in the line of text. Tom Petch Thanks, Italo -Original Message- From: tom petch [mailto:ie...@btconnect.com] Sent: mercoledì 29 maggio 2019 10:42 To: Italo Busi ; netmod@ietf.org Cc: t...@ietf.org Subject: Re: [netmod] Key collision between configured and ephemeral list entries Tom Petch - Original Message - From: "Italo Busi" To: Cc: Sent: Monday, May 27, 2019 2:16 PM Subject: [netmod] Key collision between configured and ephemeral list entries On Friday within the TEAS WG, we have discussed an issue which seems generic and therefore agreed to ask for guidelines to the Netmod WG In the TE YANG model we have defined a tunnel list with a name attribute used as a key: | +--rw tunnel* [name] | | +--ro operational-state? identityref | | +--rw namestring See: https://tools.ietf.org/html/draft-ietf-teas-yang-te-21 The issue we are facing is how to avoid name collision between configured and ephemeral tunnels. In other words, the issue we are trying to address is how to avoid the client to assign to a configured tunnel a name which have been already assigned by the server to another ephemeral tunnel and vice-versa, in particular considering NMDA rules We believe that the issue is generic and apply to any configured and ephemeral list entries Has this issue been already discussed/resolved in Netmod WG? If not, what is the Netmod WG opinion/suggestion? We are currently considering the following option: Use a special character for ephemeral names - e.g. such names always are prepended by special character "#" Make the special character changeable by configuration - the default can be "#" and user can change if they desire.. If this is to conform with YANG 1.1, RFC7950, then the constraint is Identifiers are used to identify different kinds of YANG items by name. Each identifier starts with an uppercase or lowercase ASCII letter or an underscore character, followed by zero or more ASCII letters, digits, underscore characters, hyphens, and dots. No # (hash) anywhere so I suspect that a lot of tooling will fail in an unpredictable way if it encounters an illegal character in an identifier. Tom Petch Thanks, Italo Italo Busi Principal Optical Transport Network Research Engineer Huawei Technologies Co., Ltd. Tel : +39 345 4721946 Email : italo.b...@huawei.com [cid:image002.png@01D5149F.354EF420] This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! From: Tarek Saad [mailto:tsaad@gmail.com] Sent: venerdì 24 maggio 2019 23:13 To: Igor Bryskin ; Rakesh Gandhi ; Xufeng ; Vishnu Pavan Beeram ; Italo Busi Cc: t...@ietf.org Subject: Discussion on modelling container TE tunnels in YANG The team on "to" list met to discuss this subject topic. Notes from today's discussion (please add
Re: [netmod] WG Last Call: draft-ietf-netmod-artwork-folding-02
It looks very good to me
Thanks, Italo
Italo Busi
Principal Optical Transport Network Research Engineer
Huawei Technologies Co., Ltd.
Tel : +39 345 4721946
Email : italo.b...@huawei.com
[cid:image001.png@01D5162F.7797D1D0]
This e-mail and its attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed above.
Any use of the information contained herein in any way (including, but not
limited to, total or partial disclosure, reproduction, or dissemination) by
persons other than the intended recipient(s) is prohibited. If you receive this
e-mail in error, please notify the sender by phone or email immediately and
delete it!
From: Kent Watsen [mailto:k...@watsen.net]
Sent: martedì 28 maggio 2019 18:37
To: Italo Busi
Cc: Lou Berger ; netmod@ietf.org; netmod-cha...@ietf.org
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-artwork-folding-02
Hi Italo,
Thank you for the text suggestion, I landed on the following text:
For readability purposes, this script forces the minimally supported
line length to be eight characters longer than the raw header text
defined in Section 7.1.1 and Section 8.1.1 so as to ensure that the
header can be wrapped by a space (' ') character and three equal
('=') characters on each side of the raw header text.
Kent // author
On May 28, 2019, at 9:33 AM, Italo Busi
mailto:italo.b...@huawei.com>> wrote:
Hi Kent,
Thanks for your reply
For what I am concerned, the clarification you have provided is sufficient to
me (no need to change the code)
You might also consider adding similar text at the beginning of Appendix A, if
you think this helps. Something along the line:
The script forces the desired maximum line length to be a bit longer than the
raw header text defined in sections 7 and 8, to further ensure that the header
will always have some '=' characters wrapping around the header, for
readability, in the unlikely scenario that such a narrow-width is needed.
Italo
Italo Busi
Principal Optical Transport Network Research Engineer
Huawei Technologies Co., Ltd.
Tel : +39 345 4721946
Email : italo.b...@huawei.com
This e-mail and its attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed above.
Any use of the information contained herein in any way (including, but not
limited to, total or partial disclosure, reproduction, or dissemination) by
persons other than the intended recipient(s) is prohibited. If you receive this
e-mail in error, please notify the sender by phone or email immediately and
delete it!
From: Kent Watsen [mailto:k...@watsen.net]
Sent: lunedì 27 maggio 2019 19:57
To: Italo Busi mailto:italo.b...@huawei.com>>
Cc: Lou Berger mailto:lber...@labn.net>>;
netmod@ietf.org;
netmod-cha...@ietf.org
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-artwork-folding-02
Hi Italo,
1) Section 7.2.1 (Folding for Single Backslash Strategy) says:
Ensure that the desired maximum line length is not less than the
minimum header, which is 46 characters. If the desired maximum line
length is less than this minimum, exit (this text-based content
cannot be folded).
However, the first line defined in section 7.1.1 is a "45-character string".
I think that the paragraph be changed as:
Ensure that the desired maximum line length is not less than the
minimum header, which is 45 characters. If the desired maximum line
length is less than this minimum, exit (this text-based content
cannot be folded).
Fixed in my local copy.
2) Section 8.2.1 (Folding for Double Backslash Strategy) says:
Ensure that the desired maximum line length is not less than the
minimum header, which is 45 characters. If the desired maximum line
length is less than this minimum, exit (this text-based content
cannot be folded).
However, the first line defined in section 8.1.1 is a "46-character string".
I think that the paragraph be changed as:
Ensure that the desired maximum line length is not less than the
minimum header, which is 46 characters. If the desired maximum line
length is less than this minimum, exit (this text-based content
cannot be folded).
Fixed in my local copy.
A question for clarification. Reading the following code in Appendix A:
if [[ $strategy -eq 2 ]]; then
min_supported=`expr ${#hdr_txt_2} + 8`
else
min_supported=`expr ${#hdr_txt_1} + 8`
fi
It seems to me that the minimum lengths applied by the code in Appendix A are
be 53 and 54 (instead of 45 and 46 respectively)
Is my understanding correct?
The script is not conflicting with the draft, as it does ensure that the length
is not less than the raw header text. Though, to your point, it adds an
additional buffer to further ensure that the header will always have some '='
characters
Re: [netmod] Key collision between configured and ephemeral list entries
- Original Message - From: "Italo Busi" Sent: Wednesday, May 29, 2019 11:02 AM Hi Tom, Thanks for your reply It seems to me that the text you have quoted is from: https://tools.ietf.org/html/rfc7950#section-6.2 If I can understand correctly, especially for section 6.2.1, this constraints does not apply to name attributes whose syntax is defined as a string and used as key of a list, such as the tunnel list defined in the TE YANG model: | +--rw tunnel* [name] | | +--ro operational-state? identityref | | +--rw namestring My understanding is that a tunnel list entry with a name starting with '#' can exist in a YANG DS Italo Ah yes, my misunderstanding. 'string' type is a bit more flexible i.e. The string built-in type represents human-readable strings in YANG. Legal characters are the Unicode and ISO/IEC 10646 [ISO.10646] characters, including tab, carriage return, and line feed but excluding the other C0 control characters, the surrogate blocks, and the noncharacters. Plenty of scope there! If this approach is taken, then I agree that hash is a good choice as it stands out, unlike, say, underscore which vanishes in the line of text. Tom Petch Thanks, Italo -Original Message- From: tom petch [mailto:ie...@btconnect.com] Sent: mercoledì 29 maggio 2019 10:42 To: Italo Busi ; netmod@ietf.org Cc: t...@ietf.org Subject: Re: [netmod] Key collision between configured and ephemeral list entries Tom Petch - Original Message - From: "Italo Busi" To: Cc: Sent: Monday, May 27, 2019 2:16 PM Subject: [netmod] Key collision between configured and ephemeral list entries On Friday within the TEAS WG, we have discussed an issue which seems generic and therefore agreed to ask for guidelines to the Netmod WG In the TE YANG model we have defined a tunnel list with a name attribute used as a key: | +--rw tunnel* [name] | | +--ro operational-state? identityref | | +--rw namestring See: https://tools.ietf.org/html/draft-ietf-teas-yang-te-21 The issue we are facing is how to avoid name collision between configured and ephemeral tunnels. In other words, the issue we are trying to address is how to avoid the client to assign to a configured tunnel a name which have been already assigned by the server to another ephemeral tunnel and vice-versa, in particular considering NMDA rules We believe that the issue is generic and apply to any configured and ephemeral list entries Has this issue been already discussed/resolved in Netmod WG? If not, what is the Netmod WG opinion/suggestion? We are currently considering the following option: Use a special character for ephemeral names - e.g. such names always are prepended by special character "#" Make the special character changeable by configuration - the default can be "#" and user can change if they desire.. If this is to conform with YANG 1.1, RFC7950, then the constraint is Identifiers are used to identify different kinds of YANG items by name. Each identifier starts with an uppercase or lowercase ASCII letter or an underscore character, followed by zero or more ASCII letters, digits, underscore characters, hyphens, and dots. No # (hash) anywhere so I suspect that a lot of tooling will fail in an unpredictable way if it encounters an illegal character in an identifier. Tom Petch Thanks, Italo Italo Busi Principal Optical Transport Network Research Engineer Huawei Technologies Co., Ltd. Tel : +39 345 4721946 Email : italo.b...@huawei.com [cid:image002.png@01D5149F.354EF420] This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! From: Tarek Saad [mailto:tsaad@gmail.com] Sent: venerdì 24 maggio 2019 23:13 To: Igor Bryskin ; Rakesh Gandhi ; Xufeng ; Vishnu Pavan Beeram ; Italo Busi Cc: t...@ietf.org Subject: Discussion on modelling container TE tunnels in YANG The team on "to" list met to discuss this subject topic. Notes from today's discussion (please add if I missed): Name collision between configured and ephemeral tunnels: This is a generic problem in NMDA. How to handle collisions between configured and ephemeral (or auto-created) objects of a list, if the list uses the object (string based) name as the key? Both configured and ephemeral can have the same object name but they are different objects - how to avoid such collision. Proposed solution: Option 1: Use a special character for ephemeral names - e.g. such names
Re: [netmod] Key collision between configured and ephemeral list entries
Hi Tom, Thanks for your reply It seems to me that the text you have quoted is from: https://tools.ietf.org/html/rfc7950#section-6.2 If I can understand correctly, especially for section 6.2.1, this constraints does not apply to name attributes whose syntax is defined as a string and used as key of a list, such as the tunnel list defined in the TE YANG model: | +--rw tunnel* [name] | | +--ro operational-state? identityref | | +--rw namestring My understanding is that a tunnel list entry with a name starting with '#' can exist in a YANG DS Thanks, Italo -Original Message- From: tom petch [mailto:ie...@btconnect.com] Sent: mercoledì 29 maggio 2019 10:42 To: Italo Busi ; netmod@ietf.org Cc: t...@ietf.org Subject: Re: [netmod] Key collision between configured and ephemeral list entries Tom Petch - Original Message - From: "Italo Busi" To: Cc: Sent: Monday, May 27, 2019 2:16 PM Subject: [netmod] Key collision between configured and ephemeral list entries On Friday within the TEAS WG, we have discussed an issue which seems generic and therefore agreed to ask for guidelines to the Netmod WG In the TE YANG model we have defined a tunnel list with a name attribute used as a key: | +--rw tunnel* [name] | | +--ro operational-state? identityref | | +--rw namestring See: https://tools.ietf.org/html/draft-ietf-teas-yang-te-21 The issue we are facing is how to avoid name collision between configured and ephemeral tunnels. In other words, the issue we are trying to address is how to avoid the client to assign to a configured tunnel a name which have been already assigned by the server to another ephemeral tunnel and vice-versa, in particular considering NMDA rules We believe that the issue is generic and apply to any configured and ephemeral list entries Has this issue been already discussed/resolved in Netmod WG? If not, what is the Netmod WG opinion/suggestion? We are currently considering the following option: Use a special character for ephemeral names - e.g. such names always are prepended by special character "#" Make the special character changeable by configuration - the default can be "#" and user can change if they desire.. If this is to conform with YANG 1.1, RFC7950, then the constraint is Identifiers are used to identify different kinds of YANG items by name. Each identifier starts with an uppercase or lowercase ASCII letter or an underscore character, followed by zero or more ASCII letters, digits, underscore characters, hyphens, and dots. No # (hash) anywhere so I suspect that a lot of tooling will fail in an unpredictable way if it encounters an illegal character in an identifier. Tom Petch Thanks, Italo Italo Busi Principal Optical Transport Network Research Engineer Huawei Technologies Co., Ltd. Tel : +39 345 4721946 Email : italo.b...@huawei.com [cid:image002.png@01D5149F.354EF420] This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! From: Tarek Saad [mailto:tsaad@gmail.com] Sent: venerdì 24 maggio 2019 23:13 To: Igor Bryskin ; Rakesh Gandhi ; Xufeng ; Vishnu Pavan Beeram ; Italo Busi Cc: t...@ietf.org Subject: Discussion on modelling container TE tunnels in YANG The team on "to" list met to discuss this subject topic. Notes from today's discussion (please add if I missed): Name collision between configured and ephemeral tunnels: This is a generic problem in NMDA. How to handle collisions between configured and ephemeral (or auto-created) objects of a list, if the list uses the object (string based) name as the key? Both configured and ephemeral can have the same object name but they are different objects - how to avoid such collision. Proposed solution: Option 1: Use a special character for ephemeral names - e.g. such names always are prepended by special character "#" Make the special character changeable by configuration - the default can be "#" and user can change if they desire.. Others? AI (Italo): to send email to netmod group. Container TE tunnels discussion: - Container tunnels are grouping of tunnels between same 2 endpoints to share incoming traffic towards the egress - Member tunnels of a container tunnel can be auto-created/deleted on-demand and controlled by thresholds specified under the container - Some attributes may apply on the container tunnel and inherited down to member tunnels of
Re: [netmod] Key collision between configured and ephemeral list entries
Tom Petch - Original Message - From: "Italo Busi" To: Cc: Sent: Monday, May 27, 2019 2:16 PM Subject: [netmod] Key collision between configured and ephemeral list entries On Friday within the TEAS WG, we have discussed an issue which seems generic and therefore agreed to ask for guidelines to the Netmod WG In the TE YANG model we have defined a tunnel list with a name attribute used as a key: | +--rw tunnel* [name] | | +--ro operational-state? identityref | | +--rw namestring See: https://tools.ietf.org/html/draft-ietf-teas-yang-te-21 The issue we are facing is how to avoid name collision between configured and ephemeral tunnels. In other words, the issue we are trying to address is how to avoid the client to assign to a configured tunnel a name which have been already assigned by the server to another ephemeral tunnel and vice-versa, in particular considering NMDA rules We believe that the issue is generic and apply to any configured and ephemeral list entries Has this issue been already discussed/resolved in Netmod WG? If not, what is the Netmod WG opinion/suggestion? We are currently considering the following option: Use a special character for ephemeral names - e.g. such names always are prepended by special character "#" Make the special character changeable by configuration - the default can be "#" and user can change if they desire.. If this is to conform with YANG 1.1, RFC7950, then the constraint is Identifiers are used to identify different kinds of YANG items by name. Each identifier starts with an uppercase or lowercase ASCII letter or an underscore character, followed by zero or more ASCII letters, digits, underscore characters, hyphens, and dots. No # (hash) anywhere so I suspect that a lot of tooling will fail in an unpredictable way if it encounters an illegal character in an identifier. Tom Petch Thanks, Italo Italo Busi Principal Optical Transport Network Research Engineer Huawei Technologies Co., Ltd. Tel : +39 345 4721946 Email : italo.b...@huawei.com [cid:image002.png@01D5149F.354EF420] This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! From: Tarek Saad [mailto:tsaad@gmail.com] Sent: venerdì 24 maggio 2019 23:13 To: Igor Bryskin ; Rakesh Gandhi ; Xufeng ; Vishnu Pavan Beeram ; Italo Busi Cc: t...@ietf.org Subject: Discussion on modelling container TE tunnels in YANG The team on "to" list met to discuss this subject topic. Notes from today's discussion (please add if I missed): Name collision between configured and ephemeral tunnels: This is a generic problem in NMDA. How to handle collisions between configured and ephemeral (or auto-created) objects of a list, if the list uses the object (string based) name as the key? Both configured and ephemeral can have the same object name but they are different objects - how to avoid such collision. Proposed solution: Option 1: Use a special character for ephemeral names - e.g. such names always are prepended by special character "#" Make the special character changeable by configuration - the default can be "#" and user can change if they desire.. Others? AI (Italo): to send email to netmod group. Container TE tunnels discussion: - Container tunnels are grouping of tunnels between same 2 endpoints to share incoming traffic towards the egress - Member tunnels of a container tunnel can be auto-created/deleted on-demand and controlled by thresholds specified under the container - Some attributes may apply on the container tunnel and inherited down to member tunnels of the container - Q: Should model allow member tunnel to override inherited attributes from container tunnel? - Q: Should all auto-created member tunnels of a container have the same prefix/suffix - i..e prefix/suffix can be configurable Regards, Tarek > ___ > 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
