[netmod] Re: 3rd WGLC on system-config-10 (was "2nd")
On Thu, Dec 19, 2024 at 11:41:26AM +, maqiufang (A) wrote: > > Another example would be a license that expires, such that a subset of the > configuration is no longer valid. Choices could be: > - Configuration is left as it is, but the configuration is no longer > valid, and the configuration becomes unapplied. Attempts to configure the > feature without a valid license would be rejected with an error during > validation. > - Configuration is automatically removed from running by the device > (but I don't like this option). I prefer if the client *always* controls the > contents of running. > - Always allow the configuration, even if there is no valid license > present) but just don't apply it if there isn't a valid license (this seems > like generally less helpful behaviour to me). I believe the proper model is that the configuration remains valid but it is not applied. Like we can have interface configuration that is valid but not applied (e.g. the interface does not exist or is of the wrong type). > So, in summary, perhaps not as clean as a MUST, but maybe more > pragmatic/realistic? I believe a lot of this has to do with designing data models such that validity of configuration is not directly tied to the presence of certain resources. The difference between config being valid and config being valid and applied matters. > My concern is related to the statement in RFC 8342: MUST always be > a valid configuration data tree. > If a client references an interface eth0 in which is afterwards > physically removed and thus disappears from , we end up with dangling > reference in . Similarly, If the upgrade/downgrade happens before > keeping the configuration consistent, the invalidity of configuration between > t1 (the upgrade/downgrade) and t2 (the first operation to make configuration > consistent) seems also a violation of that statement. > > I kind of agree that we should say less rather than more, especially when > this is beyond the scope of the document. The examples here are used only to > enlighten some possible solutions, we can remove these, but I am really > unsure we should relax MUST to SHOULD here. If config is bound to resources by name, then name binding failures lead to configuration not being applied. This is acceptable and part of our NMDA. Having name binding failures cause invalid intended is IMHO not acceptable and hence also something NMDA did not allow. This is not about clever wording, this is about agreeing on a proper architectural model. /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: Erik Kline's No Objection on draft-ietf-netmod-rfc6991-bis-17: (with COMMENT)
On Wed, Dec 18, 2024 at 11:55:54AM -0800, Erik Kline wrote:
> On Wed, Dec 18, 2024 at 11:02 AM Jürgen Schönwälder
> wrote:
>
> > On Tue, Dec 10, 2024 at 10:37:34PM +0100, Jürgen Schönwälder wrote:
> > > On Sat, Nov 30, 2024 at 03:18:45PM -0800, Erik Kline via Datatracker
> > wrote:
> > > >
> > > > --
> > > > COMMENT:
> > > > --
> > > >
> > > > # Internet AD comments for draft-ietf-netmod-rfc6991-bis-17
> > > > CC @ekline
> > > >
> > > > ## Comments
> > > >
> > > > * "typedef protocol-number {
> > > >If IPv6 extension headers are present, then the
> > > >protocol number type represents the upper layer protocol
> > > >number, i.e., the number of the last 'next header' field
> > > >of the IPv6 extension headers."
> > > >
> > > > Surely since this can represent all values of the Next Header field
> > this
> > > > _could_ indicate the value of an IPv6 Extension Header?
> > > >
> > > > It seems to me that we should just say this is the value of the
> > > > protocol/next header field wherever this numberspace is indicated,
> > and
> > > > that in some contexts extension headers might be skipped over and the
> > > > ultimate next header value is what is meant in this field.
> > > >
> > > > This should be called out on a case-by-case basis, though, I would
> > expect
> > > > (i.e. wherever this type is used).
> > >
> > > These are possible alternate semantics making the type more flexible
> > > to use but also requiring that every usage spells out what is actually
> > > meant.
> > >
> >
> > I actually think this is a valuable idea. To me, it makes sense to
> > have (i) a type that essentially models what we have in the IANA
> > protocol number registry and where the usage needs to clarify how this
> > works with a chain of extension headers and (ii) a derived type that
> > has the semantics that we currently have for those cases where people
> > just want the protocol number of the next protocol following any
> > extension headers.
> >
> >
> How do you think we should proceed, then?
I guess you discuss all issues related to this document with the other
ADS and then the IESG tells the AD how to proceed with this document.
I am just a document editor.
/js
--
Jürgen Schönwälder Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: Erik Kline's No Objection on draft-ietf-netmod-rfc6991-bis-17: (with COMMENT)
On Tue, Dec 10, 2024 at 10:37:34PM +0100, Jürgen Schönwälder wrote:
> On Sat, Nov 30, 2024 at 03:18:45PM -0800, Erik Kline via Datatracker wrote:
> >
> > --
> > COMMENT:
> > --
> >
> > # Internet AD comments for draft-ietf-netmod-rfc6991-bis-17
> > CC @ekline
> >
> > ## Comments
> >
> > * "typedef protocol-number {
> >If IPv6 extension headers are present, then the
> >protocol number type represents the upper layer protocol
> >number, i.e., the number of the last 'next header' field
> >of the IPv6 extension headers."
> >
> > Surely since this can represent all values of the Next Header field this
> > _could_ indicate the value of an IPv6 Extension Header?
> >
> > It seems to me that we should just say this is the value of the
> > protocol/next header field wherever this numberspace is indicated, and
> > that in some contexts extension headers might be skipped over and the
> > ultimate next header value is what is meant in this field.
> >
> > This should be called out on a case-by-case basis, though, I would expect
> > (i.e. wherever this type is used).
>
> These are possible alternate semantics making the type more flexible
> to use but also requiring that every usage spells out what is actually
> meant.
>
I actually think this is a valuable idea. To me, it makes sense to
have (i) a type that essentially models what we have in the IANA
protocol number registry and where the usage needs to clarify how this
works with a chain of extension headers and (ii) a derived type that
has the semantics that we currently have for those cases where people
just want the protocol number of the next protocol following any
extension headers.
/js
--
Jürgen Schönwälder Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: Gunter Van de Velde's Discuss on draft-ietf-netmod-rfc6991-bis-17: (with DISCUSS)
On Wed, Dec 11, 2024 at 05:22:44AM -0800, Gunter Van de Velde via Datatracker wrote: > Gunter Van de Velde has entered the following ballot position for > draft-ietf-netmod-rfc6991-bis-17: Discuss > > 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.) > > > -- > DISCUSS: > -- > > > # Upon reviewing MPLS-TE Administrative Groups as defined in OSPFv2 (RFC > 3630), > OSPFv3 (RFC 5329), IS-IS (RFC 5305), and (Extended-)Administrative-Groups (RFC > 7308), I noted that these RFCs define and utilize 32-bit bitmasks, or sets of > 32-bit bitmasks, for (Extended-)Administrative-Groups. While a 32-bit bitmask > can be represented as a decimal uint32 value, it may be more operationally > useful—especially within YANG models—to display these values directly as > bitmasks. > > I am therefore raising this DISCUSS to consider adding a dedicated bitmask > type > to facilitate this form of representation as a common type. > I am not sure what is proposed here. Note that there have been several discussions related to bits and their representation in YANG modules. It seems that there is not a simple type that addresses all issues that come up. How bits or bit masks are exposed in a management interface seems to be specific to what the bits mean. There also was a discussion at some point in time how to deal with bits that are at some time unallocated but later allocated. See for example draft-haas-netmod-unknown-bits-02.txt. To me, it seems the proper action would be to write guidelines discussing the pros and cons of different approaches to represent bits and bit masks. In general it would be good if we would have a collection of YANG design pattern but so far this idea never really took off (i.e., nobody found the time to do the work). /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: Orie Steele's Discuss on draft-ietf-netmod-rfc6991-bis-17: (with DISCUSS and COMMENT)
that has no defined initial value, > that a default statement MUST NOT be used. Some of this text predates YANG, see for example RFC 2578 (1999) and its predecessors. I am reluctant to make changes. But when it comes to proper use of RFC 2119 language, I am always happy to follow the guidance of those who understand its proper use. > ### What about leap seconds? > > Not sure if leap seconds matter for YANG, iirc, they can sometimes be relevant > for GPS systems. > > ``` > 634 The date-and-time type is compatible with the dateTime XML > 635 schema dateTime type with the following notable exceptions: > ``` > > ``` > Because the dateTime type and other date- and time-related types defined in > this specification do not support leap seconds, there are portions of the > ·UTC· > timeline which cannot be represented by values of these types. Users whose > applications require that leap seconds be represented and that date/time > arithmetic take historically occurring leap seconds into account will wish to > make appropriate adjustments at the application level, or to use other types. > ``` The date-and-time type (which also goes back to SMIv2 RFC 2579 and its history) does not do leap seconds nor does it handle years larger than . I think it can represent -MM-DDT23:59:59.999 (for some number of 9s). That said, allowing 60 seconds for leap seconds would technically be possible as this would enlarge the value space of the type, which according to section 11 of RFC 7950 third bullet is allowed. So we could update the pattern to allow for leap seconds. > ### Securing Considerations > > ``` > 1759 This document defines common data types using the YANG data > modeling > 1760 language. The definitions themselves have no security impact on > the > 1761 Internet, but the usage of these definitions in concrete YANG > modules > 1762 might have. The security considerations spelled out in the YANG > 1763 specification [RFC7950] apply for this document as well. > ``` > > This document incorporates URI normalization, datetimes, and internationalized > email addresses and domain names by reference. > > You should repeat security considerations for at least a few of these topics > here. > > For example: > [...] Not sure about "repeating" security considerations. Perhaps what you suggest is that there should be statement saying: If an author uses one of the types defined in these modules, then the author should consult the security considerations contained in the references associated with the definition of the type. I prefer a generic solution rather then copying material and then the next update of this collection of definitions will get even more complicated. Also note that authors of YANG modules published as RFCs have to provide security considerations for the actual leafs and operations. /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: Artart telechat review of draft-ietf-netmod-rfc6991-bis-17
Dear Bron, the problem is that the canonical format uses -00:00 and this is what compliant deployed systems are expected to generate. Changing the canonical format to something different renders deployed systems non-compliant. Perhaps this is a reasonable trade-off to make, perhaps it is not. I am not making this call, I believe the WG felt like not touching this with this update. /js On Tue, Dec 17, 2024 at 04:09:15AM -0800, Bron Gondwana via Datatracker wrote: > Reviewer: Bron Gondwana > Review result: Ready with Nits > > I am the ARTART reviewer. > > I previously reviewed -16 and had feedback about the datetime formats. Thank > you for taking that feedback on board. I like the text you have for the new > "date" type. I do still think that it would be valuable to include a note > regarding the inadvisability of relying on 'Z' to mean "it definitely happened > in GMT" and recommending always using "+00:00" for that purpose, as well as > advising against producing new data with "-00:00" since it's not defined by > the > more recent versions of ISO8601 and this is supposed to be a profile of 8601. > > But I don't think it's worth blocking the document for, hence "Ready with > Nits". > > Again, thanks for your great response to my earlier feedback. Otherwise the > document looks great. > > -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: Intdir telechat review of draft-ietf-netmod-rfc6991-bis-17
Thanks for your review, comments inline. On Thu, Dec 12, 2024 at 08:03:51AM -0800, Antoine Fressancourt via Datatracker wrote: > > Based on my review, if I was on the IESG I would ballot this document as YES. > > Overall, the document is clear and detailed. > > The following are minor issues (typos, misspelling, minor text improvements) > with the document. Note that I would describe myself as a total beginner / > non-expert with regards to YANG, so my comments should be interpreted with > this > in mind: > > * After being puzzled by the lack of definition of the "union" base type, I > realized that the document assumes a description of some base types such as > uint32, uint64, string or union, without indicating clearly a reference > document where these types are presented and defined (or at least I didn't get > this reference from reading the document). I wonder whether it would be > possible to state (maybe in Section 2?) where those "basic" base types are > defined. Base types etc. are defined as part of the YANG language, see the references to RFC 7950. > * In table 3, I would give the module associated with the SMIv2 type in a > separate column rather than in parenthesis after the SMIv2 type name. This was done to fit the table into the traditional character per line limit for the textual RFC format... > * In the "date-no-zone" typedef, it was not clear for me from the text in the > description how an entity receiving a YANG document with this date type should > interpret it: should he use its local time zone, or a reference (say, UTC) > time > zone? A date-no-zone value is not representing a specific 24 hour period as the time zone offset is unknown and hence this is closer to a 48 hour period. > * Some type definitions have no reference. While I understand this reference > might be optional, for some type definitions, I think this lack of reference > is > problematic, for instance for the following types: > > * date-no-zone > > * type-no-zone > > * ipv4-address > > * ipv4-address-no-zone > > * ipv4-prefix > > * ipv4-address-and-prefix > > For the ipv4-related type, I would just reference RFC 4001, as it is already > referenced in the document. I am not sure about adding a reference for the sake of having a reference. I think RFC 4001 is not a suitable reference for IPv4 addresses (the definition of InetAddressIPv4 in there also has no reference, so we just point somewhere else that is not more useful than what this document has). /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: I-D Action: draft-ietf-netmod-system-config-10.txt
On Tue, Dec 10, 2024 at 06:37:45PM +, Kent Watsen wrote: > Thanks Qiufang. > > Looking at the diffs, I hope Andy and Juergen will be satisfied. > > In either case, the chairs think that it’s time to start another WGLC. > You can count the following comments as last call comments if you want: - I find the new text in section 6.1 handwaving. - I find it difficult that RFC 8342 says in Figure 2 that system configuration feeds into operational but now we introduce a system configuration datastore feeding system configuration into intended. - There also seems to be an implicit assumptions that clients have to be able to handle notifications about sudden changes of configuration in running once a server supports a system datastore. - What about things like the entity-tag used by RESTCONF? Does it change if the content of changes? /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: Erik Kline's No Objection on draft-ietf-netmod-rfc6991-bis-17: (with COMMENT)
On Sat, Nov 30, 2024 at 03:18:45PM -0800, Erik Kline via Datatracker wrote:
>
> --
> COMMENT:
> --
>
> # Internet AD comments for draft-ietf-netmod-rfc6991-bis-17
> CC @ekline
>
> ## Comments
>
> * "typedef protocol-number {
>If IPv6 extension headers are present, then the
>protocol number type represents the upper layer protocol
>number, i.e., the number of the last 'next header' field
>of the IPv6 extension headers."
>
> Surely since this can represent all values of the Next Header field this
> _could_ indicate the value of an IPv6 Extension Header?
>
> It seems to me that we should just say this is the value of the
> protocol/next header field wherever this numberspace is indicated, and
> that in some contexts extension headers might be skipped over and the
> ultimate next header value is what is meant in this field.
>
> This should be called out on a case-by-case basis, though, I would expect
> (i.e. wherever this type is used).
These are possible alternate semantics making the type more flexible
to use but also requiring that every usage spells out what is actually
meant.
> * ipv[46]-address-no-zone
>
> Why are these patterns so much more permissive than the non-zone parts
> of the address patterns? Why not just copy the address pattern text and
> leave off the % pattern chunk?
Because these typedefs are _derived_ from the ipv4-address and
ipv6-address and hence both pattern apply.
> * email-address
>
> This pattern seems overly permissive. It appears to permit the RFC 5322
> S3.2.3 "specials" that are not part of "dot-atom".
>
> I'm no SMTP expert, but it seems like at least excluding the @ special
> might help? E.g.
>
> [^@]+@[^@]+
>
> or something.
There as a version where we tried to capture many of the email address
format but that turned out to lead to a very long pattern that still
was not capturing everything correctly and failed badly on
internationalized email addresses. So we went back to a rather
simplistic pattern since implementations will need specific code to
properly validate (international) email addresses.
/js
--
Jürgen Schönwälder Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: I-D Action: draft-ietf-netmod-rfc8407bis-21.txt
On Tue, Dec 03, 2024 at 08:37:50AM +, mohamed.boucad...@orange.com wrote: > Hi Jürgen, > > The only change made vs 8407 is that long trees goes to an appendix, not main > document. The whole point about tree diagrams is that they should help to explain things. See RFC 8340 section 3.3 for details, pointing to it should be sufficient, there is no need to add anything. Note that section 3.3. of RFC 8340 also talks about considering an appendix if diagrams can't be split into smaller chunks. > That's reflect existing practices, saves authors time (including late > comments in IESG reviews about dry and long trees), etc. > > On the "page" point, please note that 8340 reasons with that unit as well :-) > " As tree diagrams are intended to provide a simplified >view of a module, diagrams longer than a page should generally be >avoided." Look into RFC 8340 and you will note that the back then official .txt versions still had pagination... As always, it is difficult to predict the future. But nowadays we know that pagination is a not a reliable metric anymore. /js > Thank you. > > Cheers, > Med > > > -Message d'origine- > > De : Jürgen Schönwälder > > Envoyé : mardi 3 décembre 2024 08:51 > > À : Lou Berger > > Cc : BOUCADAIR Mohamed INNOV/NET ; > > Kent Watsen (kent+i...@watsen.net) ; > > netmod@ietf.org > > Objet : Re: [netmod] Re: I-D Action: draft-ietf-netmod- > > rfc8407bis-21.txt > > > > > > I believe there is nothing to change, RFC 8407 got it straight: > > > > 3.4. Tree Diagrams > > > >YANG tree diagrams provide a concise representation of a YANG > > module > >and SHOULD be included to help readers understand YANG module > >structure. Guidelines on tree diagrams can be found in > > Section 3 of > >[RFC8340]. > > > > It is somewhat pointless to talk about pages on modern RFC > > formats that have no pages or varying page sizes and I think it > > is best to leave the guidance on the use of tree diagrams to > > RFC8340. (There is also no need to add another SHOULD that RFC > > 8340 should be consulted - are we approaching the point where > > every sentence has to have a capitalized verb?) I vote for no > > change of the RFC 8407 text here. > > > > /js > > > > On Mon, Dec 02, 2024 at 06:12:08PM -0500, Lou Berger wrote: > > > Med, > > > > > > Thanks for the update, you now have: > > > > > >3.4. Tree Diagrams > > > > > >YANG tree diagrams provide a concise representation of a > > YANG module > > >and SHOULD be included to help readers understand YANG > > module > > >structure. Guidelines on tree diagrams can be found in > > Section 3 of > > >[RFC8340]. Tree diagrams longer than one page SHOULD be > > included in > > >an appendix, i.e., not in the main body of the document. > > > > > > > > > How about: > > > > > >3.4. Tree Diagrams > > > > > >YANG tree diagrams provide a concise representation of a > > YANG module > > >and SHOULD be included to help readers understand YANG > > module > > >structure. Guidelines on tree diagrams can be found in > > Section 3 of > > >[RFC8340] and SHOULD be followed. > > > > > > Thanks, > > > > > > Lou > > > > > > On 11/14/2024 2:56 AM, mohamed.boucad...@orange.com wrote: > > > > Hi all, > > > > > > > > This version implements the changes discussed in Dublin, > > especially to address the comments about long trees (Lou) and > > better organize the commentary text in the sec template (Rob). > > > > > > > > Kent, it seems that you had a comment about clarifying "long > > lines" (?) but I fail to see which part you were referring to, > > especially that there are no occurrences of "lines" or "long > > line" in -21. May be this was related to some of the text removed > > to address the comment from Lou? > > > > > > > > Unless Kent still think a new rev is needed (and assuming he > > provides text :-)), I think this version is ready to be sent to > > the IESG. > > > > > > > > Thank you. > > > > > > > > Cheers, > > > > Med > > > > > > > > > -Message d'origine- > > > > > De :internet-dra...@ietf.org > > Envoyé : > > > > > jeud
[netmod] Re: I-D Action: draft-ietf-netmod-rfc8407bis-21.txt
jAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsI > > > ldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=TgPG%2BoExl6Z9GN27ifA%2FaXYeny > > > juNEjhs%2BGPyqbC8pc%3D&reserved=0 > > > > > > There is also an HTML version available at: > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > > > Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-netmod-rfc8407bis- > > > 21.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C4aeea5b9e > > > 9654b719a2308dd048011cb%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C > > > 0%7C638671670286853445%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > > > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjo > > > yfQ%3D%3D%7C0%7C%7C%7C&sdata=VkB16NFtocbYQX5eL44D0EQaEGqrx6%2F3KG > > > B7urTEbl4%3D&reserved=0 > > > > > > A diff from the previous version is available at: > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > > > Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-netmod- > > > rfc8407bis- > > > 21&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C4aeea5b9e9654b > > > 719a2308dd048011cb%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6 > > > 38671670286867934%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU > > > sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3 > > > D%3D%7C0%7C%7C%7C&sdata=V9MbbyKxm79Vx7qiOfDngiaYB%2FPWBNsCzGxuYK2 > > > EvI4%3D&reserved=0 > > > > > > Internet-Drafts are also available by rsync at: > > > rsync.ietf.org::internet-drafts > > > > > > > > > ___ > > > I-D-Announce mailing list --i-d-annou...@ietf.org To unsubscribe > > > send an email toi-d-announce-le...@ietf.org > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > > ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > > electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme ou > > falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged > > information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and > > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have been > > modified, changed or falsified. > > Thank you. > > > ___ > netmod mailing list -- netmod@ietf.org > To unsubscribe send an email to netmod-le...@ietf.org -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: origin "system" in system-config-09
On Mon, Dec 02, 2024 at 11:35:30AM +, maqiufang (A) wrote: > Hi, Jürgen, > > > > Although RFC 8342 avoids it, the problem remains in the real world: > > The client has the desire to reference system defined nodes, Must the > referenced system configuration always be copied to ? Does the > entire system-generated list entry need to be copied, or it is just the list > with at least the key? What if the system configuration changes and a stale > copy ends up in ? The datastore has to lead to a valid . A valid means that the configuration is valid, it does not mean that the configuration can all be applied. This is why we distinguish between and in the NMDA world. > How does the client overwrite a system-provided value? Or how to configure > the descendant nodes of system configuration? Is the copy needed? You configure the value. > Some system configurations are defined solely as a convenience (e.g., some > system provided policies), one of the objectives is to avoid re-creating > system configuration in . > > I think the current design makes the interplay between system configuration > and client-provided configuration clear (e.g., allows references > system config without requiring it to be copied into ). > So far, things like dangling references have been a no-go for a valid aka datastore. /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: origin "system" in system-config-09
On Sun, Dec 01, 2024 at 06:25:34PM +, Kent Watsen wrote: > > > Another option that comes to mind is that the system datastore does > > not feed into anything. Instead, it just exposes the (current) system > > configuration and if someone wants to use it, that someone can copy it > > into running and then takes responsibility for it. > > I do not favor this because it leads to stale definitions. > How can something that is not feeding into anything lead to stale definitions? The argument was that the system may change and such a change my cause to become invalid if is merged into . This was the reason why in RFC 8342 is _not_ feeding into . Hence, I proposed that if people want to expose system, they do it in a way such that is accessible but not automatically used. To use it, "something" taking over responsiblity has to make definitions explicit config in . /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: origin "system" in system-config-09
On Fri, Nov 22, 2024 at 08:06:57AM +, maqiufang (A) wrote: > Hi, Juergen, > > > > I agree that if system configuration changes, any reference to it might cause > to become invalid. As Kent suggested, how about we add some > following text in section 6.1 to clarify: > > Server MUST ensure that any updates of do not render > invalid. However, any mechanism for handling these circumstances is outside > the scope of this document. > For me, this translates into "we designed something that has a problem for which we have no solution". I do not think this is sound engineering. > > Or even go one step further, although out of scope, we can gives some > examples to show how to ensure remains valid: > > · Servers internally marked any invalid configuration in > caused due to changes as “inactive” Well, we have no inactive, so this translates into "we designed something that has a problem and the solution is to use something we still have to define". I do not think this is sound engineering. > · Servers migrate system configuration update in , e.g., by > updating configuration data that references stale system nodes > > · What else? > There were reasons why NMDA has system configuration feeding into operational. We may just rediscover the reasons for this... /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: origin "system" in system-config-09
On Thu, Nov 28, 2024 at 10:42:38AM +0100, Jürgen Schönwälder wrote: > On Fri, Nov 22, 2024 at 08:06:57AM +, maqiufang (A) wrote: > > Hi, Juergen, > > > > > > > > I agree that if system configuration changes, any reference to it might > > cause to become invalid. As Kent suggested, how about we add > > some following text in section 6.1 to clarify: > > > > Server MUST ensure that any updates of do not render > > invalid. However, any mechanism for handling these circumstances is outside > > the scope of this document. > > > > For me, this translates into "we designed something that has a problem > for which we have no solution". I do not think this is sound engineering. > > > > > Or even go one step further, although out of scope, we can gives some > > examples to show how to ensure remains valid: > > > > · Servers internally marked any invalid configuration in > > caused due to changes as “inactive” > > Well, we have no inactive, so this translates into "we designed > something that has a problem and the solution is to use something we > still have to define". I do not think this is sound engineering. > > > · Servers migrate system configuration update in , e.g., > > by updating configuration data that references stale system nodes > > > > · What else? > > > > There were reasons why NMDA has system configuration feeding into > operational. We may just rediscover the reasons for this... > Another option that comes to mind is that the system datastore does not feed into anything. Instead, it just exposes the (current) system configuration and if someone wants to use it, that someone can copy it into running and then takes responsibility for it. /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: origin "system" in system-config-09
On Thu, Nov 21, 2024 at 08:20:18PM +, Jason Sterne (Nokia) wrote: > I don't think we can just say to get rid of leafrefs and use name bindings > instead (or require-instance false). In many situations, the "built in" > system objects were talking about in the draft are in a list that can also > contain user-configured entries, and it is useful in many data models to have > hard leafrefs (require instance true) to those entries (e.g. avoid misconfig > with dangling references). > But when the referenced leaf disappears since it is controlled by the system, you do what? Accept invalid config? Reboot? Send an SMS to tell a human network operator to please put the linecard back or to ask the finance department to extend the software license that just expired? /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: origin "system" in system-config-09
I agree that content from must be or:intended. I am not a fan of system messing around with . RFC 8342 merges system config configuration in after and I think this was by design. The motiviation of this I-D appears to provide config true nodes that can be referenced by other explicit configuration. This certainly leads to issues if the system config can change dynamically, e.g., by removing or replacing line cards, and you end up with dangling references. It is best if config in references resources by name, like we configure an interface foo and if an interface named foo appears, the config is applied to this interface. This is a robust model, other solutions like having the system messing around with or merging config from into intended are much less robust, leading to "implementation specific" solutions if such things happen. But even if people want to have something populated in or , it would be great if the actual binding to resources would still be a name binding that resolves to nothing if the corresponding resource is not present. /js On Thu, Nov 21, 2024 at 05:19:08PM +, Jason Sterne (Nokia) wrote: > I’m not sure. The discussion has caused some doubt in my mind. > > If is merged with to form , then it is a little > odd that the origin (when reading ) isn’t just or:intended. > (on the other hand, I can see it being useful to know that some piece of > config came from instead of ) > > RFC8342 shows “system configuration” merging *after* intended. In that case > it is a little easier to see how the origin would be or:system. > > But even if we put that issue aside (and just allow some config in > to have origin = or:system when it comes from the DS), I’m not > certain I agree that all elements that appear in the DS with > origin = or:system must necessarily also show up in the DS. > > For built-in referenceable list entries (e.g. qos polices, system interface) > I can see how they are 1:1 between the DS and or:system in the > DS. > > But I’m less certain that we’ve considered all potential types of elements or > scenarios where reading something from the DS can return > or:system. For example: > > * User configures pir = 1022 (e.g. some QoS policing parameter) > * Server accepts pir = 1022, but rounds/maps it to a value that is > actually supported on that particular hardware platform, so the system is > actually using pir = 1024 > * Reading should return pir = 1024, but could the origin be > or:system in this case? > * I think it would be odd for pir to suddenly show up in the DS > in this situation (and I don’t think we should mandate that) > > Jason > > > From: Kent Watsen > Sent: Thursday, November 21, 2024 8:29 AM > To: Jürgen Schönwälder ; Jason Sterne > (Nokia) ; maqiufang > Cc: netmod@ietf.org > Subject: Re: [netmod] origin "system" in system-config-09 > > > CAUTION: This is an external email. Please be very careful when clicking > links or opening attachments. See the URL nok.it/ext for additional > information. > > > Juergen, > > Thank you for helping to close this item. > > Jason, > > Are you okay with this resolution? > > Qiufang, > > Please update the draft to define what happens in case an update to > schema and/or data causes to become invalid. > > As a participant, I wonder if it would be possible to enumerate such cases. > For instance, let’s assume a software-update removes or renames a “shared > object” in that is being used. In this case, I would hope that the > installer would check for use of the old shared object and prompt the user > what to do. For instance, if the shared object was removed, the installer > could auto-create the shared object in . Similarly, if the shared > object was renamed, the installer could auto-update the leafref in > to point to the new name. Likely it will be impossible to enumerate all > possibilities, and so some generic catch-all text will be needed. For > instance (please rephrase), “Servers MUST ensure that updates to > schema and/or data do not result in becoming invalid. It is out > of scope of this document to define specific remediation mechanisms." > > Kent > > > while re-reading parts of the I-D, I tend to agree that using > or:system seems about right. > > Perhaps more explanation would be helpful how to resolve problems is > if client config depends on confif and changes to > cause to become invalid. Or is the undefined merge going to > "unmerge" stale client config in this situation? Or does the device > reboot to signal it had an internal problem? ;-) Section 6 details > that such a situation is possible, it does not detail how s
[netmod] Re: origin "system" in system-config-09
Hi Kent, while re-reading parts of the I-D, I tend to agree that using or:system seems about right. Perhaps more explanation would be helpful how to resolve problems is if client config depends on confif and changes to cause to become invalid. Or is the undefined merge going to "unmerge" stale client config in this situation? Or does the device reboot to signal it had an internal problem? ;-) Section 6 details that such a situation is possible, it does not detail how system changes leading to an invalid are handled. /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: origin "system" in system-config-09
I thought I just learned that there is no system origin value. Well, if the values come from intended, then that is what the origin is. I do not think we should change that, I assume that was a reason why we report intended and not running etc. Perhaps the decision was wrong but if it was, we should take a general decision on this and not a per datastore decision. Note that this also touches on whether we want to expose template mechanisms or factory defaults or whatever comes next in the origin values. I guess I am concerned about getting into many uncoordinated updates of NMDA. /js On Fri, Nov 08, 2024 at 03:10:53PM +, maqiufang (A) wrote: > The document tries to update the definition of or:intended in NMDA, you may > want to refer to the last paragraph of section 1.3 > (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-netmod-system-config-09%23section-1.3&data=05%7C02%7Cjschoenwaelder%40constructor.university%7Cde3ca57726034ae086e508dd00078c0d%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C638666754642650653%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=7KDTKORHIdvkHHbnsZVedqGGxtfiWGTHpj%2FQcyvSwek%3D&reserved=0), > which says: > "This document also updates the definition of "intended" origin metadata > annotation identity defined in Section 5.3.4 of [RFC8342]. The "intended" > identity of origin value defined in [RFC8342] represents the origin of > configuration provided by , this document updates its definition as > the origin source of configuration explicitly provided by , and > allows a subset of configuration in that flows from yet > is not configured or overridden explicitly in to use "system" as > its origin value." > > Best Regards, > Qiufang > > -Original Message- > From: Jürgen Schönwälder > Sent: Friday, November 8, 2024 10:23 PM > To: maqiufang (A) > Cc: Jason Sterne ; Kent Watsen > ; netmod@ietf.org > Subject: Re: [netmod] Re: origin "system" in system-config-09 > > This then likely makes sense but if system is merged into intended, then > values should have or:intended, no? > > /js > > On Fri, Nov 08, 2024 at 01:42:45PM +, maqiufang (A) wrote: > > Hi, Jürgen, > > > > It is, but the identity defined in the I-D is only derived from > > ds:conventional. To use sysds:system as the origin value, I think it needs > > to be derived from or:origin, which I am unsure if possible, since the > > identical identity (i.e., system derived from origin) is already defined in > > RFC8342. > > > > Best Regards, > > Qiufang > > > > -Original Message- > > From: Jürgen Schönwälder > > Sent: Friday, November 8, 2024 8:10 PM > > To: maqiufang (A) > > Cc: Jason Sterne ; Kent Watsen > > ; netmod@ietf.org > > Subject: Re: [netmod] Re: origin "system" in system-config-09 > > > > On Fri, Nov 08, 2024 at 12:08:05PM +, maqiufang (A) wrote: > > > Hi, Jason, all, > > > > > > I think all system configuration that is non-deletable should be defined > > > in , if things differ from case to case, I have concern that it > > > is hard to enumerate all cases. The draft already states that > > > may change dynamically. Deletable system configuration should be present > > > in , otherwise how is it possible for the client to delete it? > > > If it is in , doesn't it have an origin value "intended"? If we > > > make a distinction this way, is it safe to infer that all nodes using > > > or:system are originating from ? Am I missing something? > > > > > > Jürgen has suggested to use sysds:system to report configuration > > > originating from , but I am unsure if that is possible to define > > > another identical identity also derived from "origin" identity? > > > > It is defined in your ID... > > > > /js > > > > -- > > Jürgen Schönwälder Constructor University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > > -- > Jürgen Schönwälder Constructor University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: origin "system" in system-config-09
This then likely makes sense but if system is merged into intended, then values should have or:intended, no? /js On Fri, Nov 08, 2024 at 01:42:45PM +, maqiufang (A) wrote: > Hi, Jürgen, > > It is, but the identity defined in the I-D is only derived from > ds:conventional. To use sysds:system as the origin value, I think it needs to > be derived from or:origin, which I am unsure if possible, since the identical > identity (i.e., system derived from origin) is already defined in RFC8342. > > Best Regards, > Qiufang > > -----Original Message- > From: Jürgen Schönwälder > Sent: Friday, November 8, 2024 8:10 PM > To: maqiufang (A) > Cc: Jason Sterne ; Kent Watsen > ; netmod@ietf.org > Subject: Re: [netmod] Re: origin "system" in system-config-09 > > On Fri, Nov 08, 2024 at 12:08:05PM +, maqiufang (A) wrote: > > Hi, Jason, all, > > > > I think all system configuration that is non-deletable should be defined in > > , if things differ from case to case, I have concern that it is > > hard to enumerate all cases. The draft already states that may > > change dynamically. Deletable system configuration should be present in > > , otherwise how is it possible for the client to delete it? If it > > is in , doesn't it have an origin value "intended"? If we make a > > distinction this way, is it safe to infer that all nodes using or:system > > are originating from ? Am I missing something? > > > > Jürgen has suggested to use sysds:system to report configuration > > originating from , but I am unsure if that is possible to define > > another identical identity also derived from "origin" identity? > > It is defined in your ID... > > /js > > -- > Jürgen Schönwälder Constructor University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: origin "system" in system-config-09
On Fri, Nov 08, 2024 at 12:08:05PM +, maqiufang (A) wrote: > Hi, Jason, all, > > I think all system configuration that is non-deletable should be defined in > , if things differ from case to case, I have concern that it is hard > to enumerate all cases. The draft already states that may change > dynamically. Deletable system configuration should be present in , > otherwise how is it possible for the client to delete it? If it is in > , doesn't it have an origin value "intended"? If we make a > distinction this way, is it safe to infer that all nodes using or:system are > originating from ? Am I missing something? > > Jürgen has suggested to use sysds:system to report configuration originating > from , but I am unsure if that is possible to define another > identical identity also derived from "origin" identity? It is defined in your ID... /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: origin "system" in system-config-09
On Thu, Nov 07, 2024 at 02:33:09PM +, Kent Watsen wrote: > > Indeed. It might help to think about the use-case that intends to > support. My understanding is that it’s trying to reveal more about what the > buried program logic does, so that the network’s functioning can be better > understood, e.g., to implement a digital twin. > I guess I understand the system datastore differently. Perhaps some examples help: 1) Consider an interface generating link-local IPv6 addresses. I expect that these address has or:system, I do not expect to find them in the system datastore. 2) Consider a system that has a default administrative user account. I expect that this account has sysds:system, I consider this hard wired configuration. 3) I consider a list of applications or preconfigured ACL rules as sysds:system content. This is also the example given in the I-D. I do not find where the document says that all system generated applied config should be reflected in sysds:system. This would turn sysds:system into a constantly changing dynamic configuration datastore. And if system is merged into intended, I start wondering whether values would not have or:intended. Or if your model applies, then why would we even need a new identity since we have already or:system? /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: origin "system" in system-config-09
On Thu, Nov 07, 2024 at 08:01:14AM +, Kent Watsen wrote: > > > I think it is important to keep the distinction between 'or:system' > > and 'sysds:system' since config generated by the system is different > > than config originating from a system datastore. > > I saw this comment last night and it didn’t sit right. > > Assume a server initially has no datastore, and so reports a node’s > origin as “ds:system”. > > Then later supports the datastore, trying to expose some of what it > does internally. Nothing has changed with the internal code, only the > datastore was created. Why should the node’s origin change? For me, a valued copied from a datastore is different than a value generated by some program logic buried somewhere inside the system. I assume we have different understandings what a system datastore is all about, which then may be a bigger problem. > Regarding a value in varying from a value in , > this just seems like a bug in the YANG defined for the > datastore. For me, the origin indicates where I can find the source of a value. If the source is the system datastore, then I expect that to be reported and I expect to find the value also in the system datastore. If the source of the value is the system itself, then I expect that to be reported and I do not necessarily expect to find the value in the system datastore. I fear we may have a bigger problem by not agreeing on what the system datastore actually is... /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: origin "system" in system-config-09
Jason, to answer your second question first: If the value of "foo" was determined by the system, then is should use the 'or:system' origin. (I want to know the true origin while troubleshooting.) Shall we choose a different name to avoid any potential confusion? I am usually split on such questions. On the one hand there is no technical reason not to use the most obvious name, but on the other hand it can be expected that some will screw up on this. (But then they also get an opportunity to learn that identity values are qualified names.) /js On Wed, Nov 06, 2024 at 06:45:39PM +, Jason Sterne (Nokia) wrote: > Thanks Jurgen. > > Maybe it would also help reduce confusion if we use a slightly different name > (in addition to namespace) for nodes from the new system DS. Perhaps origin > = system-datastore? > > Any thoughts on my last question? Does it seem reasonable to you that the > leaf "foo" in operational would use origin = or:system in that case where the > applied value differs from the configured value? > > Jason > > > -Original Message- > > From: Jürgen Schönwälder > > Sent: Wednesday, November 6, 2024 1:28 PM > > To: Jason Sterne (Nokia) > > Cc: netmod@ietf.org > > Subject: Re: [netmod] origin "system" in system-config-09 > > > > > > CAUTION: This is an external email. Please be very careful when clicking > > links or > > opening attachments. See the URL nok.it/ext for additional information. > > > > > > > > Hi, > > > > I think the identity values are scoped by their module, hence there > > should be a distinction between 'or:system' and 'sysds:system' (using > > the XML encoding with the default namespace prefixes here as an > > example). > > > > I think it is important to keep the distinction between 'or:system' > > and 'sysds:system' since config generated by the system is different > > than config originating from a system datastore. > > > > /js > > > > On Wed, Nov 06, 2024 at 05:59:32PM +, Jason Sterne (Nokia) wrote: > > > Hi all, > > > > > > draft-ietf-netmod-system-config-09 - System-defined > > Configuration<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-netmod-system-&data=05%7C02%7Cjschoenwaelder%40constructor.university%7Ce8bd55d8141246a217c908dcfe9338dd%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C638665155485899808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Exe0oBgOSlFwaKG%2B1ZhgTIElzdHo4E9juZTTuj5NgEs%3D&reserved=0 > > config/> proposes an origin of "system" for nodes in the operational > > datastore > > that came from the system DS. > > > > > > But I'm wondering if we may want to consider differentiating between: > > > > > > * Nodes that use the system origin in the original NMDA spec (before > > > this > > new system DS work), but may not actually exist in the new system DS > > > * Nodes that come from the system DS > > > > > > The way it stands currently, there could be nodes in the operational DS > > > with an > > origin of system that are not in the system DS. Is that confusing? Or are > > we OK > > with: > > > > > > 1. Any node in the system DS shows up as origin "system" in the > > > operational > > DS, but > > > 2. Not all nodes with origin "system" in the operational DS are in the > > > system > > DS > > > > > > Somewhat related to this issue: NMDA allows a config true (CT) node to > > > have > > one value in and a different value in . The > > > > view is supposed to return what is actually in use (which can in theory > > differ from > > what was configured in running/intended). > > > > > > If a node "foo" has value 1500 in , but in operational the > > > value is > > 1492, what should the origin be for node foo? System? > > > [note in this question/example, node "foo" is not in the system DS. It is > > > just a > > standard config node] > > > > > > Jason (he/him) > > > > > > > > ___ > > > netmod mailing list -- netmod@ietf.org > > > To unsubscribe send an email to netmod-le...@ietf.org > > > > > > -- > > Jürgen Schönwälder Constructor University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: origin "system" in system-config-09
Hi, I think the identity values are scoped by their module, hence there should be a distinction between 'or:system' and 'sysds:system' (using the XML encoding with the default namespace prefixes here as an example). I think it is important to keep the distinction between 'or:system' and 'sysds:system' since config generated by the system is different than config originating from a system datastore. /js On Wed, Nov 06, 2024 at 05:59:32PM +, Jason Sterne (Nokia) wrote: > Hi all, > > draft-ietf-netmod-system-config-09 - System-defined > Configuration<https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config/> > proposes an origin of "system" for nodes in the operational datastore that > came from the system DS. > > But I'm wondering if we may want to consider differentiating between: > > * Nodes that use the system origin in the original NMDA spec (before this > new system DS work), but may not actually exist in the new system DS > * Nodes that come from the system DS > > The way it stands currently, there could be nodes in the operational DS with > an origin of system that are not in the system DS. Is that confusing? Or are > we OK with: > > 1. Any node in the system DS shows up as origin "system" in the > operational DS, but > 2. Not all nodes with origin "system" in the operational DS are in the > system DS > > Somewhat related to this issue: NMDA allows a config true (CT) node to have > one value in and a different value in . The > view is supposed to return what is actually in use (which can > in theory differ from what was configured in running/intended). > > If a node "foo" has value 1500 in , but in operational the value is > 1492, what should the origin be for node foo? System? > [note in this question/example, node "foo" is not in the system DS. It is > just a standard config node] > > Jason (he/him) > > ___ > netmod mailing list -- netmod@ietf.org > To unsubscribe send an email to netmod-le...@ietf.org -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis
2024 > > >>> >>> 13:37 *À :* BOUCADAIR Mohamed INNOV/NET > > >>> >> > > mailto:mohamed.boucad...@orange.com > > > > <mailto:mohamed.boucad...@orange.com%3cmailto:mohamed.boucad...@orange.com>>>; > > >>> >>> netmod@ietf.org<mailto:netmod@ietf.org > > <mailto:netmod@ietf.org%3cmailto:netmod@ietf.org>>; > > > > draft-ietf-netmod-rfc8407...@ietf.org<mailto:draft-ietf-netmod-rfc8407...@ietf.org > > > > <mailto:draft-ietf-netmod-rfc8407...@ietf.org%3cmailto:draft-ietf-netmod-rfc8407...@ietf.org>>; > > Jan > > >>> >> Lindblad > > >>> >>> (jlindbla) > > mailto:jlind...@cisco.com > > <mailto:jlind...@cisco.com%3cmailto:jlind...@cisco.com>>> > > >>> >>> *Cc :* Kent Watsen > > mailto:kent+i...@watsen.net > > <mailto:kent+i...@watsen.net%3cmailto:kent+i...@watsen.net>>> > > *Objet :* Re: > > >>> [netmod] > > >>> >> Re: > > >>> >>> WGLC on draft-ietf-netmod-rfc8407bis > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> Med, Jan, WG, > > >>> >>> >
[netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis
I assume this depends on the sophistication of the automation you have in place to generate the .xml file. I guess Kent has pretty advanced machinery in place meanwhile. But more important: While I surely prefer to read broken down diagrams as they also tend to come with more meaningful descriptions, my problem is the desire to regulate each and every little detail. Why do we not let authors take an informed decision? Why do we not provide guidelines that enable authors to understand the pros and cons so that they can take an informed decision? Why do we not tell authors how tools can be used to manage broken down diagrams? And why do we have to 'standardize' the placement of tree diagrams in our documents at all? Is this really something that makes the Internet work better? /js On Tue, Nov 05, 2024 at 01:24:58PM +, Italo Busi wrote: > By reading the current text in section 3.4, I am getting a bit worried that > we are increasing the workload of the editors of the YANG models drafts > > While I fully agree with the initial statement, "YANG tree diagrams provide a > concise representation of a YANG module and SHOULD be included to help > readers understand YANG module structure", I am wondering whether authors > need to do more than just copying the tree generated by pyang > > For example, splitting the output of pyang into smaller diagrams requires > editorial efforts and need to be re-done every time the YANG model is updated > during the draft development > > In some of the draft I have worked on, I have included some YANG tree > snapshots but regretted this because they quickly tend to get out of synch > during the draft development > > What would be the drawback to always require the full data tree to be > included into an Appendix, without introducing different cases? > > Italo > > > -Original Message- > > From: Jürgen Schönwälder > > Sent: martedì 5 novembre 2024 13:21 > > To: Lou Berger > > Cc: Jan Lindblad ; netmod@ietf.org > > Subject: [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis > > > > Since RFCs nowadays came in multiple formats, we do not know anymore for > > sure what a page is. The text and html renderings do not seem to be > > paginated > > anymore, the pdf rendering still seems to have pages. The canonical format > > seems to be the xml file, which has no pagination either. > > > > We should rely on good judgment of the authors, a SHOULD NOT rule looks > > like bureaucracy winning over trust into authors to make appropriate > > choices. > > > > /js > > > > On Tue, Nov 05, 2024 at 10:28:10AM +, Lou Berger wrote: > > > Med > > > > > > See inline > > > On 10/29/2024 8:20 AM, mohamed.boucad...@orange.com wrote: > > > > > > > > Re-, > > > > > > > > The new guidance: > > > > > > > > * characterizes what is long/too long tree > > > > > > > In yesterday's session you also mentioned that rfc8340 didn't define > > > what a long/large tree is. I think you must have missed it in section > > > 3.3 of RFC > > > 8340: YANG Tree Diagrams > > > <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8340%23section-3.3&data=05%7C02%7Cjschoenwaelder%40constructor.university%7Cf132696f7fe34b6639e008dcfd9d43b2%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C638664099166590809%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ubWRohKjpHVM2gd86hWuiFW95iSgZuCP%2BmnvH3Khcu8%3D&reserved=0> > > > : > > > > > > As tree diagrams are intended to provide a simplified > > > view of a module, diagrams longer than a page should generally be > > > avoided. > > > > > > Isn't this sufficient. > > > > > > > * recommends against including too long trees in the main doc, while > > > > Section 3 of RFC8340has the following: > > > > > > > > When long diagrams are included in a document, > > > > > > > > authors should consider whether to include the long diagram in the > > > > > > > > main body of the document or in an appendix. > > > > > > > so want to change the existing non-RFC2119 formulation "should .. include > > > .. > > > in an appendix" to "SHOULD NOT include in the main body of the > > > document", is this correct? > > > > > > Thanks, > > > > > > Lou > > > > > > > > > > Cheers,
[netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis
>>> >>> > > >>> >>> > > >>> >>> Cheers, > > >>> >>> > > >>> >>> Med > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> *De :* BOUCADAIR Mohamed INNOV/NET > > >>> >>> *Envoyé :* mercredi 2 octobre 2024 11:13 *À :* 'Lou Berger' > > >>> >>> mailto:lber...@labn.net > > <mailto:lber...@labn.net%3cmailto:lber...@labn.net>>>; > > netmod@ietf.org<mailto:netmod@ietf.org > > <mailto:netmod@ietf.org%3cmailto:netmod@ietf.org>>; > > >>> >>> > > > > draft-ietf-netmod-rfc8407...@ietf.org<mailto:draft-ietf-netmod-rfc8407...@ietf.org > > > > <mailto:draft-ietf-netmod-rfc8407...@ietf.org%3cmailto:draft-ietf-netmod-rfc8407...@ietf.org>>; > > Jan Lindblad (jlindbla) > > >>> < > > >>> >>> jlind...@cisco.com<mailto:jlind...@cisco.com > > <mailto:jlind...@cisco.com%3cmailto:jlind...@cisco.com>>> *Cc :* > > Kent Watsen mailto:kent+i...@watsen.net > > <mailto:kent+i...@watsen.net%3cmailto:kent+i...@watsen.net>>> > > >>> >> *Objet > > >>> >>> :* RE: [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> Hi Lou, > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> - Keeping long trees in the main document is really not > > >>> >> helpful to > > >>> >>> digest a module. I also know by experience that this > > >>> raises > > >>> >> comments, > > >>> >>> including from the IESG. > > >>> >>> - Keeping long trees that exceed 69 line max in the main > > >>> or > > >>> >> as an > > >>> >>> appendix is really hard to follow. > > >>> >>> - There are already RFCs out there do not include long > > >>> trees, > > >>> >> but a > > >>> >>> note about how to generate it. The narrative text uses > > >>> small > > >>> >> snippets to > > >>> >>> help readers walk through the model. > > >>> >>> - Some consistency is needed in how we document our > > >>> modules + > > >>> >> help > > >>> >>> authors with clear guidance (e.g., characterize what is a > > >>> >> long > > >>> >>> tree) > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> I’m afraid that we can’t simply leave the OLD 8407 as it is. > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> That’s said, I’m only the pen holder and will implement > > >>> whatever > > >>> >> the > > >>> >>> WG decides here. > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> Cheers, > > >>> >>> > > >>> >>> Med > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> *De :* Lou Berger > > mailto:lber...@labn.net > > <mailto:lber...@labn.net%3cmailto:lber...@labn.net>>> *Envoyé :* > > mardi 1 > > >>> octobre 2024 > > >>> >>> 13:37 *À :* BOUCADAIR Mohamed INNOV/NET > > >>> >> > > mailto:mohamed.boucad...@orange.com > > > > <mailto:mohamed.boucad...@orange.com%3cmailto:mohamed.boucad...@orange.com>>>; > > >>> >>> netmod@ietf.org<mailto:netmod@ietf.org > > <mailto:netmod@ietf.org%3cmailto:netmod@ietf.org>>; > > > > draft-ietf-netmod-rfc8407...@ietf.org<mailto:draft-ietf-netmod-rfc8407...@ietf.org > > > > <mailto:draft-ietf-netmod-rfc8407...@ietf.org%3cmailto:draft-ietf-netmod-rfc8407...@ietf.org>>; > > Jan > > >>> >> Lindblad > > >>> >>> (jlindbla) mailto:jlind...@cisco.com > > <mailto:jlind...@cisco.com%3cmailto:jlind...@cisco.com>>> > > >>> >>> *Cc :* Kent Watsen > > mailto:kent+i...@watsen.net > > <mailto:kent+i...@watsen.net%3cmailto:kent+i...@watsen.net>>> > > *Objet :* Re: > > >>> [netmod] > > >>> >> Re: > > >>> >>> WGLC on draft-ietf-netmod-rfc8407bis > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> Med, Jan, WG, > > >>> >>> > > >>> >>> I have to say that I read the discussion concluding with to > > >>> NOT > > >>> >> change > > >>> >>> the current recommendation, see > > >>> >>> > > >>> >> > > >>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > > >>> >> mail > > >>> >>> archive.ietf.org > > > > <http://archive.ietf.org/><http://archive.ietf.org/>%2Farch%2Fmsg%2Fnetmod%2F0Q0YiyNi15V- > > >>> Szzf5awLVh- > > >>> >> 15_c%2 > > >>> >> > > >>> F&data=05%7C02%7Cmohamed.boucadair%40orange.com > > <http://40orange.com/><http://40orange.com/>%7C360a053d61314c78 > > >>> >> 51bc > > >>> >> > > >>> 08dcec6c99f5%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63864519 > > >>> >> 8411 > > >>> >> > > >>> 573595%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI > > >>> >> iLCJ > > >>> >> > > >>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=FuJbQGSOk7%2FkMXATR > > >>> >> 1fn3 > > >>> >>> YScP4MBfkRWYvYXz90NyNI%3D&reserved=0 > > >>> >>> > > >>> >>> I personally use an ereader (or computer) more than paper and > > >>> >> having > > >>> >>> to go to a static URL -- probably when I'm off line -- does > > >>> NOT > > >>> >> seem > > >>> >>> like something we should be recommending. Furthermore, I'm > > >>> not > > >>> >> sure > > >>> >>> what our process has to say about having the HTML include > > >>> *text > > >>> >>> content* that is not in the text version. > > >>> >>> > > >>> >>> Again just my perspective. > > >>> >>> > > >>> >>> What do others think? do they feel strongly that this change > > >>> >> from the > > >>> >>> current recommendation (in RFC8340) of having long trees in > > >>> >> appendixes > > >>> >>> is a good or bad idea? (Yes, I'm in the strongly against > > >>> camp.) > > >>> >>> > > >>> >>> Thanks, > > >>> >>> > > >>> >>> Lou > > >>> >>> > > >>> >>> On 10/1/2024 4:24 AM, > > mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com > > > > <mailto:mohamed.boucad...@orange.com%3cmailto:mohamed.boucad...@orange.com>> > > wrote: > > >>> >>> > > >>> >>> Hi Lou, > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> 1. The comment that triggered the change and companion > > >>> thread > > >>> >> where > > >>> >>> this was discussed and changes proposed can be seen at: > > >>> >>> > > >>> >>> > > >>> >> > > >>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > > >>> >> mail > > >>> >>> archive.ietf.org > > > > <http://archive.ietf.org/><http://archive.ietf.org/>%2Farch%2Fmsg%2Fnetmod%2F- > > >>> >> > > >>> b2HX0XUK49qJB19LHu6MC0D9zc%2F&data=05%7C02%7Cmohamed.boucadair%40o > > >>> >> > > >>> range.com > > > > <http://range.com/><http://range.com/>%7C360a053d61314c7851bc08dcec6c99f5%7C90c7a20af34b40bfbc4 > > >>> >> > > >>> 8b9253b6f5d20%7C0%7C0%7C638645198411584985%7CUnknown%7CTWFpbGZsb3d > > >>> >> > > >>> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3 > > >>> >> > > >>> D%7C0%7C%7C%7C&sdata=r4xdN4asqklRHaI%2BIixWX29CCw7i1QBlmAHlNXrKjng > > >>> >> %3D&reserved=0 > > >>> > > > >>> __ > > >>> > > >>> > __ > > >>> > Ce message et ses pieces jointes peuvent contenir des > > >>> informations > > >>> > confidentielles ou privilegiees et ne doivent donc pas etre > > >>> diffuses, > > >>> > exploites ou copies sans autorisation. Si vous avez recu ce > > >>> message > > >>> > par erreur, veuillez le signaler a l'expediteur et le detruire > > >>> ainsi que les pieces jointes. Les messages electroniques etant > > >>> susceptibles d'alteration, Orange decline toute responsabilite si > > >>> ce message a ete altere, deforme ou falsifie. Merci. > > >>> > > > >>> > This message and its attachments may contain confidential or > > >>> > privileged information that may be protected by law; they should > > >>> not be distributed, used or copied without authorisation. > > >>> > If you have received this email in error, please notify the > > >>> sender and delete this message and its attachments. > > >>> > As emails may be altered, Orange is not liable for messages that > > >>> have been modified, changed or falsified. > > >>> > Thank you. > > >> > > > > > > >> Ce message et ses pieces jointes peuvent contenir des > > informations confidentielles ou privilegiees et ne doivent donc > > >> pas etre diffuses, exploites ou copies sans autorisation. Si > > vous avez recu ce message par erreur, veuillez le signaler > > >> a l'expediteur et le detruire ainsi que les pieces jointes. Les > > messages electroniques etant susceptibles d'alteration, > > >> Orange decline toute responsabilite si ce message a ete altere, > > deforme ou falsifie. Merci. > > >> > > >> This message and its attachments may contain confidential or > > privileged information that may be protected by law; > > >> they should not be distributed, used or copied without > > authorisation. > > >> If you have received this email in error, please notify the > > sender and delete this message and its attachments. > > >> As emails may be altered, Orange is not liable for messages > > that have been modified, changed or falsified. > > >> Thank you. > > > > > > > > > > > > > Ce message et ses pieces jointes peuvent contenir des > > informations confidentielles ou privilegiees et ne doivent donc > > > pas etre diffuses, exploites ou copies sans autorisation. Si > > vous avez recu ce message par erreur, veuillez le signaler > > > a l'expediteur et le detruire ainsi que les pieces jointes. Les > > messages electroniques etant susceptibles d'alteration, > > > Orange decline toute responsabilite si ce message a ete altere, > > deforme ou falsifie. Merci. > > > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; > > > they should not be distributed, used or copied without > > authorisation. > > > If you have received this email in error, please notify the > > sender and delete this message and its attachments. > > > As emails may be altered, Orange is not liable for messages that > > have been modified, changed or falsified. > > > Thank you. > > > > > > > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc > > > > pas etre diffuses, exploites ou copies sans autorisation. Si vous > > avez recu ce message par erreur, veuillez le signaler > > > > a l'expediteur et le detruire ainsi que les pieces jointes. Les > > messages electroniques etant susceptibles d'alteration, > > > > Orange decline toute responsabilite si ce message a ete altere, > > deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; > > > > they should not be distributed, used or copied without authorisation. > > > > If you have received this email in error, please notify the sender > > and delete this message and its attachments. > > > > As emails may be altered, Orange is not liable for messages that > > have been modified, changed or falsified. > > > > Thank you. > > > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > > ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > > electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme ou > > falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged > > information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and > > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have been > > modified, changed or falsified. > > Thank you. > ___ > netmod mailing list -- netmod@ietf.org > To unsubscribe send an email to netmod-le...@ietf.org -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: 2nd WG Last Call: ddraft-ietf-netmod-yang-module-versioning-12, draft-ietf-netmod-yang-semver-17, draft-ietf-netmod-yang-module-filename-00
that there > are non-backwards-compatible changes and you will need to look at this 2.0.0 > to see how it affects your tooling. > Given the discussion above: Given a recommended-min-version of 1.3.0, a 1.2.2_compatible module may actually work. And there is no guarantee that 2.0.0 will actually work. (Sure, any claims about future versions are difficult once we allow NBC changes.) So even claims about lower version numbers may not necessarily always be correct. It seems there is no well defined partial order with _compatible and back ports may cause a recommended-min-version declaration to be inaccurate. > - An existing compliant YANG compiler will not "locate a module with > a version that is viable according to the conditions above". An > existing compiler YANG compiler will ignore the extension > statements recommended-min-version (and recommended-min-date). I > think you need to acknowledge this and word things differently. > Sure, a compiler that supporting recommended-min-version may > generate suitable warnings, but existing compliant YANG 1.1 and > YANG 1 compilers can't be expected to do something fancy due to > the presence of an (from the compiler's perspective) unknown > extension. > > [JMC] Thanks. Where in the doc are you looking? > > I don’t find the exact text you quote. Section 5.2 comes close, but it’s > not exact. This text: If an import by recommended-min-version cannot locate a module with a version that is viable according to the conditions above, the YANG compiler should emit a warning, and then continue to resolve the import based on established [RFC7950] rules. > [JMC] But a compiler that is compliant with (or aware of) YANG Semver, would > be able to emit a proper warning if it cannot locate a module that meets the > import rules. I agree that a standard YANG 1[.1] compiler would not be aware > of this extension and would therefore load an available module by name and > might ultimately end up with compiler errors. My struggle has always been about the situation where two YANG 1.1 compiler, given the same set of YANG modules, resolve imports differently and thus they work with semantically different data models. It seems you are still planning to split the world into 'YANG 1.1' compilers and 'YANG 1.1 semver' compilers. /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: 2nd WG Last Call: ddraft-ietf-netmod-yang-module-versioning-12, draft-ietf-netmod-yang-semver-17, draft-ietf-netmod-yang-module-filename-00
o use a prefix like yanglib-status (or yl-status - see below)? - Appendix A: Changing a type is NBC only if the new type is having different syntax or semantics. See section 11 of RFC 7950, there is an explicit bullet for this. * YANG Semantic Versioning - The claims made in the first paragraph of the abstract about the versioning document do not seem to be aligned with that document when it says "a more flexible approach to importing modules by revision". My understanding is that the versioning document says that collections of suitable modules are maintained outside of YANG modules and there is a recommended-min-date, which is a piece of documentation but not changing YANG's current import logic. - I am still confused by the complexity introduced here. Why do we need both X.Y.Z and X.Y.Z_compatible? What is the difference, when do I use which? - X.Y.Z_non_compatible sounds like a somewhat questionable idea. To me, this says "we claim this is X.Y.Z but we know it should be something different". The _non_compatible modifier essentially overwrites the meaning of [SemVer], rendering X.Y.Z at best into a branch identifier. Perhaps this is what the industry really wants, three digit branch identifiers but not really [SemVer]? - The example in Section 4.4.1 is interesting and welcome but unfortunately there is no recommendation how situations should be handled if branches split off (and perhaps even merge later). - If I need to make a BC update to X.Y.Z_compatible but X.Y.Z+1_non_compatible has already been taken, what do I do? - I am not sure how the recommended-min-version helps if there are branches since there is not guarantee that 2.0.0 > v1.1.1 implies that 2.0.0 includes everything that was in 1.1.1. If recommended-min-version is 1.1.1, then an import of 2.0.0 may still fail, no? - An existing compliant YANG compiler will not "locate a module with a version that is viable according to the conditions above". An existing compiler YANG compiler will ignore the extension statements recommended-min-version (and recommended-min-date). I think you need to acknowledge this and word things differently. Sure, a compiler that supporting recommended-min-version may generate suitable warnings, but existing compliant YANG 1.1 and YANG 1 compilers can't be expected to do something fancy due to the presence of an (from the compiler's perspective) unknown extension. - Is 'ys' a good module prefix? Yes, it is YANG's variation of SemVer, but perhaps ys is a bit too cryptic? What about 'semver' or if we optimistically assume we do not need another versioning scheme even just 'ver' (the reverse of 'rev'). rev:non-backwards-compatible rev:non-backwards-compatible rev:recommended-min-date rev:recommended-min-date ys:version 3.1.0 semver:version 3.1.0 ys:recommended-min-version semver:recommended-min-version - Description of the version extension: "The version extension can be used to provide an additional identifier associated with a module or submodule revision. I am not sure about "additional identifier". Its just a version number. So what about: "The version extension can be used to assign a version number to a module or submodule revision. - I like the choice ietf-yang-library-semver, see my suggestion to use ietf-yang-library-status for the other yang library extension above. I also like the yl-semver prefix here, I do not like so much the ys-conf prefix used in the other draft. Some consistency may be nice. - Editorial s/do not not require/do not require/ /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: Artart last call review of draft-ietf-netmod-rfc6991-bis-16
Thanks for your review, Bron. See my response inline... On Sun, Sep 29, 2024 at 09:27:56AM -0700, Bron Gondwana via Datatracker wrote: > Reviewer: Bron Gondwana > Review result: Not Ready > > I'm the designated ARTART reviewer for this document. It's generally well > written and clear; I didn't see any issues with the document itself, however > there are some obsolete references and changes to align with work done > elsewhere in the IETF which I believe would improve the overall > cross-compatibility of IETF specifications significantly, hence my marking it > as "NOT READY". > > *Date-Time:* > > While the date-time format duplicates the description found in RFC 6021 and > later RFC 6991, the construct -00:00 has been identified as being incompatible > with the latest ISO8601 by the work in the SEDATE working group. I would > refer > you to section 2 of RFC 9557 for the full description and update of RFC 3339 > which was done there. I suggest that this document should be updated to align > with (and reference) RFC 9557 and deprecate the usage of -00:00; instead using > "Z" to mean "local time reference point is unknown" as is common practice. > This will improve future interoperability with ISO8601. > > Likewise the same issue occurs with the new "date" format and "time" format. This has been discussed in the WG and the conclusion was to not change the 'date-and-time' format as it is widely implemented. Note that RFC 6020 picked -00:00 as the canonical representation for values in UTC with an unknown local time-offset. RFC 9557 now suggests to use Z instead. If we change date-and-time to use Z instead of -00:00, then existing implementations of 'date-and-time' become non-compliant. Hence, we prefer to stick to what we have. For the new 'date' and 'time' definitions we can adopt RFC 9557 and use Z instead of -00:00. This of course means that UTC values with an unknown local time-offset will be reported differently in 'date-and time' values and 'date' or 'time' values. Yes, all this is somewhat unfortunate. I will update the definitions of 'date' and 'time' to follow RFC 9557 but I will not touch 'date-and-time' for now unless lets say the IESG decides that alignment with RFC 9557 is more important than our concerns about compliance of existing implementations generating canonical representations. > *Email Address:* > > The email-address construct in this document is limited to 7-bit. > RFC 6531 and RFC 6532 have extended Email Address to allow UTF-8 > characters. There's a good analysis of the changes at: [...] > Since this is a new datatype being added, it should support all legal email > addresses as defined in current IETF RFCs; so be extended for 8 bit > local-parts. Similarly, the domain part of the address should explicitly > mention A-labels for Internationalized domain names, as the "domain-name" > construct does. I agree that we should support internationalized email addresses. Given the complexity of defining a tight regular expression, this seems to be the wrong path to go. (You pointed to a regular expression that is already close to 1k long and according to its author still has limitations.) Instead, we should leave it to implementations to do validation using regular code. My take is that standardizing a regex to validate email addresses is not something this WG should do. Instead, we should leave it to implementations to do validation in regular code. I will replace the current regular expression with a rather generic expression that accepts international characters, I will add a reference to RFC 6531, and I will add text spelling out that this email type supports u-labels and a-labels in DNS names. /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: IANA considerations for revised RFCs in rfc8407bis
Perhaps this needs to be worked out with IANA. I just report what I was told recently. /js On Mon, Oct 21, 2024 at 03:05:39PM +, mohamed.boucad...@orange.com wrote: > Re-, > > Please see inline. > > Cheers, > Med > > > -Message d'origine- > > De : Jürgen Schönwälder > > Envoyé : lundi 21 octobre 2024 16:32 > > À : BOUCADAIR Mohamed INNOV/NET > > Cc : netmod@ietf.org > > Objet : Re: [netmod] IANA considerations for revised RFCs in > > rfc8407bis > > > > > On Mon, Oct 21, 2024 at 01:48:57PM +, > > mohamed.boucad...@orange.com wrote: > > > > > > We don't have explicit text to say that a rev has to ask to > > update the ref in "ns", though. > > > > > > > I think IANA does not touch the XML namespace registration at all, > > [Med] Actually, it does. Please, for example, yang:ietf-interfaces, > yang:ietf-template, etc. > > > hence RFC 8341 says something like: > > > >This document reuses the URI for "$module" in the "IETF XML > >Registry". > > [Med] Still, that entry was updated to point to 8341: > > yang:ietf-netconf-acm urn:ietf:params:xml:ns:yang:ietf-netconf-acm > ns/yang/ietf-netconf-acm.txt[RFC8341] > > > > > Ideally, there is a cut and paste friendly template for the common > > cases: > > > > a) A document defining new YANG modules not maintained by IANA > > b) A document defining new YANG modules maintained by IANA > > c) A document revising YANG modules not maintained by IANA > > d) A document revising YANG modules maintained by IANA > > > > Well, d) should exist since the module is maintained by IANA, so > > we have cases a)-c). Mixing things together in some what may make > > it harder than necessary for document authors to engineer the text > > they need to use. > > > > [Med] a/b are the same. What differs is the answer to "Maintained by IANA?". > Created sub-sections to easily reference the templates, but only kept two > cases. > > > > /js > > > > -- > > Jürgen Schönwälder Constructor University Bremen > > gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > > Germany > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: IANA considerations for revised RFCs in rfc8407bis
On Mon, Oct 21, 2024 at 01:48:57PM +, mohamed.boucad...@orange.com wrote: > > We don't have explicit text to say that a rev has to ask to update the ref in > "ns", though. > I think IANA does not touch the XML namespace registration at all, hence RFC 8341 says something like: This document reuses the URI for "$module" in the "IETF XML Registry". Ideally, there is a cut and paste friendly template for the common cases: a) A document defining new YANG modules not maintained by IANA b) A document defining new YANG modules maintained by IANA c) A document revising YANG modules not maintained by IANA d) A document revising YANG modules maintained by IANA Well, d) should exist since the module is maintained by IANA, so we have cases a)-c). Mixing things together in some what may make it harder than necessary for document authors to engineer the text they need to use. /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] IANA considerations for revised RFCs in rfc8407bis
Hi, we sometimes revise RFCs with YANG modules and I now learned that IANA wants to have IANA consideration sections that are patterned like the one in RFC 8341. In short, the first sentence clarifies that the existing registration in the XML registry is reused and the second specifies that IANA creates a new entry in their module registry (they have an entry for each revision of the module there). Perhaps this is something RFC 8407 could clarify what to write for a new module and what to write for an udpated module. /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: Yangdoctors last call review of draft-ietf-netmod-rfc6991-bis-16
Thanks for the review Martin. See my responses inline... On Tue, Sep 03, 2024 at 07:33:39AM -0700, Martin Björklund via Datatracker wrote: > Reviewer: Martin Björklund > Review result: Ready with Nits > > Here is my YANG doctor's review of draft-ietf-netmod-rfc6991-bis-16. > > o typedef email-address > > The domain part of "email-address" is different from the type > "domain-name". This looks a bit odd. If special characters can > occur in the domain part of an email address, one would assume that > they can occur in a domain name as well. Email addresses are more complex than just . We meanwhile also received a review suggesting that we support internationalized email addresses and this likely means u-labels in the domain name part instead of a-labels we use in the domain-name type. As a consequence, I believe that capturing all details of valid email addresses precisely in a regular expression is a flawed idea as this leads to super complex regular expressions that are hard to get right (for the interested readers, check our "How can I validate an email address using a regular expression?" on stack overflow. So I will revert to a rather course grained regular expression. I will share more details in my response to the Artart review. > o typedef protocol-number > > "The protocol-number type represents an 8-bit Internet > protocol number, carried in the 'protocol' field of the > IPv4 header or in the 'next header' field of the IPv6 > header. If IPv6 extension headers are present, then the > protocol number type represents the upper layer protocol > number, i.e., the number of the last next header' field > ^^^ ' missing > of the IPv6 extension headers. Fixed in my sources. > o typedef ipv6-address-and-prefix > > "The ipv6-address-and-prefix type represents an IPv6 > address and an associated ipv4 prefix. > >s/ipv4 prefix/IPv6 prefix/ Fixed in my sources. > o typedef ipv4-address-and-prefix > > "The ipv4-address-and-prefix type represents an IPv4 > address and an associated ipv4 prefix. > >s/ipv4 prefix/IPv4 prefix/ Fixed in my sources. > o "schema node instance" > > This term is used in a few places in ietf-yang-types, for example: > > A schema node instance of this type will be set to zero (0) > on creation > > This isn't correct, since a schema node is a node in the schema > tree, and doesn't have a value. With RFC 7950 terminology, it would > be "a node in the data tree". It is unfortunate that there is no > specific term for this in RFC 7950. > > Perhaps it would be easier to just write "An instance of this > type...". > > (I know that this was not correct RFC 6991 either) I suggest we use 'A data tree node using this type' as a replacement of "A schema node instance of this type'. Since a data tree is defined in RFC 7950 to be an instantiated tree of any data modeled with YANG, this should be fix the problem. /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: Opsdir last call review of draft-ietf-netmod-rfc6991-bis-16
Thanks for the review. I like the proposal to merge the text currently found in the appendix into the introduction (and to also point out that Section 2 provides an overview of all types). I am less sure a detailed discussion why specific types were added is useful. At the end it is the NETMOD working group managing this document. Perhaps I should add a statement like "Additional type definitions may be added in the future by submitting proposals to the NETMOD working group." to clarify that there is a process to propose new types. And this may also serve as a hint that detailed discussions can be found in the working group archives. /js On Tue, Sep 10, 2024 at 08:14:11AM -0700, Giuseppe Fioccola via Datatracker wrote: > Reviewer: Giuseppe Fioccola > Review result: Has Nits > > This document is clear for its scope. It simply adds new type definitions to > the "ietf-yang-types" and "ietf-inet-types" YANG modules and obsoletes RFC > 6991. > > The new types defined in the YANG modules are quite understandable, but I > would > suggest to add some explanation, maybe in section 2, about the motivations > behind the addition of these new types (for example, the new date/time related > types compared to the date-and-time type already defined in RFC 6021). > > I noticed that there are two appendixes about the changes from RFC 6991 and > from RFC 6021, which only refer to section 3 and section 4. I think it is > useful to add a reference also to section 2, since the tables there show the > new types with respect to RFC 6991 and RFC 6021. Additionally, you can > consider > to move these appendixes as subsections of section 1. > > > -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: Dnsdir last call review of draft-ietf-netmod-rfc6991-bis-16
Thanks for the review, Florian. I will add a reference to RFC 9499 to the domain-name type definition. /js On Mon, Sep 30, 2024 at 03:14:48AM -0700, Florian Obser via Datatracker wrote: > Reviewer: Florian Obser > Review result: Ready > [...] > > Changes relevant to the DNS are the introduction of a host-name type > and using that type in the definition of the host type. Both changes > are useful. In RFC 6991 the host type is too wide and domain-name type > has some hand-wavy text about host names having stricter requirements > than domain names. > > Strictly speaking the domain-name type does not fully capture what is > currently understood to be a domain name in the DNS, but the > description of the type acknowledges this: "The pattern above is > intended to allow for current practice in domain name use, and some > possible future expansion." This seems sensible for a YANG type. > > An informative reference to RFC 9499 - DNS Terminology would be > useful. > > I'm marking the draft "ready" from a dnsdir point of view. > -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: Genart last call review of draft-ietf-netmod-rfc6991-bis-16
Russ, I have added the references for the two resolved errata to my document sources so this should be resolved in the next update of the I-D. /js On Thu, Sep 26, 2024 at 09:09:40AM -0700, Russ Housley via Datatracker wrote: > Reviewer: Russ Housley > Review result: Ready with Nits > [...] > > Document: draft-ietf-netmod-rfc6991-bis-16 > Reviewer: Russ Housley > Review Date: 2024-09-26 > IETF LC End Date: 2024-10-08 > IESG Telechat date: Unknown > > > Summary: Ready with Nits > > > Major Concerns: > > None. > > > Minor Concerns: > > Please add references for the two resolved errata: > [...] > > Nits: > > None. > > -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: 2nd WGLC on system-config-08
On Tue, Aug 20, 2024 at 12:20:55PM +, Jan Lindblad (jlindbla) wrote: > > PS: And with a well designed merge operation, one might in the future > even move towards breaking the monolithic into pieces, > like we do for the singleton today. > > [janl] Could you expand on that last PS? I’m not following your train of > thought here. > If you take the configuration of a web server, then it is common practice to organize the configuration of different sites a server is serving into separate files. (I am talking about modularity of config instance data, not modularity of the underlying data models.) The server then loads the configs of all active sites and merges the settings somehow to derive all the internal settings necessary to provide the configured services. In the NC/RC world, we have a single monolithic and hence all the busy merging needs to happen on the client side or you hope that clients respect each other instead of stepping onto each others toes when they make changes. I can see possible advantages of splitting our monolithic into multiple s that are then merged on the server side into the grand unified . This gives us modularity, possibly easier to manage access controls, perhaps execution gains if it is possible to localize validations that do not always have to generate and revalidate the grand unified . I understand that this may sound far reaching since the IETF tends to move slwly and to be rightfully conservative about more radical proposals. On the other hand, having a plan where to go with a technology may help to guide current work and to avoid getting stuck with point solutions that at the end make it impossible to evolve beyond a certain stage. /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: 2nd WGLC on system-config-08
As an old Unix guy, I hardly know any complex service that is not configured via multiple configuration files, using combinations of include and merge mechanisms to produce the final configuration the service uses. The idea of a monolithic gave us conceptual simplicity. But in practice, it helps to be able to break down large and complex configurations into meaningful pieces that are merged together. If you follow this logic, then introducing a well defined merge mechanism when flows into makes fall out as just a special. Introducing a well defined merge mechanism is a powerful addition to NMDA, a special purpose copy from to is at best a point solution. The authors of this draft likely just want a copy to running solution standardized. But then the draft needs to say that and not something different. For me, a copy to solution is a missed opportunity to introduce a mechanism that is much more general and powerful than just providing a solution for the datastore. /js PS: One way to look at templates is that they expand to config snippets that are merged with running. PS: And with a well designed merge operation, one might in the future even move towards breaking the monolithic into pieces, like we do for the singleton today. On Mon, Aug 19, 2024 at 09:18:46PM +, Kent Watsen wrote: > Hi Jürgen, > > > > On Aug 15, 2024, at 11:10 AM, Jürgen Schönwälder > > wrote: > > > > On Sun, Aug 11, 2024 at 02:10:31PM +, Kent Watsen wrote: > >> > >> This email begins a two-week WGLC on: > >> > >>System-defined Configuration > >> > >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-netmod-system-config-08&data=05%7C02%7Cjschoenwaelder%40constructor.university%7Ce9f7b1ecbe534b0205b508dcc0948485%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C638596991341830370%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=DIVpTU%2BLerxzFk6QLUJTWJxohdj%2Bx0MrG3D6sj9Bk04%3D&reserved=0 > > > > I have reviewed draft-ietf-netmod-system-config-08 as part of the WG > > last call. I think the document is _not_ready_, in fact, I find the > > document inconsistent. There is text (and a figure) suggesting that > > system config is merged after template expansion into intendedn and > > then there is text and lots of details how system config is copied > > into running. These are two very different things and you either do > > copy to running or merge to intended. > > +1 If everything in is copied into , there is no need to > merge. > > That said, not *everything* in is necessarily copied. It’s more > likely everything used-by-running (referenced, overridden, etc.) that is > copied. Other things (e.g., loopback interface) may never be copied to > running, yet are still conceptually merged into intended, and later appear in > . > > Earlier today I wrote Jan that the reason why the merge occurs after > template-expansion is because we (presumably) know how to merge > configuration, but not how to merge templates. Put aside for a moment the > fact that we don’t have a template solution defined, and just accept that it > would likely be really hard. But your comment could be played backwards, to > show that the “resolve-system” parameter is similarly intractable. That is, > if contains templates, how would the server know how/where to copy > data into ? > > Double-checking why config is being copied from into , I > see broadly two reasons: > > 1. For so-called “shared objects”, only because some feel that “running alone > must be valid”, solely for the benefit of existing systems that do offline > validation. If it is felt that such change cannot occur without versioning > the protocols, then this (NETMOD WG) draft can state that, leaving it to the > NETCONF WG to decide when to publish NETCONF 1.2 and RESTCONF 1.1. > > 2. For the ability for clients to a) override system-defined values and b) > configure descendent nodes to system-defined nodes. The question is, though, > why is this needed? Do any existing systems exist where clients can do (a) > or (b)? Is there actually a use-case where this is needed? Section 5.5.3 > gives an example of the MTU on the loopback interface being changed, and > 5.5.4 gives an example of a “description” being changed - how do vendors > support such things today or, if they don’t, then is it needed now? > > One might claim that there is a hybrid case (mixing 1 and 2 above) where it > is desired to change the values of a system-defined shared-object. But maybe > we shouldn’t support that case. Maybe it should be that either > refer
[netmod] Re: 2nd WGLC on system-config-08
t. What breaks if a data node happens to have the schema's default value? * The "ietf-system-datastore" Module - Why is section 8.2 here? I expected to see the definition of the "ietf-system-datastore" module and not a 2+ pages example of something relatively unrelated. Perhaps move all lengthy examples into the appendix and use only short concise examples where really needed in the body of the specification. In this section, I do not see the need for an example at all. * Security Considerations - While you follow the default security templates, I wonder whether more needs to be said here. If I have a server supporting resolve-system but not implementing , I have no way to predict how the result produced by an edit-config will look like. So I have to fully trust that resolve-system does not lead to a modification of running that may have undesirable consequences. I did not go to rewrite my review now that I see that I fundamentally misunderstood the proposed solution at the beginning. The reason is that Figure 1 is misleading. The reason is that you seem to have two models and neither is captured in Figure 1: +---+ |+---+ | | | +--->| |<+ | (ct, ro) | | (ct, rw) | +---+ +---+ | // configuration transformations, | // e.g., removal of nodes marked | // as "inactive", expansion of +---+ // templates | | v ++ | | // subject to validation | (ct, ro) | ++ This is the situation where the client learns about system config by reading and then explicitly copying over into whatever is needed. The other model is really a partial copy of into via the "resolve-system" magic: +---+ |+---+ | | | +--->| |<+ | (ct, ro) |->| (ct, rw) | +---+ +---+ | // configuration transformations, | // e.g., removal of nodes marked | // as "inactive", expansion of +---+ // templates | | v ++ | | // subject to validation | (ct, ro) | ++ But then I do find statements like this: Configuration in is merged with to create the contents of after the configuration transformations to (e.g., template expansion, removal of inactive configuration defined in [RFC8342]) have been performed (Section 5.1). This apparently is conflict with what is really proposed. So my confusion is very well justified I think. There is a very big difference between thinking of as an overlay of and or thinking of as something that either explicit or implicitly is copied into as a side-effect of certain operations. /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: AD review of draft-ietf-netmod-rfc6991-bis-15
Hi Kent,
I have posted -16. The essential changes are:
- 'date-with-zone-offset' renamed to 'date' again
- 'time-with-zone-offset' renamed to 'time' again
- 'ipv4-address' change of zone index to %.+
- 'ipv6-address' change of zone index to %.+
The rest are editoral updates like dropping module prefixes where they
are not required etc.
/js
On Tue, Jul 30, 2024 at 05:02:29PM +, Kent Watsen wrote:
> Hi Juergen,
>
> During the IETF 120 NETMOD session, there was a discussion regarding the
> status of this document. The chairs asked if anyone would be willing to help
> get it over the line. Both Rob and Joseph (CC-ed) volunteered.
>
> Is there a repo that you were working out of?
>
> Kent // as shepherd
>
>
> > On Apr 6, 2024, at 2:23 AM, Jürgen Schönwälder
> > wrote:
> >
> > Hi Mahesh,
> >
> > I stopped working on this document since the AD indicated that he will
> > refuse any non-backwards compatible changes (regardless whether they
> > can be considered bug fixes). And I am personally also not happy about
> > some of the new naming conventions (which this message/thread was
> > about). If we are now taking a fresh look at things, I can produce a
> > new version, but this really only makes sense if we are willing to
> > actually publish this update.
> >
> > /js
> >
> > On 06.04.24 06:04, Mahesh Jethanandani wrote:
> >> Hi Juergen,
> >> Reviving this thread to identify next steps for the document. Where are we
> >> with publishing a -16 version of the draft?
> >> I do not see objections to most of your suggestions on the changes you
> >> recommend. For milli vs micro part of the discussion, could we have both?
> >> Separately, on the other thread on for changes to IPv6 zone definition,
> >> which I will respond to, can you summarize what the consensus is, so we
> >> can try to close on the thread.
> >> Thanks
> >>> On Mar 23, 2023, at 11:29 AM, Andy Bierman wrote:
> >>>
> >>>
> >>>
> >>> On Thu, Mar 23, 2023 at 5:11 AM tom petch >>> <mailto:ie...@btconnect.com>> wrote:
> >>> From: netmod mailto:netmod-boun...@ietf.org>>
> >>> on behalf of Jürgen Schönwälder
> >>> Sent: 23 March 2023 11:13
> >>>
> >>> On Wed, Mar 22, 2023 at 01:31:43PM +, Rob Wilton (rwilton) wrote:
> >>>> Hi Jürgen,
> >>>>
> >>>> Thanks for the draft. Please see my AD review comments below, except
> >>>> for a couple of comments related to the change to ipv6-address
> >>>> definition that I've spun into a separate thread so that I can include
> >>>> the interested parties of draft-ietf-6man-rfc6874bis into the discussion.
> >>>
> >>> Thanks for your review. See responses inline.
> >>>
> >>>> Moderate level comments:
> >>>>
> >>>> (1) p 13, sec 3. Core YANG Types
> >>>>
> >>>> typedef date-with-zone-offset {
> >>>>
> >>>> Why don't we just call this 'date' rather than 'date-with-zone-offset',
> >>>> particularly because the zone information is optional? Intuitively,
> >>>> from the name of this type, I would have expected that zone information
> >>>> as being required rather than being optional.
> >>>>
> >>>> I also note that the current naming convention of this type seems
> >>>> somewhat inconsistent from "date-no-zone", since one of them includes
> >>>> "offset" and the other does not.
> >>>>
> >>>> This same comment also applies to 'time-with-zone-offset'.
> >>>
> >>> Earlier versions had just 'date' and 'time' and both included a zone
> >>> offset. We then also got 'date-no-zone' and 'time-no-zone' and all was
> >>> kind of nice and consistent. Then the IP address debate kicked in and
> >>> finally some people made the point that we should be always explicit
> >>> (but then you can't encode all semantics in a name anyway). So this is
> >>> how we got to the names we have now. For me personally, 'date' and
> >>> 'date-no-zone' and 'time' and 'time-no-zone' was just fine. The
> >>> '-offset' came in as a way to future proof definitions since in s
[netmod] Re: AD review of draft-ietf-netmod-rfc6991-bis-15
I will leave the definition of date-and-time as is. When the definition was created, we followed RFC 3339: If the time in UTC is known, but the offset to local time is unknown, this can be represented with an offset of "-00:00". This differs semantically from an offset of "Z" or "+00:00", which imply that UTC is the preferred reference point for the specified time. RFC 3339 kind of suggested that "Z" and "+00:00" mean the same, so we made "-00:00" the canonical format if the offset to local time is unknown and we can't change the canonical format. It is what it is. The WG may consider to create a new YANG module for date and time types and there we can define a date-and-time replacement with new semantics and we can also provide types supporting some of the good stuff in RFC 9557 (in particular referring to time zone names instead of just static offsets). /js On Tue, Jun 04, 2024 at 07:41:43AM +0200, Carsten Bormann wrote: > Hi Kent, > > thank you for this feedback. > > >> (2) I’d love to know what kinds of timestamps real YANG implementations > >> send here — do they really pollute their timestamps with local-time offset > >> information? > >> Does any recipient actually care about the local-time relation information > >> encoded here? > >> I’d expect everything to be -00:00, but then I’m a utilitarian. > > > > In all applications I’ve worked on, time is encoded in UTC using the ‘Z’ > > suffix on the wire, and as UTC in the database. The presentation-layer > > always maps the UTC to/from local-time. > > So essentially, you already are in RFC 9557 land: > You are seeing the use of “Z” in a situation where there really is no > information about the local time that might apply to this timestamp. RFC > 3339/6991 would have used -00:00 for that, and RFC 9557 uses Z. > > So actually, there may be two kinds of backwards compatibility here: > (1) backwards compatibility to what the spec says (RFC 3339/6991 and the two > buckets for -00:00 and for Z/+00:00) > (2) backwards compatibility to what implementations and common operational > use actually imply (RFC 9557 and the two buckets for Z and +00:00, where only > the Z bucket is actually employed). > > Interesting. > > So does anyone have an example where implementations or operational practices > actually care about that second piece of information in a timestamp, namely > the relationship to some local-time offset? > > Grüße, Carsten > > -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: Yang Scalability
On Thu, Jul 25, 2024 at 08:01:27AM +, Robert Peschi (Nokia) wrote: > > Using templates also means transmitting much less data from the client to the > device server, e.g. during a copy-config. Naturally, this would accordingly > reduce protocol transmission penalty. It also greatly reduces the footprint > of the running data store on the persistent memory of the device. > Configuation templates were left out of standardization many years ago. There was no interest to standardize configuration templates (perhaps companies needed ways to distinguish products or finding agreement on a standard template format was considered too hard and time consuming or ...). RFC 8342 (published March 2018) acknowledges the existence of configuration template mechanisms but also notes that they are proprietary: o Some implementations have proprietary mechanisms that allow clients to define configuration templates in . These templates are expanded automatically by the system, and the resulting configuration is applied internally. The question is whether it is possible now (starting in 2024) to define a standard configuration template mechanism that has a chance to be implemented widely. See also the YANG next issue #18 (opened on 2017-03-17). /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
[netmod] Re: YANG Versioning question - namespace version?
The YANG naming scheme is (module, path). The XML namespaces are an XML serialization artifact. By promising backwards compatibility, the (module, path) naming scheme was sufficient (non-backwards compatible changes require to change either the module, the path, or both). The versioning effort proposes to evolve the current naming scheme to (module, path, version). This requires that in _all_ places where YANG-defined data is stored and processed, the version context needs to be made available, which essentially implies availability of the YANG library of the originating server plus code to process the same at all places where YANG-defined data is stored or processed and where robustness matters. /js On 18.06.24 08:22, Jan Lindblad (jlindbla) wrote: Kent, I was recently asked why YANG module namespaces aren’t versioned. For example, the “1.0” at the end of this URI "urn:ietf:params:xml:ns:yang:ietf-crypto-types:1.0”. The stated concern was "because without this, then management of backward compatibility becomes a nightmare.” In the very early days of YANG, we actually had a brief while when the NS strings were composed just like that, with a sort of version number at the end. To know that something is a new/different version of something else you need two information elements. Something that indicates “sameness” and something that indicates “newness”. When tracking files in git, the “sameness” typically comes from keeping the same filename (even if git can handle file renames if registered properly). In YANG, we didn’t want to rely on the filename, since the module filenames are not necessarily globally unique, as the thinking went. So the NS string serves as the sameness factor, and must therefore not change. Basically, modules with different NS strings are (considered) completely unrelated. To indicate “newness”, we depend on the revision statement in YANG. In the Versioning Design Team, we have also been toying around with a checksum to indicate newness, but that has not taken root. Theoretically, it would of course be possible to indicate both things in the NS string by appending a version number at the end, but then all clients and servers would have to agree on the convention/rule that the characters after the last colon in the NS string need to be processed differently. That ship has probably crossed the ocean by now, but we could bring it up for YANG next. But I fail to see why our non-choice of this particular solution would necessarily drive us into a nightmare. The necessary information is available in the modules, just not in the NS string alone. Best Regards, /jan This convention was established prior to my becoming active in the IETF, but my guess is that the reason is because the YANG-module update rules in RFC 7950 Section 11 ensure backwards compatibility, and hence the versioning the namespace would have no value. That said, the YANG Versioning effort introduces the possibility of NBC changes, which makes me wonder if this is something that should be discussed. Thoughts? Kent ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
Re: [netmod] AD review of draft-ietf-netmod-rfc6991-bis-15
On Tue, Apr 16, 2024 at 10:08:09AM -0700, Mahesh Jethanandani wrote: > Hi Jürgen, > > It appears that Brian and you had made progress on the other thread related > to IPv6 zone definition. Are there any outstanding issues that need to be > resolved? > > What is the plan to submit an updated version of the document? > I had to take a fresh look at things and I think the discussion around zones of IP addresses is moving to a conclusion. That said, I believe we are not done with the work related to dates, times, and durations. What we have is not really good and also in conflict with newer work that came out of the sedate WG and has passed IESG approval (I think). Here is a not so short summary (I have even more details since I did take a look into what standard libraries of various system programming languages offer). * date-and-time, date, time For time zones, we used to have the canonical format +00:00 for systems in UTC located and a known timezone offset of 00:00. For systems in UTC with an unknown timezone offset, the canonical format has been -00:00. This was based on RFC 3339 which introduced the -00:00 which is not strictly allowed by the ISO 8601 format. The sedate work is updating RFC 3339 recommending against the use of the -00:00 notation (since it is not conforming to ISO 8601) and instead suggests that Z is used for systems in UTC with an unknown timezone offset. The question is now how we deal with this non-backwards compatible change of RFC 3339 that apparently got approved by the IESG and hence there is believe that the Internet won't break based on the argument that using Z instead of -00:00 is already common practice. If so, do we simply align our definition with the updated version of RFC 3339? Or do we go an deprecate date-and-time and create a new definition (and then we deal with the updates of all affected modules over time)? Note that this also affects the newly defined zoned types date and time. Looking forward, we may even want to consider supporting formats that allow for timezone names instead of only static numeric offsets. So another option might be to leave date-and-time as is (potentially deprecating it once there is a better replacement) and to start a new module, say ietf-chrono, that defines new date and time related types that are aligned with the updated RFC 3339 and the work done by the sedate working group to enable the use of time zone names. * nanoseconds, microseconds, milliseconds, seconds, minutes, hours There was some discussion around the choice of signed vs unsigned base types and the choice between 32 and 64 bits. I have investigated a bit what standard libraries of system programming languages do and I concluded that using signed integer types dominates and that we should use 64-bit types for everything up to and including seconds (and not offer 32-bit alternatives). It is easy to range restrict to just positive numbers and it is also easy to range restrict to use less than 64 bits. If we would start a new module for date and time types, then these definitions should likely be moved there as well. I believe to have proper types for data and time and durations, it is best to factor this work out into a separate effort. This gives us more freedom to do things right without any harm on backwards compatibility (we would not change date-and-time, except perhaps adding a warning note that use of -00:00 is getting discouraged). /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Changes to IPv6 zone definition in draft-ietf-netmod-rfc6991-bis-15
On Mon, Apr 08, 2024 at 10:03:14AM +1200, Brian E Carpenter wrote:
> >
> > > While I'm here, I looked at typedef ipv6-address {}. Two comments:
> > >
> > > 1. "If the zone index is not present, the default zone of the device
> > > will be used."
> > > FYI, although RFC 4007 describes the default zone, it's optional. For
> > > example, there is no default zone on Linux; if you execute a socket call
> > > with a zero or null zone, it's a run-time error.
> >
> > I am pretty optimistic that you can memset a sockaddr_in6 to zero and
> > then fill out the sin6_addr field and things will work.
>
> I'm afraid not. If you call sendmsg() with a link-local destination and
> a zero sin6_scope_id, you get "[Errno 22] Invalid argument". If you call
> it with a non-existing positive value, you get "[Errno 101] Network is
> unreachable".
>
> Tested on my Linux machine with the attached Python script. And I knew
> this anyway from testing with ping.
So for a global address, a sin6_scope_id set to 0 means the scope is
ignored but for a non-global address, a 0 is taken as something that
must resolve to an interface numbered 0 (which likely does not exist)?
So what do we do, simply remove the sentence that talks about a
default zone?
> > Perhaps the zero
> > is not what RFC 4007 calls the default zone, then we need to find
> > better wording. But then RFC 4007 also says:
> >
> > An implementation should also support the concept of a "default" zone
> > for each scope. And, when supported, the index value zero at each
> > scope SHOULD be reserved to mean "use the default zone".
>
> However, that "should" and "SHOULD" have not been implemented for Linux.
> > > 2. There seems to be a limited character set for the zone ID. RFC 4007
> > > doesn't restrict the character set; it just says "non-null strings".
> > > IMHO that's a bug, but if I want to name an interface
> > > *%!@#$^&()_-+=:;'"?\|}{}{/.><, it's allowed by the RFC. (The text
> > > doesn't even specify ASCII, and the remark about "conflict with the
> > > delimiter" is meaningless, if you think about parsing.)
> >
> > > If you intend to limit the character set more than RFC 4007 does, that
> > > should be stated, and probably discussed on the 6man list.
> >
> > Yes, the zone ID is underspecified, and we can't really fix that. What
> > we had did not allow forward slashes, although they are used by some
> > vendors. So we are trying to improve but whatever we do is debatable
> > since the zone ID is underspecified. (On Linux, I am pretty sure an
> > interface name does not even have to be ASCII or UTF-8. Whatever we
> > end up doing, we will likely assume UTF-8.)
>
> OK, I understand that choice. Maybe you should say in the description
> that the zone ID is underspecified in the RFC?
I will make the zone match .+ and adapt text from the definition of
interface names (interfaces/name):
If a system uses zone names that are not represented in UTF-8, then
an implementation needs to use some mechanism to transform the
local name into UTF-8. The definition of such a mechanism is
outside the scope of this document.
> > This is why I suggested to write an ID that explains what happens if
> > people go creative with zone IDs so that people know that certain zone
> > IDs will not play nice with YANG modules, certain zone IDs will not play
> > nice with URLs and so on. People can than take an informed decision and
> > deal with the consequences.
>
> Well, I think 6man really ought to clean up RFC 4007 in this respect.
> But that is a battle for another day.
>
> Brian
> import socket
>
> def tryz(zone):
> try:
> print("Trying zone", zone)
> sock = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM)
> sock.connect(("fe80::2e3a:fdff:fea4:dde7", 12345, 0, zone))
> result = sock.sendmsg([msg_bytes])
> print("Result:", result, "bytes sent")
> sock.close()
> except Exception as e:
> print(e)
>
> msg_bytes = bytes(b"Test")
>
> tryz(socket.if_nametoindex("wlp2s0"))
> tryz(99)
> tryz(0)
On Linux 6.1.0 (Debian 12.5), I get:
Trying zone 2
Result: 4 bytes sent
Trying zone 99
[Errno 101] Network is unreachable
Trying zone 0
[Errno 22] Invalid argument
On MacOS 14.4.1, I get:
Trying zone 4
Result: 4 bytes sent
Trying zone 99
[Errno 22] Invalid argument
Trying zone 0
[Errno 65] No route to host
Apparently, the behaviours of implementations vary...
/js
--
Jürgen Schönwälder Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Changes to IPv6 zone definition in draft-ietf-netmod-rfc6991-bis-15
Please see inline...
On 06.04.24 22:50, Brian E Carpenter wrote:
I am discovering your draft as I type, but I assume you are referring to
typedef uri {}. Assuming that RFC6874 is indeed obsoleted, you can just
forget about this issue until something changes.
I do see a quite different glitch in your typedef uri {}. If the host
part of a URI is a literal IPv6 address, normalizing to uppercase
contradicts Section 4.3 of RFC5952 which says:
'4.3. Lowercase
The characters "a", "b", "c", "d", "e", and "f" in an IPv6 address
MUST be represented in lowercase.'
Therefore, normalizing to uppercase would be an error. However, I think
your text is wrong anyway: section 6.2.2.1 of RFC3986 applies to hex
digits *within a percent-encoded triplet* and in fact hex digits in the
host part would be normalized to lowercase.
So where your draft reads "except for hexadecimal digits", it should
read "except for hexadecimal digits within a percent-encoded triplet",
for consistency with RFC3986 and RFC5952.
I will do the following change:
OLD
[...] All unnecessary
percent-encoding is removed, and all case-insensitive
characters are set to lowercase except for hexadecimal
digits, which are normalized to uppercase as described in
Section 6.2.2.1.
NEW
[...] All unnecessary
percent-encoding is removed, and all case-insensitive
characters are set to lowercase except for hexadecimal
digits within a percent-encoded triplet, which are
normalized to uppercase as described in Section 6.2.2.1
of RFC 3986.
While I'm here, I looked at typedef ipv6-address {}. Two comments:
1. "If the zone index is not present, the default zone of the device
will be used."
FYI, although RFC 4007 describes the default zone, it's optional. For
example, there is no default zone on Linux; if you execute a socket call
with a zero or null zone, it's a run-time error.
I am pretty optimistic that you can memset a sockaddr_in6 to zero and
then fill out the sin6_addr field and things will work. Perhaps the zero
is not what RFC 4007 calls the default zone, then we need to find
better wording. But then RFC 4007 also says:
An implementation should also support the concept of a "default" zone
for each scope. And, when supported, the index value zero at each
scope SHOULD be reserved to mean "use the default zone".
2. There seems to be a limited character set for the zone ID. RFC 4007
doesn't restrict the character set; it just says "non-null strings".
IMHO that's a bug, but if I want to name an interface
*%!@#$^&()_-+=:;'"?\|}{}{/.><, it's allowed by the RFC. (The text
doesn't even specify ASCII, and the remark about "conflict with the
delimiter" is meaningless, if you think about parsing.)
If you intend to limit the character set more than RFC 4007 does, that
should be stated, and probably discussed on the 6man list.
Yes, the zone ID is underspecified, and we can't really fix that. What
we had did not allow forward slashes, although they are used by some
vendors. So we are trying to improve but whatever we do is debatable
since the zone ID is underspecified. (On Linux, I am pretty sure an
interface name does not even have to be ASCII or UTF-8. Whatever we
end up doing, we will likely assume UTF-8.)
This is why I suggested to write an ID that explains what happens if
people go creative with zone IDs so that people know that certain zone
IDs will not play nice with YANG modules, certain zone IDs will not play
nice with URLs and so on. People can than take an informed decision and
deal with the consequences.
/js
--
Jürgen Schönwälder Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Changes to IPv6 zone definition in draft-ietf-netmod-rfc6991-bis-15
On 06.04.24 22:57, Brian E Carpenter wrote: On 06-Apr-24 19:52, Jürgen Schönwälder wrote: I believe numeric zone identifiers were always supported so they always work as a fallback. Correct, but do all network elements actually support RFC4007? Maybe there are devices where interfaces do not have a simple sequential numbering. There is nothing that says sequential. And the native identifier for an interface used to be a number (and text about using the number as the canonical format is not new either). /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Changes to IPv6 zone definition in draft-ietf-netmod-rfc6991-bis-15
ion 11.2 seems to indicate that there is no restriction. RFC 4007 is woefully vague, but it does limit the character set to ASCII. The failings I have noted so far include: 1) No length limit - i.e. exposed to buffer overrun bugs and exploits; 2) NULL is not disallowed - i.e. exposed to NULL-terminated string bugs and exploits; 3) In fact, no statement about non-alphanumeric characters at all; 4) No statement about case sensitivity or case folding; [It's clear to me that RFC 4007 needs to be revisited after we have settled the current issues.] All of these are problematic in the URI context, not to mention the poor choice of "%" as a delimiter. The above doesn't tell me what is intended about case sensitivity, and it does include "/" which is troublesome in URIs. Maybe you could consider an even more complex definition that distinguishes general zone identifiers from URI-friendly zone identifiers? The latter would be something like '(%[a-z0-9][a-z0-9\-\._~]*)?' Then there could be a general recommendation to use the restricted character set if, and only if, there is an operational requirement to generate URIs for a given interface. draft-ietf-6man-rfc6874bis, which I'm currently holding a 'discuss' ballot position on, effectively limits the usable character set of zone-ids to the unreserved set in URIs, which seems to match those above except for '/' that is allowed above (and used in many interface names), but not in the URI's unreserved character set. A further difference is that upper case characters are allowed in this typedef but are not allowed when used in the host part of URIs. Well, more precisely they will almost certainly be normalized to lower case by the URI parser. Update - I've now seen the thread 'ipv6-address in RFC 6991 (and bis)', and Jürgen has put together a useful blog post, thanks! Given that "interface-name" in RFC 8343, and the text in RFC 4007 section 11.2, then arguably the safest thing here would be to allow the zone-id to be unrestricted, i.e., "(%.*)?" However, this would leave draft-ietf-6man-rfc6874bis as only being able to support a small fraction of interface names as zone-ids in URLs. The authors of draft-ietf-6man-rfc6874bis seem to indicate that it works for all interface names that currently matter for their use case. That appears to be correct, as noted in the newly proposed text at https://www.cs.auckland.ac.nz/~brian/draft-ietf-6man-rfc6874bis-06X.html#section-1-5 An alternative solution could be to somewhere define the zone-ids in YANG to match the restrictive set in draft-ietf-6man-rfc6874bis (i.e., lower case only, and disallow '/'). I think that this would then require that we recommend a conversion of interface names into draft-ietf-6man-rfc6874bis compatible zone-ids interface-names. E.g., such a conversion could take the interface name, and change any uppercase characters to lower case, and replace any symbol that isn't in the allowed character set with '_'. This conversion is effectively one way, and there is a theoretical risk that the converted interface names could collide, but this may be unlikely in practice. Obviously, this conversation doesn't handle non-ASCII interface names, but I'm not sure how realistic it is that they would be used anyway. Remember there is a browser between the URI and the operating system, and the browser communicates with the operating system via a socket interface. So such a conversion is useless unless the socket interface in the device concerned is fully aware of the mapping. So even if there is a use case, there are a lot of moving parts here. Personally I think allowing non-ASCII would be disastrously complex and would have no real advantage for netops staff. Езернет1/0/1 instead of Ethernet1/0/1 doesn't seem worth all the resultant hassle. This general comment also applies for the same change for 'ipv4-address'. Fortunately this is 100% out of scope for the 6man draft. (3) draft-ietf-netmod-rfc6991-bis-15, p 28, sec 4. Internet Protocol Suite Types The canonical format of IPv6 addresses uses the textual representation defined in Section 4 of RFC 5952. The canonical format for the zone index is the numerical format as described in Section 11.2 of RFC 4007."; Would it make sense to also change the canonical format for the zone index to be interface name (or converted interface name) rather than numeric id (when used in YANG models)? Please not. In a completely different context (RFC 8990) I've written code handling link local addresses and multiple interfaces, and driving it by interface index rather than by name is definitely the way to go. Humans may like the names, but the numbers are much better for programs. Regard Brian This comme
Re: [netmod] AD review of draft-ietf-netmod-rfc6991-bis-15
Hi Mahesh,
I stopped working on this document since the AD indicated that he will
refuse any non-backwards compatible changes (regardless whether they
can be considered bug fixes). And I am personally also not happy about
some of the new naming conventions (which this message/thread was
about). If we are now taking a fresh look at things, I can produce a
new version, but this really only makes sense if we are willing to
actually publish this update.
/js
On 06.04.24 06:04, Mahesh Jethanandani wrote:
Hi Juergen,
Reviving this thread to identify next steps for the document. Where are we with
publishing a -16 version of the draft?
I do not see objections to most of your suggestions on the changes you
recommend. For milli vs micro part of the discussion, could we have both?
Separately, on the other thread on for changes to IPv6 zone definition, which I
will respond to, can you summarize what the consensus is, so we can try to
close on the thread.
Thanks
On Mar 23, 2023, at 11:29 AM, Andy Bierman wrote:
On Thu, Mar 23, 2023 at 5:11 AM tom petch mailto:ie...@btconnect.com>> wrote:
From: netmod mailto:netmod-boun...@ietf.org>> on behalf of
Jürgen Schönwälder
Sent: 23 March 2023 11:13
On Wed, Mar 22, 2023 at 01:31:43PM +, Rob Wilton (rwilton) wrote:
Hi Jürgen,
Thanks for the draft. Please see my AD review comments below, except for a
couple of comments related to the change to ipv6-address definition that I've
spun into a separate thread so that I can include the interested parties of
draft-ietf-6man-rfc6874bis into the discussion.
Thanks for your review. See responses inline.
Moderate level comments:
(1) p 13, sec 3. Core YANG Types
typedef date-with-zone-offset {
Why don't we just call this 'date' rather than 'date-with-zone-offset',
particularly because the zone information is optional? Intuitively, from the
name of this type, I would have expected that zone information as being
required rather than being optional.
I also note that the current naming convention of this type seems somewhat inconsistent from
"date-no-zone", since one of them includes "offset" and the other does not.
This same comment also applies to 'time-with-zone-offset'.
Earlier versions had just 'date' and 'time' and both included a zone
offset. We then also got 'date-no-zone' and 'time-no-zone' and all was
kind of nice and consistent. Then the IP address debate kicked in and
finally some people made the point that we should be always explicit
(but then you can't encode all semantics in a name anyway). So this is
how we got to the names we have now. For me personally, 'date' and
'date-no-zone' and 'time' and 'time-no-zone' was just fine. The
'-offset' came in as a way to future proof definitions since in some
contexts you may want to indicate the timezone not with a fixed offset
but with a timezone name like 'Europe/Berlin' that is then resolved
using more complex rules to a specific offset.
I personally would be happy to change date-with-zone-offset back to
date and time-with-zone-offset back to time and to deal with the
future in the future...
Me too. I think that the fashion for incorporating ever more semantics into an
identifier is a misunderstanding of what an identifier is for ie to identify.
Me three.
IMO simple names like 'date' and 'time' and 'date-and-time' are easier to
understand.
Optional fields are different than mandatory fields.
If a data type has some mandatory field, then it may need to have its own
typedef and name.
Tom Petch
Andy
(2) p 27, sec 4. Internet Protocol Suite Types
I've moved this comment to a separate thread.
(3) p 28, sec 4. Internet Protocol Suite Types
I've moved this comment to a separate thread.
Minor level comments:
(4) p 13, sec 3. Core YANG Types
description
"The date type represents a time-interval of the length
of a day, i.e., 24 hours.
I think that it might be helpful if the first part of the description stated
that the type optionally includes the zone offset, particularly to
differentiate from the type that excludes it.
I am happy to add. "It includes and optional time zone offset." so
that it says:
"The date type represents a time-interval of the length
of a day, i.e., 24 hours. It includes and optional time
zone offset.
With the current naming scheme, we would have to
s/date/date-with-zone-offset/ everywhere in the description.
That will look pretty ugly. [sarcasm on] Perhaps we should
call it 'date-with-optional-zone-offset' and then the additional
sentence is not needed anymore. [sarcasm off]
This same comment also applies to 'time-with-zone-offset'.
Yes.
(5) p 14, sec 3. Core YANG Types
Re: [netmod] On prefixes again RE: IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis
Yes, for long XPath expressions, one likes to have short prefixes, the shorter the better. In other contexts, such as type definitions, one may want to use longer prefixes providing more context. It seems you can't have both at the same time. Given this inherent conflict, I am not sure that generally pushing for longer prefixes is a good thing. For modules with long XPath expressions, an author may consider to go for one character local prefixes even if they require to lookup their meaning in the imports (or people have modern editors that can dynamically show an expansion) because mutli-line XPath expressions with lots of repetitive substrings are pretty bad for human eyes. /js On Fri, Mar 15, 2024 at 08:22:03AM -0700, Andy Bierman wrote: > On Fri, Mar 15, 2024 at 7:24 AM Jürgen Schönwälder > wrote: > > > I wonder which problem we are solving with adding more little rules. > > Perhaps a future version of YANG will do away with prefixes but until > > this happens, I do not think we need to add more rules about how to > > choose prefixes. The original intend was that they are short to keep > > YANG snippets concise and easy to read. > > > > > > This is the IETF Coding Conventions document, not the YANG specification. > Naming conventions are CLRs but often with some benefits. > > What problems? > > 1) If there are multiple modules used in imports then the reader must be > able to > easily tell the prefixes apart. If prefixes are too short and not > meaningful, this task > gets more difficult. I find myself constantly going back to the imports to > make sure > I am matching the prefix to the correct module. > > 2) If there are complex XPath expressions then prefixes that are too long > make the > expression unreadable, especially as it is chopped into "string" + > "string" format > to fit into 72 character lines. If prefixes are too short then back to > problem (1). > > 3) It is becoming more common to have vendor modules import modules from > multiple SDOs. > Prefix naming conventions are already the BCP everywhere but the IETF. > > Is it too late to start for IETF? There are many modules already with no > naming consistency, > so this would only affect new modules. There will never be consistent > naming of prefixes > so it may not be worth the change now. > > > > /js > > > > -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] On prefixes again RE: IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis
> Thank you. > ___ > netmod mailing list > netmod@ietf.org<mailto:netmod@ietf.org> > https://www.ietf.org/mailman/listinfo/netmod > > > Mahesh Jethanandani > mjethanand...@gmail.com<mailto:mjethanand...@gmail.com> > > > > > > ___ > netmod mailing list > netmod@ietf.org<mailto:netmod@ietf.org> > https://www.ietf.org/mailman/listinfo/netmod > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] On prefixes RE: Next steps for draft-ietf-netmod-rfc8407bis
Hi Med, I believe it is a misconception that text not written in capital letters is not normative. I also believe we need _guidelines_ on the choice of identifiers like prefixes and not hard rules. Prefixes do not have to be unique. It is nice if they are for widely used modules, but we are on a slippery path if we think of them as something that should be unique. Then they get long or clumsy or both (or worse we encourage a competition to allocate nice short prefixes). Yes, the original language is vague, on purpose. I guess I miss which problem is solved by requiring uniqueness that practically can't be ensured and is technically also not necessary. /js On 05.03.24 09:58, mohamed.boucad...@orange.com wrote: Hi Jürgen, Please see inline. Cheers, Med -Message d'origine- De : netmod De la part de Jürgen Schönwälder Envoyé : lundi 4 mars 2024 20:44 À : netmod@ietf.org Objet : Re: [netmod] On prefixes RE: Next steps for draft-ietf-netmod- rfc8407bis Hi, the statement "should be selected carefully to be unique" is impossible to implement given an open ended set of YANG modules. [Med] Hmm, but there is no normative text in that sentence. What concretely needs to be followed is indicated in the sentence right after (SHOULD NOT); which is inherited from 8407. Isn't "selected carefully to be unique" echoing the spirit of this text from RFC7950? Developers of YANG modules and submodules are RECOMMENDED to choose names for their modules that will have a low probability of colliding with standard or other enterprise modules, e.g., by using the enterprise or organization name as a prefix for the module name. Within a server, all module names MUST be unique. If this section only applies to IETF modules (I thought it is more general) and IANA never makes a mistake and we accept that prefixes get longer or cryptic over time, then this may be possible to implement, but I am not sure this is actually desirable. The original wording "likely to be unique" was selected carefully, it conveys the message that prefixes can't be assumed to be unique. [Med] "SHOULD ...likely" is really ambiguous as a reco if the text does not explain when it won't be Perhaps it should be even further watered down to "likely to be unique in a certain usage context". [Med] What is a usage context? how that usage context is known? How a module is concretely bound to it? Etc. IMO, this triggers more questions that it clarifies the guidance. I believe the original wording was good enough and does not need an update. Every update, even if well intended, carries a risk to break something that works. /js On 04.03.24 19:39, Randy Presuhn wrote: Hi - On 2024-03-04 12:51 AM, mohamed.boucad...@orange.com wrote: Hi Jan, I went so far with the following: OLD: Prefix values SHOULD be short but are also likely to be unique. Prefix values SHOULD NOT conflict with known modules that have been previously published. NEW: Prefix values should be selected carefully to be unique, and ideally not too long. Specifically, prefix values SHOULD NOT conflict with known modules that have been previously published. I'm having troubles with the normative language here. If we maintain the two sentences, the second SHOULD is sufficient for the uniqueness IMO. Also, as per RFC2119, we should clarify when the SHOULD NOT can be safely ignored: SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. An obvious case is an updated version of a published version. ... In dealing with SHOULD statements in RFCs, both as an implementor and as a specification writer, I find it useful to re-phrase (at least in my head) a "SHOULD NOT X" as "MUST be able to cope with others doing X, even if it does not itself do X." A "SHOULD NOT X" in a specification does NOT relieve implementations of the duty to work correctly when X happens, because "SHOULD NOT X" means that X is indeed permitted, even if discouraged. If X causes a an implementation pair to violate protocol or miscommunicate (e.g. referencing the wrong syntax or semantics) at some level, then it really needs to be a "MUST NOT". But this is an old, old argument, and gliding along with "likely uniqueness" rather than uniqueness has been a longstanding bug/feature of netmod. I'd just like to see a bit more guidance for implementors so their products don't crash and burn when they do encounter "duplicate" prefixes in the wild. Randy __
Re: [netmod] On prefixes RE: Next steps for draft-ietf-netmod-rfc8407bis
Hi, the statement "should be selected carefully to be unique" is impossible to implement given an open ended set of YANG modules. If this section only applies to IETF modules (I thought it is more general) and IANA never makes a mistake and we accept that prefixes get longer or cryptic over time, then this may be possible to implement, but I am not sure this is actually desirable. The original wording "likely to be unique" was selected carefully, it conveys the message that prefixes can't be assumed to be unique. Perhaps it should be even further watered down to "likely to be unique in a certain usage context". I believe the original wording was good enough and does not need an update. Every update, even if well intended, carries a risk to break something that works. /js On 04.03.24 19:39, Randy Presuhn wrote: Hi - On 2024-03-04 12:51 AM, mohamed.boucad...@orange.com wrote: Hi Jan, I went so far with the following: OLD: Prefix values SHOULD be short but are also likely to be unique. Prefix values SHOULD NOT conflict with known modules that have been previously published. NEW: Prefix values should be selected carefully to be unique, and ideally not too long. Specifically, prefix values SHOULD NOT conflict with known modules that have been previously published. I’m having troubles with the normative language here. If we maintain the two sentences, the second SHOULD is sufficient for the uniqueness IMO. Also, as per RFC2119, we should clarify when the SHOULD NOT can be safely ignored: SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. An obvious case is an updated version of a published version. ... In dealing with SHOULD statements in RFCs, both as an implementor and as a specification writer, I find it useful to re-phrase (at least in my head) a "SHOULD NOT X" as "MUST be able to cope with others doing X, even if it does not itself do X." A "SHOULD NOT X" in a specification does NOT relieve implementations of the duty to work correctly when X happens, because "SHOULD NOT X" means that X is indeed permitted, even if discouraged. If X causes a an implementation pair to violate protocol or miscommunicate (e.g. referencing the wrong syntax or semantics) at some level, then it really needs to be a "MUST NOT". But this is an old, old argument, and gliding along with "likely uniqueness" rather than uniqueness has been a longstanding bug/feature of netmod. I'd just like to see a bit more guidance for implementors so their products don't crash and burn when they do encounter "duplicate" prefixes in the wild. Randy _______ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Fwd: Draft Minutes for Virtual Interim
Kent, I may be old fashioned but the IETF used to determine consensus on mailing lists (and as an experienced WG chair I assume you know ways to do that). Perhaps you can simply change the wording in the (draft) minutes and we move on. Thanks, /js On Wed, Jan 31, 2024 at 03:46:13PM +, Kent Watsen wrote: > > Hi Juergen, > > > Well, statements like "the WG agrees" are problematic for things that > > have not been discussed on the mailing list. Perhaps it is the people > > attending the interim agreed? Well, I can't tell, I have not been > > there... > > Maybe but… > - it was an official Interim meeting (not just a design team) > - the subject of this email indicates “Draft Minutes”. > - the body of the email says "Please report any updates needed here." > > Clearly the email is the “confirmation" on the list, and hence it didn't > seem wrong to predictively say "the WG agrees”. > > That said, I wonder who all constitute the “working group”. Does it make > sense to extend that label to folks who don’t participate? The “netmod” > mailing list has 410 members, but it’s hard to imagine the “working group” > being anywhere close to that. > > Kent > > -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Draft Minutes for Virtual Interim
Well, statements like "the WG agrees" are problematic for things that have not been discussed on the mailing list. Perhaps it is the people attending the interim agreed? Well, I can't tell, I have not been there... On Wed, Jan 31, 2024 at 02:15:56AM +, Kent Watsen wrote: > Hi Jason, > > > On Jan 30, 2024, at 11:55 AM, Jason Sterne (Nokia) > > wrote: > > > > Hi WG, > > (and in particular to those who attended the interim). > > > > The summary below mostly matches my memory of the discussions, but I don’t > > really remember us concluding on this: > > > > The WG agreed to let 7950-bis "update" 8342 (NMDA) with the > > clarification the alone does not have to be valid. > > E.g., clients may have to perform transforms to calculate > > , which is subject to validation. > > The audio indicates Rob saying this and no one objecting. > Are you objecting? > > > > (the rest of the minutes/summary below also seems to contradict that > > paragraph being a conclusion no?) > > Your comments below are not text-edits to the minutes, so it is unclear how > they apply to the minutes. > > Kent > > > > I thought it was going to remain somewhat optional/indeterminate if running > > will be valid: > > Servers may or may not enforce running to be valid (i.e. they may only > > validate intended as a proxy for validating running) > > Clients can’t necessarily expect to be able to offline validate running, > > although it may work in circumstances where the operator doesn’t use > > templates or inactive config *or* the client reproduces the server logic > > for the running->intended transforms > > > > Jason > > > > From: netmod mailto:netmod-boun...@ietf.org>> On > > Behalf Of Kent Watsen > > Sent: Monday, January 29, 2024 7:21 PM > > To: netmod@ietf.org <mailto:netmod@ietf.org> > > Subject: [netmod] Draft Minutes for Virtual Interim > > > > > > CAUTION: This is an external email. Please be very careful when clicking > > links or opening attachments. See the URL nok.it/ext <http://nok.it/ext> > > for additional information. > > > > > > Link to minutes: > > https://datatracker.ietf.org/doc/minutes-interim-2024-netmod-01-202401231400/ > > > > Reproduced below for convenience. > > > > Please report any updates needed here. > > > > Kent (and Lou) > > > > > > > > This virtual interim was soley focused on the "system-config" draft. > > Qiufang Ma presented. > > > > Draft: https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config > > > > In the course of two hours, there was a lot of discussion. So much so > > that trying to capture all the points verbatim would take too long. A > > link to the video is here: https://www.youtube.com/watch?v=sAF0fppqBGA. > > > > A high-level summary is: > > > > Qiufang's presentation focused on two main questions? > > > > 1) The "origin" issue. > > > > The WG agreed that nodes copied into should > > have origin "intended". The system-config draft will "update" > > RFC 8342 (NMDA) to state this. > > > > The WG agreed that data-migration is 1) not -specific > > concern and 2) is out-of-scope for this draft. > > > > 2) Validity of alone. > > > > The WG agreed to let 7950-bis "update" 8342 (NMDA) with the > > clarification the alone does not have to be valid. > > E.g., clients may have to perform transforms to calculate > > , which is subject to validation. > > > > The WG agreed on a new Option 4: this document doesn't say > > anything at all about the validity of . That is, > > fully rely on existing 7950 and 8342 statements. > > > > This leaves it up to interpretation. > > > > Templates and inactive configuration are nice for humans, but > > unnecessary for machine-to-machine interfaces. That is, the > > issues arounds such mechanisms are largely moot in environments > > using a controller. > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Is changing the type with union a BC change?
Different encodings keep different amounts of type information. The
RFC 7950 rules were written for the single encoding that did exist
when RFC 7950 was published (even though RFC 7951 was on the radar but
then the rules go back to RFC 6020 where we only had a stringified
representation of values). A great example how collections of well
intended extensions (or initial naiveness) results in technical
complexity.
/js
On Thu, Jan 18, 2024 at 03:58:57PM +, Reshad Rahman wrote:
> Hi Jason,
> I agree for the second case, and IIRC we did discuss that in the
> yang-module-versioning context.
> But the first case, I don't understand why it's NBC if there's a new type.
> Encodings of the OLD types wouldn't change?
> Regards,Reshad.
> On Thursday, January 18, 2024, 09:36:46 AM EST, Jason Sterne (Nokia)
> wrote:
>
>
> Hi guys,
>
>
>
> The second case is NBC. I remember wondering the same thing myself but the
> type in OLD is foo which the type in NEW is union. That is NBC (and in some
> encodings outside of XML, sending that leaf with type foo vs type union,
> member foo would be different).
>
>
>
> OLD
>
> type foo;
>
>
>
> NEW
>
> type union {
>
> type foo;
>
> type bar
>
> }
>
>
>
> The first case is NBC if the addition of the new member adds a new type to
> the list of members. So it depends on the underlying types of foo, bar and
> baz. If they were all strings, for example, then it is BC. But if foo and
> bar are “int” and then “baz” is a string, then adding that new member type
> into the union is NBC.
>
>
>
> Jason
>
>
>
> From: netmod On Behalf Of Jan Lindblad
> Sent: Thursday, January 18, 2024 5:13 AM
> To: Italo Busi
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Is changing the type with union a BC change?
>
>
>
> |
>
> |
> CAUTION: This is an external email. Please be very careful when clicking
> links or opening attachments. See the URL nok.it/ext for additional
> information.
> |
>
>
>
>
> Italo,
>
>
>
> Yes, this too would be BC according to the rules. There may be some
> situations where this kind of change might be disruptive in the real world,
> however, for example if you did this to a list key.
>
>
>
> Best Regards,
>
> /jan
>
>
>
>
>
>
>
>
> Thanks Jan
>
>
>
> Following the same logic, also the following change can be considered BC:
>
>
>
> OLD
>
> type foo;
>
>
>
> NEW
>
> type union {
>
> type foo;
>
> type bar
>
> }
>
>
>
> Is my understanding correct?
>
>
>
> Thanks again
>
>
>
> Italo
>
>
>
> From: Jan Lindblad
> Sent: giovedì 18 gennaio 2024 10:33
> To: Italo Busi
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Is changing the type with union a BC change?
>
>
>
> Italo,
>
>
>
> Yes, in my judgement this change should be considered BC according to YANG
> rules.
>
>
>
> Note that the BC concept is a sort of *agreement* between client and server
> implementors that determines what kind of changes a) are allowed + b) have to
> be tolerated. Even when things are BC, that does not guarantee that things
> will always keep interoperating properly.
>
>
>
> Best Regards,
>
> /jan
>
>
>
>
>
>
>
>
>
>
>
>
>
> On 17 Jan 2024, at 23:22, Italo Busi
> wrote:
>
>
>
> I have some questions/doubts about whether changing a type with union is a BC
> or NBC change
>
>
>
> For example, is the following change a BC or NBC change?
>
>
>
> OLD
>
> type union {
>
> type foo;
>
> type bar
>
> }
>
>
>
> NEW
>
> type union {
>
> type foo;
>
> type bar;
>
> type baz
>
> }
>
>
>
> Section 11 of RFC7950 is silent on this case although this change is
> expanding the allowed value space and therefore it looks like a BC change
>
>
>
> Thanks, Italo
>
>
>
>
>
> ___
> 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
--
Jürgen Schönwälder Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] [yang-doctors] Operational State usage of YANG choices and constraints
On Fri, Dec 22, 2023 at 07:22:55PM +, Kent Watsen wrote: > With limited experience wrt the impact on servers, as a client, it’s always > best for the opstate data to be modeled as accurately as possible, for better > processing and user experience. > What is accurate? I think the answer is "it depends". There are states that a model allows to represent and there are states it does not allow to represent. If a device ends up in a state that the model can't represent, then the device has a problem, From a debugging point of view, the worst is a device in a state that can't be represented propoerly reporting a valid state it is not in. So like everything else, it is a modeling decision, like picking types and everything else. I am not sure that 'as accurate as possible" is a helpful guideline; for operational state I prefer to see as much as possible the device's true state. (But even picking data types for leaves restricts what can be represented, so it is a judgement call.) /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] draft-ietf-netmod-rfc8407bis: must + error-message for "config false"
I think an important piece is missing here is, namely _who_ is doing the validation and who is in charge of keeping things valid. For config data, the server has the task to keep the config datastores valid (or more precisely the resulting intended configuration). For state data, if the server's state does not satisfy the constraints, then this is what the server's true state is. It is then at best a client's job to check whether a server's state is valid. (And then there are subtleties like whether it is at all feasible for a client to obtain a consistent snapshot of the server's state.) /js On Thu, Nov 16, 2023 at 09:33:05AM +, mohamed.boucad...@orange.com wrote: > Hi all, > > Thank you all for the feedback. > > Here is the text I suggest to capture the outcome of the discussion: > >Section 8.1 of [RFC7950] includes a provision for defining a >constraint on state data and specifies that the constraint must be >true in a valid state data. However, Section 5.3 of [RFC8342] soften >that behavior by allowing semantic constraints to be violated under >some circumstances to help detecting anomalies. Relaxing validation >constraints on state data is meant to reveal deviations of the >observed behavior vs. intended behavior of a managed entity and >hopefully trigger corrective actions by a management system. From >that perspective, it is RECOMMENDED to avoid defining constraints on >state data that would hinder the detection of abnormal behaviors of a >managed entity. > > Comments are still welcome. > > You can also proposed change here: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fboucadair%2Frfc8407bis%2Fpull%2F24%2Ffiles&data=05%7C01%7Cjschoenwae%40constructor.university%7C26abf6cf21c74491173d08dbe6871eeb%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C638357240241272993%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=js2FRW5aKEFjQCMqqOrM%2FjeRQ3hOu267C8hi6NkfGP4%3D&reserved=0 > > Thanks. > > Cheers, > Med > > > -Message d'origine----- > > De : netmod De la part de Kent Watsen > > Envoyé : mardi 7 novembre 2023 09:17 > > À : Jason Sterne (Nokia) > > Cc : Jürgen Schönwälder ; > > netmod@ietf.org; Rob Wilton (rwilton) > > > > Objet : Re: [netmod] draft-ietf-netmod-rfc8407bis: must + error- > > message for "config false" > > > > My confusion, sorry, I was thinking "mandatory". > > > > Must statements on opstate are useful, but less important. > > > > Kent > > > > > > > On Nov 6, 2023, at 5:26 PM, Kent Watsen wrote: > > > > > > "Must" statements on opstate usefully helps clients know when > > certain values will always appear, enabling better optimization and > > usability. > > > > > > E.g., for Syslog messages, there must always be a timestamp, > > severity, and a message. It would be unhelpful for the server to not > > declare its intention to always send these fields. > > > > > > Kent > > > > > > > > >> On Nov 6, 2023, at 10:49 AM, Jason Sterne (Nokia) > > wrote: > > >> > > >> +1 on what Jurgen and Rob are pointing out here. > > >> > > >> I'm not sure it makes a ton of sense to actually have a lot of > > "must" statements in state models. We could consider discouraging > > them? (but we need to continue *allowing* them). > > >> > > >> Jason > > >> > > >>> -Original Message- > > >>> From: netmod On Behalf Of Rob Wilton > > >>> (rwilton) > > >>> Sent: Thursday, November 2, 2023 5:17 AM > > >>> To: Jürgen Schönwälder ; > > >>> mohamed.boucad...@orange.com > > >>> Cc: netmod@ietf.org > > >>> Subject: Re: [netmod] draft-ietf-netmod-rfc8407bis: must + > > >>> error-message for "config false" > > >>> > > >>> > > >>> CAUTION: This is an external email. Please be very careful when > > >>> clicking links or opening attachments. See the URL nok.it/ext for > > >>> additional information. > > >>> > > >>> > > >>> > > >>> Specifically regarding MUST statements on state date, RFC 8342 > > >>> section 5.3, also has this statement (which effectively aligns to > > Jürgen's last paragraph): > > >>> > > >>> SHO
Re: [netmod] Updated Content of Module Versioning - T8 (recommended-min for imports)
If compilers can pick different revisions and this results in different interpretations of YANG definitions then thigns are broken. /js On Wed, Nov 15, 2023 at 10:30:49PM +, Jason Sterne (Nokia) wrote: > Hi all, > > A poll at IETF118 was roughly split on recommended-min. > > We discussed this in the weekly YANG versioning call and feel we should: > 1) keep recommended-min-date in the Module Versioning draft > 2) add recommended-min-label (or similar name) in the YANG Semver draft. > They would be mutually exclusive inside a single import statement. > > As defined in Module Versioning, the recommended-min is informational only. > Compilers/tools are not required to use the recommended-min as a constraint. > > We don't believe this causes any new incompatibility issues wrt RFC7950. > > RFC7950 section 5.1.1 says the following: > >If a module is not imported with a specific revision, it is undefined > which revision is used. > > So clients, servers and tools can pick whatever revision they want. Two > different tools may pick different revisions. > > In section 5.6.5 RFC7950 says the following: > >If a server lists a module C in the "/modules-state/module" list from >"ietf-yang-library" and there are other modules Ms listed that import >C without specifying the revision date of module C, the server MUST >use the definitions from the most recent revision of C listed for >modules Ms. > > Recommended-min does not affect conformance and is not mandatory. So a > server, toolchain, etc can continue to select the "most recent revision" even > if that revision is older than the recommended-min. > > Jason > > > > -Original Message- > > From: Jürgen Schönwälder > > Sent: Thursday, October 26, 2023 4:23 AM > > To: Andy Bierman > > Cc: Joe Clarke (jclarke) ; Jason Sterne > > (Nokia) ; netmod@ietf.org > > Subject: Re: [netmod] Updated Content of Module Versioning - T8 > > (recommended-min for imports) > > > > > > CAUTION: This is an external email. Please be very careful when clicking > > links or > > opening attachments. See the URL nok.it/ext for additional information. > > > > > > > > Well, yes, import-by-revision is broken. However, changing the way how > > imports work changes the YANG language. So it is important to know > > which version of the YANG language tools implement. For this we have > > language version numbers. > > > > /js > > > > On Wed, Oct 25, 2023 at 02:44:26PM -0700, Andy Bierman wrote: > > > On Wed, Oct 25, 2023 at 12:03 PM Joe Clarke (jclarke) > > 40cisco@dmarc.ietf.org> wrote: > > > > > > > This is the reason that, for me, I’d want the extension to be outside > > > > the > > > > description in something that is machine-readable. Tools that do > > > > understand this extension could make a better decision about which > > > > module > > > > revision to use. > > > > > > > > > > > > > > > > > > +1 > > > > > > The YANG author should know if their module depends on imported > > > definitions > > > from a specific revision. > > > IMO the min-revision is needed in this case, and SHOULD be present. > > > There is a big difference between "module will compile" and "module will > > > work as intended". > > > > > > Tools that do not understand the extension will resolve the import as they > > > > normally would, which may lead to a failure at compile time (e.g., for a > > > > missing node). > > > > > > > > > > This extension MUST be ignored if the 'revision-date' statement is present > > > in the import-stmt. > > > > > > > > > > > > > > Joe > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > *From: *netmod on behalf of Jürgen > > Schönwälder > > > > > > > > *Date: *Wednesday, October 25, 2023 at 14:45 > > > > *To: *Jason Sterne (Nokia) > > > > *Cc: *netmod@ietf.org > > > > *Subject: *Re: [netmod] Updated Content of Module Versioning - T8 > > > > (recommended-min for imports) > > > > > > > > I am strongly against this. The import statement is used by tools. > > > > Adding a recommendation for humans that existing and conforming tools > > >
Re: [netmod] draft-ietf-netmod-rfc8407bis: must + error-message for "config false"
Here is what RFC 7950 says: 7.5.4.1. The "error-message" Statement The "error-message" statement, which is optional, takes a string as an argument. If the constraint evaluates to "false", the string is passed as in the in NETCONF. Since state data is not (directly) modified by processing RPCs, which would carry the ? If the answer is 'none', then why define an for state data? My take has always been that operational state data should report as much as possible the true state of the device - even if the current state violates certain constraints. The entity to check constraints would be a managing system, not the managed system. That said, the wording in section 7.5.4.1 indicates that the designers had servers processing RPCs in mind. /js On Tue, Oct 31, 2023 at 10:40:15AM +, mohamed.boucad...@orange.com wrote: > Hi all, > > In the context of https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-yang/, > Dhruv has received in the past a comment about the use of "must + > error-message" for "config false" data nodes. He reported that comment at > https://mailarchive.ietf.org/arch/msg/yang-doctors/gWnXnyNHPVv_nZB1PQjThAwP1JY/, > but without any follow-up. > > rfc7950#section-8.1 includes a provision for the use of "must" for state > data, but silent about the use of error-message. Some guidance for authors > may be useful here. > > The following options are being considered: > > (1) Remove both must and error-message for config false data nodes > (2) Remove error-message but keep the must > (3) keep both > > I think that (3) is OK as this is a formal way to detect anomalies in state > data, but I'm open to hear what the WG thinks. > > Opinions whether we need to include a mention about this in > draft-ietf-netmod-rfc8407bis are welcome. > > Thank you. > > Cheers, > Med > > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] MUST offline-validation of alone be required? possible solution and further discussion
RFC 8342 has relevant information, including some MUSTs and SHOULDs. /js On Thu, Oct 26, 2023 at 07:49:06AM +, maqiufang (A) wrote: > Hi, all > > I want to bring up a key issue that has been discussed before but hasn't > really been agreed upon: MUST offline-validation of alone be > required? > > The question behind this issue is about: must referenced system config always > be copied into to satisfy referential integrity constraints, or > is implicitly valid if is valid by merging and > (after config transformation like removal of inactive config and > expansion of templates) to create its contents, alone doesn't have > to be offline valid. > > It feels like the WG has a mixed viewpoints, and I would like to find a > solution and seek convergence here. Actually I am thinking, instead of > directly stating in the draft that any referenced system config must be > contained in , we can point to RFC 7950 and RFC 8342 and state that > MUST always be a valid configuration data tree. So that we just > leave it there and interpretations may vary. Anyway, the client can always > explicitly copy referenced system config into or use the > "resolve-system" parameter if an offline-validation of is needed. > > If we can reach an agreement on this handling, I believe then we can move on. > > One the other side, I also understand that we should not shy away from this > issue and need effectively work it out. Below are some thoughts and inputs > from the WG: > > > * Yes, alone must be offline valid > > o Pros > > ? Clients can easily offline validate without offline merging > and (which would bring extra complexity to clients) > > o Cons: > > ? Painful copy is needed. > > ? Need to deal with the scenario where the system config has updated and a > stale copy is still in > > * No, Offline validation of MAY consider other datastores > as well, two options: > > o Treat it as a bug-fix in existing RFCs > > ? Cons: might break legacy clients and existing tool chains > > o Wait for a new version of YANG/NC/RC > > ? Cons: might incur delay > > Any further thoughts on this? Comments and suggestions would be much > appreciated. > > > Best Regards, > Qiufang > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Updated Content of Module Versioning - T8 (recommended-min for imports)
Well, yes, import-by-revision is broken. However, changing the way how imports work changes the YANG language. So it is important to know which version of the YANG language tools implement. For this we have language version numbers. /js On Wed, Oct 25, 2023 at 02:44:26PM -0700, Andy Bierman wrote: > On Wed, Oct 25, 2023 at 12:03 PM Joe Clarke (jclarke) 40cisco@dmarc.ietf.org> wrote: > > > This is the reason that, for me, I’d want the extension to be outside the > > description in something that is machine-readable. Tools that do > > understand this extension could make a better decision about which module > > revision to use. > > > > > > > > +1 > > The YANG author should know if their module depends on imported definitions > from a specific revision. > IMO the min-revision is needed in this case, and SHOULD be present. > There is a big difference between "module will compile" and "module will > work as intended". > > Tools that do not understand the extension will resolve the import as they > > normally would, which may lead to a failure at compile time (e.g., for a > > missing node). > > > > This extension MUST be ignored if the 'revision-date' statement is present > in the import-stmt. > > > > > > Joe > > > > Andy > > > > > > > > *From: *netmod on behalf of Jürgen Schönwälder > > > > *Date: *Wednesday, October 25, 2023 at 14:45 > > *To: *Jason Sterne (Nokia) > > *Cc: *netmod@ietf.org > > *Subject: *Re: [netmod] Updated Content of Module Versioning - T8 > > (recommended-min for imports) > > > > I am strongly against this. The import statement is used by tools. > > Adding a recommendation for humans that existing and conforming tools > > will not understand just causes confusion. > > > > /js > > > > On Wed, Oct 25, 2023 at 06:41:19PM +, Jason Sterne (Nokia) wrote: > > > Hi all, > > > > > > Starting a dedicated thread for T8 recommended-min for imports > > > > > > These are my own personal opinions (not those of the > > authors/contributors). > > > > > > It has been discussed before that import by a specific revision is > > somewhat broken (not recommended). It is mentioned in section 2.5 of the > > versioning requirements draft: > > https://www.ietf.org/archive/id/draft-ietf-netmod-yang-versioning-reqs-08.html#name-no-good-way-to-specify-whic > > > > > > Based on previous WG LC discussions, we already changed from a > > revision-or-derived extension (that did affect conformance & what a tool > > could/should use), to a weaker recommended-min in order to avoid further > > changes to the YANG language & conformance rules. The recommended-min is > > pretty much purely a documentation tag that helps users of the modules > > understand what versions of imports might be best to use (e.g. when > > supporting multiple modules in a server, or constructing a "package" of > > modules that work together). > > > > > > We could instead just say to put this information into a description > > field in the module. But it is helpful if the field is broken out (i.e. > > structured data) and more easily machine readable. > > > > > > So I'd like to see this stay as part of Module Versioning but be renamed > > to recommended-min-date. Then in YANG Semver we should add > > recommended-min-semver-label. > > > > > > Jason > > > > > > > > > From: netmod On Behalf Of Jason Sterne (Nokia) > > > Sent: Tuesday, October 24, 2023 9:58 AM > > > To: netmod@ietf.org > > > Subject: [netmod] Updated Content of Module Versioning > > > > > > Hello NETMOD WG, > > > > > > The YANG versioning authors and weekly call group members have been > > discussing the next steps for the versioning drafts. > > > > > > We'd propose that the first step is to converge on what aspects of the > > current Module Versioning draft should be retained, and which parts should > > be removed. We can then work towards a final call on an updated version > > with this revised scope. > > > > > > Below is a summary of the main topics in the Module Versioning draft. > > We've divided the items T1-T10 into 2 groups: > > > A) Baseline content of Module Versioning > > > B) Items which need more WG discussion > > > > > > In addition to whatever discussions happen on this email list, we have > > also created a hedgedoc where you c
Re: [netmod] Updated Content of Module Versioning - T8 (recommended-min for imports)
See draft-schoenw-netmod-yang-relaxed-versioning-00.txt. A proper solution without bumping the YANG version number is impossible. If the YANG version number can't be touched, then all you can do is to document the NBC changes - and wait for a YANG next project to fix the rest. /js On Wed, Oct 25, 2023 at 06:51:12PM +, Jason Sterne (Nokia) wrote: > Can you clarify what you'd recommend then if we don't have it? > > For example: > - IETF module A needs to import ietf-yang-types to use hex-string (only > added in the 2013-07-15 version) > > Use import but without a revision substatement? (i.e. avoid import by > specific revision)? > > Add something to the description of module A to mention it needs at least > 2013-07-15? > > Jason > > > -Original Message- > > From: Jürgen Schönwälder > > Sent: Wednesday, October 25, 2023 2:45 PM > > To: Jason Sterne (Nokia) > > Cc: netmod@ietf.org > > Subject: Re: [netmod] Updated Content of Module Versioning - T8 > > (recommended-min for imports) > > > > > > CAUTION: This is an external email. Please be very careful when clicking > > links or opening attachments. See the URL nok.it/ext for additional > > information. > > > > > > > > I am strongly against this. The import statement is used by tools. > > Adding a recommendation for humans that existing and conforming tools > > will not understand just causes confusion. > > > > /js > > > > On Wed, Oct 25, 2023 at 06:41:19PM +, Jason Sterne (Nokia) wrote: > > > Hi all, > > > > > > Starting a dedicated thread for T8 recommended-min for imports > > > > > > These are my own personal opinions (not those of the > > authors/contributors). > > > > > > It has been discussed before that import by a specific revision is > > somewhat broken (not recommended). It is mentioned in section 2.5 of the > > versioning requirements draft: https://www.ietf.org/archive/id/draft-ietf- > > netmod-yang-versioning-reqs-08.html#name-no-good-way-to-specify-whic > > > > > > Based on previous WG LC discussions, we already changed from a > > revision-or-derived extension (that did affect conformance & what a tool > > could/should use), to a weaker recommended-min in order to avoid further > > changes to the YANG language & conformance rules. The recommended- > > min is pretty much purely a documentation tag that helps users of the > > modules understand what versions of imports might be best to use (e.g. > > when supporting multiple modules in a server, or constructing a "package" > > of modules that work together). > > > > > > We could instead just say to put this information into a description > > > field in > > the module. But it is helpful if the field is broken out (i.e. structured > > data) > > and more easily machine readable. > > > > > > So I'd like to see this stay as part of Module Versioning but be renamed > > > to > > recommended-min-date. Then in YANG Semver we should add > > recommended-min-semver-label. > > > > > > Jason > > > > > > > > > From: netmod On Behalf Of Jason Sterne > > (Nokia) > > > Sent: Tuesday, October 24, 2023 9:58 AM > > > To: netmod@ietf.org > > > Subject: [netmod] Updated Content of Module Versioning > > > > > > Hello NETMOD WG, > > > > > > The YANG versioning authors and weekly call group members have been > > discussing the next steps for the versioning drafts. > > > > > > We'd propose that the first step is to converge on what aspects of the > > current Module Versioning draft should be retained, and which parts should > > be removed. We can then work towards a final call on an updated version > > with this revised scope. > > > > > > Below is a summary of the main topics in the Module Versioning draft. > > We've divided the items T1-T10 into 2 groups: > > > A) Baseline content of Module Versioning > > > B) Items which need more WG discussion > > > > > > In addition to whatever discussions happen on this email list, we have > > > also > > created a hedgedoc where you can register your preference for items T7- > > T10. It would be much appreciated if you can put your opinion in the > > hedgedoc here: > > > https://notes.ietf.org/CdKrT5kVSF6qbnRSY4KeSA?both > > > > > > > > > GROUP A (Baseline content of Module Vesioning) > > > --
Re: [netmod] Updated Content of Module Versioning - T7 (Filename changes)
I strongly disagree. You can add additional file names, you can't soften the existing SHOULD to a conditional SHOULD. /js On Wed, Oct 25, 2023 at 06:45:31PM +, Jason Sterne (Nokia) wrote: > Sure - I'd be OK with adding some wording here that makes it clear the 7950 > recommendation remains. > > i.e. you SHOULD use my-module@2023-01-06 as per 7950, but if you elect to not > use that format, and want to use a label in the filename, then this format is > RECOMMENDED: my-module#3.0.2.yang. > > I can see that 'primary identifier' isn't great. Maybe something more like > "to uniquely identify the version of the module" or similar. > > Jason > > > -Original Message- > > From: Jürgen Schönwälder > > Sent: Wednesday, October 25, 2023 2:32 PM > > To: Jason Sterne (Nokia) > > Cc: netmod@ietf.org > > Subject: Re: [netmod] Updated Content of Module Versioning - T7 > > (Filename changes) > > > > > > CAUTION: This is an external email. Please be very careful when clicking > > links or opening attachments. See the URL nok.it/ext for additional > > information. > > > > > > > > It needs to be clear that the existing text in section 5.2 remains > > untouched. > > > >YANG modules and submodules are typically stored in files, one > >"module" or "submodule" statement per file. The name of the file > >SHOULD be of the form: > > > > module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' ) > > > >"module-or-submodule-name" is the name of the module or submodule, > >and the optional "revision-date" is the latest revision of the module > >or submodule, as defined by the "revision" statement (Section 7.1.9). > > > > Words like 'primary identifier' confuse me. > > > > /js > > > > On Wed, Oct 25, 2023 at 06:22:57PM +, Jason Sterne (Nokia) wrote: > > > Hi all, > > > > > > Starting a dedicated thread for T7 Filename changes. > > > > > > These are my own personal opinions (not those of the > > authors/contributors). > > > > > > RFC7950 says that the filename format SHOULD be my-module@2023-01- > > 06.yang<mailto:my-mod...@2023-01-06.yang> > > > > > > Module versioning currently says the following format is RECOMMENDED > > (if the file has a revision label): my-module#3.1.2.yang > > > > > > I'd recommend we remove that from Module Versioning, but add it to the > > YANG Semver draft (where all revision label text will be located - it is all > > being removed from Module Versioning). > > > > > > We could potentially say it more like this: > > > > > > If a revision has an associated yang-semver-label, and if the publisher > > > wishes to use the label in the filename as the primary identifier for the > > > version of the module instead of the revision date, then it is > > > RECOMMENDED to put the yang-semver-label into the filename as > > follows: > > > > > > module-or-submodule-name ['#' yang-semver-label] ( '.yang' / '.yin' ) > > > > > >E.g., acme-router-module#2.0.3.yang > > > > > > YANG module (or submodule) files may be identified using either the > > > revision-date (as per [RFC8407] section 3.2) or the revision label. > > > > > > If we don't at least have a recommendation (*if* people really want to put > > the label in the filename), then we might have different organizations using > > different formats: > > > > > > * org #1: my-mod...@2.0.3.yang<mailto:my-mod...@2.0.3.yang> > > > * org#2:my-module#2@2023-01-06.yang<mailto:my- > > module#2@2023-01-06.yang> > > > * org#3:my-module%2.0.3.yang > > > * org#4:my-module(2.0.3).yang > > > > > > I'm trying to find wording that doesn't strongly mandate the my- > > module#2.0.3.yang filename format, but does highly recommend it *if* > > someone is going to put a label in the filename somewhere. > > > > > > Jason > > > > > > > > > From: netmod On Behalf Of Jason Sterne > > (Nokia) > > > Sent: Tuesday, October 24, 2023 9:58 AM > > > To: netmod@ietf.org > > > Subject: [netmod] Updated Content of Module Versioning > > > > > > Hello NETMOD WG, > > > > >
Re: [netmod] Updated Content of Module Versioning - T8 (recommended-min for imports)
modules, and hence the revision-label-scheme extension will > be removed from this draft. > > T4. revision-label extension (Sec 3.4) > Removed. Related to T3 above, given that a single versioning scheme is > sufficient, the revision-label extension will be moved to the YANG Semver > draft, and removed from Module Versioning. > > T5. Resolving ambiguous imports in YANG library (Sec 5.1) > Removed. This will be removed from Module Versioning (could be considered in > YANG Next, although that is many years away). Note, RFC 7950, section 5.6.5, > paragraph 5 does consistently define how to build the schema. The change in > the draft was to always prioritise an implemented module over the most recent > implemented *or* import-only revision. But this will be removed. > > T6. Advertisement for how deprecated & obsolete nodes are handled (Sec 5.2.2) > Retained. This information is important for clients to be able to accurately > construct the schema and hence it is retained in Module Versioning. > > GROUP B (Needs WG discussion) > --- > For these items we don't have consensus within the WG - they need more > discussion and input. > > It is recommended to go back and look at the NETMOD emails on these topics > (from the WG LC discussions). > > Please add your name beside your preferred option in the poll: > https://notes.ietf.org/CdKrT5kVSF6qbnRSY4KeSA?both > > T7. filename changes (Sec 3.4.1) > The authors/contributors are leaning towards suggesting that this moved > change be moved to YANG Next consideration. However, there isn't complete > consensus, with concerns that the vendors will each define their own > incompatible file naming schemes for YANG modules that use version numbers. > If we retain this work then this would likely move to the YANG Semver draft. > [See hedgedoc poll T7] > > T8. recommended-min for imports (Sec 4) > The WG seems to be somewhat split on how urgent this is, and there isn't > consensus amongst authors/contributors for retaining this work or deferring > it. One option is to keep it, but renamed as recommended-min-date. > [See hedgedoc poll T8] > > T9. Versioning of YANG instance data (Sec 6) > There wasn't any consensus among the authors/contributors as to whether this > should be retained or deferred to a new version of the YANG instance data > document. > [See hedgedoc poll T9] > > T10. Do *all* whitespace changes (including whitespace between statements) > require a new revision to be published? Sec 3.1, last paragraph. > The authors/contributors are somewhat split on whether to retain this. The > advantage of keeping this is that it makes it very easy to check (i.e., via a > simple text diff tool) whether two modules pertaining to be the same version > are in fact the same. It should also mean that it is easy to generate a > hash-based fingerprint of a module revision. The alternative gives more > flexibility to users to reformat modules (e.g., for different line-lengths), > but complicates the check to ensure that a YANG module revision hasn't been > changed or makes it slightly more expensive to generate a hash since the > module formatting would need to be normalized first. > [See hedgedoc poll T10] > > Jason (he/him) > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Updated Content of Module Versioning - T7 (Filename changes)
aft changes RFC 7950 so that marking a data node as obsolete is an > NBC change because it can break clients. > (ii) "extensions" > - This draft changes the RFC 7950 rules to allow extensions to define the > backwards compatibility considerations for the extension itself. The > existing RFC 7950 rules only allow extensions to be added, not changed or > removed. > (iii) "import by revision-date" > - This draft changes the RFC 7950 rules to allow the revision date of an > import-statement to be changed/added/removed. The imported module must be > versioned separately (i.e., by a YANG package/library defining the schema). > (iv) "whitespace": > - This draft clarifies the existing RFC 7950 behaviour that changing > insignificant whitespace is classified as a backwards compatible change > > T3. revision-label-scheme extension (Sec 3.4.2) > Removed. Based on WG LC discussions we will go back to a single versioning > scheme for YANG modules, and hence the revision-label-scheme extension will > be removed from this draft. > > T4. revision-label extension (Sec 3.4) > Removed. Related to T3 above, given that a single versioning scheme is > sufficient, the revision-label extension will be moved to the YANG Semver > draft, and removed from Module Versioning. > > T5. Resolving ambiguous imports in YANG library (Sec 5.1) > Removed. This will be removed from Module Versioning (could be considered in > YANG Next, although that is many years away). Note, RFC 7950, section 5.6.5, > paragraph 5 does consistently define how to build the schema. The change in > the draft was to always prioritise an implemented module over the most recent > implemented *or* import-only revision. But this will be removed. > > T6. Advertisement for how deprecated & obsolete nodes are handled (Sec 5.2.2) > Retained. This information is important for clients to be able to accurately > construct the schema and hence it is retained in Module Versioning. > > GROUP B (Needs WG discussion) > --- > For these items we don't have consensus within the WG - they need more > discussion and input. > > It is recommended to go back and look at the NETMOD emails on these topics > (from the WG LC discussions). > > Please add your name beside your preferred option in the poll: > https://notes.ietf.org/CdKrT5kVSF6qbnRSY4KeSA?both > > T7. filename changes (Sec 3.4.1) > The authors/contributors are leaning towards suggesting that this moved > change be moved to YANG Next consideration. However, there isn't complete > consensus, with concerns that the vendors will each define their own > incompatible file naming schemes for YANG modules that use version numbers. > If we retain this work then this would likely move to the YANG Semver draft. > [See hedgedoc poll T7] > > T8. recommended-min for imports (Sec 4) > The WG seems to be somewhat split on how urgent this is, and there isn't > consensus amongst authors/contributors for retaining this work or deferring > it. One option is to keep it, but renamed as recommended-min-date. > [See hedgedoc poll T8] > > T9. Versioning of YANG instance data (Sec 6) > There wasn't any consensus among the authors/contributors as to whether this > should be retained or deferred to a new version of the YANG instance data > document. > [See hedgedoc poll T9] > > T10. Do *all* whitespace changes (including whitespace between statements) > require a new revision to be published? Sec 3.1, last paragraph. > The authors/contributors are somewhat split on whether to retain this. The > advantage of keeping this is that it makes it very easy to check (i.e., via a > simple text diff tool) whether two modules pertaining to be the same version > are in fact the same. It should also mean that it is easy to generate a > hash-based fingerprint of a module revision. The alternative gives more > flexibility to users to reformat modules (e.g., for different line-lengths), > but complicates the check to ensure that a YANG module revision hasn't been > changed or makes it slightly more expensive to generate a hash since the > module formatting would need to be normalized first. > [See hedgedoc poll T10] > > Jason (he/him) > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)
Jan, I need to see the text. Using the existing versioning draft as a base for this minimal solution scares me since this document went over board. I need to see the text that details in which situations an NBC change is allowed. I need to see the definition of the extension to mark NBC changes. Only then I can tell whether we made progress. If the WG does draft-schoenw-netmod-yang-relaxed-versioning-00 without the import statement change (section 2), which was the reason to bump the YANG language version number, then I am OK. /js On Tue, Oct 03, 2023 at 05:06:42PM +, Jan Lindblad (jlindbla) wrote: > Jürgen, > > Thanks for the clarifications. It seems to me we're in complete agreement > here. > > Here are the use cases I can think of: > a) Tools that don't care about modules being backwards-compatible are fine. > They will see good-old 7950 and 6020 YANG modules which are supposed to be > backwards compatible, but sometimes are not. Occasionally they will see an > unknown extension statement that they ignore. > b) Tools which flag YANG modules that are not backwards compatible and are > unaware of the extension statement will flag all incompatibilities as errors. > Not ideal, but an uncommon case that is pretty easy to handle in practice. > c) Tools which flag YANG modules that are not backwards compatible and are > *aware* of the extension statement will flag incompatibilities without proper > markup as errors, and allow the rest. This is great. > d) 7950 and 6020 module authors are (theoretically) bound by the strict sec > 11 and sec 10 backwards compatibility rules, like today. > e) Module authors that need to introduce backwards incompatible changes may > do so provided some appropriate extension statement defined in an upcoming > document is applied. > > To me, this makes sense. If it does to you too, Jürgen, that would certainly > make me happy. > > Best Regards, > /jan > > > > > On 2 Oct 2023, at 18:06, Jürgen Schönwälder > wrote: > > RFC 7950 is clear that extensions must be designed such that they can > be ignored by YANG parsers and tools. > > If you use 'mandatory, are you talking about 'mandatory' in an RFC > 8407 sense (and not in an YANG language sense)? The difference here is > between 'mandatory to use by module authors' versus 'mandatory to be > understood by tools'. > > /js > > On Mon, Oct 02, 2023 at 03:52:00PM +, Jason Sterne (Nokia) wrote: > Hi guys, > > I think we'll need to be concrete about exactly which parts/extensions in > Module Versioning we're talking about. And it will likely be a slightly > different debate/discussion for each one. > > I think the top level rev:non-backwards-compatible extension (and it being > mandatory) is important to bundle in with the NBC rule change to SHOULD NOT. > > The rev:recommended-min is useful IMO but may not be critical to include & > bundle into the first versioning RFC. I still think it is useful for the YANG > ecosystem to have this though. > > In Key Issue #2 we've raised the question about the rev:revision-label-scheme > already. > > We should probably discuss each of these different & separate ideas/concepts > in individual threads though.. > > Jason > > -Original Message- > From: Jürgen Schönwälder > Sent: Monday, October 2, 2023 11:45 AM > To: Jan Lindblad (jlindbla) > Cc: Jason Sterne (Nokia) ; Kent Watsen > ; netmod@ietf.org > Subject: Re: [netmod] YANG Versioning: discussion around 7950 bis or errata > (from Key Issue #1) > > > CAUTION: This is an external email. Please be very careful when clicking > links or > opening attachments. See the URL nok.it/ext for additional information. > > > > Jan, > > I am certainly not against documenting NBC changes. This can be done > using extension statements. Whether such extensions are defined in the > same document or not at the end is a procedural question. > > That said, any extensions that go beyond something that can be safely > ignored (e.g., extensions that for example influence how imports are > resolved) do for me require a new YANG language version. It would help > if people could acknowledge that we have agreement on this. Otherwise, > I fear that we may repeat the same discussion we had again several > months later. > > /js > > On Mon, Oct 02, 2023 at 02:34:31PM +, Jan Lindblad (jlindbla) wrote: > Jürgen, WG, > > I agree that a document that updates 7950 would be the preferred solution > here, rather than a bis or errata. > > I'm quite attracted, however, by the idea to bundle the softening of 7950 with > the requirement to
Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)
RFC 7950 is clear that extensions must be designed such that they can be ignored by YANG parsers and tools. If you use 'mandatory, are you talking about 'mandatory' in an RFC 8407 sense (and not in an YANG language sense)? The difference here is between 'mandatory to use by module authors' versus 'mandatory to be understood by tools'. /js On Mon, Oct 02, 2023 at 03:52:00PM +, Jason Sterne (Nokia) wrote: > Hi guys, > > I think we'll need to be concrete about exactly which parts/extensions in > Module Versioning we're talking about. And it will likely be a slightly > different debate/discussion for each one. > > I think the top level rev:non-backwards-compatible extension (and it being > mandatory) is important to bundle in with the NBC rule change to SHOULD NOT. > > The rev:recommended-min is useful IMO but may not be critical to include & > bundle into the first versioning RFC. I still think it is useful for the YANG > ecosystem to have this though. > > In Key Issue #2 we've raised the question about the rev:revision-label-scheme > already. > > We should probably discuss each of these different & separate ideas/concepts > in individual threads though.. > > Jason > > > -Original Message- > > From: Jürgen Schönwälder > > Sent: Monday, October 2, 2023 11:45 AM > > To: Jan Lindblad (jlindbla) > > Cc: Jason Sterne (Nokia) ; Kent Watsen > > ; netmod@ietf.org > > Subject: Re: [netmod] YANG Versioning: discussion around 7950 bis or errata > > (from Key Issue #1) > > > > > > CAUTION: This is an external email. Please be very careful when clicking > > links or > > opening attachments. See the URL nok.it/ext for additional information. > > > > > > > > Jan, > > > > I am certainly not against documenting NBC changes. This can be done > > using extension statements. Whether such extensions are defined in the > > same document or not at the end is a procedural question. > > > > That said, any extensions that go beyond something that can be safely > > ignored (e.g., extensions that for example influence how imports are > > resolved) do for me require a new YANG language version. It would help > > if people could acknowledge that we have agreement on this. Otherwise, > > I fear that we may repeat the same discussion we had again several > > months later. > > > > /js > > > > On Mon, Oct 02, 2023 at 02:34:31PM +, Jan Lindblad (jlindbla) wrote: > > > Jürgen, WG, > > > > > > I agree that a document that updates 7950 would be the preferred solution > > here, rather than a bis or errata. > > > > > > I'm quite attracted, however, by the idea to bundle the softening of 7950 > > > with > > the requirement to document any incompatibilities introduced. This way, we > > get > > something useful back as we provide the needed flexibility. This is > > something I > > would have an easy time to explain to YANG practitioners, and it seems > > pragmatic > > to me. > > > > > > I agree completely that YANG extensions cannot change YANG at all for > > > clients > > that are not in on them. In the key issue #1 debate, however, I believe most > > people agreed that we should allow non-backwards compatible changes to some > > degree. To also require that any such non-backwards compatible changes are > > documented using an extension statement is not to muddy the waters in my > > opinion. Quite the contrary, actually. People's understanding of what's > > going on > > will likely be improved by this requirement, for clients and server > > implementors > > alike. > > > > > > We can certainly discuss the pros and cons of requiring users to document > > > their > > non-backwards compatible changes once we have the key issue #1 behind us. > > > > > > Best Regards, > > > /jan > > > > > > > > > On 29 Sep 2023, at 07:45, Jürgen Schönwälder > > wrote: > > > > > > Jason, > > > > > > the must/should change is technically a change of the language. We can > > > do a short RFC to do that so that we get unstuck and oour AD allows us > > > again to publish YANG modules where bug fixes or alignment with other > > > modeled technologies is desirable. > > > > > > Adding decorations that can be ignored is something one can do with > > > YANG extensions. However, once such extensions change the behaviour > > > of YANG lang
Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)
Jan, I am certainly not against documenting NBC changes. This can be done using extension statements. Whether such extensions are defined in the same document or not at the end is a procedural question. That said, any extensions that go beyond something that can be safely ignored (e.g., extensions that for example influence how imports are resolved) do for me require a new YANG language version. It would help if people could acknowledge that we have agreement on this. Otherwise, I fear that we may repeat the same discussion we had again several months later. /js On Mon, Oct 02, 2023 at 02:34:31PM +, Jan Lindblad (jlindbla) wrote: > Jürgen, WG, > > I agree that a document that updates 7950 would be the preferred solution > here, rather than a bis or errata. > > I'm quite attracted, however, by the idea to bundle the softening of 7950 > with the requirement to document any incompatibilities introduced. This way, > we get something useful back as we provide the needed flexibility. This is > something I would have an easy time to explain to YANG practitioners, and it > seems pragmatic to me. > > I agree completely that YANG extensions cannot change YANG at all for clients > that are not in on them. In the key issue #1 debate, however, I believe most > people agreed that we should allow non-backwards compatible changes to some > degree. To also require that any such non-backwards compatible changes are > documented using an extension statement is not to muddy the waters in my > opinion. Quite the contrary, actually. People's understanding of what's going > on will likely be improved by this requirement, for clients and server > implementors alike. > > We can certainly discuss the pros and cons of requiring users to document > their non-backwards compatible changes once we have the key issue #1 behind > us. > > Best Regards, > /jan > > > On 29 Sep 2023, at 07:45, Jürgen Schönwälder > wrote: > > Jason, > > the must/should change is technically a change of the language. We can > do a short RFC to do that so that we get unstuck and oour AD allows us > again to publish YANG modules where bug fixes or alignment with other > modeled technologies is desirable. > > Adding decorations that can be ignored is something one can do with > YANG extensions. However, once such extensions change the behaviour > of YANG language constructs, we get into muddy waters. > > I prefer to clearly separate changes of the language from additional > decorations that can be ignored and do not influence the behaviour of > YANG implementations (i.e., they can be ignored). > > /js > > On Thu, Sep 28, 2023 at 08:57:42PM +, Jason Sterne (Nokia) wrote: > Hi all, > > IMO - We've already started moving out of the "stuck" situation. We no longer > have to debate whether a new YANG 1.2 is needed for allowing an NBC change. > That will be the end of a big distraction and circular discussions for the WG. > > I'm not so convinced we want to rush and do a separate RFC just for that one > part of Module Versioning (and one part of the original versioning > requirements). It is a key/critical part, but we should continue discussing > what other parts we'd want to also tackle as part of the "first" versioning > RFC. > > I'm very doubtful we should relax MUST to SHOULD NOT without also at least > making the rev:non-backwards-compatible marker mandatory (as per Module > Versioning). The marking is a key part of making this all better for > consumers of modules and clients (one of the main problems is the current > silent NBC changes happening). > > We should also clarify that marking an element as "status obsolete" is NBC. > That has major impact on clients who are trying to continue using an old > version of the module. > > (and there are likely at least a few other pieces from Module Versioning that > should be in a "first" RFC) > > Jason > > -Original Message- > From: netmod On Behalf Of Jürgen Schönwälder > Sent: Thursday, September 28, 2023 9:12 AM > To: Reshad Rahman > Cc: Kent Watsen ; netmod@ietf.org > Subject: Re: [netmod] YANG Versioning: discussion around 7950 bis or errata > (from Key Issue #1) > > > CAUTION: This is an external email. Please be very careful when clicking > links or > opening attachments. See the URL nok.it/ext for additional information. > > > > The truth is that we did bug fixes in the past. We now have maneuvered > us into a situation where work is put on hold because we do not even > do bug fixes anymore (and yes, I know, the line between bug fixes, > alignment with moving targets and other chan
Re: [netmod] [Editorial Errata Reported] RFC6991 (7647)
On Mon, Oct 02, 2023 at 02:20:04PM +, Rob Wilton (rwilton) wrote: > > Hence my proposal is to reject this erratum, but perhaps Jürgen you can > update your copy of rfc-6991bis to make these consistent please? And yes, I > appreciate that I need to finish processing my AD review of your doc. > I have removed all prefixes from type statement arguments that refer to locally defined types. /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)
Jason, the must/should change is technically a change of the language. We can do a short RFC to do that so that we get unstuck and oour AD allows us again to publish YANG modules where bug fixes or alignment with other modeled technologies is desirable. Adding decorations that can be ignored is something one can do with YANG extensions. However, once such extensions change the behaviour of YANG language constructs, we get into muddy waters. I prefer to clearly separate changes of the language from additional decorations that can be ignored and do not influence the behaviour of YANG implementations (i.e., they can be ignored). /js On Thu, Sep 28, 2023 at 08:57:42PM +, Jason Sterne (Nokia) wrote: > Hi all, > > IMO - We've already started moving out of the "stuck" situation. We no longer > have to debate whether a new YANG 1.2 is needed for allowing an NBC change. > That will be the end of a big distraction and circular discussions for the WG. > > I'm not so convinced we want to rush and do a separate RFC just for that one > part of Module Versioning (and one part of the original versioning > requirements). It is a key/critical part, but we should continue discussing > what other parts we'd want to also tackle as part of the "first" versioning > RFC. > > I'm very doubtful we should relax MUST to SHOULD NOT without also at least > making the rev:non-backwards-compatible marker mandatory (as per Module > Versioning). The marking is a key part of making this all better for > consumers of modules and clients (one of the main problems is the current > silent NBC changes happening). > > We should also clarify that marking an element as "status obsolete" is NBC. > That has major impact on clients who are trying to continue using an old > version of the module. > > (and there are likely at least a few other pieces from Module Versioning that > should be in a "first" RFC) > > Jason > > > -Original Message- > > From: netmod On Behalf Of Jürgen Schönwälder > > Sent: Thursday, September 28, 2023 9:12 AM > > To: Reshad Rahman > > Cc: Kent Watsen ; netmod@ietf.org > > Subject: Re: [netmod] YANG Versioning: discussion around 7950 bis or errata > > (from Key Issue #1) > > > > > > CAUTION: This is an external email. Please be very careful when clicking > > links or > > opening attachments. See the URL nok.it/ext for additional information. > > > > > > > > The truth is that we did bug fixes in the past. We now have maneuvered > > us into a situation where work is put on hold because we do not even > > do bug fixes anymore (and yes, I know, the line between bug fixes, > > alignment with moving targets and other changes is vague and needs to > > be decided on a case by case basis). The fastest way to get unstuck is > > to write this one page content RFC that changes MUST to SHOULD and > > then we at least get out of the being stuck situation. > > > > /js > > > > On Thu, Sep 28, 2023 at 01:00:23PM +, Reshad Rahman wrote: > > > As a client (consumer of models), I do not want only the MUST -> SHOULD > > change, IMO that would be worse than the current situation. > > > Regards,Reshad. > > > On Wednesday, September 27, 2023, 09:16:10 PM EDT, Kent Watsen > > wrote: > > > > > > This was my thought as well, that it would be best to have the > > > smallest-possible > > draft update 6020/7950. That way, when someone follows the “Updated” links, > > they’re not overloaded with material that could’ve been left out. > > > Jason was saying that just doing MUST/SHOULD by alone isn’t great, that at > > least the "rev:non-backwards-compatible” extension statement should be > > included and, by extension I suppose, the rules for editing the revision > > history. > > Presumably revision labels could be left out. IDK what minimal is possible. > > > K. // contributor > > > > > > > > > > > > On Sep 27, 2023, at 7:06 PM, Rodney Cummings > > wrote: > > > > > > > > > It is easy to write a short RFC updating RFC 7950, changing one sentence > > > from > > MUST to SHOULD. > > > > > > > > > I agree. I found that I cannot enter a response to the poll, because I > > > disagree > > with both Option 1 and Option 2. > > > > > > My concern is that there are many people out there who are implementing > > YANG, but who do not follow discussions on this mailing list. I'm concerned > > that > > there is a
Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)
The truth is that we did bug fixes in the past. We now have maneuvered
us into a situation where work is put on hold because we do not even
do bug fixes anymore (and yes, I know, the line between bug fixes,
alignment with moving targets and other changes is vague and needs to
be decided on a case by case basis). The fastest way to get unstuck is
to write this one page content RFC that changes MUST to SHOULD and
then we at least get out of the being stuck situation.
/js
On Thu, Sep 28, 2023 at 01:00:23PM +, Reshad Rahman wrote:
> As a client (consumer of models), I do not want only the MUST -> SHOULD
> change, IMO that would be worse than the current situation.
> Regards,Reshad.
> On Wednesday, September 27, 2023, 09:16:10 PM EDT, Kent Watsen
> wrote:
>
> This was my thought as well, that it would be best to have the
> smallest-possible draft update 6020/7950. That way, when someone follows the
> “Updated” links, they’re not overloaded with material that could’ve been left
> out.
> Jason was saying that just doing MUST/SHOULD by alone isn’t great, that at
> least the "rev:non-backwards-compatible” extension statement should be
> included and, by extension I suppose, the rules for editing the revision
> history. Presumably revision labels could be left out. IDK what minimal is
> possible.
> K. // contributor
>
>
>
> On Sep 27, 2023, at 7:06 PM, Rodney Cummings
> wrote:
>
>
> It is easy to write a short RFC updating RFC 7950, changing one sentence from
> MUST to SHOULD.
>
>
> I agree. I found that I cannot enter a response to the poll, because I
> disagree with both Option 1 and Option 2.
>
> My concern is that there are many people out there who are implementing YANG,
> but who do not follow discussions on this mailing list. I'm concerned that
> there is a serious risk that those people will interpret the change from MUST
> to SHOULD as "backward compatibility is irrelevant for YANG". We all know
> that the concern is about bug fixes and so on, but without explaining that in
> a short and focused manner (i.e., the short RFC described above), that will
> be lost in the noise of the larger draft-ietf-netmod-yang-module-versioning
> change.
>
> draft-ietf-netmod-yang-module-versioning is a great draft, but I think it
> should move forward as an independent RFC, distinct from the MUST/SHOULD
> change.
>
> Rodney Cummings
>
> -Original Message-
> From: netmod On Behalf Of Jürgen Schönwälder
> Sent: Tuesday, September 26, 2023 5:24 PM
> To: Jason Sterne (Nokia)
> Cc: netmod@ietf.org
> Subject: Re: [netmod] YANG Versioning: discussion around 7950 bis or errata
> (from Key Issue #1)
>
> It is easy to write a short RFC updating RFC 7950, changing one sentence from
> MUST to SHOULD. This is inline with the goal to not change the language,
> i.e., to keep the version numbers.
>
> /js
>
> On Tue, Sep 26, 2023 at 03:00:19PM +, Jason Sterne (Nokia) wrote:
>
> Hello NETMOD WG,
>
> We've had a poll going for a few weeks to determine if we require YANG 1.2
> for allowing ("SHOULD NOT") NBC changes (see "Poll on YANG Versioning NBC
> Approach").
>
> As part of that, some discussion has happened on the list around
> potentially doing an errata for RFC7950/6020 or a bis of 7950/6020 (if
> rough consensus is reached for option 1 of the poll)
>
> 7-8 of us discussed this in the YANG Versioning weekly call group today.
>
> First of all: this question of mechanics (errata vs bis vs Module Versioning
> draft) is orthogonal to the poll. Let's first and separately resolve the poll
> and confirm if we need YANG 1.2 or not (that's the fundamental question the
> poll is resolving - everything else is a subsequent issue to be discussed).
> We'll let the chairs confirm when/if rough consensus on the poll has been
> reached.
>
> But *if* the answer to the poll is option 1, then the weekly call group was
> unanimous that we should not do an errata for RFC7950/6020 and we should not
> do a 7950/6020 bis. We should just continue with the Module Versioning draft
> which will update 7950 and 6020.
>
> The primary reason is that we shouldn't just change MUST NOT to SHOULD NOT
> without also tying it together with the mandatory top level
> rev:non-backwards-compatible extension when an NBC change is done. Changing
> the NBC rule to SHOULD NOT needs to be in the same RFC as the mandatory
> rev:non-backwards-compatible tag.
>
> Other reasons:
>
> * an errata probably isn't correct since this isn't fixing an intent that
> was present back when 7950 was written (it was clearly the intent at t
Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)
It is easy to write a short RFC updating RFC 7950, changing one
sentence from MUST to SHOULD. This is inline with the goal to not
change the language, i.e., to keep the version numbers.
/js
On Tue, Sep 26, 2023 at 03:00:19PM +, Jason Sterne (Nokia) wrote:
> Hello NETMOD WG,
>
> We've had a poll going for a few weeks to determine if we require YANG 1.2
> for allowing ("SHOULD NOT") NBC changes (see "Poll on YANG Versioning NBC
> Approach").
>
> As part of that, some discussion has happened on the list around potentially
> doing an errata for RFC7950/6020 or a bis of 7950/6020 (if rough consensus is
> reached for option 1 of the poll)
>
> 7-8 of us discussed this in the YANG Versioning weekly call group today.
>
> First of all: this question of mechanics (errata vs bis vs Module Versioning
> draft) is orthogonal to the poll. Let's first and separately resolve the poll
> and confirm if we need YANG 1.2 or not (that's the fundamental question the
> poll is resolving - everything else is a subsequent issue to be discussed).
> We'll let the chairs confirm when/if rough consensus on the poll has been
> reached.
>
> But *if* the answer to the poll is option 1, then the weekly call group was
> unanimous that we should not do an errata for RFC7950/6020 and we should not
> do a 7950/6020 bis. We should just continue with the Module Versioning draft
> which will update 7950 and 6020.
>
> The primary reason is that we shouldn't just change MUST NOT to SHOULD NOT
> without also tying it together with the mandatory top level
> rev:non-backwards-compatible extension when an NBC change is done. Changing
> the NBC rule to SHOULD NOT needs to be in the same RFC as the mandatory
> rev:non-backwards-compatible tag.
>
> Other reasons:
>
> * an errata probably isn't correct since this isn't fixing an intent that
> was present back when 7950 was written (it was clearly the intent at the time
> to block NBC changes)
> * a bis would be odd without actually introducing other changes to YANG
> and changing the version (this discussion is all based on "if the answer to
> the poll is option 1")
>
> Jason (he/him)
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Jürgen Schönwälder Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://constructor.university/>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] example prefix
RFC 8407 says: o The local module prefix MAY be used for references to typedefs, groupings, extensions, features, and identities defined in the module. Do you propose to change this and if so to what? /js On Mon, Sep 25, 2023 at 12:14:54PM +, tom petch wrote: > From: Jürgen Schönwälder > Sent: 25 September 2023 13:10 > > We are not discussing any examples here. > > > > Good > > I am suggesting an addition to RFC8407 s.4.2 to prevent future confusion > > Tom Petch > > /js > > On Mon, Sep 25, 2023 at 12:09:07PM +, tom petch wrote: > > > > I wonder if we should have a prefix to show that the prefix is an example. > > > > Thus some vendors might think that > > prefix vendor-alto-ds > > is the prefix that must be used in vendor modules that support discovery > > based on the examples in draft-ietf-alto-oam-yang > > > > Perhaps a prefix such as > > eg-... > > would be better although I would rather it were three or four characters. > > > > Tom Petch > > ___________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Jürgen Schönwälder Constructor University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <https://constructor.university/> -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] example prefix
We are not discussing any examples here. /js On Mon, Sep 25, 2023 at 12:09:07PM +, tom petch wrote: > > I wonder if we should have a prefix to show that the prefix is an example. > > Thus some vendors might think that > prefix vendor-alto-ds > is the prefix that must be used in vendor modules that support discovery > based on the examples in draft-ietf-alto-oam-yang > > Perhaps a prefix such as > eg-... > would be better although I would rather it were three or four characters. > > Tom Petch > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] [Editorial Errata Reported] RFC6991 (7647)
Interesting. I would have removed all prefixes that are not strictly necessary. Why do you think having the prefixes is a good thing? /js On Sat, Sep 23, 2023 at 10:34:21AM +0200, David Martínez García wrote: > Hello, > > > Using the prefix is perhaps redundant but surely not wrong. > > Yes, I definetely agree with this. > > > Which consistency are you looking for, use of prefixes only when > > absolutely necessary, or always use prefixes? > > My proposal is to always use prefixes when defining typedefs that point to > other typedefs different than the base/primitive ones (such as string, > uint32, enumeration, etc.). > > Thank you. > > - David. -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] [Editorial Errata Reported] RFC6991 (7647)
On Mon, Sep 18, 2023 at 04:23:59AM -0700, RFC Errata System wrote: > Notes > - > In Section 3, the textual definition of the "ietf-yang-types" module > presents, in my opinion, inconsistencies when defining typedefs that point to > other typedefs in the same module: sometimes the value for the "type" key > contains the prefix of the module and sometimes not. Please, see the example > attached. This can also be applied to other typedefs defined in the latest > revisions of the module, such as "date-no-zone" and "time-no-zone". I think > this should be addressed to provide clarification and consistency, and thus > can be extended to other modules and the YANG standard as well. Thanks for > your time. > Using the prefix is perhaps redundant but surely not wrong. Which consistency are you looking for, use of prefixes only when absolutely necessary, or always use prefixes? /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Poll on YANG Versioning NBC Approach
If the poll does not say what you want it to say, then the poll is broken. Right now, I see the following solution proposals floating around: 1) We change a single sentence in RFC 7950 and put an end to a multi-year effort that causes the AD to block other work from moving forward. 2) We make changes to YANG but we pretend that they are not real changes to YANG and we leave it to developers and operators to figure out differences in implementation behaviour one can create. 3) We make some minimal changes to YANG and we create clarity which rules apply and what what implementations support by giving the result a new version number. Are there others? Lets talk about solutions and their properties, lets stop standing on our heads. Guess what my acceptable and non-acceptable solutions are. /js On Thu, Sep 14, 2023 at 03:42:43PM +, Jason Sterne (Nokia) wrote: > I think it has been mentioned, but maybe worth repeating: this poll is *NOT* > about accepting the entire Module Versioning + YANG Semver content as it > currently stands. > > We separated out the first of several key issues to try and make progress. > This is just the basic fundamental decision of whether we will allow (as a > "SHOULD NOT") NBC changes in in YANG 1.0/YANG1.1 (option 1), or we are going > to mandate that can only happen in a YANG 1.2 (option 2). > > After this poll settles out (hoping we'll get rough concensus), then we'll > get back to chipping away at the other key issues (e.g. see email "YANG > Versioning: Key Issues #2 and #3 - revision labels" from back in July, but > there will be several other such debates & discussions). > > Jason > > > -Original Message- > > From: netmod On Behalf Of Jürgen Schönwälder > > Sent: Thursday, September 14, 2023 5:35 AM > > To: Rob Wilton (rwilton) > > Cc: Jan Lindblad (jlindbla) ; netmod@ietf.org > > Subject: Re: [netmod] Poll on YANG Versioning NBC Approach > > > > > > CAUTION: This is an external email. Please be very careful when clicking > > links or > > opening attachments. See the URL nok.it/ext for additional information. > > > > > > > > On Tue, Sep 12, 2023 at 01:42:57PM +, Rob Wilton (rwilton) wrote: > > > > > > I think that for this first poll this is the question that we should > > > initially focus on. > > I.e., at a starting point, do you agree to updating RFC 6020, RFC 7950, to > > allow > > changing the MUST to a SHOULD without a new YANG 1.2? > > > > > > > There are many options, one is to just change a single sentence. But > > the poll fails to sort the options out. > > > > > If we can get consensus on this part, then I think that we can try and > > > tackle > > getting consensus on the other updates in draft-ietf-netmod-yang-module- > > versioning to decide whether to include those in a document that updates > > existing > > versions of YANG without a change in the YANG versioning number, or whether > > those changes should be deferred to a new version of YANG (which I hope that > > the WG starts after this versioning work completes - but I'll no longer be > > an AD at > > that stage). > > > > This work is going on for years, the WG has failed so far to enumerate > > the options and come to a conclusion. > > > > > > There are features in draft-ietf-netmod-yang-module-versioning that > > > > you can use only with new tools that implement the features. I am not > > > > sure why tools that support different variants of YANG 1 and YANG 1.1 > > > > are any easier in practice than a tool that says clearly what it > > > > implements. > > > [Rob Wilton (rwilton)] > > > > > > I hear two concerns: > > > (1) Existing tooling handling YANG 1 and YANG 1.1 modules must handle NBC > > changes anyway because they see them in the wild and that won't change. > > E.g., > > it is 99% likely that OpenConfig will still continue to use Yang 1 modules. > > > (2) All existing tooling won't be able to handle YANG 1.2 without tooling > > changes. > > > > If you do not need YANG 1.2 features, YANG 1 just works fine. The > > assumption that once can use YANG 1.2 features with YANG 1 modules by > > simply not calling the features YANG 1.2 is what puts me off. > > > > > > I continue to believe the questions are badly phrased. Instead of > > > > discussing properties and trade-offs of solutions, we discuss the > > > > version number. And we accept that bumping the version number is > > >
Re: [netmod] Poll on YANG Versioning NBC Approach
On Tue, Sep 12, 2023 at 01:42:57PM +, Rob Wilton (rwilton) wrote: > > I think that for this first poll this is the question that we should > initially focus on. I.e., at a starting point, do you agree to updating RFC > 6020, RFC 7950, to allow changing the MUST to a SHOULD without a new YANG 1.2? > There are many options, one is to just change a single sentence. But the poll fails to sort the options out. > If we can get consensus on this part, then I think that we can try and tackle > getting consensus on the other updates in > draft-ietf-netmod-yang-module-versioning to decide whether to include those > in a document that updates existing versions of YANG without a change in the > YANG versioning number, or whether those changes should be deferred to a new > version of YANG (which I hope that the WG starts after this versioning work > completes - but I'll no longer be an AD at that stage). This work is going on for years, the WG has failed so far to enumerate the options and come to a conclusion. > > There are features in draft-ietf-netmod-yang-module-versioning that > > you can use only with new tools that implement the features. I am not > > sure why tools that support different variants of YANG 1 and YANG 1.1 > > are any easier in practice than a tool that says clearly what it > > implements. > [Rob Wilton (rwilton)] > > I hear two concerns: > (1) Existing tooling handling YANG 1 and YANG 1.1 modules must handle NBC > changes anyway because they see them in the wild and that won't change. > E.g., it is 99% likely that OpenConfig will still continue to use Yang 1 > modules. > (2) All existing tooling won't be able to handle YANG 1.2 without tooling > changes. If you do not need YANG 1.2 features, YANG 1 just works fine. The assumption that once can use YANG 1.2 features with YANG 1 modules by simply not calling the features YANG 1.2 is what puts me off. > > I continue to believe the questions are badly phrased. Instead of > > discussing properties and trade-offs of solutions, we discuss the > > version number. And we accept that bumping the version number is > > considered too costly but at the same time the entire work is about > > introducing version numbers to data models (where the same logic will > > sooner of later apply). Yes, for me, this is real-world irony. > [Rob Wilton (rwilton)] > > I see this as: What are we able to do now without changing the YANG > versioning number, and without breaking existing tools, to help solve real > world issues today? I.e., the aim is to bound our solution by what we are > pragmatically able to support in YANG 1/YANG 1.1 without breaking existing > tooling (which should already ignore existing statements that they don't > understand). > > Yang 1.2/2 should be worked on, but that will probably include other changes > as well and involve some level of effort from tool vendors to support. It > will also probably also take many years. > A one line sentence change replacing MUST with SHOULD Not is one thing, the ID on the table a different thing. /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Adoption poll for draft-ma-netmod-immutable-flag-08
rules/policies, do you think it as an abuse?
{JS} the actual definition is the problem as explained above
/js
Best Regards,
Qiufang
On Tue, Sep 05, 2023 at 06:40:09PM +0200, Jan Lindblad wrote:
Jürgen,
I agree completely with you regarding transactional management. Well said.
In my reading of -08, however, I don't see the non-transactional behavior you
describe in there any more. It was there in -01, but based on feedback from me
and others, I think it has been washed out. If you still find non-transactional
behavior in the latest rev, could you please point it out to me as well? My
support too depends on the absence of such language.
I believe the document targets config true data that can never really be
changed by any client. This data remains unchanged/unchangeable except possibly
during a software version upgrade, entitlement/license change, hardware
insertion or similar system-redefining event. Such data is config true simply
because there are config true dependencies, such as leafrefs or must conditions
on min and max range values. I think this kind of usage could be a relevant use
case, and I'd support discussing ways to describe that in the WG.
Best Regards,
/jan
On 5 Sep 2023, at 18:05, Jürgen Schönwälder
NETMOD WG,
>
>This email begins a 2-week adoption poll for:
>https://datatracker.ietf.org/doc/draft-ma-netmod-immutable-flag/08
>
>There is no known IPR on this draft (IPR call
><https://mailarchive.ietf.org/arch/msg/netmod/_S-cKw5jIBmDKEPBRq8KeAbNLGg/>).
>
>Please voice your support or technical objections to adoption on the list by
>the end of the day (any time zone) Sep 19.
>
>Thank you,
>Kent (as co-chair)
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod
--
Jürgen Schönwälder Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://constructor.university/>
___
netmod mailing list
netmod@ietf.org <mailto:netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
--
Jürgen Schönwälder Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://constructor.university/>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
--
Jürgen Schönwälder Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://constructor.university/>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Poll on YANG Versioning NBC Approach
The two options mix things together. Option 1 says updating YANG 1 and YANG 1.1 to allow YANG modules to be modified _based on draft-ietf-netmod-yang-module-versioning_ but this document has much more in it than just changing a MUST to SHOULD. There are features in draft-ietf-netmod-yang-module-versioning that you can use only with new tools that implement the features. I am not sure why tools that support different variants of YANG 1 and YANG 1.1 are any easier in practice than a tool that says clearly what it implements. I continue to believe the questions are badly phrased. Instead of discussing properties and trade-offs of solutions, we discuss the version number. And we accept that bumping the version number is considered too costly but at the same time the entire work is about introducing version numbers to data models (where the same logic will sooner of later apply). Yes, for me, this is real-world irony. /js PS: There is no need to update YANG 1.1 modules to YANG 1.2 as long as you do not use YANG 1.2 rules and mechanism. On Tue, Sep 12, 2023 at 12:43:56PM +, Jan Lindblad (jlindbla) wrote: > Jürgen, all, > > I see the irony in changing the YANG RFC(s) without updating the YANG > language version number, but digging a bit deeper, I think the question is > not as clear-cut as it might seem at first. > > Altering the contents of the backwards-compatibility section of RFC 6020 (sec > 10) and RFC 7950 (sec 11) clearly implies changes in YANG module authors' > behavior. > > Speaking as a YANG compiler implementor, however, I don't see any changes > that have to made to the compiler because of this RFC change. There are no > new keywords, none are removed. There is no change in the meaning of existing > keywords. There is no difference in the output the compiler needs to generate. > > So while there are changes to the YANG *standard* (meaning RFCs) there is no > actual change to the YANG *language*. If we require user's to mark their > modules with version 1.2 (or 2.0), from the compiler's pov, that would just > be an alias for YANG 1.1. It means a fair amount of trouble to update all the > tools out there to accept "yang-version 1.2" but do nothing new. It also adds > a burden to YANG module implementors, since they would have to go through all > YANG 1.1 modules and mark them 1.2, for no change in meaning. For > organizations with some modules still on YANG 1.0, the bar is even higher. > > I think the most pragmatic approach in this case would be to change the RFC > text in the backwards-compatibility sections and not update the yang-version > number as long as no change is required in the compilers. If anyone can point > to actual things the compiler needs to do differently, I'd be interested to > hear. > > Best Regards, > /jan > > > > > On 12 Sep 2023, at 07:55, Jürgen Schönwälder > > wrote: > > > > I disagree with the poll. There are important teachnigal differences > > behind the two options that this polls tries to hide. > > > > Updating YANG 1 and YANG 1.1 means creating YANG 1' and YANG > > 1.1'. There is no way that a new versioning approach will be > > understood by existing YANG tooling. That's an illusion. > > > > /js > > > > On Mon, Sep 11, 2023 at 10:39:39PM +, Kent Watsen wrote: > >> WG, > >> > >> Please help the YANG-versioning effort move forward by participating in > >> the following poll: > >> > >> - https://notes.ietf.org/netmod-2023-sept-poll (Datatracker login > >> required) > >> > >> Kent and Lou > >> > > > >> ___ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > > > > > > -- > > Jürgen Schönwälder Constructor University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 <https://constructor.university/> > > > > ___ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Poll on YANG Versioning NBC Approach
Versioning people told me that the version numbers follows from the kind of changes made. If true, then discussing the version number first is backwards. /js On Tue, Sep 12, 2023 at 11:59:45AM +, Jason Sterne (Nokia) wrote: > Hi Jurgen, > > We need this poll to set fundamental direction in the WG. Yes, there will > still be discussion & debate around *either* option once we select one. But > we need to agree on whether we're moving ahead by updating YANG 1.0/YANG 1.1 > (without requiring any sort of new YANG version number) or if we as a WG are > going to insist on only allowing this work to continue and exist in YANG > modules marked with a new YANG version 1.2. > > We need to put this part of the decision behind us and move onto the next set > of discussions & issues. > > Jason > > > -----Original Message- > > From: netmod On Behalf Of Jürgen Schönwälder > > Sent: Tuesday, September 12, 2023 1:55 AM > > To: Kent Watsen > > Cc: netmod@ietf.org > > Subject: Re: [netmod] Poll on YANG Versioning NBC Approach > > > > > > CAUTION: This is an external email. Please be very careful when clicking > > links or > > opening attachments. See the URL nok.it/ext for additional information. > > > > > > > > I disagree with the poll. There are important teachnigal differences > > behind the two options that this polls tries to hide. > > > > Updating YANG 1 and YANG 1.1 means creating YANG 1' and YANG > > 1.1'. There is no way that a new versioning approach will be > > understood by existing YANG tooling. That's an illusion. > > > > /js > > > > On Mon, Sep 11, 2023 at 10:39:39PM +, Kent Watsen wrote: > > > WG, > > > > > > Please help the YANG-versioning effort move forward by participating in > > > the > > following poll: > > > > > > - https://notes.ietf.org/netmod-2023-sept-poll (Datatracker login > > > required) > > > > > > Kent and Lou > > > > > > > > ___ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > -- > > Jürgen Schönwälder Constructor University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 <https://constructor.university/> > > > > ___ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Poll on YANG Versioning NBC Approach
I disagree with the poll. There are important teachnigal differences behind the two options that this polls tries to hide. Updating YANG 1 and YANG 1.1 means creating YANG 1' and YANG 1.1'. There is no way that a new versioning approach will be understood by existing YANG tooling. That's an illusion. /js On Mon, Sep 11, 2023 at 10:39:39PM +, Kent Watsen wrote: > WG, > > Please help the YANG-versioning effort move forward by participating in the > following poll: > > - https://notes.ietf.org/netmod-2023-sept-poll (Datatracker login required) > > Kent and Lou > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Adoption poll for draft-ma-netmod-immutable-flag-08
sible statements just to ignore them? Perhaps Martin knows best. Some of the text needs editorial work or better descriptions. An example: "If servers always reject client modification attempts to some data node that can only be created, modified and deleted by the device itself, an 'immutable' YANG extension can be used to formally indicate to the client. The logic feels backwards to me. The server rejects modification attempts because some data is considered immutable by the server. The text suggests it is the other way round, or worse, makes no sense (consider a server rejecting a request repeatedly due to a lack of permissions, this does not imply that the data is now immutable). And the immutable statement is about designing at data model design time that certain leafs are immutable. The server's behavior follows the model, not the other way round. And I would consider an immutable definition in the data model to actually be prescriptive in some form or the other. Adding immutable of an existing immutable statement is non-backwards compatible changes. Other changes to immutable are backwards compatible."; What? I am also puzzled what the 'value' of the immutable extension statement is. The definition needs to be rewritten so that it defines precisely what this extension statement is. The description of the immutable annotation has similar issues, except that for this one we know that the value is a boolean value. "define the with-immutable grouping."; This is the kind of descriptions nobody needs. Perhaps explain what this definition is good for in order to establish the context for the stuff in the grouping and how it is used later. The example in A.1 is not really convincing. For the leafref to work, you need a set of immutable leafs, one for each timer value supported by the server. Are people really doing such constructions for timer values?? I understand that you want a leafref pointing to one out of N supported values, the timer value story, however, sounds weird. Do you have more convincing examples that are still easy to understand? The example in A.2 confuses me. Interface configurations are applied to physically present interfaces. There is a name binding of the interface configuration to a physical interface. This section seems to suggest something very different from how I understand RFC 8343. I have no idea why A.2.1 is there, it seems to show normal NC behavior or did I miss something? That said, what I am indeed missing is a clear definition which error is returned if an attempt is made to mutate an immutable leaf (well to a value it does not have). In A.3, if we have entries in lists that are immutable because the server believes this is good for the customer, then I am concerned that this stuff is not a static rare thing but something that will come and go dynamically. I see great potential for abuse of such a mechanism. Once the client needs to adapt to server logic to determine the mutability of things, we are on a slippery slope. /js On Tue, Sep 05, 2023 at 06:40:09PM +0200, Jan Lindblad wrote: > Jürgen, > > I agree completely with you regarding transactional management. Well said. > > In my reading of -08, however, I don't see the non-transactional behavior you > describe in there any more. It was there in -01, but based on feedback from > me and others, I think it has been washed out. If you still find > non-transactional behavior in the latest rev, could you please point it out > to me as well? My support too depends on the absence of such language. > > I believe the document targets config true data that can never really be > changed by any client. This data remains unchanged/unchangeable except > possibly during a software version upgrade, entitlement/license change, > hardware insertion or similar system-redefining event. Such data is config > true simply because there are config true dependencies, such as leafrefs or > must conditions on min and max range values. I think this kind of usage could > be a relevant use case, and I'd support discussing ways to describe that in > the WG. > > Best Regards, > /jan > > > > > On 5 Sep 2023, at 18:05, Jürgen Schönwälder > > wrote: > > > > I do not support this work. Yes, it is some effort on the server side > > to figure out how move from config state A to config state B. This > > proposal essentially pushes the work towards the clients that now have > > to figure out how to single step a server from config state A to > > config state B - and if things fail on intermediate steps it is the > > clients that have to figure out how to roll back the changes to get > > back to config state A (if that is possible at all). The or
Re: [netmod] Adoption poll for draft-ma-netmod-immutable-flag-08
I do not support this work. Yes, it is some effort on the server side to figure out how move from config state A to config state B. This proposal essentially pushes the work towards the clients that now have to figure out how to single step a server from config state A to config state B - and if things fail on intermediate steps it is the clients that have to figure out how to roll back the changes to get back to config state A (if that is possible at all). The original promise of NETCONF was that it is not necessary anymore to have clients that please the server, which was comiing out of many years of experience with protocols that required clients to please the servers. If implementations have constraints on what kinds of edits are possible, then this is an implementation limitation and hence this should be documented in deviation statements but not in the data models. /js On Tue, Sep 05, 2023 at 12:42:35PM +, Kent Watsen wrote: > NETMOD WG, > > This email begins a 2-week adoption poll for: > https://datatracker.ietf.org/doc/draft-ma-netmod-immutable-flag/08 > > There is no known IPR on this draft (IPR call > <https://mailarchive.ietf.org/arch/msg/netmod/_S-cKw5jIBmDKEPBRq8KeAbNLGg/>). > > Please voice your support or technical objections to adoption on the list by > the end of the day (any time zone) Sep 19. > > Thank you, > Kent (as co-chair) > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02
On Tue, Sep 05, 2023 at 02:28:02PM +, Italo Busi wrote: > > In order to keep the semantics, it is possible to prefix the name of the YANG > leaf carrying the hex-dump of the reserved field with the RFC number where > the reserved field is defined (e.g., rfcxxx-foo). > Several decades ago, people thought it was a clever idea to name data models using RFC numbers. But over time, when RFCs get replaced and obsoleted, this started to look really odd (and who outside the IETF wants to be bothered with RFC numbers). /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] List name: singular or plural?
On Thu, Aug 31, 2023 at 12:02:59PM +, tom petch wrote:
>
>
> The issue I come across, saw it again today in nrp-yang, is
>
> container interfaces
> list interface
> key interface
> leaf interface
>
> which I find clunky but do not have a good alternative for.
>
Surprising is the leaf interface. I know, we have multiple encodings
today, but back then we had XML and this translates into
x
y
RFC 8343 has
container interfaces {
list interface {
key "name";
}
leaf name;
}
which in XML becomes
y
and initially NETCONF only had XML encodings. in JSON you get
something like this:
{
"interfaces": {
"interface": [
{
"name": "x"
},
{
"name": "y"
}
]
}
}
Perhaps what people find clunky is a function of which encoding they
are using. Perhaps it helps if people read 'list interfaces {}' as
"list of interfaces".
/js
--
Jürgen Schönwälder Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://constructor.university/>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] 回复：confusion about canonicalization of date-and-time type value in?? netconf reply
On Tue, Aug 29, 2023 at 11:04:37AM +0800, lyzliyu...@163.com wrote: >But I think rfc7950 section 9.1 is only about yang built-in type because >section 9's title is built-in type. > >If someone define a leaf with date-and-time type but modify it's pattern >to only Z-suffix time form( this is valid in rfc7950), and then if the >server still reply the value with +08:00 form, then the server actually >reply an invalid value which violates the pattern. >So I think it is not a good practice for a server to do such value change >in reply for the non built-in type. > Canonicalization comes into play when there are multiple possible _representations_ of the same value. The idea is that a server may accept different representations as input but always responds with a predictable representation as output. /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] confusion about canonicalization of date-and-time type value in netconf reply
Your question seems to be whether the server should return the
canonical format or the format used in the request. My take is that
the server should always return the canonical format. See RFC 7950
Section 9.1.
/js
On Tue, Aug 29, 2023 at 01:01:42AM +0800, 老空楼 wrote:
> If a list key is date-and-time type, is it a little bit strange for a netconf
> server to reply data with key value different from that in get/get-config
> request ?
>
> Demo module:
>
> module test {
>
> namespace "urn:test";
>
> prefix test;
>
> import ietf-yang-types {
>
> prefix yang;
>
> }
>
> container con {
>
> list time-range {
>
> key "start-time";
>
> leaf start-time {
>
> type yang:date-and-time;
>
> }
>
> leaf else {
>
> type string;
>
> }
>
> }
>
> }
>
> }
>
> Suppose a client send a get rpc to query the /test:con
>
>
>
>
>
>
> and the server reply
>
>
>
> 2022-02-01T08:00:00+08:00
> something
>
>
>
> which mean there only on list entry with key "2022-02-01T08:00:00+08:00".
> And then if the client send another get rpc with list key value
> "2022-02-01T00:00:00Z" in subtree
>
>
>
> 2022-02-01T00:00:00Z
>
>
>
> shoud the server reply the list entry with key "2022-02-01T08:00:00+08:00" as
> in the previous get rpc?
>
>
>
> 2022-02-01T08:00:00+08:00
> something
>
>
>
> Although I know that according to RF6991 the date-and-time value should be
> canolicalize, but I think it still seems a little strange for a server to
> reply value different from the request ?
> How the working group consider this situation?
> Thanks.
>
>
>
--
Jürgen Schönwälder Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://constructor.university/>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WGLC on node-tags-09
The use case described in the document is that client A tags nodes and client B consumes the tags, i.e., two management applications coordinate their work via tags set on the server's data tree. I am not sure who orchestrates management applications in this way but those who do likely do not expect interoperability on the level of the tags since there is likely additional behaviour implied by setting tags. If the idea is to standardize general metric tags for documentation or lookup purposes (or some other yet to be defined purposes), then what may appear to be simple task may turn out to be much more complex once you dive into the details what tags really mean. There is a large body of work on metrics that has been done in the Benchmarking Methodology WG (bmwg). Work aiming to define a registry of tags for metrics should surely be reviewed by bmwg people. There is also RFC 8911 produced by IPPM, which seems to overlap with this effort to define a metrics registry. Perhaps the whole metrics registry work needs more thought and cross WG review and it may make sense to move it to a separate document. /js On Fri, Aug 04, 2023 at 04:13:50PM +, tom petch wrote: > From: netmod on behalf of Kent Watsen > > Sent: 19 April 2023 02:59 > > This email begins a two-week WGLC on: > > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-09 > > Please take time to review this draft and post comments by May 2nd. > Favorable comments are especially welcomed. > > I think that this is a bad idea. It lacks a coherent taxonomy, a bit like > setting up a relational database without first considering what classes there > will be, what inheritance there is and so on. > > It seems to be an ad-hoc collection of categories that are of interest to the > authors and are likely to be meaningless in practice in the internet at > large. It should look at what aspects of management it covers and then the > data related to each and the provide usable criteria to determine into which > category a data item falls. This is substantial work, but then so is setting > up a usable relational database and I see enough of those where the thought > has not been put in on the underlying concepts, principles and so have proved > more of a hindrance than a help. > > Tom Petch > > > > > This draft went through a WGLC a year ago. The authors addressed the > comments received and have been were waiting for feedback. In essence, this > draft is presumed to reflect WG consensus and thusly, if no objection is > received, the draft will move to the next step in the publication process. > > Ref: https://mailarchive.ietf.org/arch/msg/netmod/n2P9yohA-X-xSIt6FlMr4wOqmuI/ > > Kent // 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 -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02
On Thu, Aug 03, 2023 at 03:08:19PM -0400, Acee Lindem wrote: > I don’t support adoption as I think this solution to the problem of receiving > unknown bits is excessive and the fact that it is Non-Backward Compatible > (NBC) change to remove the unknown bits once they are defined. Rather, just > add an optional read-only unknown-foo-bits leaf of type yang:hex-string and > return the hex representation if they’re any unknown bits in the field. > Or always report the raw data in the hex-string if this information is considered useful so that clients do not have to guess what a server considers a known bit (which may change over time). I tend to agree that the solution feels overly complex. /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] yang with relaxed versioning
Hi, to demonstrate how a minimal solution allowing limited non-backwards compatible changes can look like, I have posted the following internet draft: https://datatracker.ietf.org/doc/draft-schoenw-netmod-yang-relaxed-versioning/ There are details missing but I am positive that everything necessary can be written down using ~15 pages (in the old style text format). For the reasoning behind this approach, see my blog posts. https://www.beadg.de/js/post/yang-versioning-update/ /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] yang versioning blog posts
I have written a blog post on YANG versioning summarizing concerns about the current proposal and outlining a possible path towards a minimal solution. https://www.beadg.de/js/post/yang-versioning-update/ This post references an earlier post I wrote about three years ago. https://www.beadg.de/js/post/yang-versioning/ /js (who will unfortunately not be able to attend the SF meeting) -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
Dear Jason, the three options come with a bunch of details that make it hard to support any of them. I think what is needed is a dialog, not a choice of given options (for a yet to be determined set of issues and options to come). /js On Mon, Jul 17, 2023 at 05:52:00PM +, Jason Sterne (Nokia) wrote: > Hi all, > > At the request of the NETMOD chairs, and on behalf of the YANG Versioning > weekly call group, here's a summary of Key Issue #1 for the versioning work > (i.e. for the Module Versioning and YANG Semver WGLC). > > We'd like to suggest that the WG has a strong focus on deciding on this > specific issue first. Then we'll move on to tackle other key issues. The idea > is to try and avoid getting tangled in a web of multiple intertwined issues. > > Key Issue #1 is the following: Allow NBC changes in YANG 1.0 & YANG 1.1 or > not? > > For now please avoid debating other issues in this thread (e.g. multiple vs > single label schemes, whether YANG semver is a good scheme, etc). Let's focus > on K1 and work towards a WG decision. > > ### > K1) Allow NBC changes in YANG 1.0 & YANG 1.1 or not? > > Option 1 - Update RFC7950 to Allow NBC Changes > --- > - Module Versioning modifies 7950 to allow NBC changes > - guidance that NBC changes SHOULD NOT be done (impact to user base) > - rev:non-backwards-compatible is a YANG extension > - introduction in published YANG does not impact current tooling (ignored > until recognized) > PROS: > - address fundamental requirement of this versioning work (requirements doc) > - allows gradual adoption in the industry. YANG authors can immeditately > start publishing with the new extensions. > - move faster to produce modules in the IETF (accept some errors/iteration) > - address the liaison from external standards bodies in a reasonable timeframe > - authors believe work is ready > - broad vendor support > - rough alignment with OpenConfig (use YANG 1.0 + OC Semver) > CONS: > - perception that we're "cheating" by not bumping our own spec's version > - Not fundamentally mandatory for clients or servers using YANG (mandatory > for YANG claiming conformance to Module Versioning). > > Option 2 - RFC7950-bis: Publish a new version of the YANG language to allow > NBC changes > --- > - NBC changes only allowed in a new (future) version of YANG > - TBD: YANG 1.2 vs 2.0 (note YANG 1.1 isn't BC with YANG 1.0) > - Content = Module Versioning + YANG Semver + very limited YANG NEXT items > - rev:non-backwards-compatible tag is a language keyword > - consequence: any use of it breaks all YANG 1.0/1.1 tooling that hasn't > been updated > - TBD how to handle small NBC changes in IETF in the short term (i.e. non > conformance to 7950)? > - RFC6991 bis - change the use/meaning of ip-address (or change datetime) > - YANG date-and-time (because of SEDATE date string changes) > > PROS: > - address fundamental requirement of this versioning work (requirements doc) > - clear delineation of changes in the YANG language > - consistent with philosophy that version number changes for significant > changes in a spec (avoids concern that YANG is changing without bumping the > version of YANG) > - can do this with mandatory YANG keywords which helps increase conformance > to the new rules > CONS: > - difficult to roll out in the industry. Tools need upgrading before they > won't error on a YANG 1.2 module. > - Authors can't publish YANG 1.2 until their users have upgraded their tools. > Everyone has to move at once. > - likely large delay in producing the work (unclear what would go into YANG > 1.2, may not reach concensus easily on N items) > - delay in follow up work (Packages, Schema Comparison, Version Selection) > - continue dominating WG effort for longer (opportunity cost) > > Option 3 - Strict Adherence to Current RFC7950 Rules > --- > - IESG will be unable to approve any RFCs that make any changes to IETF YANG > modules that don't strictly conform to those rules > - RFC6991 bis would not be allowed to change the use/meaning of > ip-address (or change datetime) > - YANG date-and-time couldn't change (related to SEDATE date > string changes) > PROS: > - clear rules for entire industry including IETF > CONS: > - doesn't address agreed/adopted requirements of YANG versioning work > - incorrect assumption in tool chains, etc that NBC changes don'
Re: [netmod] [Teas] Lines too long in YANG tree diagrams
Some research says that the human eye is not good (fast) at reading texts with very long lines since our eyes loose orientation, in particular on return sweeps. This has influenced typography in both the offline and the online world for decades. While modern displays can easily render lines way longer than ~70 characters, using such long lines may not be useful until we also update our human eyes. Breaking large tree diagrams into smaller pieces is a service to the readers. Hitting the line length limit is an indicator that it may be time to split up tree diagrams. /js On Thu, Jul 06, 2023 at 07:46:38AM +, mohamed.boucad...@orange.com wrote: > Hi all, > > Indeed. > > FWIW, we used to have a similar guideline for the modules themselves in > draft-boucadair-netmod-rfc8407bis: > > CURRENT: >Native YANG features (e.g., breaking line, "+") SHOULD be used to fit >a module into the line limits. Exceptionally, RFC8792-folding of >YANG modules MAY be used if and only if native YANG features are not >sufficient. > > I updated it to also cover Italo's initial comment: > > NEW: >Native YANG features (e.g., breaking line, "+") SHOULD be used to fit >a module into the line limits. Exceptionally, RFC8792-folding of >YANG modules MAY be used if and only if native YANG features are not >sufficient. A similar approach (e.g., use "--yang-line-length 69" or >split a tree into subtrees) SHOULD be followed for tree diagrams. > > Cheers, > Med > > > -Message d'origine- > > De : Teas De la part de Jürgen Schönwälder > > Envoyé : jeudi 6 juillet 2023 00:31 > > À : Italo Busi > > Cc : netmod@ietf.org; cc...@ietf.org; TEAS WG > > Objet : Re: [Teas] [netmod] Lines too long in YANG tree diagrams > > > > Tree diagrams are a means to explain the structure of a module. It > > is often useful to larger diagrams into small pieces and then the > > line length problem resolves itself. See also Section 3.3 of RFC > > 8340. > > > > /js > > > > On Wed, Jul 05, 2023 at 09:58:46PM +, Italo Busi wrote: > > > RFC8340 suggests to use the "--tree-line-length 69" option to > > produce YANG tree diagrams to be included into an Internet-Draft > > or RFC. > > > > > > Although this option works well in many cases, there are few > > cases > > > where pyang produces YANG tree diagram with lines too long even > > with > > > the "--tree-line-length 69" option and in this case it is not > > fully > > > clear what could be done when including those YANG tree diagram > > into > > > Internet-Drafts or RFCs > > > > > > Section 5.2 of RFC8792 says: > > > > > > It is RECOMMENDED that authors do as much as possible within the > > selected format to avoid long lines. > > > > > > My interpretation of the RECOMMENDED key word and of "as much as > > > possible" is that we MUST always use the "--tree-line-length 69" > > > option to generate the YANG tree diagrams to be included into > > > Internet-Drafts or RFCs and that we MAY use RFC8792 tool to fold > > the > > > YANG tree diagrams when they contain lines too long > > > > > > Is my interpretation correct? > > > > > > Thanks, Italo > > > > > > > > > > > ___ > > > netmod mailing list > > > netmod@ietf.org > > > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > > www. > > > > > ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C01%7Cmohamed.bouc > > adai > > > > > r%40orange.com%7Cf3ffe07d44fd4ed0e96708db7da78c46%7C90c7a20af34b40 > > bfbc > > > > > 48b9253b6f5d20%7C0%7C0%7C638241930786968316%7CUnknown%7CTWFpbGZsb3 > > d8ey > > > > > JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7 > > C300 > > > > > 0%7C%7C%7C&sdata=FghTSoqFDCSnCdBAOva8o2GTk18sEEzRwkq9S8Pu%2Bv8%3D& > > rese > > > rved=0 > > > > > > -- > > Jürgen Schönwälder Constructor University Bremen > > gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > > Germany > > Fax: +49 421 200 3103 > > <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > > Fconstructor.university%2F&data=05%7C01%7Cmohamed.boucadair%40oran > > ge.com%7Cf3ffe07d44fd4ed0e96708db7da78c46%7C90c7a20af34b40bfbc48b9 > > 253b6f5d20%7C0%7
Re: [netmod] Lines too long in YANG tree diagrams
Tree diagrams are a means to explain the structure of a module. It is often useful to larger diagrams into small pieces and then the line length problem resolves itself. See also Section 3.3 of RFC 8340. /js On Wed, Jul 05, 2023 at 09:58:46PM +, Italo Busi wrote: > RFC8340 suggests to use the "--tree-line-length 69" option to produce YANG > tree diagrams to be included into an Internet-Draft or RFC. > > Although this option works well in many cases, there are few cases where > pyang produces YANG tree diagram with lines too long even with the > "--tree-line-length 69" option and in this case it is not fully clear what > could be done when including those YANG tree diagram into Internet-Drafts or > RFCs > > Section 5.2 of RFC8792 says: > > It is RECOMMENDED that authors do as much as possible within the selected > format to avoid long lines. > > My interpretation of the RECOMMENDED key word and of "as much as possible" is > that we MUST always use the "--tree-line-length 69" option to generate the > YANG tree diagrams to be included into Internet-Drafts or RFCs and that we > MAY use RFC8792 tool to fold the YANG tree diagrams when they contain lines > too long > > Is my interpretation correct? > > Thanks, Italo > > > ___________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] I-D Action: draft-ietf-netmod-yang-versioning-reqs-08.txt
On Mon, Jun 26, 2023 at 03:53:19PM +, Joe Clarke (jclarke) wrote: > This revision is a resurrection of the expired I-D to help frame the > LC discussions around module versioning and YANG Semver. Thanks, Section 5 is an interesting read. The solution we got seems to be going over board on some requirements while not addressing some other requirements (or I have not understood how). /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts
On Tue, Jun 13, 2023 at 05:54:40PM +, Joe Clarke (jclarke) wrote: > > - I prefer to have non-backwards compatible changes marked and > > explained in the modules instead of relying on some schema > > comparison algorithm. > > > > [JMC] IMHO, the algorithm is useful in addition to any per-module notation > > as the tooling can provide a clear, consolidated report of the overall > > compatibility. > > > > Sure, years ago I implemented smidiff, but then assuming that every > reader has the proper tools is likely wrong. And while tools can spot > differences, they lack the ability to give explanations or advice how > to adapt to changes. NBC changes deserve to be documented where they > take place. Tooling can spot missing documentation. > > [JMC] We have per-module notation, and we discussed general per-node tags > (though they were moved to schema comparison as you point out). Part of this > oscillation is due to changes in feedback over time, and I am unclear the > best path forward on this issue. Myself, personally, I would be okay > bringing back the per-node tags as I agree with your point above. > The module revision derives from the changes, hence hiding the changes behind a module revision label and suggesting tools to find the details is really backwards. It is relatively pointless whether a module is at revision a.b.c or d.e.f, as long as the definitions imported and used from that module have no NBC changes, the module revision label does not matter for this particular import. If Rob's story is true that NBC changes are rare, then marking them where they occur seems the simplest and most effective solution. /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
