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 C3957A5AC264; Fri, 9 Jan 2026 19:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -4.085 X-Spam-Level: X-Spam-Status: No, score=-4.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 MTCKaVT-tvqz; Fri, 9 Jan 2026 19:21:08 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 95D00A5AC255; Fri, 9 Jan 2026 19:21:08 -0800 (PST) Received: from mail.maildlp.com (unknown [172.18.224.107]) by frasgout.his.huawei.com (SkyGuard) with ESMTPS id 4dp3nN02LFzHnGcW; Sat, 10 Jan 2026 11:20:56 +0800 (CST) Received: from kwepemh500011.china.huawei.com (unknown [7.202.181.142]) by mail.maildlp.com (Postfix) with ESMTPS id D8DE640571; Sat, 10 Jan 2026 11:21:06 +0800 (CST) Received: from dggpemf200008.china.huawei.com (7.185.36.39) by kwepemh500011.china.huawei.com (7.202.181.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Sat, 10 Jan 2026 11:21:05 +0800 Received: from kwepemf100006.china.huawei.com (7.202.181.220) by dggpemf200008.china.huawei.com (7.185.36.39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Sat, 10 Jan 2026 11:21:04 +0800 Received: from kwepemf100006.china.huawei.com ([7.202.181.220]) by kwepemf100006.china.huawei.com ([7.202.181.220]) with mapi id 15.02.1544.036; Sat, 10 Jan 2026 11:21:04 +0800 From: "Dongjie (Jimmy)" To: "Zhang, Zhaohui" , "slitkows.ietf@gmail.com" , 'idr' Thread-Topic: [Idr] Re: WG last call and IPR call for draft-ietf-idr-rt-derived-community (December 11, 2025 to January 5, 2026) Thread-Index: AQHcbgg4L9H/uCPBSUGg1dSznPwKa7VK4s4w Date: Sat, 10 Jan 2026 03:21:04 +0000 Message-ID: References: <834bfae9b2854393a028459f9a8601fb@huawei.com> <004701dc6da7$1593dc50$40bb94f0$@gmail.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.85.155.147] Content-Type: multipart/alternative; boundary="_000_a2e0f3e9ba7942f6955e25ed61ff5958huaweicom_" MIME-Version: 1.0 Message-ID-Hash: E5GKMP5XVMMUNOP7UNURFLZB2XSAUOOA X-Message-ID-Hash: E5GKMP5XVMMUNOP7UNURFLZB2XSAUOOA X-MailFrom: jie.dong@huawei.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: 'idr-chairs' X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BIdr=5D_Re=3A_WG_last_call_and_IPR_call_for_draft-ietf-idr-rt-de?= =?utf-8?q?rived-community_=28December_11=2C_2025_to_January_5=2C_2026=29?= List-Id: Inter-Domain Routing Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --_000_a2e0f3e9ba7942f6955e25ed61ff5958huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, The IDR chairs have received limited comments on the WG LC for draft-ietf-i= dr-rt-derived-community in the WG LC call. See the call at: https://mailarc= hive.ietf.org/arch/msg/idr/_51JdiKO37tSfBjkVHd3UXOIHFc/ After reviewing the draft and the comments, the IDR chairs and shepherd fee= l this draft is ready for publication. However, due to the holiday period, = the WG LC for draft-ietf-idr-rt-derived-community is extended on 1/16/2026. Please comment quickly if you do not think this draft is ready for publicat= ion. Best regards, Jie (as document shepherd) From: Zhang, Zhaohui Sent: Tuesday, December 16, 2025 5:17 AM To: slitkows.ietf@gmail.com; Dongjie (Jimmy) ; 'idr' <= idr@ietf.org> Cc: 'idr-chairs' Subject: RE: [Idr] Re: WG last call and IPR call for draft-ietf-idr-rt-deri= ved-community (December 11, 2025 to January 5, 2026) Hi Stephane, Thanks for your review and comments. I've made some changes in my local sou= rce file. Please see zzh> below. From: slitkows.ietf@gmail.com > Sent: Monday, December 15, 2025 4:42 AM To: 'Dongjie (Jimmy)' >; 'i= dr' > Cc: 'idr-chairs' > Subject: [Idr] Re: WG last call and IPR call for draft-ietf-idr-rt-derived-= community (December 11, 2025 to January 5, 2026) HI Jie, Few comments: Section 3: * Two typos: s/Subt-Types/Sub-Types/g Zzh> Thanks! Fixed. Section 4: * The fact that we consider the type being the first byte for most of t= he ext comms expect for IPv6 ones where we consider the two first bytes is = really confusing (subtype is within type). I know that it's following how i= t's defined at IANA, but this is really creating confusion while RFC5701 st= ill needs "subtype" field properly. Maybe at least for the example given ab= out Type 0x0011, we could mention that we talk about sub-type 0x11 used for= RT vs the general 0x02. Otherwise, we try to compare things that are not d= irectly comparable. * "When a new type is defined and registered, the corresponding...", it= 's not clear what we are talking about, I guess we talk about new types of = RT derived EC. The entire paragraph does not sound super clear to me. Can w= e simplify ? Previous paragraph says that we cannot guarantee subtype 0x02 = for any new RT created, then we can say that similarly we cannot guarantee = that new RT derived ECs, will get sub-type 0x15. BTW, wouldn't it be someth= ing we would like to enforce to simplify operation/understanding ? (so sub-= type 0x02 is always RT, 0x15 always for RT-derived EC) Zzh> Indeed, it would be nice if we could enforce 0x02 for RT and 0x15 for = RT-derived, but my understanding is that we can't - I'll defer this to the = IDR experts. Zzh> I deleted the entire paragraph and added some texts to the previous an= d next paragraph to address the two comments: While it may be desired to follow the unwritten convention and assign sub-type 0x02 for future Route Targets of future types of ECs, there is no guarantee of that. For example, Type 0x0011 (which can be interpreted as with a sub-type 0x11) is assigned for UUID-based Route Target that imposes as an IPv6 Address Specific EC (even though UUID is not an IPv6 address). When a new type of extended community is defined and registered, and a sub-type under this new type is registered for Route Target purposes, it is suggested to also register a sub-type for derivation purposes, preferably with the same value 0x15. However, there is no guarantee of that either. Section 6 (Security): I agree that this document is not defining how these ECs are used, however,= as they could potentially influence some indirect behaviors (not defined i= n this document), it should be good to mention that user should pay attenti= on to stripping unintended received ECs from external peers. Zzh> How about adding a sentence to the paragraph? ... Any potential security concerns need be addressed by documents that specify the actual usage. Additionally, in general one should pay attention to stripping unintended received ECs from external peers. Thanks! Jeffrey From: Dongjie (Jimmy) > Sent: Thursday, December 11, 2025 2:35 AM To: idr > Cc: idr-chairs > Subject: [Idr] WG last call and IPR call for draft-ietf-idr-rt-derived-comm= unity (December 11, 2025 to January 5, 2026) This begins the working group last call for the draft on "Extended Communit= ies Derived from Route Targets": https://datatracker.ietf.org/doc/draft-iet= f-idr-rt-derived-community/ Due to the holiday season in the end of the year, this last call ends on Ja= nuary 5th, 2026 so as to give the working group time to review and comment. For purposes of the shepherd's report and according to IETF BCP 78/79, the = authors are requested to declare whether they are aware of any undisclosed = IPR covering this draft. Members of the working group are similarly obligat= ed to report any IPR they are aware of as well. Best regards, Jie (as WG secretary & document shepherd) --_000_a2e0f3e9ba7942f6955e25ed61ff5958huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

The IDR chairs have received limited comments on the WG LC= for draft-ietf-idr-rt-derived-community in the WG LC call. See the call at= : https://mailarchive.i= etf.org/arch/msg/idr/_51JdiKO37tSfBjkVHd3UXOIHFc/

 

After reviewing the draft and the comments, the IDR chairs= and shepherd feel this draft is ready for publication. However, due to the= holiday period, the WG LC for draft-ietf-idr-rt-derived-community is extended on 1/16/2026.

 

Please comment quickly if you do not think this draft is r= eady for publication.

 

Best regards,

Jie (as document shepherd)

 

From: = Zhang, Zhaohui <zhaohui.zhang@hpe.com>
Sent: Tuesday, December 16, 2025 5:17 AM
To: slitkows.ietf@gmail.com; Dongjie (Jimmy) <jie.dong@huawei.com= >; 'idr' <idr@ietf.org>
Cc: 'idr-chairs' <idr-chairs@ietf.org>
Subject: RE: [Idr] Re: WG last call and IPR call for draft-ietf-idr-= rt-derived-community (December 11, 2025 to January 5, 2026)

 

Hi Stephane,

 

Thanks for your review and comments. I̵= 7;ve made some changes in my local source file.

 

Please see zzh> below.=

 

From: slitkows.ietf@gmail.com <= slitkows.ietf@gmail.com>
Sent: Monday, December 15, 2025 4:42 AM
To: 'Dongjie (Jimmy)' <jie= .dong@huawei.com>; 'idr' <idr@iet= f.org>
Cc: 'idr-chairs' <idr-chai= rs@ietf.org>
Subject: [Idr] Re: WG last call and IPR call for draft-ietf-idr-rt-d= erived-community (December 11, 2025 to January 5, 2026)

 

HI Jie,

 

Few comments:

 

Section 3:

  • Two typos: s/Subt-Types/Sub-Types/g

    •  

    Zzh> Thanks! Fixed.


    Section 4:

    • The fact that we consider the type being the first byte for = most of the ext comms expect for IPv6 ones where we consider the two first bytes is really confusing (subtype is within type).= I know that it’s following how it’s defined at IANA, but this = is really creating confusion while RFC5701 still needs “subtype”= ; field properly. Maybe at least for the example given about Type 0x0011, we could mention that we talk about sub-type 0x11 used for RT= vs the general 0x02. Otherwise, we try to compare things that are not dire= ctly comparable.

     

    • “When a new type is defined and registered, the corres= ponding…”, it’s not clear what we are talking about, I gu= ess we talk about new types of RT derived EC. The entire paragraph does not so= und super clear to me. Can we simplify ? Previous paragraph says that we ca= nnot guarantee subtype 0x02 for any new RT created, then we can say that si= milarly we cannot guarantee that new RT derived ECs, will get sub-type 0x15. BTW, wouldn’t it be some= thing we would like to enforce to simplify operation/understanding ? (so su= b-type 0x02 is always RT, 0x15 always for RT-derived EC)<= /li>

     

    Zzh> In= deed, it would be nice if we could enforce 0x02 for RT and 0x15 for RT-deri= ved, but my understanding is that we can’t – I’ll defer this to the IDR experts.

    Zzh> I = deleted the entire paragraph and added some texts to the previous and next = paragraph to address the two comments:

     = ;

       While it may be desired= to follow the unwritten convention and assign

       sub-type 0x02 for futur= e Route Targets of future types of ECs, there

       is no guarantee of that= .  For example, Type 0x0011 (which can be

       interpreted a= s with a sub-type 0x11) is assigned for UUID-based Route

       Target that imposes as = an IPv6 Address Specific EC (even though UUID

       is not an IPv6 address)= .

     

       When a new type of exte= nded community is defined and registered, and

       a sub-type under this n= ew type is registered for Route Target

       purposes, it is suggest= ed to also register a sub-type for derivation

       purposes, preferably wi= th the same value 0x15.  However, there is no

    =             &nb= sp;    guarantee of that either.

     = ;

    Section 6 (Security):

    I agree that this document is not defining = how these ECs are used, however, as they could potentially influence some i= ndirect behaviors (not defined in this document), it should be good to mention that user should pay attention to stripping u= nintended received ECs from external peers.

     

    Zzh> How about adding a sentence to the = paragraph?

     

       … Any potential security= concerns need

       be addressed by documents that= specify the actual usage.

       Additionally, in general one should pay attention= to stripping

       unintended received = ECs from external peers.

     

    Thanks!

    Jeffrey

     

    From: = Dongjie (Jimmy) <jie.dong=3D40huawei.com@dmarc.ietf.org>
    Sent: Thursday, December 11, 2025 2:35 AM
    To: idr <idr@ietf.org>
    Cc: idr-chairs <idr-chairs= @ietf.org>
    Subject: [Idr] WG last call and IPR call for draft-ietf-idr-rt-deriv= ed-community (December 11, 2025 to January 5, 2026)

     

    This begins the working group l= ast call for the draft on “Extended Communities Derived from Route = Targets”: https://datatracker.ietf.org/doc/draft-ietf-idr-rt-derived-community/

     

    Due to the holiday season in th= e end of the year, this last call ends on January 5th, 2026 so a= s to give the working group time to review and comment.

     

    For purposes of the shepherd's = report and according to IETF BCP 78/79, the authors are requested to declar= e whether they are aware of any undisclosed IPR covering this draft. Member= s of the working group are similarly obligated to report any IPR they are aware of as well.

     

    Best regards,=

    Jie (as WG secretary & docu= ment shepherd)

     

--_000_a2e0f3e9ba7942f6955e25ed61ff5958huaweicom_--