Re: [Gen-art] Genart last call review of draft-ietf-pce-stateful-path-protection-08

[Dhruv Dhody <[e-mail]>]

Hi Pete,

Thanks for your review and nits. Just snipping to two points...

> OLD
>      |   PT      |     Path Protection Association Flags         |S|P|
> NEW
>      |   PT      |                Unassigned                     |S|P|
>

I feel it is important to keep the name "flags" in the figure to match
with the text following the figure. Also this seems to be our usual
practice in past documents as well. We can change to just "flags" if
you would prefer that?

For context ->

   The format of the Path Protection Association TLV (Figure 1) is as
   follows:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Type = TBD2         |              Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   PT      |     Path Protection Association Flags         |S|P|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 1: Path Protection Association TLV format

   Path Protection Association Flags (32 bits) - The following flags are
   currently defined -

      Protecting (P): 1 bit - This bit is as defined in Section 14.1 of
      [RFC4872] to indicate if the LSP is working or protection LSP.

      Secondary (S): 1 bit - This bit is as defined in Section 14.1 of
      [RFC4872] to indicate if the LSP is primary or secondary LSP.  The
      S flag is ignored if the P flag is not set.

      Protection Type (PT): 6 bits - This field is as defined in
      Section 14.1 of [RFC4872] to indicate the LSP protection type in
      use.

      Unassigned bits are considered reserved.  They MUST be set to 0 on
      transmission and MUST be ignored on receipt.


> Section 6:
>
> At the top of the section, I suggest putting in the following:
>
> [Note to RFC Editor and IANA: Sections 3.1, 3.2, and 4.5 contain "TBD1" through
> "TBD5" those should be replaced by the values that IANA assigns. Also, Section
> 4.5 includes several occurrences of the phrase "(Early allocation by IANA)";
> please confirm that the value mentioned there is correct and delete that phrase
> from the document before publication.]
>

I would suggest the authors to remove the phrase "(Early allocation by
IANA)" in the document now as the referenced draft is in RFC-EDITOR
queue and the early allocation tag is removed in the IANA page -
https://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects

Thanks!
Dhruv