Re: [Lsr] Roman Danyliw's No Objection on draft-ietf-ospf-te-link-attr-reuse-14: (with COMMENT)
Hi Roman, thanks for your comments, please see inline (##PP): On 10/06/2020 23:58, Roman Danyliw via Datatracker wrote: 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? ##PP We did not limit the size at the beginning, but later due to limited size of ISIS TLVs we limited it to 8 bytes to leave some space for the attributes itself (draft-ietf-isis-te-app). We wanted to keep the consistency between ISIS and OSPF which also helps BGP-LS. 8 octets should be future-proof enough (64 apps). We keep the byte for the SABM and UDABM lengths to avoid problems of existing implementation. ** 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”. ##PP TE is one of the applications using link attributes for selecting the explicit paths. Messing around with advertisement of the link attributes that TE uses may affect the TE path selection. I modified as: "including impacting Traffic Engineering that uses various link attributes for its path computation." Would that be good enough? ** 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. Here's the text from the RFC3630: "However, tampering with TE LSAs may have an effect on traffic engineering computations, and it is suggested that any mechanisms used for securing the transmission of normal OSPF LSAs be applied equally to all Opaque LSAs, including the TE LSAs specified here" thanks, Peter ___ 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
