HI Chen, If the WG Adoption passes, we can change that name of the draft at the time of adoption (i.e. publish draft-ietf-pce-bier-te-00). There is no need for you to create a new draft with a name change while the adoption poll is ongoing!
Thanks! Dhruv On Sun, Oct 1, 2023 at 3:19 PM <[email protected]> wrote: > Hi Adian, > > Many thanks for your comprehensive and helpful review. > > We have just published the new version draft-chen-pce-bier-te-00，which > include all your comments. > > Since the name of the draft has been updated based on the opinions of > Jeffery and Nils, it needs to be reviewed by the chairman before it can be > seen on the IETF page. Please check back later. > > Please, See inline for detailed response... > > > > Original > *From: *AdrianFarrel <[email protected]> > *To: *'Dhruv Dhody' <[email protected]>;[email protected] <[email protected]>; > *Cc: *[email protected] <[email protected]>; > *Date: *2023年09月29日 05:45 > *Subject: **Re: [Pce] WG Adoption of draft-chen-pce-bier-11* > _______________________________________________ > Pce mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/pce > > Hi, > > > > I have no objection to the working group taking on this draft although > > I suspect that the community of interest is quite small, so there is > > some concern about proper review and WG consensus. Hopefully this > > adoption poll will secure a few promises of future review. > > > > A few editorial points, below. > > > > Cheers, > > Adrian > > > > === > > > > Can we please get out of the habit of bring drafts up for adoption with > > more than five authors on the front page. They will never get as far as > > RFCs like that, and it seems unreasonable to ask the working group > > chairs to appoint document editors after adoption - the authors should > > sort this out for themselves. > > > [Ran]: Sure. We will communicate with the authors. Since China is on > National Day holiday, so can we deal with it later? > > --- > > > > Please run idnits and clean up the document. It would have been easy to > > do this before requesting adoption. > > [Ran] Done. > > --- > > > > Please use the correct boilerplate in Section 2. > > [Ran] Done. > > --- > > > > Section 3 has > > BIER-TE computed by a PCE can be represented in the > > following forms: > > but then there is only one form shown. > > [Ran] Done. Changed to : BIER-TE computed by a PCE can be represented as: > > The previous version defined three forms, but after discussion, only one > was retained. > > --- > > > > Several of the new TLVs etc. have bit-flag fields with bits defined. > > Please consider whether you need to ask IANA to create registries to > > track further bit assignments. If you don't need registries, why do > > you need whole fields? > > [Ran] Done. Already applied for iana allocation for bits. > > --- > > > > 6.2 > > > > You should give some clues about the value of the Length field since you > > know what values it might have. Also, I presume that the Length field > > could tell you a lot about the BFR prefix. > > > > But, also, you say it is one octet, and you show it as 16 bits. > > [Ran] Done. Changed to 2 octet. Consistent with the type and length of > other TLVs of the LSP objet. > > --- > > > > 6.2 > > > > If the tunnel identifier is 11 or 23 octets then the TLV is not a > > multiple of 4 (which is usually the case for PCEP TLVs). Is it padded > > or what? > > [Ran] Done. Added padding field. > > --- > > > > 6.3 > > > > In order to setup an BIER-TE, a new PATH-SETUP-TYPE TLV MUST be > > contained in RP/SRP object. > > > > Not sure that this document is needed to set up anything with BIER-TE. > > It is just something that you can use. > > [Ran]: It can easily identify that the path that needs to be established > is a BIER-TE path. > > Similar to SR, SRv6 defines new PATH-SETUP-TYPE TLV contained in RP/SRP > object. > > --- > > > > 6.6 > > > > Could you abbreviate "ERO Object" as EROO? ;-) > > [Ran] Done. > > --- > > > > 6.6.1 > > > > The definition of "Adjacency BitString" seems to indicate that any > > number of bits can be present. But the description of "Length" says that > > the TLV length must be a multiple of 4 octets. How is the TLV padded? > > [Ran] The TLV is added the "Reserved" field to pad. > > > How does someone reading the TLV know where the bit string stops? > > [Ran] Done. Added some descriptions about the relationship between BSL > and bitstring. > > If k is the length of the BitString, the value of BitStringLen is > log2(k)-5. However, only > > certain values are supported: > > * 1: 64 bits > > * 2: 128 bits > > * 3: 256 bits > > * 4: 512 bits > > * 5: 1024 bits > > --- > > > > Section 6.7 has same issues as 6.6 > > > > --- > > > > Is Section 8 correct? It says: > > > > IANA has registered the code points for the protocol elements defined > > in this document. > > > > But I don't think those have been registered. > > [Ran] Sorry, typo, updated > > > *From:* Pce <[email protected]> *On Behalf Of *Dhruv Dhody > *Sent:* 25 September 2023 17:49 > *To:* [email protected] > *Cc:* [email protected] > *Subject:* [Pce] WG Adoption of draft-chen-pce-bier-11 > > > > Hi WG, > > This email begins the WG adoption poll for draft-chen-pce-bier-11. > > https://datatracker.ietf.org/doc/draft-chen-pce-bier/ > > Should this draft be adopted by the PCE WG? Please state your reasons - > Why / Why not? What needs to be fixed before or after adoption? Are you > willing to work on this draft? Review comments should be posted to the list. > > Please respond by Monday 9th Oct 2023. > > Please be more vocal during WG polls! > > Thanks! > Dhruv & Julien > > >
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
