[Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-ospfv3-extended-lsa-yang-29: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-lsr-ospfv3-extended-lsa-yang-29: 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: -- Thank you for addressing my DISCUSS feedback and explaining the details of OSPFv3 extended LSAs. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Roman Danyliw's Discuss on draft-ietf-lsr-ospfv3-extended-lsa-yang-28: (with DISCUSS and COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-lsr-ospfv3-extended-lsa-yang-28: 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-ospfv3-extended-lsa-yang/ -- DISCUSS: -- ** Section 5. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. There are the subtrees and data nodes and their sensitivity/vulnerability: /ospf:ospf/extended-lsa-support /ospf:ospf/ospf:areas/ospf:area/extended-lsa-support The ability to disable OSPFv3 Extended LSA support can result in a denial of service. Isn’t it more than just denial of service? In certain environments wouldn’t the ability to modify OSPF Extended LSA configurations enable an attacker to: modify network topologies to enable select traffic to avoid inspection or treatment by security controls; route traffic in a way that it would be subject to inspect/modification by an adversary node; or gain access to otherwise segregated parts of the network. -- COMMENT: -- As an editorial note, I would have benefit from some narrative prose on the data model. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-isis-area-proxy-12: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-lsr-isis-area-proxy-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-isis-area-proxy/ -- COMMENT: -- Thank you for addressing my COMMENT and DISCUSS feedback. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Roman Danyliw's Discuss on draft-ietf-lsr-isis-area-proxy-11: (with DISCUSS and COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-lsr-isis-area-proxy-11: 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-isis-area-proxy/ -- DISCUSS: -- ** Section 4.3. Do all the candidates need the Area Proxy System Identifier TLVs need the same system identifier? -- Section 4.2 says “For consistency, all Area Leader candidates SHOULD be configured with the same Proxy System ID, Proxy Hostname, and any other information that may be inserted into the Proxy LSP.” -- Section 4.3.1 says: “All candidates advertising the Area Proxy System Identifier TLV MUST be advertising the same system identifier.” The first statement suggests that consistency might not always be required, but the second statement is clear that it always must be the same identifier. Per our discussion on https://mailarchive.ietf.org/arch/msg/lsr/HbpEgfX4p7rSMr490kylMyy5pFA, I believe the agreed resolution is to s/MUST/SHOULD/ in Section 4.3.1. -- COMMENT: -- Thank you to Alexey Melnikov for the SECDIR review. ** Section 8. 8. Security Considerations This document introduces no new security issues. Security of routing within a domain is already addressed as part of the routing protocols themselves. This document proposes no changes to those security architectures. -- What are the relevant pointers to IS-IS security considerations? Per https://mailarchive.ietf.org/arch/msg/lsr/HbpEgfX4p7rSMr490kylMyy5pFA/, please consider adding references to RFC 5304 and 5310. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Roman Danyliw's Discuss on draft-ietf-lsr-isis-area-proxy-10: (with DISCUSS and COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-lsr-isis-area-proxy-10: 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-isis-area-proxy/ -- DISCUSS: -- ** Section 4.3. Do all the candidates need the Area Proxy System Identifier TLVs need the same system identifier? -- Section 4.2 says “For consistency, all Area Leader candidates SHOULD be configured with the same Proxy System ID, Proxy Hostname, and any other information that may be inserted into the Proxy LSP.” -- Section 4.3.1 says: “All candidates advertising the Area Proxy System Identifier TLV MUST be advertising the same system identifier.” The first statement suggests that consistency might not always be required, but the second statement is clear that it always must be the same identifier. ** Section 8. The following statement doesn’t appear to be accurate. 8. Security Considerations This document introduces no new security issues. Security of routing within a domain is already addressed as part of the routing protocols themselves. This document proposes no changes to those security architectures. -- Aren’t a few the filtering activities described in Section 5.2 security-related? -- What are the relevant pointers to IS-IS security considerations? -- COMMENT: -- Thank you to Alexey Melnikov for the SECDIR review. ** Section 4.3.1 However, before withdrawing the Area Proxy System Identifier, an implementation SHOULD protect against unnecessary churn from transients by delaying the withdrawal. The amount of delay is implementation-dependent. Are there any guidelines on how the delay period should be computed? ** Section 4.4.4. An entry for a neighbor in both the IS Neighbors TLV and the Extended IS Neighbors would be functionally redundant, so the Area Leader SHOULD NOT do this. Under what circumstances would this advice be ignored (i.e., why not a MUST)? ** Section 4.4.5 and 4.4.6 describe various behavior where fields “SHOULD” be copied. What governs the choice of not copying these fields? Would operators be impacted in troubleshooting or even operations if different implementations applied this advice differently? Would it be up to local configuration? Later sections in 4.4.* also have “SHOULD” behavior as well where the reason for not following the behavior is not clear. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-ospfv3-srv6-extensions-14: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-lsr-ospfv3-srv6-extensions-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/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-srv6-extensions/ -- COMMENT: -- Thank you for addressing my DISCUSS and COMMENT feedback. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Roman Danyliw's Discuss on draft-ietf-lsr-ospfv3-srv6-extensions-12: (with DISCUSS and COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-lsr-ospfv3-srv6-extensions-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-ospfv3-srv6-extensions/ -- DISCUSS: -- ** Section 12. While OSPFv3 is under a single administrative domain, there can be deployments where potential attackers have access to one or more networks in the OSPFv3 routing domain. In these deployments, stronger authentication mechanisms such as those specified in [RFC4552] or [RFC7166] SHOULD be used. Please rewrite this guidance. It appears to be saying that in networks with potential attackers stronger authentication mechanisms SHOULD be used. With the use of the language of "_potential attacker" and "_one_ or more", isn’t that all networks? Is this equivalent to strong auth SHOULD be used? -- COMMENT: -- ** Section 12. This document cites the applicability of RFC8362’s Security Considerations whose primary guidance appears to be: If there were ever a requirement to digitally sign OSPFv3 LSAs as described for OSPFv2 LSAs in RFC 2154 [OSPF-DIGITAL-SIGNATURE], the mechanisms described herein would greatly simplify the extension. Is the signature mechanism in RFC2154 still considered viable and needed? I note that it was published with experimental status in 1997 and supports only one signature-hash mechanism, RSA-MD5, despite having seemingly robust extensibility mechanisms via https://www.iana.org/assignments/ospf-sig-alg/ospf-sig-alg.xhtml. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-isis-flood-reflection-11: (with COMMENT)
Roman Danyliw 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: -- Thank you to Rich Salz for the SECDIR review. ** Section 4.1 The Flood Reflection TLV SHOULD NOT appear more than once in an IIH. Why isn’t the guidance here “MUST NOT” appear since any subsequent, duplicate Flood Reflection TLVs are ignored? Same comment on the discovery Sub-TLV in Section 4.2, and Section 4.4 ** Section 4.3 Carries encapsulation type and further attributes necessary for tunnel establishment as defined in [RFC9012]. The Protocol Type sub-TLV as defined in [RFC9012] MAY be included. The first sentence suggests that the semantics of this field are defined by RFC9012. The second sentence suggests that it is optional to support the Protocol Type sub-TLV per Section 3.4.1 of RFC9012. This is confusing to me because RFC9012 supports a number of sub-TLVs to include the Protocol Type one explicitly called out. Is that the only sub-TLV supported for use? Editorial ** Section 1. Typo. s/Maintainance/Maintenance/ ** Section 1. Editorial. Consider using a less colloquial phrase than “Deployment-wise”. ** Section 4.2. Editorial. s/one ore more/one or more/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-ospf-l2bundles-06: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-lsr-ospf-l2bundles-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-l2bundles/ -- COMMENT: -- Thank you to Russ Mundy for the SECDIR review. I support Lars Eggert DISCUSS position. It would be clearer if the the Y/N status indicated by Figure 2 were document via an additional column in the https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xhtml#extended-link-tlv-sub-tlvs registry. Same observation for Y/N/X in Figure 3 and https://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#extended-lsa-sub-tlvs. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-flex-algo-24: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-lsr-flex-algo-24: 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-flex-algo/ -- COMMENT: -- Thank you to Charlie Kaufman for the SECDIR review. ** Section 4. We want the mapping between the Flex-Algorithm and its meaning to be flexible and defined by the user. Is a “Flex-Algorithm” (with hyphen) the same as a “Flex Algorithm” (no hyphen) defined in Section 3? Why the difference in notation? ** Section 4. The set consisting of (a) calculation-type, (b) metric-type, and (c) a set of constraints is referred to as a Flexible-Algorithm Definition. Flexible-Algorithm is a numeric identifier in the range 128-255 that is associated via configuration with the Flexible-Algorithm Definition. This text repeats the text in Section 3 verbatim. Is it needed twice? ** Section 5. ... and (b) are in the same Flex-Algorithm definition advertisement scope What is a “FAD advertisement scope?” Should this be an additional term defined in Section 3? ** Section 5.1. Should the explanation of “Metric-Type” say that it’s value comes from the “IGP Metric-Type Registry” per Section 18.1.2? Section 5.1. Is it possible for a peer not to support a particular Metric-Type? If so, have is that signaled? ** Section 5.1. An IS-IS L1/L2 router MAY be configured to re-generate the winning FAD from level 2, ... What is the “winning FAD?” ** Section 5.1 and 5.2. Editorial. Definition of Flex-Algorithm in the TLV. -- Section 5.1 Flex-Algorithm: Single octet value between 128 and 255 inclusive. -- Section 5.2 Flex-Algorithm:: Flex-Algorithm number. Value between 128 and 255 inclusive. Should this text be the same? ** Section 5.2. Editorial. Why is the text defining Metric-Type repeated verbatim from what is written in Section 5.1, but Calc-Type and Priority cite Section 5.1? ** Section 6.4. New flag bits may be defined in the future. Implementations MUST check all advertised flag bits in the received IS-IS FADF Sub-TLV - not just the subset currently defined. Let’s assume bits other than those define in this document are set. Is there an IANA registry to check to understand their semantics? ** Section 13.1. During the route computation, it is possible for the Flex-Algorithm specific metric to exceed the maximum value that can be stored in an unsigned 32-bit variable. In such scenarios, the value MUST be considered to be of value 0x during the computation and advertised as such. Should this guidance be referenced in Section 8 – that 0x could be 0x or an overflow value? ** Section 17. This draft adds two new ways to disrupt IGP networks: An attacker can hijack a particular Flex-Algorithm by advertising a FAD with a priority of 255 (or any priority higher than that of the legitimate nodes). An attacker could make it look like a router supports a particular Flex-Algorithm when it actually doesn't, or vice versa. What are the consequences of the described attacker behaviors? Is “disrupt[ing] the IGP networks” just a denial of service? Could it also be steering traffic in a particular way to allow inspection or modification; or to avoid network based mitigations? ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-ospf-bfd-strict-mode-08: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-lsr-ospf-bfd-strict-mode-08: 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-bfd-strict-mode/ -- COMMENT: -- Thank you to Wes Hardaker for the SECDIR review. ** Section 1. Typo. s/adjaceny/adjacency/ ** Section 1. Typo. s/establishement/establishment/ ** Section 8. If authentication is being used in the OSPF routing domain [RFC5709][RFC7474], then the Cryptographic Authentication TLV [RFC5613] SHOULD also be used to protect the contents of the LLS block. Since strict-mode BFD functionality is not going to be present in legacy implementations, could it be mandatory to protect the LLS block (i.e., use of the Cryptographic Authentication TLV is a MUST)? ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Roman Danyliw's Abstain on draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)
Roman Danyliw 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: -- (updated position) I'm balloting ABSTAIN for the reasons already eloquently stated by Ben; and with follow-up from Warren and Murray. I support Eric Kline's Discuss position. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)
Roman Danyliw 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: -- I'm glad to see language clarifying error handling. Thanks for the work on it. Section 3.2. Per “It is RECOMMENDED that implementations provide controls for the enablement of behaviors that are not backward compatible”, I want to double check that I’m understanding this sentence correctly. RFC5304 provides normative guidance that isn’t backward compatible with ISO10589. RFC6233 provide guidance that isn’t backward compatible with either RFC5304 or ISO10589. Is the initial sentence effectively saying that implementations should support deployments in configurations that are not backward compatible (i.e., those using the newer TLVs)? As these changes are covering security matters, I read “controls” in the cyber mitigation sense -- they prevent an action, not enable one. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Roman Danyliw's No Objection on draft-ietf-isis-te-app-14: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-isis-te-app-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-isis-te-app/ -- COMMENT: -- (revised) ** Section 4.1. As I understand it, the SABM can be of 0 – 8 octets in length. The SABM Length field represents that length and has 7 bits to do that. However, the maximum number of bits needed to represent 8 is only 4 bits. What’s the thinking on those three extra bits? Should they be marked as reserved? I would have the same question for the UDABM mask. ** Section 6.2. I didn’t follow what it means to send the sub-TLV in Section 4.2 with a zero length SABM Length and UDABM Length – that is two empty bitmasks? Is that permitted? What would it convey? ** Section 8. Per “Tampering with the information defined in this document may have an effect on applications using it, including impacting Traffic Engineering.”, I have no disagreement with this statement. However, I would recommend adding a brief statement what is the security impact of “impacting Traffic Engineering”. ** Section 8. Per “This is similar in nature to the impacts associated with (for example) [RFC5305]”, what specific text in RFC5305 was envisioned? The SecCon section (Section 6) of RFC5305 contains only one sentence that points to RFC5304? ** Section 8. Consider using the editorial framing of the first paragraph of Section 13 in draft-ietf-ospf-te-link-attr-reuse to introduce how the RFC5304 applies here. ** Editorial -- Section 3. Editorial. Consider providing a reference for the registries instead of an inline URL. -- Section 4.1. The rendering of the sub-TLV diagram was split between Page 6 and 7 when this draft is read in TXT format. IMO, it would be more readable if it was on one page. -- Per Section 4.1. Editorial. Per “See the following section for a description …”, please explicitly name the section. -- Section 4.2. Typo. s/Identifer/Identifier/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Roman Danyliw's No Objection on draft-ietf-ospf-te-link-attr-reuse-14: (with COMMENT)
Roman Danyliw 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: -- (revised) ** Section 5. (same comment as raised about Section 4.1. of draft-ietf-isis-te-app) If the possible values of SABM Length and UDABM Length are 0, 4 and 8, and these are stored literally, why are 8 bits required? Could they be reallocated to the Reserved field? ** Section 13. (same comment as raised about Section 4.1. of draft-ietf-isis-te-app) Per “Tampering with the information defined in this document may have an effect on applications using it, including impacting Traffic Engineering.”, I have no disagreement with this statement. However, I would recommend adding a brief statement what is the security impact of “impacting Traffic Engineering”. ** Section 13. Per "This is similar in nature to the impacts associated with (for example) [RFC3630]", what specific text in RFC3630 was envisioned. I didn't follow the link. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Roman Danyliw's No Objection on draft-ietf-ospf-te-link-attr-reuse-14: (with COMMENT)
Roman Danyliw 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: -- ** Section 5. (same comment as raised about Section 4.1. of draft-ietf-isis-te-app) If the possible values of SABM Length and UDABM Length are 0, 4 and 8, and these are stored literally, why are 8 bits required? Could they be reallocated to the Reserved field? ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Roman Danyliw's No Objection on draft-ietf-isis-te-app-14: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-isis-te-app-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-isis-te-app/ -- COMMENT: -- ** Section 4.1. As I understand it, the SABM can be of 0 – 8 octets in length. The SABM Length field represents that length and has 7 bits to do that. However, the maximum number of bits needed to represent 8 is only 4 bits. What’s the thinking on those three extra bits? Should they be marked as reserved? I would have the same question for the UDABM mask. ** Section 6.2. I didn’t follow what it means to send the sub-TLV in Section 4.2 with a zero length SABM Length and UDABM Length – that is two empty bitmasks? Is that permitted? What would it convey? ** Section 8. Per “Tampering with the information defined in this document may have an effect on applications using it, including impacting Traffic Engineering.”, I have no disagreement with this statement. However, I would recommend adding a brief statement what is the security impact of “impacting Traffic Engineering”. ** Section 8. Per “This is similar in nature to the impacts associated with (for example) [RFC5305]”, what specific text in RFC5305 was envisioned? The SecCon section (Section 6) of RFC5305 contains only one sentence that points to RFC5304? ** Editorial -- Section 3. Editorial. Consider providing a reference for the registries instead of an inline URL. -- Section 4.1. The rendering of the sub-TLV diagram was split between Page 6 and 7 when this draft is read in TXT format. IMO, it would be more readable if it was on one page. -- Per Section 4.1. Editorial. Per “See the following section for a description …”, please explicitly name the section. -- Section 4.2. Typo. s/Identifer/Identifier/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Roman Danyliw's No Objection on draft-ietf-isis-mpls-elc-12: (with COMMENT)
Roman Danyliw 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: -- Two editorial nits: ** Section 3. Editorial. s/ When a router propagates a prefix between ISIS levels ([RFC5302],/When a router propagates a prefix between ISIS levels [RFC5302],/ ** Section 4. Figure 2. The text says that “A MSD-Type Code 2 has been assigned by IANA”, but Figure 2 says “MSD-Type=TBD2”. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Roman Danyliw's Discuss on draft-ietf-isis-yang-isis-cfg-40: (with DISCUSS)
Roman Danyliw has entered the following ballot position for draft-ietf-isis-yang-isis-cfg-40: 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-yang-isis-cfg/ -- DISCUSS: -- Section 7. A DISCUSS for discussion. Thanks for this enumeration of writeable and readable nodes which could be considered sensitive. Per the list of nodes that could expose the topology of the network, wouldn’t the following also have sensitive topology information: -- /isis/local-rib -- /isis/hostnames Furthermore, shouldn’t the log files also be protected as the errors or status posted there could also leak topology information: -- /isis/spf-log -- /isis/lsp-log ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-isis-rfc5306bis-06: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-lsr-isis-rfc5306bis-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/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-rfc5306bis/ -- COMMENT: -- (1) Section 3.1. The two “NOTE” statements in this section seem to conflict: -- NOTE: These timers are NOT applicable to a router which is preparing to do a planned restart. -- NOTE: The timer T3 is only used by a restarting router. (2) Per the definition of the “Remaining Time” field, when is it the “remaining holding time” vs. “recommended holding time" (3) Editorial Nits: -- Multiple places. s/signalling/signaling/g ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Roman Danyliw's Discuss on draft-ietf-ospf-xaf-te-06: (with DISCUSS)
Roman Danyliw has entered the following ballot position for draft-ietf-ospf-xaf-te-06: 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-ospf-xaf-te/ -- DISCUSS: -- An easy item to address. Per Section 5, “Specifically, TE traffic may be delivered to the wrong tail-end router, which could lead to suboptimal routing or even traffic loops”, the impact could also include providing access to an attacker. Perhaps: OLD: Specifically, TE traffic may be delivered to the wrong tail-end router, which could lead to suboptimal routing or even traffic loops. NEW: Specifically, TE traffic may be delivered to the wrong tail-end router, which could lead to suboptimal routing; traffic loops; or expose the traffic to attacker inspection or modification. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Roman Danyliw's Discuss on draft-ietf-isis-segment-routing-extensions-24: (with DISCUSS and COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-isis-segment-routing-extensions-24: 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-segment-routing-extensions/ -- DISCUSS: -- I need a bit of help understanding how to read the Security Considerations text – threats are identified but how they are mitigated seems implicit. The text, “In general the same types of attacks … However, the latter will be more difficult to detect …”, alludes to a similar threat without a reference and seems to suggest it will be worse in the deployed environment of this extension. The next paragraph, “Existing security extensions … [RFC5304] and [RFC5310] apply …” states that [RFC5304] and [RFC5310] also apply. What does apply mean here – should they be used? Do they mitigate what’s described in the previous paragraph? -- COMMENT: -- Section 2.3. Typo. s/advertsied/advertised/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
