[netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis

[Lou Berger <[e-mail]>]

thanks (and Yay!)

On 11/6/2024 1:44 AM, [e-mail] wrote:
>
> Hi Lou,
>
> You should have done that earlier ;-)
>
> I can convince myself to live with this change.
>
> Cheers,
>
> Med
>
> *De :* Lou Berger <[e-mail]>
> *Envoyé :* mardi 5 novembre 2024 18:39
> *À :* BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> *Cc :* Jan Lindblad <[e-mail]>; [e-mail]
> *Objet :* Re: [netmod] WGLC on draft-ietf-netmod-rfc8407bis
>
> 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, [e-mail] wrote:
>
>     Hi Lou,
>
>     Please see inline.
>
>     Cheers,
>
>     Med
>
>     *De :* Lou Berger <[e-mail]> <mailto:[e-mail]>
>     *Envoyé :* mardi 5 novembre 2024 10:28
>     *À :* BOUCADAIR Mohamed INNOV/NET <[e-mail]>
>     <mailto:[e-mail]>
>     *Cc :* Jan Lindblad <[e-mail]>
>     <mailto:[e-mail]>; [e-mail]
>     *Objet :* Re: [netmod] WGLC on draft-ietf-netmod-rfc8407bis
>
>     Med
>
>     See inline
>
>     On 10/29/2024 8:20 AM, [e-mail] 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 <[e-mail]> <mailto:[e-mail]>
>         *Envoyé :* mardi 29 octobre 2024 12:34
>         *À :* BOUCADAIR Mohamed INNOV/NET
>         <[e-mail]>
>         <mailto:[e-mail]>; Lou Berger
>         <[e-mail]> <mailto:[e-mail]>; [e-mail]
>         *Cc :* Jan Lindblad <[e-mail]>
>         <mailto:[e-mail]>
>         *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 [e-mail] 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 <[e-mail]>
>             *Envoyé :* mardi 22 octobre 2024 17:29
>             *À :* BOUCADAIR Mohamed INNOV/NET
>             <[e-mail]>; Lou Berger
>             <[e-mail]>; Andy Bierman <[e-mail]>
>             *Cc :* Mahesh Jethanandani <[e-mail]>;
>             [e-mail]; [e-mail];
>             Jan Lindblad <[e-mail]>; Kent Watsen
>             <[e-mail]>
>             *Objet :* RE: [netmod] WGLC on draft-ietf-netmod-rfc8407bis
>
>             Med,
>
>             ----------
>             On October 22, 2024 8:22:47 AM
>             [e-mail] 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 <[e-mail]>
>             > Envoyé : mardi 22 octobre 2024 14:00
>             > À : BOUCADAIR Mohamed INNOV/NET
>             <[e-mail]>; Lou Berger
>             <[e-mail]>; Andy Bierman <[e-mail]>
>             > Cc : Mahesh Jethanandani <[e-mail]>;
>             [e-mail]; [e-mail];
>             Jan Lindblad <[e-mail]>; Kent Watsen
>             <[e-mail]>
>             > Objet : RE: [netmod] WGLC on draft-ietf-netmod-rfc8407bis
>             >
>             >
>             > Med,
>             >
>             > ----------
>             > On October 22, 2024 1:21:31 AM
>             [e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>
>             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
>             <[e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>>
>             >>> Envoyé : lundi 21 octobre 2024 23:38
>             >>> À : BOUCADAIR Mohamed INNOV/NET
>             <[e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>>;
>             >>> Andy Bierman
>             <[e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>>
>             >>> Cc : Mahesh Jethanandani
>             <[e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>>;
>             >>> [e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>;
>             [e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>;
>             Jan
>             >>> Lindblad <[e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>>;
>             Kent Watsen
>             <[e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>>
>             >>> 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,
>             [e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>
>             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
>             <[e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>>
>             Envoyé : lundi 14
>             >>> octobre 2024
>             >>> >> 18:24 À : BOUCADAIR Mohamed INNOV/NET
>             >>>
>             <[e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>>
>             >>> >> Cc : Mahesh Jethanandani
>             <[e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>>;
>             Lou Berger
>             >>> >> <[e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>>;
>             [e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>;
>             draft-ietf-netmod-
>             >>> >> [e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>;
>             Jan Lindblad <[e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>>;
>             Kent
>             >>> Watsen
>             >>> >> <[e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>>
>             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
>             <[e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>>
>             >>> >> 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
>             <[e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>>
>             *Envoyé
>             >>> :*
>             >>> >> samedi
>             >>> >>> 12 octobre 2024 01:54 *À :* BOUCADAIR Mohamed
>             INNOV/NET
>             >>> >>>
>             <[e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>>
>             *Cc :* Lou Berger
>             >>> >> <[e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>>;
>             >>> >>> [e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>;
>             [e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>;
>             Jan
>             >>> >> Lindblad
>             >>> >>> <[e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>>;
>             Kent Watsen
>             <[e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>>
>             >>> *Objet
>             >>> >> :* Re:
>             >>> >>> [netmod] WGLC on draft-ietf-netmod-rfc8407bis
>             >>> >>>
>             >>> >>>
>             >>> >>>
>             >>> >>>
>             >>> >>> Hi Med,
>             >>> >>>
>             >>> >>>
>             >>> >>>
>             >>> >>> Speaking as a contributor ...
>             >>> >>>
>             >>> >>>
>             >>> >>>
>             >>> >>> On Oct 11, 2024, at 8:47 AM,
>             [e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>
>             >>> 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'
>             >>> >>> <[e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>>;
>             [e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>;
>             >>> >>>
>             [e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>;
>             Jan Lindblad (jlindbla)
>             >>> <
>             >>> >>> [e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>>
>             *Cc :* Kent Watsen
>             <[e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>>
>             >>> >> *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
>             <[e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>>
>             *Envoyé :* mardi 1
>             >>> octobre 2024
>             >>> >>> 13:37 *À :* BOUCADAIR Mohamed INNOV/NET
>             >>> >>
>             <[e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>>;
>             >>> >>> [e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>;
>             [e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>;
>             Jan
>             >>> >> Lindblad
>             >>> >>> (jlindbla)
>             <[e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>>
>             >>> >>> *Cc :* Kent Watsen
>             <[e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>>
>             *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,
>             [e-mail]<mailto:[e-mail]
>             <mailto:[e-mail]%3cmailto:[e-mail]>>
>             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.
>
> ____________________________________________________________________________________________________________
> 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.