Ballot for draft-ietf-savnet-intra-domain-problem-statement
Yes
No Objection
Note: This ballot was opened for revision 22 and is now closed.
# Gunter Van de Velde, RTG AD, comments for draft-ietf-savnet-intra-domain-problem-statement-22 # The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-savnet-intra-domain-problem-statement-22.txt # Thank you for fixing all the comments and issues from the prior Telechat. This document has improved significantly, is easy to read and is well written. # Detailed Review # =============== 166 Improper Block: The validation results that the packets with 167 legitimate source addresses are blocked improperly due to inaccurate 168 SAV rules. 169 170 Improper Permit: The validation results that the packets with spoofed 171 source addresses are permitted improperly due to inaccurate SAV 172 rules. GV> Maybe trivial and mostly editorial, is it possible to add a few words on "proper block (or simply 'block')" and "proper permit (or simply 'permit')". The above explains the improper beg=havior without specifying what is proper behavior. 177 1.2. Requirements Language 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 181 "OPTIONAL" in this document are to be interpreted as described in 182 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 183 capitals, as shown here. GV> This is an informational document and BCP14 keywords do not necessary apply. Potentially you want to add the following paragraph for clarity: " The requirements language is used in Section 5 and applies to implementations of SAV conformant to the listed requirements. " 231 requires manual maintenance. Operators must update them promptly to 232 reflect changes in prefixes or topology. Failure to do so may result 233 in outdated ACLs that inadvertently block legitimate traffic. GV> The larger security issue is not an improper block, but a improper permit. Could be worthwile to add to the paragraph. Thanks for this write-up. Gunter Van de Velde RTG Area Director
I want to thank Robert Sparks for his ARTART review, and echo his comment about the need for this to be published as an RFC (also mentioned by Charles and Med). I have no objection to this document proceeding.
I want to thank Robert Sparks for the ARTART review. I agree with his suggestion to consider using the document to refine the group's charter text rather than publishing it as an informational RFC. That said, I do not have any ART-related concerns, nor do I object to the publication of this document if there is working group consensus that it is helpful to do so. The document provides a gap analysis and identifies requirements for new intra-domain SAV solutions; however, I find these requirements to be subjective and difficult to prove that a given solution or mechanism will necessarily address them. Roman has already provided more detailed feedback for this as part of his DISCUSS, which I support.
Thank you to Robert Sparks and Ben Schwartz for the reviews. They were very helpful. I will echo the comment of both reviewers and other ADs - this document doesn't appear to need to be published. It really seems most useful as a document guiding the design of any additional SAV mechanisms or enhancements. That is material useful for inside the WG.
Thanks to Ben Schwartz for their multiple secdir reviews. It is unusual to have this many reviewers suggest that the draft should not be an RFC. I count at least three (Art, Secdir, Opsdir) plus at least a couple of ADs. I support the discuss positions of Roman, Med and Ketan.
Thanks for addressing (partly) my DISCUSS points (see https://mailarchive.ietf.org/arch/msg/savnet/lXvPRzPjJ0V0r97rKHToQx1Zyds/ for archive). By "partly addressing my DISCUSS point", I mean that, while the clarity is vastly better, I had to read 3 times the section 1 to eventually understand it. The term "intra-domain SAV" is still heavily misleading. The authors have selected to address my non-blocking COMMENTs, while this is disapointing, it is not blocking. Finally, I still support Roman Danyliw's DISCUSS related to the vague use of "fewer" in section 5.1
Thanks to the authors and the WG for their work on this document. Also thanks for the productive discussions and the updates to address the discussion points and comments in my original ballot.
Hi Dan, Jianping, Lancheng, Mingqing, and Nan, Thank you for the discussion and for taking care of the comments. The changes [1] made since my first ballot [2] are really great. Cheers, Med [1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-savnet-intra-domain-problem-statement-22&url2=draft-ietf-savnet-intra-domain-problem-statement-24&difftype=--html [2] https://mailarchive.ietf.org/arch/msg/savnet/s0128azyYuCAVcU-1wgR9BZrkNk/
Thank you to Tim Evens for the GENART review. Thank you for addressing my DISCUSS feedback.
I appreciate the authors addressing my discuss concern. Given my remaining feedback is about whether WGs really need to publish requirements docs or not, which is subjective, I am balloting No Objection.