[Idr] Re: WG last call and IPR call for draft-ietf-idr-rt-derived-community (December 11, 2025 to January 5, 2026)

["Dongjie (Jimmy)" <[e-mail]>]

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.ietf.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 ready for publication.

Best regards,
Jie (as document shepherd)

From: Zhang, Zhaohui <[e-mail]>
Sent: Tuesday, December 16, 2025 5:17 AM
To: [e-mail]; Dongjie (Jimmy) <[e-mail]>; 'idr' <[e-mail]>
Cc: 'idr-chairs' <[e-mail]>
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've made some changes in my local source file.

Please see zzh> below.

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Monday, December 15, 2025 4:42 AM
To: 'Dongjie (Jimmy)' <[e-mail]<mailto:[e-mail]>>; 'idr' <[e-mail]<mailto:[e-mail]>>
Cc: 'idr-chairs' <[e-mail]<mailto:[e-mail]>>
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 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 directly 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 we 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 something 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 and 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 in this document), it should be good to mention that user should pay attention 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) <jie.dong=[e-mail]<mailto:jie.dong=[e-mail]>>
Sent: Thursday, December 11, 2025 2:35 AM
To: idr <[e-mail]<mailto:[e-mail]>>
Cc: idr-chairs <[e-mail]<mailto:[e-mail]>>
Subject: [Idr] WG last call and IPR call for draft-ietf-idr-rt-derived-community (December 11, 2025 to January 5, 2026)

This begins the working group last call for the draft on "Extended Communities Derived from Route Targets": https://datatracker.ietf.org/doc/draft-ietf-idr-rt-derived-community/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-idr-rt-derived-community/__;!!NEt6yMaO-gk!HM_gtfG6roAto46LMIv6EI5eXa8lIqs9FoH6knPzzK9-ZyDO0tpHhcoUiCEWgGieV28DMOLKL-WJXpq11ZSmSR5v$>

Due to the holiday season in the end of the year, this last call ends on January 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 obligated to report any IPR they are aware of as well.

Best regards,
Jie (as WG secretary & document shepherd)