[netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis
Andy Bierman <andy@yumaworks.com> Mon, 21 October 2024 21:55 UTC
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15DEDC239D72 for <netmod@ietfa.amsl.com>; Mon, 21 Oct 2024 14:55:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ey6rfGk1ilb for <netmod@ietfa.amsl.com>; Mon, 21 Oct 2024 14:55:00 -0700 (PDT)
Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1B04C23A45D for <netmod@ietf.org>; Mon, 21 Oct 2024 14:55:00 -0700 (PDT)
Received: by mail-pj1-x102c.google.com with SMTP id 98e67ed59e1d1-2e2a96b242cso699317a91.3 for <netmod@ietf.org>; Mon, 21 Oct 2024 14:55:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks.com; s=google; t=1729547700; x=1730152500; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ITDpJyNtg/sBUrWholu8pwFw+HKQyiyaHrJuCCakkiE=; b=EfCff1mbHva1x27RPHUbQEhk59p7woc39DGcWUgh7Z8HnBhgyNPFBbspH7ieCd/PdT hOVIPenEbYMTSbt/Wbkt8qqoGPg14/aBgvEvB3dKsPv8+1uRHg2pagML4pWThr5MAHfe J1KwsmRSuy/wjf9T3T1NVfwNpNAoKO3oO77+gecKcTGQOmHSvyFVrbgSFZyiPWjgb2vE oIwhQFM4ooUVW5uOTVAIM73kVoU0rd3TAs2z5j9kxPz/iP0ZX/Hd+GovxtxhLXy/aJ68 611dq0byzMA9j9y78XohzDSxpTpcStMc5vDQIWZsaV7mLWC3ICCM7dc67I/0mNojUnCz FiuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729547700; x=1730152500; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ITDpJyNtg/sBUrWholu8pwFw+HKQyiyaHrJuCCakkiE=; b=R3wNOCk9a+KqD22H5jKTsJCHsyvY08jtKR2VJDXfg+tl7pm9Wf8XEJc32Tp/e03Ez8 Lojfi/0gGbHpKv4vRqOCGoHIHE5CeRIw6TlBbvr5puM1PEZH2jGeaa8h3jZjPscdQ3ay Rbcd1Q1eXVVjwpMM4evKPIWJBM1bbNlSCq8V+CA4mZLs3lzPLdg0gbxy9KbL3RYc2SzL Gfhe/1KM4WDMFiyvpjQFpUHsWVYEak6cG6z79rjctF5g7xOnmJ5i561fDlJJI67X9sq4 1JfKahKnm1lVKZHsXAi4jAUh21DbJ0dblhR/chpakOcoQpO1nK+xHsw+88MjebHwWKGc 9TiQ==
X-Forwarded-Encrypted: i=1; AJvYcCVsELiA7EoApGk2caTPD46ftiPRIK/AYGc3iBl80GwOXvVMuwk2ZkrOnp/DRzHdlzF2mfbRZBI=@ietf.org
X-Gm-Message-State: AOJu0YykZETzfq+wl70tlPeVkjCHVZXc7a/QXuJdPwcY6fgSjYFcgQHo 9a0LxpZJlmXHcdqVSVi34SQn2qHjaUMohs1vWWTw7O1Xq65gPCi5ompRkDr8TtWZhucshKwxRth uu7d9NsZtcu5iDtj86+LZ8R5+XSR4kh5r7UO0QQ==
X-Google-Smtp-Source: AGHT+IE12IE2Bt/1LEgsG5BJiHi8TkJykpImmqK8t7117LTLV9eUY4gaf3JbOV0VP3LPvt9kOG2rRXU0UvAvOIocQrI=
X-Received: by 2002:a17:90b:2249:b0:2e2:c04b:da94 with SMTP id 98e67ed59e1d1-2e5618d0f69mr6309583a91.5.1729547699666; Mon, 21 Oct 2024 14:54:59 -0700 (PDT)
MIME-Version: 1.0
References: <0100018f4e31af70-fd072689-4a32-4547-b32c-ce06781df2b5-000000@email.amazonses.com> <0100019211083dbf-15ebf66a-653f-487c-b15e-15380177c80f-000000@email.amazonses.com> <e607aa67-7c53-419c-aa5f-30c74aae7d96@labn.net> <DU2PR02MB101600DEE6F92ED7C4F88709988772@DU2PR02MB10160.eurprd02.prod.outlook.com> <d7df2a1d-3105-4707-8d9b-fb4aa44695a9@labn.net> <DU2PR02MB10160F06D1B981EF21FD3E2AE88792@DU2PR02MB10160.eurprd02.prod.outlook.com> <7808C613-1D00-4CD9-AE77-CD31A5DBA64E@gmail.com> <DU2PR02MB101607E90C5B149C450030DA188442@DU2PR02MB10160.eurprd02.prod.outlook.com> <CABCOCHR7350peqjhmRzvaP36uUvaZ2TyRwTvEinBs_o8B_HUCg@mail.gmail.com> <DU2PR02MB10160E0626A79F0128A5F9BBC88452@DU2PR02MB10160.eurprd02.prod.outlook.com> <dab6e745-987c-44b2-b484-a0a4e4af18a4@labn.net>
In-Reply-To: <dab6e745-987c-44b2-b484-a0a4e4af18a4@labn.net>
From: Andy Bierman <andy@yumaworks.com>
Date: Mon, 21 Oct 2024 14:54:48 -0700
Message-ID: <CABCOCHSOZj12DyWx3of8tpWW1qaUsBqRMe=4hKAWt2P1SoZ0Vw@mail.gmail.com>
To: Lou Berger <lberger@labn.net>
Content-Type: multipart/alternative; boundary="00000000000042e36c062503b40b"
Message-ID-Hash: FOV62NPYMETMJBBSSSO3NCDANVEGWGE7
X-Message-ID-Hash: FOV62NPYMETMJBBSSSO3NCDANVEGWGE7
X-MailFrom: andy@yumaworks.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-netmod.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "netmod@ietf.org" <netmod@ietf.org>, "draft-ietf-netmod-rfc8407bis@ietf.org" <draft-ietf-netmod-rfc8407bis@ietf.org>, Jan Lindblad <jlindbla@cisco.com>, Kent Watsen <kent+ietf@watsen.net>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis
List-Id: NETMOD WG list <netmod.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/dBeF6_HxIk28GkRe41onr96oY9s>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Owner: <mailto:netmod-owner@ietf.org>
List-Post: <mailto:netmod@ietf.org>
List-Subscribe: <mailto:netmod-join@ietf.org>
List-Unsubscribe: <mailto:netmod-leave@ietf.org>
On Mon, Oct 21, 2024 at 2:38 PM Lou Berger <lberger@labn.net> wrote: > 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. > > +1 Still do not understand the problem caused by YANG trees over 5 pages. > Thanks, > > Lou > Andy > > On 10/15/2024 2:22 AM, mohamed.boucadair@orange.com 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 <andy@yumaworks.com> > >> Envoyé : lundi 14 octobre 2024 18:24 > >> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com> > >> Cc : Mahesh Jethanandani <mjethanandani@gmail.com>; Lou Berger > >> <lberger@labn.net>; netmod@ietf.org; draft-ietf-netmod- > >> rfc8407bis@ietf.org; Jan Lindblad <jlindbla@cisco.com>; Kent > >> Watsen <kent+ietf@watsen.net> > >> 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 <mohamed.boucadair@orange.com> > >> 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 > >> Faut > >>> hor- > >> tools.ietf.org%2Fapi%2Fiddiff%3Furl_1%3Dhttps%3A%2F%2Fnetmod-wg.gi > >>> thub.io%2Frfc8407bis%2Fdraft-ietf-netmod- > >> rfc8407bis.txt%26url_2%3Dhttp > >>> s%3A%2F%2Fnetmod-wg.github.io%2Frfc8407bis%2Flong-trees%2Fdraft- > >> ietf-n > >>> etmod- > >> rfc8407bis.txt&data=05%7C02%7Cmohamed.boucadair%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 <mjethanandani@gmail.com> *Envoyé :* > >> samedi > >>> 12 octobre 2024 01:54 *À :* BOUCADAIR Mohamed INNOV/NET > >>> <mohamed.boucadair@orange.com> *Cc :* Lou Berger > >> <lberger@labn.net>; > >>> netmod@ietf.org; draft-ietf-netmod-rfc8407bis@ietf.org; Jan > >> Lindblad > >>> <jlindbla@cisco.com>; Kent Watsen <kent+ietf@watsen.net> *Objet > >> :* Re: > >>> [netmod] WGLC on draft-ietf-netmod-rfc8407bis > >>> > >>> > >>> > >>> > >>> Hi Med, > >>> > >>> > >>> > >>> Speaking as a contributor ... > >>> > >>> > >>> > >>> On Oct 11, 2024, at 8:47 AM, mohamed.boucadair@orange.com 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 > >> Fauthor- > >> tools.ietf.org%2Fapi%2Fiddiff%3Furl_1%3Dhttps%3A%2F%2Fnetmod- > >> wg.github.io%2Frfc8407bis%2Fdraft-ietf-netmod- > >> rfc8407bis.txt%26url_2%3Dhttps%3A%2F%2Fnetmod- > >> wg.github.io%2Frfc8407bis%2Flong-trees%2Fdraft-ietf-netmod- > >> rfc8407bis.txt&data=05%7C02%7Cmohamed.boucadair%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%2Fnetmod- > >> wg%2Frfc8407bis%2Fpull%2F70%2Ffiles&data=05%7C02%7Cmoh > >> amed.boucadair%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' > >>> <lberger@labn.net>; netmod@ietf.org; > >>> draft-ietf-netmod-rfc8407bis@ietf.org; Jan Lindblad (jlindbla) < > >>> jlindbla@cisco.com> *Cc :* Kent Watsen <kent+ietf@watsen.net> > >> *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 <lberger@labn.net> > >>> *Envoyé :* mardi 1 octobre 2024 13:37 > >>> *À :* BOUCADAIR Mohamed INNOV/NET > >> <mohamed.boucadair@orange.com>; > >>> netmod@ietf.org; draft-ietf-netmod-rfc8407bis@ietf.org; Jan > >> Lindblad > >>> (jlindbla) <jlindbla@cisco.com> > >>> *Cc :* Kent Watsen <kent+ietf@watsen.net> *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%2Farch%2Fmsg%2Fnetmod%2F0Q0YiyNi15V-Szzf5awLVh- > >> 15_c%2 > >> F&data=05%7C02%7Cmohamed.boucadair%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, mohamed.boucadair@orange.com 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%2Farch%2Fmsg%2Fnetmod%2F- > >> b2HX0XUK49qJB19LHu6MC0D9zc%2F&data=05%7C02%7Cmohamed.boucadair%40o > >> 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. >
- [netmod] WGLC on draft-ietf-netmod-rfc8407bis Kent Watsen
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis Lou Berger
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis mohamed.boucadair
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis Kent Watsen
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis Qin Wu
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis Lou Berger
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis Mahesh Jethanandani
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis Kent Watsen
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis mohamed.boucadair
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis mohamed.boucadair
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis Lou Berger
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis Kent Watsen
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis Reshad Rahman
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis mohamed.boucadair
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis tom petch
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis mohamed.boucadair
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis mohamed.boucadair
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis mohamed.boucadair
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis Mahesh Jethanandani
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis mohamed.boucadair
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis Andy Bierman
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis mohamed.boucadair
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis Lou Berger
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis mohamed.boucadair
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis tom petch
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis Andy Bierman
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis mohamed.boucadair
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis Lou Berger
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis mohamed.boucadair
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis Lou Berger
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis Andy Bierman
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis mohamed.boucadair
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis mohamed.boucadair
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis Lou Berger
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis mohamed.boucadair
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis Lou Berger
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis Jürgen Schönwälder
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis Italo Busi
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis Jürgen Schönwälder
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis Lou Berger
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis mohamed.boucadair
- [netmod] It's not junk! was Re: Re: WGLC on draft… tom petch
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis mohamed.boucadair
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis Italo Busi
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis Lou Berger
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis mohamed.boucadair
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis Jürgen Schönwälder
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis Kent Watsen
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis mohamed.boucadair
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis Benoit Claise
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis Andy Bierman
- [netmod] Re: WGLC on draft-ietf-netmod-rfc8407bis mohamed.boucadair