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

[Jürgen Schönwälder <[e-mail]>]

A capitalized SHOULD, really?

Here is my counter proposal: Make no change to what is currently in
RFC 8407, the pointer to RFC 8340 is sufficient.

/js

On Tue, Nov 05, 2024 at 06:38:55PM +0000, Lou Berger wrote:
> Med,
> 
> I think we're going in circles here how about this:
> 
> OLD (current RFC)
> 
> 3.4.  Tree Diagrams
> 
>    YANG tree diagrams provide a concise representation of a YANG module
>    and SHOULD be included to help readers understand YANG module
>    structure.  Guidelines on tree diagrams can be found in Section 3 of
>    [RFC8340].
> 
>    If YANG tree diagrams are used, then an informative reference to the
>    YANG tree diagrams specification MUST be included in the document.
>    Refer to Section 2.2 of [RFC8349] for an example of such a reference.
> 
> NEW (changes are in bold)
> 
> 3.4.  Tree Diagrams
> 
>    YANG tree diagrams provide a concise representation of a YANG module
>    and SHOULD be included to help readers understand YANG module
>    structure.  Guidelines on tree diagrams can be found in Section 3 of
>    [RFC8340]. *Tree diagrams longer than one page SHOULD be included*
> *   in an appendix, i.e and not in the main body of the document.*
> 
>    If YANG tree diagrams are used, then an informative reference to the
>    YANG tree diagrams specification MUST be included in the document.
>    Refer to Section 2.2 of [RFC8349] for an example of such a reference.
> 
> Lou
> 
> On 11/5/2024 8:50 AM, [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.

> _______________________________________________
> netmod mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]


-- 
Jürgen Schönwälder              Constructor University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany