[Idr] Re: New Liaison Statement, "oLS to IETF on BGP data model"
Jeffrey Haas <jhaas@pfrc.org> Wed, 03 December 2025 17:08 UTC
Return-Path: <jhaas@pfrc.org>
X-Original-To: idr@mail2.ietf.org
Delivered-To: idr@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id EF5D394AF56F for <idr@mail2.ietf.org>; Wed, 3 Dec 2025 09:08:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvM_iZLCeklh for <idr@mail2.ietf.org>; Wed, 3 Dec 2025 09:08:37 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by mail2.ietf.org (Postfix) with ESMTP id B9B6094AF557 for <idr@ietf.org>; Wed, 3 Dec 2025 09:08:30 -0800 (PST)
Received: from smtpclient.apple (99-188-202-8.lightspeed.livnmi.sbcglobal.net [99.188.202.8]) by slice.pfrc.org (Postfix) with ESMTPSA id 3F99E1E24F; Wed, 3 Dec 2025 12:08:30 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_A9B8F698-5E86-476C-B62C-1178B3637146"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <PAUP264MB6756C5543E490A0137B5ACFA88D9A@PAUP264MB6756.FRAP264.PROD.OUTLOOK.COM>
Date: Wed, 03 Dec 2025 12:08:29 -0500
Message-Id: <9E7CE807-B904-4A9A-AAA4-68FDC94BD28C@pfrc.org>
References: <176377917609.1807088.18231834189018308158@dt-datatracker-5bd94c585b-wk4l4> <CAH6gdPwpL59w6tPxvTqbExUExRYotSETQFt3sFJwGdNEr47y2w@mail.gmail.com> <F5F747F2-F53F-4C18-809A-F8647157D73E@pfrc.org> <CAH6gdPwvtHSWvOPFE_YTbEWf-nbm7RPwVeFGzOZoi+0c1tzhvQ@mail.gmail.com> <PAUP264MB675670D0BFDC575A998A699688D9A@PAUP264MB6756.FRAP264.PROD.OUTLOOK.COM> <0882EAD9-5CF8-4F47-89B4-9ADA1015712B@gmail.com> <PAUP264MB6756C5543E490A0137B5ACFA88D9A@PAUP264MB6756.FRAP264.PROD.OUTLOOK.COM>
To: Mohamed Boucadair <mohamed.boucadair@orange.com>
X-Mailer: Apple Mail (2.3696.120.41.1.10)
Message-ID-Hash: DSGNDT7MJ7JRJHHVUOKRMKXPW5CGQRNS
X-Message-ID-Hash: DSGNDT7MJ7JRJHHVUOKRMKXPW5CGQRNS
X-MailFrom: jhaas@pfrc.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-idr.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Inter-Domain Routing Discussion List <idr@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Idr] Re: New Liaison Statement, "oLS to IETF on BGP data model"
List-Id: Inter-Domain Routing <idr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/W6JPyUpvnOFqdXK892lOxBN-FaU>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Owner: <mailto:idr-owner@ietf.org>
List-Post: <mailto:idr@ietf.org>
List-Subscribe: <mailto:idr-join@ietf.org>
List-Unsubscribe: <mailto:idr-leave@ietf.org>
> On Dec 3, 2025, at 11:21 AM, mohamed.boucadair@orange.com wrote: > > [mj] I am opposed to further split of the document at this stage. It will only further delay the publication of the module. There are common types/groupings that can be referenced/used by other modules in and outside of IETF by including the right set of modules. > [Med] I’m not sure there is extra delay that will be induced, but I think that this approach is worth to be considered by the WG to ease maintenance, usability, etc. I’m not expressing a preference, though. An underlying headache is that if the publication of dependent modules is done separately from the primary document that last call comments in one may cause failures in the other. Minimally, regardless of packaging, the bundle must proceed atomically to publication. A change in the packaging does address the module maintenance portion of this discussion. However, it does raise documentation consistency issues that having all artifacts in the same document acts as a forcing function at the editor level. In fairness to IDR, I'd suggest this portion of the conversation move elsewhere if it's to progress. These are very much the controversial discussion points covered by VELOCE. :-) -- Jeff
- [Idr] New Liaison Statement, "oLS to IETF on BGP … Liaison Statement Management Tool
- [Idr] Re: New Liaison Statement, "oLS to IETF on … Ketan Talaulikar
- [Idr] Re: New Liaison Statement, "oLS to IETF on … tom petch
- [Idr] Re: New Liaison Statement, "oLS to IETF on … Adrian Farrel
- [Idr] Re: New Liaison Statement, "oLS to IETF on … song.xueyan2
- [Idr] Re: New Liaison Statement, "oLS to IETF on … Jeffrey Haas
- [Idr] Re: New Liaison Statement, "oLS to IETF on … Jeffrey Haas
- [Idr] Re: New Liaison Statement, "oLS to IETF on … Ketan Talaulikar
- [Idr] Re: New Liaison Statement, "oLS to IETF on … mohamed.boucadair
- [Idr] Re: New Liaison Statement, "oLS to IETF on … Mahesh Jethanandani
- [Idr] Re: New Liaison Statement, "oLS to IETF on … Jeffrey Haas
- [Idr] Re: New Liaison Statement, "oLS to IETF on … song.xueyan2
- [Idr] Re: New Liaison Statement, "oLS to IETF on … mohamed.boucadair
- [Idr] Re: New Liaison Statement, "oLS to IETF on … Jeffrey Haas
- [Idr] Re: New Liaison Statement, "oLS to IETF on … song.xueyan2