Thank you for the review. Please see inline. > On Aug 14, 2019, at 11:39 PM, Liang Xia via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Liang Xia > Review result: Has Issues > > Some nits: > 1. title of Section 4.3.2: /FIB Entry is a Local Interface/FIB Entry Is A Local > Interface OK > 2. title of Section 5.2: /SR Domain as a single system with > delegation among components/SR Domain as A Single System with Delegation among > Components OK > 3. Section 2.1.1: /There are two types of padding TLVs, pad1 and > padN, the following applies to both/There are two types of Padding TLVs, pad1 > and padN, the following applies to both Ack, we’ll use Padding TLV capitalized as a name. > 4. Section 2.1.2: "Alignment > requirement: 8n". What is 8n? For better readability, can you give a more clear > clarification text? Section 2.1 describes what an alignment requirement is and how it is documented, referencing RFC8200. "All TLVs specify their alignment requirements using an xn+y format. The xn+y format is defined as per [RFC8200]. The SR Source nodes use the xn+y alignment requirements of TLVs and padding TLVs when constructing an SRH.” Does this address your concern? > 5. Section 4.1: /HMAC TLV may be set according to Section > 7./HMAC TLV may be set according to Section 2.1.2./? Thanks, I’ve fixed the XML xref for the next revision. > 6. Section 4.3: have a "*" > before every item of "A FIB entry…” > ? > Sure, I expect that would make it more obvious they are individual line items. > 1 issue: > The Security Considerations Section mainly clarifies the security protection > based on the strict SR Domain boundary protection paradigm, and the > considerations of some identified attacks. They are valuable, but maybe not > complete in scope. I noticed 2 SR related security consideration drafts > (draft-perkins-sr-security-00 and > draft-li-spring-srv6-security-consideration-00), which are trying to summarize > all the possible vulnerabilities in SR network. I personally suggests the > authors to review them and consider how to reference or incorporate the > valuable considerations from them. Thank you for this suggestion, I’ve analyzed both the referenced documents: draft-li-spring-srv6-security-consideration-01 concludes that there is no packet falsification, identity spoofing, packet replay, DOS/DDOS threat within an SR Domain. It defines a security design following that documented in draft-ietf-6man-segment-routing-header-22. I see nothing to add from this draft. draft-perkins-sr-security-00 discusses a set of deployment scenarios, and SIDs that are not documented in draft-ietf-6man-segment-routing-header-22, and are therefore out of scope for draft-ietf-6man-segment-routing-header to consider. However the discussions started with draft-perkins-sr-security-00 should continue in the context of the SPRING WG, as per its charter, for the technologies and documents it produces using the SRH. Would this address your concern? Darren
