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

[Lou Berger <[e-mail]>]

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> :

    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.

> * recommends against including too long trees in the main doc, while 
> Section 3 of RFC8340has 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?

Thanks,

Lou


> Cheers,
>
> Med
>
> *De :* Lou Berger <[e-mail]>
> *Envoyé :* mardi 29 octobre 2024 12:34
> *À :* BOUCADAIR Mohamed INNOV/NET <[e-mail]>; Lou 
> Berger <[e-mail]>; [e-mail]
> *Cc :* Jan Lindblad <[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.