A capitalized SHOULD, really? Here is my counter proposal: Make no change to what is currently in RFC 8407, the pointer to RFC 8340 is sufficient.
/js On Tue, Nov 05, 2024 at 06:38:55PM +0000, Lou Berger wrote: > Med, > > I think we're going in circles here how about this: > > OLD (current RFC) > > 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]. > > If YANG tree diagrams are used, then an informative reference to the > YANG tree diagrams specification MUST be included in the document. > Refer to Section 2.2 of [RFC8349] for an example of such a reference. > > NEW (changes are in bold) > > 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 and not in the main body of the document.* > > If YANG tree diagrams are used, then an informative reference to the > YANG tree diagrams specification MUST be included in the document. > Refer to Section 2.2 of [RFC8349] for an example of such a reference. > > Lou > > On 11/5/2024 8:50 AM, [email protected] wrote: > > > > Hi Lou, > > > > Please see inline. > > > > Cheers, > > > > Med > > > > *De :* Lou Berger <[email protected]> > > *Envoyé :* mardi 5 novembre 2024 10:28 > > *À :* BOUCADAIR Mohamed INNOV/NET <[email protected]> > > *Cc :* Jan Lindblad <[email protected]>; [email protected] > > *Objet :* Re: [netmod] WGLC on draft-ietf-netmod-rfc8407bis > > > > Med > > > > See inline > > > > On 10/29/2024 8:20 AM, [email protected] 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://www.rfc-editor.org/rfc/rfc8340#section-3.3> : > > > > */[Med] I’m familiar with that part. That’s echoed is bis as “For the > > reader's/* > > > > */convenience, a subtree should fit within a page.” but../* > > > > 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. > > > > */[Med] … that does not answer the characterization comment I was > > referred to. Please refer to the comment raised on the list: > > https://mailarchive.ietf.org/arch/browse/netmod/?q=long%20tree /* > > > > * recommends against including too long trees in the main doc, > > while Section 3 of RFC8340 has 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? > > > > */[Med] The exact change is “/*main body of the document or in an > > appendix*/” to “SHOULD NOT in the main body”./* > > > > Thanks, > > > > Lou > > > > Cheers, > > > > Med > > > > *De :* Lou Berger <[email protected]> <mailto:[email protected]> > > *Envoyé :* mardi 29 octobre 2024 12:34 > > *À :* BOUCADAIR Mohamed INNOV/NET <[email protected]> > > <mailto:[email protected]>; Lou Berger > > <[email protected]> <mailto:[email protected]>; [email protected] > > *Cc :* Jan Lindblad <[email protected]> <mailto:[email protected]> > > *Objet :* RE: [netmod] WGLC on draft-ietf-netmod-rfc8407bis > > > > Med > > > > Thanks for this. The new doc says: > > > > > These guidelines take precedence over the generic guidance in > > > Section 3 of [RFC8340]. > > > > Can you highlight what you see is the differences between the new > > section and rfc8340? (In other words, why is a reference saying > > authors should follow section 3.3 of rfc8340 insufficient?) > > > > Thanks, > > Lou > > > > ------------------------------------------------------------------------ > > > > On October 29, 2024 4:25:44 AM [email protected] wrote: > > > > Hi Lou, all, > > > > (1) > > > > There are RFCs that don’t include the full tree, but AFAIK > > there is no RFCs that include a stable pointer for a tree. > > There are I-Ds under development that follow that option, but > > I don’t think this can be used as example as these are > > following what was in rfc8407bis. > > > > (2) > > > > I paused to reply with the hope to hear more voices about this > > issue. Till now, no one else indicated preference for the > > stable URL option. > > > > With that, I prepared a PR to remove that option and only > > leave the appendix option. > > > > The full diff can be seen at: > > > > https://author-tools.ietf.org/api/iddiff?url_1=https://netmod-wg.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt&url_2=https://netmod-wg.github.io/rfc8407bis/too-long-trees-bis/draft-ietf-netmod-rfc8407bis.txt > > > > <https://author-tools.ietf.org/api/iddiff?url_1=https://netmod-wg.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt&url_2=https://netmod-wg.github.io/rfc8407bis/too-long-trees-bis/draft-ietf-netmod-rfc8407bis.txt> > > > > > > Hope this captures the opinions heard so far. > > > > Cheers, > > > > Med > > > > *De :*Lou Berger <[email protected]> > > *Envoyé :* mardi 22 octobre 2024 17:29 > > *À :* BOUCADAIR Mohamed INNOV/NET > > <[email protected]>; Lou Berger <[email protected]>; > > Andy Bierman <[email protected]> > > *Cc :* Mahesh Jethanandani <[email protected]>; > > [email protected]; [email protected]; Jan > > Lindblad <[email protected]>; Kent Watsen <[email protected]> > > *Objet :* RE: [netmod] WGLC on draft-ietf-netmod-rfc8407bis > > > > Med, > > > > ---------- > > On October 22, 2024 8:22:47 AM [email protected] wrote: > > > > > Re-, > > > > > > Can you please indicate why you think this is a bad option? > > What is the harm in recording an option that matches current > > practice? > > > > > > > Is there an example of a published rfc that points to the full > > tree via a URL? > > > > As far as I read the discussion, no one was agreeing that this > > approach was a good idea. > > > > Thanks, > > Lou > > > > > > > I remember that you indicated that you are using an > > electronic device to read docs. You can still browse the tree > > from the supplied URL. > > > > > > Cheers, > > > Med > > > > > > De : Lou Berger <[email protected]> > > > Envoyé : mardi 22 octobre 2024 14:00 > > > À : BOUCADAIR Mohamed INNOV/NET > > <[email protected]>; Lou Berger <[email protected]>; > > Andy Bierman <[email protected]> > > > Cc : Mahesh Jethanandani <[email protected]>; > > [email protected]; [email protected]; Jan > > Lindblad <[email protected]>; Kent Watsen <[email protected]> > > > Objet : RE: [netmod] WGLC on draft-ietf-netmod-rfc8407bis > > > > > > > > > Med, > > > > > > ---------- > > > On October 22, 2024 1:21:31 AM > > [email protected]<mailto:[email protected] > > > > <mailto:[email protected]%3cmailto:[email protected]>> > > wrote: > > > > > >> Hi Lou, > > >> > > >> Kent rightfully raised the point about the troubles with > > long trees that exceeds the max line thing. I also clarified > > that, e.g., > > >> > > > > > > This is separate and unrelated topic, talking about > > inclusion of full trees in appendices as is currenty allowed > > for in rfc8340. > > > > > >> * Existing specs have provisions for tree diagrams to > > be included “as a whole, by one or more sections, or even by > > subsets of nodes” (8340) > > > > > > Yes I'm familiar with that text :-) > > > > > >> * There are RFCs out there that do not include them. > > >> > > > > > > Sure, which is also allowed for in rfc8340 > > > > > >> This is a MAY after all. We can't mandate that every doc > > MUST include the full tree anyway. Are you asking for that? > > > > > > Absolutely not. I'm not quite sure what give you that > > impression. I just would like to see the additional option > > removed as I think it is a bad idea. > > > > > > Thanks, > > > Lou > > > > > >> > > >> Cheers, > > >> Med > > >> > > >>> -----Message d'origine----- > > >>> De : Lou Berger <[email protected]<mailto:[email protected] > > <mailto:[email protected]%3cmailto:[email protected]>>> > > >>> Envoyé : lundi 21 octobre 2024 23:38 > > >>> À : BOUCADAIR Mohamed INNOV/NET > > <[email protected]<mailto:[email protected] > > > > <mailto:[email protected]%3cmailto:[email protected]>>>; > > >>> Andy Bierman <[email protected]<mailto:[email protected] > > <mailto:[email protected]%3cmailto:[email protected]>>> > > >>> Cc : Mahesh Jethanandani > > <[email protected]<mailto:[email protected] > > <mailto:[email protected]%3cmailto:[email protected]>>>; > > >>> [email protected]<mailto:[email protected] > > <mailto:[email protected]%3cmailto:[email protected]>>; > > > > [email protected]<mailto:[email protected] > > > > <mailto:[email protected]%3cmailto:[email protected]>>; > > Jan > > >>> Lindblad <[email protected]<mailto:[email protected] > > <mailto:[email protected]%3cmailto:[email protected]>>>; > > Kent Watsen <[email protected]<mailto:[email protected] > > <mailto:[email protected]%3cmailto:[email protected]>>> > > >>> Objet : Re: [netmod] WGLC on draft-ietf-netmod-rfc8407bis > > >>> > > >>> > > >>> Hi. > > >>> > > >>> Looking at today's (-20) version of the document, I still see > > >>> stable pointers as an option. I really don't see the > > support for > > >>> this in the overall discussion and I personally think such > > is a > > >>> *bad* idea. > > >>> > > >>> I'd prefer that any references to the "stable pointer" > > option be > > >>> removed from the document. > > >>> > > >>> Thanks, > > >>> > > >>> Lou > > >>> > > >>> On 10/15/2024 2:22 AM, > > [email protected]<mailto:[email protected] > > > > <mailto:[email protected]%3cmailto:[email protected]>> > > wrote: > > >>> > Hi Andy, > > >>> > > > >>> > RFC8340 leaves it to the authors to include it or not. > > It uses > > >>> statements such as "When long diagrams are included in a > > document, > > >>> .." > > >>> > > > >>> > An outcome of the discussion is that we can't impose one > > option > > >>> here. For example, the current situation is that we do already > > >>> have RFCs (RFC7407, RFC9182, RFC9291, etc.) that do not > > include > > >>> the full trees because these are too long, the narrative > > text is > > >>> good enough, the document itself is +150 pages, etc. Also, > > >>> including pages and pages of text that exceeds the max > > line is not > > >>> convenient for readers. > > >>> > > > >>> > The new guidelines include a provision for when the full > > tree is > > >>> not included for better consistency among published documents. > > >>> > > > >>> > Cheers, > > >>> > Med > > >>> > > > >>> >> -----Message d'origine----- > > >>> >> De : Andy Bierman > > <[email protected]<mailto:[email protected] > > <mailto:[email protected]%3cmailto:[email protected]>>> > > Envoyé : lundi 14 > > >>> octobre 2024 > > >>> >> 18:24 À : BOUCADAIR Mohamed INNOV/NET > > >>> > > <[email protected]<mailto:[email protected] > > > > <mailto:[email protected]%3cmailto:[email protected]>>> > > >>> >> Cc : Mahesh Jethanandani > > <[email protected]<mailto:[email protected] > > <mailto:[email protected]%3cmailto:[email protected]>>>; > > Lou Berger > > >>> >> <[email protected]<mailto:[email protected] > > <mailto:[email protected]%3cmailto:[email protected]>>>; > > [email protected]<mailto:[email protected] > > <mailto:[email protected]%3cmailto:[email protected]>>; > > draft-ietf-netmod- > > >>> >> [email protected]<mailto:[email protected] > > <mailto:[email protected]%3cmailto:[email protected]>>; > > Jan Lindblad <[email protected]<mailto:[email protected] > > <mailto:[email protected]%3cmailto:[email protected]>>>; Kent > > >>> Watsen > > >>> >> <[email protected]<mailto:[email protected] > > <mailto:[email protected]%3cmailto:[email protected]>>> > > Objet : Re: [netmod] WGLC on > > >>> >> draft-ietf-netmod-rfc8407bis > > >>> >> > > >>> >> > > >>> >> Hi, > > >>> >> > > >>> >> IMO we do not need new procedures to save the reader > > from a few > > >>> extra > > >>> >> pages of YANG tree diagram text. > > >>> >> > > >>> >> This is the only option that makes sense to me: > > >>> >> > > >>> >> * Include the full tree in an appendix. > > >>> >> > > >>> >> Andy > > >>> >> > > >>> >> On Sun, Oct 13, 2024 at 10:19 PM > > <[email protected]<mailto:[email protected] > > > > <mailto:[email protected]%3cmailto:[email protected]>>> > > >>> >> wrote: > > >>> >> > > >>> >>> Hi Mahesh, > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> Yes, this refers to the main body per the structure in > > >>> >> rfc7322#section-4. > > >>> >>> Updated accordingly. > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> The diff is available using the same link: Diff: > > >>> >>> draft-ietf-netmod-rfc8407bis.txt - draft-ietf-netmod- > > >>> >> rfc8407bis.txt > > >>> >> > > >>> > > <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > > > > <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%252><https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%252> > > >>> >> Faut > > >>> >>> hor- > > >>> >> tools.ietf.org > > > > <http://tools.ietf.org/><http://tools.ietf.org/>%2Fapi%2Fiddiff%3Furl_1%3Dhttps%3A%2F%2Fnetmod- > > >>> wg.gi > > >>> >>> thub.io > > <http://thub.io/><http://thub.io/>%2Frfc8407bis%2Fdraft-ietf-netmod- > > >>> >> rfc8407bis.txt%26url_2%3Dhttp > > >>> >>> s%3A%2F%2Fnetmod-wg.github.io > > > > <http://2fnetmod-wg.github.io/><http://2fnetmod-wg.github.io/>%2Frfc8407bis%2Flong- > > >>> trees%2Fdraft- > > >>> >> ietf-n > > >>> >>> etmod- > > >>> >> > > >>> > > rfc8407bis.txt&data=05%7C02%7Cmohamed.boucadair%40orange.com > > <http://40orange.com/><http://40orange.com/>%7C3 > > >>> >> > > >>> > > 60a053d61314c7851bc08dcec6c99f5%7C90c7a20af34b40bfbc48b9253b6f5d20 > > >>> >> %7C0 > > >>> >> > > >>> > > %7C0%7C638645198411517106%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw > > >>> >> MDAi > > >>> >> > > >>> > > LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata= > > >>> >> PUXU > > >>> >>> FFa2G1oGYjtnRYtC9hFJkRu5Nx%2FISQob3izoYds%3D&reserved=0> > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> Thanks. > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> Cheers, > > >>> >>> > > >>> >>> Med > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> *De :* Mahesh Jethanandani > > <[email protected]<mailto:[email protected] > > <mailto:[email protected]%3cmailto:[email protected]>>> > > *Envoyé > > >>> :* > > >>> >> samedi > > >>> >>> 12 octobre 2024 01:54 *À :* BOUCADAIR Mohamed INNOV/NET > > >>> >>> > > <[email protected]<mailto:[email protected] > > > > <mailto:[email protected]%3cmailto:[email protected]>>> > > *Cc :* Lou Berger > > >>> >> <[email protected]<mailto:[email protected] > > <mailto:[email protected]%3cmailto:[email protected]>>>; > > >>> >>> [email protected]<mailto:[email protected] > > <mailto:[email protected]%3cmailto:[email protected]>>; > > > > [email protected]<mailto:[email protected] > > > > <mailto:[email protected]%3cmailto:[email protected]>>; > > Jan > > >>> >> Lindblad > > >>> >>> <[email protected]<mailto:[email protected] > > <mailto:[email protected]%3cmailto:[email protected]>>>; > > Kent Watsen <[email protected]<mailto:[email protected] > > <mailto:[email protected]%3cmailto:[email protected]>>> > > >>> *Objet > > >>> >> :* Re: > > >>> >>> [netmod] WGLC on draft-ietf-netmod-rfc8407bis > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> Hi Med, > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> Speaking as a contributor ... > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> On Oct 11, 2024, at 8:47 AM, > > [email protected]<mailto:[email protected] > > > > <mailto:[email protected]%3cmailto:[email protected]>> > > >>> wrote: > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> Hi Lou, Kent, all, > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> Taking into account the feedback received so far, I > > suggest > > >>> the > > >>> >>> following > > >>> >>> change: > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> OLD: > > >>> >>> > > >>> >>> YANG tree diagrams provide a concise > > representation of a > > >>> YANG > > >>> >>> module > > >>> >>> > > >>> >>> and SHOULD be included to help readers understand YANG > > >>> module > > >>> >>> > > >>> >>> structure. If the complete tree diagram for a module > > >>> becomes > > >>> >> long > > >>> >>> (more than 2 pages, typically), the diagram SHOULD be > > >>> split > > >>> >> into > > >>> >>> several smaller diagrams (a.k.a subtrees). For the > > >>> reader's > > >>> >>> > > >>> >>> convenience, a subtree should fit within a page. > > If the > > >>> >> complete > > >>> >>> tree diagram is too long (more than 5 pages, > > typically) > > >>> even > > >>> >> with > > >>> >>> groupings unexpanded (Section 2.2 of [RFC8340]), the > > >>> authors > > >>> >> SHOULD > > >>> >>> NOT include it in the document. A stable pointer to > > >>> retrieve > > >>> >> the > > >>> >>> full tree MAY be included. > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> NEW: > > >>> >>> > > >>> >>> YANG tree diagrams provide a concise > > representation of a > > >>> YANG > > >>> >>> module > > >>> >>> > > >>> >>> and SHOULD be included to help readers understand YANG > > >>> module > > >>> >>> > > >>> >>> structure. If the complete tree diagram for a module > > >>> becomes > > >>> >> long > > >>> >>> (more than 2 pages, typically), the diagram SHOULD be > > >>> split > > >>> >> into > > >>> >>> several smaller diagrams (a.k.a subtrees). For the > > >>> reader's > > >>> >>> > > >>> >>> convenience, a subtree should fit within a page. > > If the > > >>> >> complete > > >>> >>> tree diagram is too long (more than 5 pages, > > typically) > > >>> even > > >>> >> with > > >>> >>> groupings unexpanded (Section 2.2 of [RFC8340]), the > > >>> authors > > >>> >> SHOULD > > >>> >>> NOT include it in the main document. Instead, > > authors MAY > > >>> >> consider > > >>> >>> the following options: > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> [mj] Not clear what you mean by “main document”. Do > > you mean > > >>> the > > >>> >>> normative section of the document? If so, please edit > > it to > > >>> say > > >>> >> that. > > >>> >>> > > >>> >>> > > >>> >>> Thanks > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> * Provide only a stable pointer to retrieve the full > > >>> tree. > > >>> >> The > > >>> >>> full > > >>> >>> > > >>> >>> tree is thus not provided at all. > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> * Include a note about how to generate the full tree. > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> * A combination of the first and second bullets. > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> * Include the full tree in an appendix. > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> For convenience: > > >>> >>> > > >>> >>> - Diff: Diff: draft-ietf-netmod-rfc8407bis.txt - > > >>> >>> draft-ietf-netmod-rfc8407bis.txt > > >>> >>> > > >>> >> > > >>> > > <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > > > > <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%252><https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%252> > > >>> >> Fauthor- > > >>> >> tools.ietf.org > > > > <http://tools.ietf.org/><http://tools.ietf.org/>%2Fapi%2Fiddiff%3Furl_1%3Dhttps%3A%2F%2Fnetmod- > > >>> >> wg.github.io > > > > <http://wg.github.io/><http://wg.github.io/>%2Frfc8407bis%2Fdraft-ietf-netmod- > > >>> >> rfc8407bis.txt%26url_2%3Dhttps%3A%2F%2Fnetmod- > > >>> >> wg.github.io > > > > <http://wg.github.io/><http://wg.github.io/>%2Frfc8407bis%2Flong-trees%2Fdraft-ietf-netmod- > > >>> >> > > >>> > > rfc8407bis.txt&data=05%7C02%7Cmohamed.boucadair%40orange.com > > <http://40orange.com/><http://40orange.com/>%7C360 > > >>> >> > > >>> > > a053d61314c7851bc08dcec6c99f5%7C90c7a20af34b40bfbc48b9253b6f5d20%7 > > >>> >> > > >>> > > C0%7C0%7C638645198411540339%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj > > >>> >> > > >>> > > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C& > > >>> >> > > >>> > > sdata=68CtKMDgxzWjl4IsKqxJlSLpvOHAflb0Cv5TQFwExN0%3D&reserved=0> > > >>> >>> - PR: > > >>> >>> > > >>> >> > > >>> > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > > >>> >> gith > > >>> >>> ub.com <http://ub.com/><http://ub.com/>%2Fnetmod- > > >>> >> wg%2Frfc8407bis%2Fpull%2F70%2Ffiles&data=05%7C02%7Cmoh > > >>> >> > > >>> amed.boucadair%40orange.com > > > > <http://40orange.com/><http://40orange.com/>%7C360a053d61314c7851bc08dcec6c99f5%7C9 > > >>> >> 0c7a > > >>> >> > > >>> > > 20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638645198411557810%7CUnknown > > >>> >> %7CT > > >>> >> > > >>> > > WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ > > >>> >> XVCI > > >>> >> > > >>> > > 6Mn0%3D%7C0%7C%7C%7C&sdata=%2BkYIcnZV7Wwi4tUS6uOObRMUMcdt4xxyiNBOW > > >>> >> QXGp > > >>> >>> wE%3D&reserved=0 > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> Better? > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> Cheers, > > >>> >>> > > >>> >>> Med > > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> *De :* BOUCADAIR Mohamed INNOV/NET > > >>> >>> *Envoyé :* mercredi 2 octobre 2024 11:13 *À :* 'Lou > > Berger' > > >>> >>> <[email protected]<mailto:[email protected] > > <mailto:[email protected]%3cmailto:[email protected]>>>; > > [email protected]<mailto:[email protected] > > <mailto:[email protected]%3cmailto:[email protected]>>; > > >>> >>> > > > > [email protected]<mailto:[email protected] > > > > <mailto:[email protected]%3cmailto:[email protected]>>; > > Jan Lindblad (jlindbla) > > >>> < > > >>> >>> [email protected]<mailto:[email protected] > > <mailto:[email protected]%3cmailto:[email protected]>>> *Cc > > :* Kent Watsen > > <[email protected]<mailto:[email protected] > > <mailto:[email protected]%3cmailto:[email protected]>>> > > >>> >> *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 > > <[email protected]<mailto:[email protected] > > <mailto:[email protected]%3cmailto:[email protected]>>> *Envoyé > > :* mardi 1 > > >>> octobre 2024 > > >>> >>> 13:37 *À :* BOUCADAIR Mohamed INNOV/NET > > >>> >> > > <[email protected]<mailto:[email protected] > > > > <mailto:[email protected]%3cmailto:[email protected]>>>; > > >>> >>> [email protected]<mailto:[email protected] > > <mailto:[email protected]%3cmailto:[email protected]>>; > > > > [email protected]<mailto:[email protected] > > > > <mailto:[email protected]%3cmailto:[email protected]>>; > > Jan > > >>> >> Lindblad > > >>> >>> (jlindbla) > > <[email protected]<mailto:[email protected] > > <mailto:[email protected]%3cmailto:[email protected]>>> > > >>> >>> *Cc :* Kent Watsen > > <[email protected]<mailto:[email protected] > > <mailto:[email protected]%3cmailto:[email protected]>>> > > *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, > > [email protected]<mailto:[email protected] > > > > <mailto:[email protected]%3cmailto:[email protected]>> > > 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. > > > > ____________________________________________________________________________________________________________ > > 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 -- [email protected] > To unsubscribe send an email to [email protected] -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
