Francesca Palombini has entered the following ballot position for draft-ietf-lsr-isis-srv6-extensions-17: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for the work on this document. I was not around for RFC 8986, and I am not sure I understand the use case fully (I agree with Ben there), but I'll trust the responsible AD and the wg. I'll also note that I was hoping to see "Implementation status report" in the draft, as mentioned in the shepherd writeup, and was disappointed not to find any. However, I'd like to discuss a number of points, mostly on the IANA considerations and on detailed fields descriptions. I also want to bring 7. below regarding the IANA registries names to your attention, although it's not a hill I am willing to die on (that one is a "let's talk" DISCUSS, the rest I hope can be acted upon). As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion; I really think that the document would be improved with a change here, but can be convinced otherwise. Francesca 1. ----- Section 7.1 FP: The locator entries ASCII figure is not consistent with the descriptive text following it: specifically, Loc Size should follow Algorithm directly; instead, the picture seems to show there are 2 octets unused between Algorithm and Loc Size. 2. ----- Type: 5. FP: For consistency (and to make sure implementers don't rely on the ASCII figure), it would be good to indicate Type's length (1 octet I assume). 3. ----- Length: variable. FP: This does not help much understanding what this field is supposed to contain. 4. ----- Section 7.2 FP: Same issue as in 1. for the ASCII figure. 5. ----- Sections 8.1 and 8.2 FP: Same comments as 1. 2. and 3. 6. ----- If a behavior is advertised it MUST only be advertised in the TLV[s] as indicated by "Y" in the table below, and MUST NOT be advertised in the TLV[s] as indicated by "N" in the table below. FP: I find the sentence after the comma confusing, and don't understand the presence of the MUST NOT here. 7. ----- Section 11.1.1 FP: It sounds like a bad idea in general to have to rename the registry every time a TLV needs to be added to the registry... Maybe the wg and the AD should consider renaming the registries so not to have this sort of dependency. (I understand that this is a low priority comment, but still, it feels wrong to put in titles what would fit really well in a registry itself). This very much applies to Section 11.6 as well: the registry's name with the hierarchy of TLVs as part of the name feels like a really bad idea. That is typically data that goes into registries. 8. ----- Section 11.3 FP: The registry needs to be defined in the document. In particular, I see that IANA is interpreting the columns as "Value" "Description" "Reference"; is that right or should this be "Type" "Description" "Reference" (I see a mix of the two for different IANA registries)? 9. ----- Section 11.8 FP: Are bits 0, 2-15 reserved or unassigned? The terminology in section 2 is ambiguous, as it talks about "reserved for future use" (but the IANA section leaves them unassigned). Please clarify for IANA. 10. ----- Section 11.10 FP: Please define the registry (I assume it is going to be "Bit #", "Name", "Reference"). _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
