Return-Path: 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 400AB94A0BCF for ; Wed, 3 Dec 2025 08:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 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, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 YzIMb8-7KZJy for ; Wed, 3 Dec 2025 08:06:12 -0800 (PST) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 mail2.ietf.org (Postfix) with ESMTPS id 8C3A494A0BCA for ; Wed, 3 Dec 2025 08:06:12 -0800 (PST) Received: by mail-pl1-x630.google.com with SMTP id d9443c01a7336-2953e415b27so75656075ad.2 for ; Wed, 03 Dec 2025 08:06:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764777965; x=1765382765; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=JO+ak8ENyG+XAeOQqleZbYaeHPZNcGORTDPq749HABM=; b=YyT9ebgAb0SgEjubgx8QY5Aw675wWpWzvOrPJixHVw+N14qCSAkXQLXOYY27jYEgwL 5SeycVYz8vwNQHmvnHA8i59Sm0aq8aGQi+RU+dktMQNquqUoeMtcr5d/2olrCETohXG0 Jr0IR+dpheWxfIbCuYUDR8Eq1hmdEOMoAEuaCgf4lQq9Rk3agd/EDdmPotBn5WIbsK1+ aICfktG0q/TlN+V6HEd07lvivmtzjZexVvGtKNamOnMjPB4a5pxL3QfHl9/ougNKA1/l Xgqs0LI6dVp0umS/mda1wVAq4Xhlb7bEZvWXTJ0lisVn/XuXqvIyphjD4Fc5HGdV6XxB f+IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764777965; x=1765382765; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JO+ak8ENyG+XAeOQqleZbYaeHPZNcGORTDPq749HABM=; b=RN3ThyObHweTlYRVrpzmb7gQ578EBPLwrUutweNp+SXoa/m4tsfBOuCQyWlu+EEtuL g/1GpZTqhGkdeNQuL5IaWG4G4S5VSSmcWekLaG4hwuXcwaDs14Ln0MI3+4lbCXCz89c4 SMfxEb4d7xfyBvPOrY/uqOzHgx/niYC1odNWCXMvsA0HRb3lc/jCOsWn2OeJE3VI/ZpB mFXFZGk1cNP3xkYghCqQeluX/tjxMbCEhdEd1etqOBkROTG/Z0ZHCW/Xk3TU6i6uDHFF 5MnV7v8BbFqEXKLr3OCqqm7bitBS6iCWTWYttzdsr+vtRiZ7qIP+NNE5GI90Vm9CxA5q HI3g== X-Forwarded-Encrypted: i=1; AJvYcCWYTAXboSAQYGOg9wM+4VDZirqTqKF1ylNoXl5GHVn+hgIuSNZaU/W3i9SQ7eKh9fZwzfM=@ietf.org X-Gm-Message-State: AOJu0Yyq4USC7mAi6/aiIoKFCm/eg5DDJv1UONnI+LNCSJoT5KTaW35e FlTP6S9ojE05/o3WXlxoWjulmXlavqzRQDiotFbK4HAbi5fRye2M4E/5gD+A5A== X-Gm-Gg: ASbGncu4mZwO+d5wXjggCRau+6NmdnlKS+6KvLqYn8LsSMP4ZybCQ8hlPypsi4fsibP wJ3648auvRWD3g6abu3v5tjgn8A5qc3pQiQalDh39c7o2gAeVsevzbqGHMftUqDPxrpbJKnwPMS bZ3bx4++Qsebzxr8HT8EDZudIDWCte43Ul2GdsMrhJZD790CqHQ/nRhAuHXx9Ksdjo04KFMc9kj C1RaruNiXxFl8F4oGPlC1H5TDAssDDecMvz01swFcTPGQadwUTKKKE39m0RbVmIosVhUhn1OLbw yKE4hgqGM9m/Wm6/wNRK82moTDT76dLa7h+i5rsllZQhyFP9M+EZEwK/CVMiUWKQGpZLG43AclD 1DbSCHxT/A3lsi5G5zye6Mrok5svmhevzwPLqU2XrzJTDbRz96eCxdzrRQQD19BkaHPy4FpPLYs hFa/fyUMmZLY2E0C9AK/GydIaZEZCG9OfT7rlElEz83OE1irWxH+9jpCADqBslvr8yT5E= X-Google-Smtp-Source: AGHT+IFL+maXR+SUrCfXsXuua4PEhkUJWJRCI6AbbfSdIcJeETfk0zoQWDG5zkh5aiJ5nqSnWNiWag== X-Received: by 2002:a17:902:f543:b0:299:e031:16d with SMTP id d9443c01a7336-29d68400b87mr36089715ad.33.1764777965155; Wed, 03 Dec 2025 08:06:05 -0800 (PST) Received: from smtpclient.apple (c-67-180-189-3.hsd1.ca.comcast.net. [67.180.189.3]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-29bceb4af8bsm189095775ad.81.2025.12.03.08.06.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Dec 2025 08:06:04 -0800 (PST) From: Mahesh Jethanandani Message-Id: <0882EAD9-5CF8-4F47-89B4-9ADA1015712B@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_71F4F519-D8D7-45ED-ACD5-55B6C6FCD4B8" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.21\)) Date: Wed, 3 Dec 2025 08:05:50 -0800 In-Reply-To: To: mohamed.boucadair@orange.com References: <176377917609.1807088.18231834189018308158@dt-datatracker-5bd94c585b-wk4l4> X-Mailer: Apple Mail (2.3731.700.6.1.21) Message-ID-Hash: LVDQIUZQUZAN6ASJCJLS222X7JPK5MB5 X-Message-ID-Hash: LVDQIUZQUZAN6ASJCJLS222X7JPK5MB5 X-MailFrom: mjethanandani@gmail.com 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 X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BIdr=5D_Re=3A_New_Liaison_Statement=2C_=22oLS_to_IETF_on_BGP_dat?= =?utf-8?q?a_model=22?= List-Id: Inter-Domain Routing Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_71F4F519-D8D7-45ED-ACD5-55B6C6FCD4B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Med, See inline with [mj] > On Dec 3, 2025, at 7:39 AM, mohamed.boucadair@orange.com wrote: >=20 > Hi Ketan, Jeff, all, > =20 > Putting aside VELOCE for a moment, I think that the maintenance of BGP = models can be simplified and avoid +200 bis doc by considering the = following: > =20 > =C2=B7 You can offload all the IANA-maintained modules from = the current spec and seek for their publication = (iana-bgp-community-types, iana-bgp-notification, iana-bgp-types, = iana-bgp-rib-types). [mj] The plan was always to offload the IANA based modules to IANA for = further maintenance. The process of how that happens might be different, = but that is the intent. > Publishing these modules is orthogonal to the implementation policy = the IDR WG has, as this is about providing a representation of IANA = registries. > These types can be used/leveraged by other BGP-related modules as = these values are important for interop > Note also that, per 8407bis, final RFC do not need to include the = initial version of such modules as IANA is the authoritative source for = those. > You may consider one further doc split: common types/grouping vs main = data structures. This doc split is what was followed for VPN data = models, attachment circuits, etc. > Similar to IANA types, common types are likely to be leveraged outside = the IETF. [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. Thanks. > =20 > Now, if we suppose that VELOCE is in place, the current provision (no = consensus yet) is that bis will be scoped to describe updates only: > =20 > * Bis versions of the initial RFC MAY be considered to document > major changes and their rationale. Such a decision is left to = the > WG. The RFC update is scoped to the narrative part describing = the > updates. WGs may decide to maintain an adopted YANG module in = the > IETF repository but never seek for an RFC publication of major > module revisions. > =20 > Hope this helps. > =20 > Cheers, > Med > =20 > De : Ketan Talaulikar =20 > Envoy=C3=A9 : mercredi 3 d=C3=A9cembre 2025 14:33 > =C3=80 : Jeffrey Haas > Cc : Inter-Domain Routing Discussion List ; Mahesh = Jethanandani ; BOUCADAIR Mohamed INNOV/NET = > Objet : Re: New Liaison Statement, "oLS to IETF on BGP data model" > =20 > =20 >=20 > + Med and Mahesh > =20 > Hi Jeff, > =20 > You have brought up some very good points and I am adding Med and = Mahesh for their guidance. > =20 > Please check inline below. > =20 > =20 > On Wed, Dec 3, 2025 at 1:29=E2=80=AFAM Jeffrey Haas > wrote: > Ketan, >=20 >=20 > > On Nov 22, 2025, at 2:25 AM, Ketan Talaulikar > wrote: > >=20 > > The BGP-4 YANG model document has gone through WGLC and has been = waiting for implementations for more than 2 years now. I am not sure of = its current status - I do see warnings and errors being reported on the = YANG. >=20 > This isn't hugely surprising. The underlying landscape of YANG is a = nest of dependencies. A refresh and cleanup is needed. >=20 > >=20 > > All 3 IDR chairs are authors on it and the IDR Secretary is the = document shepherd. I recognize this odd situation. >=20 > Indeed. After my experience with the BGP MIB v2 effort, I tried to = avoid entanglement. I failed.=20 >=20 > > However, a decision on the future of this document is now overdue. = This Liaison is a good trigger for the WG to make a decision (and within = a timeframe so the Liaison can be responded to). > >=20 > > As AD, I've already expressed my view that an exception to the 2 = implementation rule be sought from the WG for this document so it can be = published as an RFC. I believe it was in Madrid where I had expressed = that view, but perhaps even before that. If there is consensus to = proceed with that exception, this can be progressed - else it just stays = waiting for implementation and the WG will need to give a suitable = response to BBF. > >=20 > > Sue, Jeff, Keyur, and Jie, could you please take this topic up as a = priority request from me for discussion at your next meeting? Please let = the WG know your thoughts and if there is anything that you would like = me to do, please let me know. >=20 > Our next meeting should be this Friday 5 Dec. We did not meet the = prior week due to the US Thanksgiving holiday. We can certainly discuss = the path to publication without implementation if that's what's desired. > =20 > KT> Thanks. Just to be clear the WG needs to be polled for their = desire to proceed in this manner - i.e., this is just my suggestion. > =20 >=20 > Even without the sanity check of implementation, I do urge you in your = AD role to consider the burden for review for the document in its = current form.=20 > =20 > KT> Yes, this would be a biggie but not a blocker if it were a = one-time "large commit". See further for my real concern. > =20 > As you've seen from other work from Mahesh (author, and AD), there's = been a lot of discussion about how do we move things forward faster. = This has been done under the OPSAWG VELOCE discussions. =20 >=20 > Since it almost entirely certain that publication without = implementation will require updates at a later time, it'd be useful to = know what the strategy is for updates to the contents of the draft. In = its current form, each -bis would be 225+ pages of refresh. > =20 > KT> This is a real concern and a blocking one from my perspective. = I've seen this happen recently in other WGs and it is a problem that = needs an urgent solution - ideally as part of VELOCE but if not at least = a more immediate solution to enable patching of YANG models. We cannot = be doing 200+ pages of bis. I am prepared to HOLD this work until that = problem is solved if the IDR chairs and WG agree. > =20 >=20 > While the BGP YANG document will almost certainly benefit and serve as = good use case for "do YANG faster in IETF", the authors aren't currently = signed up to define and drive such methodology. :-) It might be = appropriate to set the BGP YANG publication timeline according to = resolution of what such practices might be. > =20 > KT> +1 - I am with you and we seek help from Med & Mahesh. > =20 > Thanks, > Ketan > =20 >=20 > -- Jeff >=20 > = __________________________________________________________________________= __________________________________ > 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. >=20 > 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. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_71F4F519-D8D7-45ED-ACD5-55B6C6FCD4B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Med,

See inline with [mj]

On Dec 3, 2025, at 7:39 AM, = mohamed.boucadair@orange.com wrote:

Hi Ketan, Jeff, = all,
 
Putting = aside VELOCE for a moment, I think that the maintenance of BGP models = can be simplified and avoid +200 bis doc by considering the = following:
 
=C2=B7         You can offload all the IANA-maintained modules from the = current spec and seek for their publication (iana-bgp-community-types, = iana-bgp-notification, iana-bgp-types, = iana-bgp-rib-types).

<= div>[mj] The plan was always to offload the IANA based modules to IANA = for further maintenance. The process of how that happens might be = different, but that is the intent.

  • Publishing these modules is orthogonal to the implementation = policy the IDR WG has, as this is about providing a representation of = IANA registries.
    • These = types can be used/leveraged by other BGP-related modules as these values = are important for interop
    • Note = also that, per 8407bis, final RFC do not need to include the initial = version of such modules as IANA is the authoritative source for = those.
  • You may consider one further doc = split: common types/grouping vs main data structures. This doc split is = what was followed for VPN data models, attachment circuits, = etc.
    • Similar to IANA types, common types are likely = to be leveraged outside the = IETF.

[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.

Thanks.

 
Now, if = we suppose that VELOCE is in place, the current provision (no consensus = yet) is that bis will be scoped to describe updates = only:
 
   *  Bis versions of the initial RFC MAY be = considered to document
      major changes and their = rationale.  Such a decision is left to = the
      WG.  The RFC update is = scoped to the narrative part describing the
      updates.  = WGs may decide to maintain an adopted YANG module in = the
      IETF repository but never = seek for an RFC publication of major
      module = revisions.
 
Hope = this helps.
 
Cheers,
Med
 
De : Ketan Talaulikar = <ketant.ietf@gmail.com> 
Envoy=C3=A9 :=  mercredi 3 d=C3=A9cembr= e 2025 14:33
=C3=80 : Jeffrey Haas = <jhaas@pfrc.org>
Cc : Inter-Domain Routing = Discussion List <idr@ietf.org>; Mahesh Jethanandani = <mjethanandani@gmail.com>; BOUCADAIR Mohamed INNOV/NET = <mohamed.boucadair@orange.com>
Objet : Re: New Liaison Statement, = "oLS to IETF on BGP data model"
 

 

+ Med and = Mahesh
 
Hi Jeff,
 
You have brought = up some very good points and I am adding Med and Mahesh for their = guidance.
 
Please check = inline below.
 
 
On Wed, Dec 3, 2025 at = 1:29=E2=80=AFAM = Jeffrey Haas <jhaas@pfrc.org> = wrote:
Ketan,


> On Nov 22, 2025, at 2:25 AM, Ketan = Talaulikar <ketant.ietf@gmail.com> wrote:
> 
> The BGP-4 YANG = model document has gone through WGLC and has been waiting for = implementations for more than 2 years now. I am not sure of its current = status - I do see warnings and errors being reported on the = YANG.

This isn't hugely surprising.  The underlying = landscape of YANG is a nest of dependencies.  A refresh and cleanup = is needed.

> 
> All 3 IDR chairs = are authors on it and the IDR Secretary is the document shepherd. I = recognize this odd situation.

Indeed.  After my experience = with the BGP MIB v2 effort, I tried to avoid entanglement.  I = failed. 

> = However, a decision on the future of this document is now overdue. This = Liaison is a good trigger for the WG to make a decision (and within a = timeframe so the Liaison can be responded to).
> 
> As AD, I've = already expressed my view that an exception to the 2 implementation rule = be sought from the WG for this document so it can be published as an = RFC. I believe it was in Madrid where I had expressed that view, but = perhaps even before that. If there is consensus to proceed with that = exception, this can be progressed - else it just stays waiting for = implementation and the WG will need to give a suitable response to = BBF.
> 
> = Sue, Jeff, Keyur, and Jie, could you please take this topic up as a = priority request from me for discussion at your next meeting? Please let = the WG know your thoughts and if there is anything that you would like = me to do, please let me know.

Our next meeting should be this = Friday 5 Dec.  We did not meet the prior week due to the US = Thanksgiving holiday.  We can certainly discuss the path to = publication without implementation if that's what's = desired.
 
KT> Thanks. = Just to be clear the WG needs to be polled for their desire to proceed = in this manner - i.e., this is just my = suggestion.
 

Even without the = sanity check of implementation, I do urge you in your AD role to = consider the burden for review for the document in its current = form. 
 
KT> Yes, this = would be a biggie but not a blocker if it were a one-time "large = commit". See further for my real = concern.
 
As you've seen from = other work from Mahesh (author, and AD), there's been a lot of = discussion about how do we move things forward faster.  This has = been done under the OPSAWG VELOCE discussions.  

Since it almost = entirely certain that publication without implementation will require = updates at a later time, it'd be useful to know what the strategy is for = updates to the contents of the draft.  In its current form, each = -bis would be 225+ pages of = refresh.
 
KT> This is a = real concern and a blocking one from my perspective. I've seen this = happen recently in other WGs and it is a problem that needs an urgent = solution - ideally as part of VELOCE but if not at least a more = immediate solution to enable patching of YANG models. We cannot be doing = 200+ pages of bis. I am prepared to HOLD this work until that problem is = solved if the IDR chairs and WG agree.
 

While the BGP YANG = document will almost certainly benefit and serve as good use case for = "do YANG faster in IETF", the authors aren't currently signed up to = define and drive such methodology. :-)  It might be appropriate to = set the BGP YANG publication timeline according to resolution of what = such practices might be.
 
KT> +1 - = I am with you and we seek help from Med & = Mahesh.
 
Thanks,
Ketan
 


-- = Jeff

_________________________________________________________=
___________________________________________________
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.


Mahesh = Jethanandani
mjethanandani@gmail.com

<= br class=3D"Apple-interchange-newline">




= --Apple-Mail=_71F4F519-D8D7-45ED-ACD5-55B6C6FCD4B8--