Ballot for draft-ietf-pce-wson-rwa-ext
Yes
No Objection
Note: This ballot was opened for revision 11 and is now closed.
Benjamin's DISCUSS is a superset of issues I spotted, so I am agreeing with it. In Section 4.1: . Wavelength Selection TLV (32 bits): See Section 4.2 for details. Is TLV value 32 bit or the whole TLV? (This is the same issue as raised by Benjamin) In Section 4.3: o Link Identifiers: Identifies each link ID for which restriction is applied. The length is dependent on the link format and the Count field. Is the type field extensible? See Section 4.3.1. for Link Identifier encoding and Section 4.3.2. for the Wavelength Restriction Field encoding, respectively. 8.5. New PCEP TLV: Optical Interface Class List TLV As described in Section 4.3, a new PCEP TLV is defined to indicate the optical interface class list. IANA is to allocate this new TLV from the "PCEP TLV Type Indicators" subregistry (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- indicators). Value Description Reference --------------------------------------------------------- TBD5 Optical Interface [This.I-D] Class List I don't see TBD5 referenced anywhere else in the document. 8.6. New PCEP TLV: Client Signal TLV As described in Section 4.3, a new PCEP TLV is defined to indicate the client signal information. IANA is to allocate this new TLV from the "PCEP TLV Type Indicators" subregistry (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- indicators). Value Description Reference --------------------------------------------------------- TBD6 Client Signal Information [This.I-D] I don't see TBD6 referenced anywhere else in the document either.
I share Benjamin's concerns about the clarity of this document, and support his DISCUSS. I have added some related comments below (not overlapping with his, of Mirja's). (1) §4.2 (Wavelength Selection TLV): "The encoding of this TLV is specified as the Wavelength Selection Sub-TLV in Section 4.2.2 of [RFC7689]." It should be made clear that this document is requesting a new TLV-type code to be assigned (§8.2) for this TLV. IOW, rfc7689 just describes the value part of the TLV... (2) §4.3: s/MUST be able to specify a restriction/MUST specify a restriction I assume you really want the restriction signaled, and not just the ability to do it... (3) §4.3: "the PCE MUST have mechanisms to know the tunability restrictions" How can this be Normatively enforced? It seems to be that the MUST is out of place. s/MUST/must (4) §4.3: "the PCC MUST be able to apply additional constraints" This sounds like a requirement, which is immediately satisfied by the definition of the Wavelength Restriction Constraint TLV...so I think the MUST is out of place. s/MUST/must (5) §4.3.2: s/wavelength restriction TLV/Wavelength Restriction Constraint TLV (6) I think that these references should be Normative: rfc5440, rfc8253.
I support Benjamin's DISCUSS (and thank him for saving me some typing :-) ) IDNits complains about some citations without matching references. Please check. The "authors" section does not match the first page. Should some of those be listed as "contributors"?
Thank you for resolving my DISCUSS points.
I had some similar concerns as Benjamin but I think he listed them all. I some more minor editorial comments to add: 1) sec 4.3: "an Error-value (Error-value=3) MUST be defined so that the PCE MUST send a PCErr message with a PCEP-ERROR Object. See Section 5.1 for the details." This doesn't really make sense as normative "MUST"; I propose to change to lower case "must". 2) sec 4.3: "This TLV MAY appear more than once to be able to specify multiple restrictions." How do you know how much restrictions will be there? Based on a length field in the base protocol? Please clarify in the draft! 3) sec 4.3.2: "Length (16 bits): It is the length in bytes of the entire label set field." What is meant by "label set field" here? Please clarify in the draft or align wording accordingly. 4) Error value 3 is missing in sec 8.8!
Thank you for the very helpful Section 3.
I had concerns similar to those raised by Benjamin and I support his DISCUSS.