Re: [Pce] WG Adoption of draft-chen-pce-bier-11

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 <chen.ran@zte.com.cn> 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 <adrian@olddog.co.uk>
> *To: *'Dhruv Dhody' <dd@dhruvdhody.com>;pce@ietf.org <pce@ietf.org>;
> *Cc: *draft-chen-pce-bier@ietf.org <draft-chen-pce-bier@ietf.org>;
> *Date: *2023年09月29日 05:45
> *Subject: **Re: [Pce] WG Adoption of draft-chen-pce-bier-11*
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> 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 <pce-bounces@ietf.org> *On Behalf Of *Dhruv Dhody
> *Sent:* 25 September 2023 17:49
> *To:* pce@ietf.org
> *Cc:* draft-chen-pce-bier@ietf.org
> *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
>
>
>