[Lsr] Murray Kucherawy's No Objection on draft-ietf-lsr-ospfv3-extended-lsa-yang-28: (with COMMENT)
Murray Kucherawy has entered the following ballot position for draft-ietf-lsr-ospfv3-extended-lsa-yang-28: No Objection 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/about/groups/iesg/statements/handling-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-ospfv3-extended-lsa-yang/ -- COMMENT: -- Forwarding a comment from Orie Steele, incoming ART AD: There do not appear to be a lot of normative statements. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Murray Kucherawy's No Objection on draft-ietf-lsr-isis-area-proxy-10: (with COMMENT)
Murray Kucherawy has entered the following ballot position for draft-ietf-lsr-isis-area-proxy-10: No Objection 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/about/groups/iesg/statements/handling-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-area-proxy/ -- COMMENT: -- Section 7 creates a registry whose policy is partly Expert Review, but doesn't give any particular guidance to the Designated Experts about what qualifying criteria might be. Are there any that should be included? I also suggest removing the names of proposed designated experts; that's appropriate for the shepherd writeup or an email and doesn't need to be in the document directly. The SHOULD in Section 4.2 is bare. When might an implementer or operator deviate from that advice? If there's no legitimate condition, maybe it should be a MUST, or if it really doesn't matter, a MAY. I actually have the same question about most of the 30+ SHOULDs in this document. I wasn't able to tell just from the text in many cases what damage to interoperability I might trigger if I deviate from the advice. And in the aggregate, as an implementer, I could do none of them and still claim I'm implementing this specification. Is that intentional? ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Murray Kucherawy's No Objection on draft-ietf-lsr-ospf-terminology-06: (with COMMENT)
Murray Kucherawy has entered the following ballot position for draft-ietf-lsr-ospf-terminology-06: No Objection 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/about/groups/iesg/statements/handling-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-ospf-terminology/ -- COMMENT: -- You could delete Section 1 as it's a verbatim copy of the Abstract. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Murray Kucherawy's No Objection on draft-ietf-lsr-isis-flood-reflection-11: (with COMMENT)
Murray Kucherawy has entered the following ballot position for draft-ietf-lsr-isis-flood-reflection-11: No Objection 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/about/groups/iesg/statements/handling-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-flood-reflection/ -- COMMENT: -- Thanks for the work put into this. I just have some minor editorial things to consider. Section 4.1 contains this text: The Flood Reflection TLV SHOULD NOT appear more than once in an IIH. A router receiving one or more Flood Reflection TLVs in the same IIH MUST use the values in the first TLV and it SHOULD log such violations subject to rate limiting. There are several other instances of this pattern in later sections. In each case I'm wondering why an implementer might choose to disregard the SHOULD NOT. Is there ever a legitimate reason to do so? If so, could we include an example? If not, should this simply be a MUST? Several of the other SHOULDs leave me wondering the same thing. Thanks for a good IANA Considerations section. Section 2 defines "Tunnel Endpoint" and "Hot-Potato Routing", but those terms don't appear anywhere in the document. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Murray Kucherawy's Discuss on draft-ietf-lsr-pce-discovery-security-support-12: (with DISCUSS)
Murray Kucherawy has entered the following ballot position for draft-ietf-lsr-pce-discovery-security-support-12: 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/about/groups/iesg/statements/handling-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-pce-discovery-security-support/ -- DISCUSS: -- This should be simple to resolve, but it has to be clarified: The shepherd writeup says there were IPR claims made about the document. The question also asks for a summary of the resulting discussion, but the shepherd writeup doesn't provide one. Can we confirm that the discussion was had, or some other answer to the question can be provided? ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Murray Kucherawy's No Objection on draft-ietf-lsr-ospf-reverse-metric-12: (with COMMENT)
Murray Kucherawy has entered the following ballot position for draft-ietf-lsr-ospf-reverse-metric-12: No Objection 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/about/groups/iesg/statements/handling-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-ospf-reverse-metric/ -- COMMENT: -- Apologies for being late to the party. Just a few things to add beyond the feedback my colleagues have already provided: The first sentence in Section 2.2 uses the phrase "toward the core" three times. Seems like it could do with some common factoring. There's a SHOULD at the bottom of Section 6. Why's it only a SHOULD? When might an implementer legitimately decide to do something else? In Section 9, I suggest making it explicit that you're talking about the "Link Local Signalling TLV Identifiers" registry in the "Open Shortest Path First (OSPF) Link Local Signalling (LLS) - Type/Length/Value Identifiers (TLV)" registry group. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Murray Kucherawy's No Objection on draft-ietf-lsr-isis-rfc5316bis-04: (with COMMENT)
Murray Kucherawy has entered the following ballot position for draft-ietf-lsr-isis-rfc5316bis-04: No Objection 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/about/groups/iesg/statements/handling-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-rfc5316bis/ -- COMMENT: -- I support Alvaro's DISCUSS, and add my own comments related to his first point: The first two SHOULDs in Section 3.1 would benefit from some guidance about when an implementer might opt to deviate from that advice. This occurs again Sections 3.3.4, 3.4.1, 3.4.2, the top of Section 4 (two SHOULDs) and the bottom of Section 4 (two SHOULD NOTs). Given Section 6.3, I think RFC7981 should be a normative reference rather than an informative one. I think RFC4271 also needs to be normative since it's referenced by a SHOULD. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Murray Kucherawy's Abstain on draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)
Murray Kucherawy has entered the following ballot position for draft-ietf-lsr-isis-srv6-extensions-14: Abstain 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/iesg/statement/discuss-criteria.html for more information about 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/ -- COMMENT: -- I'm balloting ABSTAIN for the reasons cited by Warren (and, hence, Ben). Some other unrelated comments: I suggest asking IANA to review your IANA Considerations section sooner rather than later to be sure they know what you're after. I found this section somewhat hard to follow. I concur with John, who suggested that this document doesn't actually update RFC 7370. I'm aware of the conversation that happened afterwards; just going on the record here. Section 9: * "It's usage is outside of the scope of this document." -- s/It's/Its/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Murray Kucherawy's No Objection on draft-ietf-lsr-ospf-prefix-originator-11: (with COMMENT)
Murray Kucherawy has entered the following ballot position for draft-ietf-lsr-ospf-prefix-originator-11: No Objection 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/ -- COMMENT: -- A note for the IESG: This is in the shepherd writeup: -- BEGIN -- (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. -- END -- As I said on another document on this week's docket, this is increasingly common. There are three questions being asked, but only one is being answered, and not the most important one at that. I'd really like it if this started getting caught someplace in the review process before IESG Evaluation. Or, if we don't actually care about the answer anymore, we should simplify or remove the question. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Murray Kucherawy's No Objection on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)
Murray Kucherawy has entered the following ballot position for draft-ietf-lsr-isis-invalid-tlv-02: No Objection 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/ -- COMMENT: -- In the Abstract: * "... in order to insure that interoperability is maximized." -- That should be "ensure". ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Murray Kucherawy's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)
Murray Kucherawy has entered the following ballot position for draft-ietf-isis-te-app-14: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-isis-te-app/ -- DISCUSS: -- An easy one: Sections 7.3 and 7.5 create new IANA registries with "Expert Review" rules, but Section 7.5 provides no particular guidance to the Designated Expert about how to review applications, as required by Section 4.5 of BCP 26. -- COMMENT: -- Since this document is in many parts a copy of draft-ietf-ospf-te-link-attr-reuse, I'm only reviewing this delta between them here: https://www.ietf.org/rfcdiff?url1=draft-ietf-ospf-te-link-attr-reuse-14=draft-ietf-isis-te-app-14 Section 2: * "... expected to continue - so any discussion ..." -- change to "... expected to continue. Therefore, any discussion ..." * "... key points identified in the introduction - which are:" -- change hyphen to a comma Section 3: * "... advertisements include sub-TLVs for TLVs ..." -- Please define or expand "TLV" on first use. * Please just name the registries, rather than giving multi-line URLs to them. Section 3.1: * As with the matching OSPF document, I don't see the benefit of citing current registry contents rather than just referencing the registry. Section 4.3: * Interestingly, the entries for IPv4 are not capitalized (e.g., "interface address"), but they are for IPv6 (e.g., "Interface Address"). Section 6.3.2: * These two paragraphs read like they're in the wrong order. Sections 7.1 and 7.2: * These should refer back to Sections 4.2 and 4.3, respectively, where the new values are fully described. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Murray Kucherawy's No Objection on draft-ietf-ospf-te-link-attr-reuse-14: (with COMMENT)
Murray Kucherawy has entered the following ballot position for draft-ietf-ospf-te-link-attr-reuse-14: No Objection 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ospf-te-link-attr-reuse/ -- COMMENT: -- Three main things from me: (1) I found I'm in agreement below with some of the points raised in the posted OPSDIR review. Please give that another once-over. (2) A grammatical point: I think nearly every instance in this document of "which" should be replaced by "that". (3) In Section 12.3.3, I don't think it's appropriate to use MUST-type language to constrain future document authors. And now, my nit-storm: Section 1: * "... attribute advertisements - examples of which ..." -- hyphen should be a comma * "... for a link that is not enabled for RSV-TE." -- s/RSV/RSVP/ * "... path via that link it will result ..." -- comma after "link" Section 3: * Please define, or provide a reference for, "GMPLS". Section 4.1: * "... not inspected by OSPF, that acts as ..." -- s/that/which instead/ Section 5: * Several changes to this paragraph suggested: OLD: On top of advertising the link attributes for standardized applications, link attributes can be advertised for the purpose of application that is not defined as standardized one. We call such application a user defined application. What such application might be is not subject to the standardization and is outside of the scope of this specification. NEW: On top of advertising the link attributes for standardized applications, link attributes can be advertised for the purpose of applications that are not standardized. We call such an application a "User Defined Application" or "UDA". These applications are not subject to standardization and are outside of the scope of this specification. * Is the snapshot of the current content of the Link Attribute Application Identifier Registry needed? The rest of the document doesn't seem to reference it. * "... to advertise all UDAs." -- although it's fairly clear at this point what a UDA is, I suggest defining it somewhere above, maybe by hanging it off one of the other places where the full name is used such as in the paragraph above Section 6.1: * Please expand "IPFRR" on first use. Section 6.2: * "All these can be used ..." -- s/All/All of/ Section 11: * "- e.g. RSVP-TE -" -- comma after "e.g." * "... one need to make sure ..." -- s/need/needs/ * "... applications, where the enablement ..." -- remove comma * "... such application - e.g. LFA." -- change to "such application. An example of this is LFA." Section 12.3.4: * "Link attributes that are NOT allowed ..." -- s/NOT/not/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Murray Kucherawy's No Objection on draft-ietf-ospf-mpls-elc-13: (with COMMENT)
Murray Kucherawy has entered the following ballot position for draft-ietf-ospf-mpls-elc-13: No Objection 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/ -- COMMENT: -- As with the IS-IS document, I assume the presence of six authors, above our usual limit of five, was approved by your AD. I agree with Barry's point that this document and the IS-IS document could easily have been combined. Even some of the syntactical things he corrected are present in both documents. When would you ever not do what the two SHOULDs in Section 3 say? ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Murray Kucherawy's No Objection on draft-ietf-isis-mpls-elc-12: (with COMMENT)
Murray Kucherawy has entered the following ballot position for draft-ietf-isis-mpls-elc-12: No Objection 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/ -- COMMENT: -- What Barry said. Also, I presume your AD has approved going over the usual limit of five authors. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
