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]> 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]>> >>> Envoyé : lundi 21 octobre 2024 23:38 >>> À : BOUCADAIR Mohamed INNOV/NET >>> <[email protected]<mailto:[email protected]>>; >>> Andy Bierman <[email protected]<mailto:[email protected]>> >>> Cc : Mahesh Jethanandani >>> <[email protected]<mailto:[email protected]>>; >>> [email protected]<mailto:[email protected]>; >>> [email protected]<mailto:[email protected]>; >>> Jan >>> Lindblad <[email protected]<mailto:[email protected]>>; Kent Watsen >>> <[email protected]<mailto:[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]> 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]>> Envoyé >>> >> : lundi 14 >>> octobre 2024 >>> >> 18:24 À : BOUCADAIR Mohamed INNOV/NET >>> <[email protected]<mailto:[email protected]>> >>> >> Cc : Mahesh Jethanandani >>> >> <[email protected]<mailto:[email protected]>>; Lou Berger >>> >> <[email protected]<mailto:[email protected]>>; >>> >> [email protected]<mailto:[email protected]>; draft-ietf-netmod- >>> >> [email protected]<mailto:[email protected]>; Jan Lindblad >>> >> <[email protected]<mailto:[email protected]>>; Kent >>> Watsen >>> >> <[email protected]<mailto:[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]>> >>> >> 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> >>> >> 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]>> *Envoyé >>> :* >>> >> samedi >>> >>> 12 octobre 2024 01:54 *À :* BOUCADAIR Mohamed INNOV/NET >>> >>> <[email protected]<mailto:[email protected]>> *Cc >>> >>> :* Lou Berger >>> >> <[email protected]<mailto:[email protected]>>; >>> >>> [email protected]<mailto:[email protected]>; >>> >>> [email protected]<mailto:[email protected]>; >>> >>> Jan >>> >> Lindblad >>> >>> <[email protected]<mailto:[email protected]>>; Kent Watsen >>> >>> <[email protected]<mailto:[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]> >>> 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> >>> >> 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]>>; >>> >>> [email protected]<mailto:[email protected]>; >>> >>> [email protected]<mailto:[email protected]>; >>> >>> Jan Lindblad (jlindbla) >>> < >>> >>> [email protected]<mailto:[email protected]>> *Cc :* Kent Watsen >>> >>> <[email protected]<mailto:[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]>> *Envoyé >>> >>> :* mardi 1 >>> octobre 2024 >>> >>> 13:37 *À :* BOUCADAIR Mohamed INNOV/NET >>> >> <[email protected]<mailto:[email protected]>>; >>> >>> [email protected]<mailto:[email protected]>; >>> >>> [email protected]<mailto:[email protected]>; >>> >>> Jan >>> >> Lindblad >>> >>> (jlindbla) <[email protected]<mailto:[email protected]>> >>> >>> *Cc :* Kent Watsen <[email protected]<mailto:[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]> 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.
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
