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

[Lou Berger <[e-mail]>]

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]>
> *Envoyé :* mardi 5 novembre 2024 10:28
> *À :* BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> *Cc :* Jan Lindblad <[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.