[GROW] Terry Manderson's No Objection on draft-ietf-grow-irr-routing-policy-considerations-06: (with COMMENT)
Terry Manderson has entered the following ballot position for draft-ietf-grow-irr-routing-policy-considerations-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-grow-irr-routing-policy-considerations/ -- COMMENT: -- Thank you for putting the effort into this draft! The latest revision is improved, and addresses 98% of my comments when I was wearing a routing area directorate reviewer hat. Mostly I'm pleased to see a sentence in there which highlights that the RPKI doesn't carry routing policy information. I think there is a very real undertone in this document that shouldn't be avoided in that the RPKI takes steps to routing security, but misses a mark on policy integrity. I still don't buy the ideal that 10gig circuits are perceived as the norm - but happy to let that go as a future ideal.. mores law and all :) This document is one of the better outcomes of documenting in the IETF what was (is) and why wrt routing. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Genart Telechat review: draft-ietf-grow-filtering-threats-07
Robert, Pierre: Many thanks for your detailed review and re-review, Robert. And thanks for Pierre and others for taking into account the comments; I can see that the document has improved. As for the remaining issue of authors speaking vs. IETF speaking. I agree with the principle that Robert lays out. But I have also reviewed the document and given the specific text and the nature of the document (Informational RFC), I do not see a big problem with the current text. At least not something that would be Discuss-worthy from my end. FWIW, more generally, a document provides information, and there may or may not be IETF opinion backing that opinion. Standards track documents and BCP are true IETF recommendations. In my view, in those documents, even if they might say “the authors recommend XYZ” that really carries the weight of the IETF opinion. For the informational document, there is no requirement that it carries the weight of an IETF recommendation. But of course, where it is clear that there is an IETF opinion, it might still say that explicitly. Jari On 17 Aug 2015, at 20:48, Robert Sparks rjspa...@nostrum.com wrote: I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Document: draft-ietf-grow-filtering-threats-07 Reviewer: Robert Sparks Review Date: 17 Aug 2015 IETF LC End Date: 2 Jul 2015 IESG Telechat date: 20 Aug 2015 Summary: Ready with nits (but these nits may be discuss worthy) Nits/editorial comments: Thanks for removing the text suggesting when operators might charge each other. I still find the document ambiguous about what it's stating as the consensus of the IETF. In the places you changed how you used we, you did the very thing I asked to to resist - you say things now like The authors recommend. What is the IETF saying? Is it that the IETF agrees that's what the authors recommend? Or is the IETF recommending this. This needs to be edited to speak _only_ in terms of what the IETF recommends. I'm classifying this as a NIT since it's editorial, but I'm worried it's more than that. I encourage the IESG to consider whether this is a bigger issue. You still draw this conclusion: The authors observe that proactive approaches can be complex to implement and can lead to undesired effects, and thus conclude that the reactive approach is the more reasonable recommendation to deal with unexpected flows. What is the IETF consensus position on what is more reasonable, and is it even necessary for the IETF to recommend one approach over the other. Why is it not sufficient to simply document the considerations with each approach and stop there? Not much was done with my last suggestion. I still think the document needs a strong editorial revision along the lines suggested below. On 6/24/15 6:19 PM, Robert Sparks wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-grow-filtering-threats-06 Reviewer: Robert Sparks Review Date: 24-Jun-2015 IETF LC End Date: 2-Jul-2015 IESG Telechat date: not yet scheduled for a telechat Summary: Ready with nits From looking at the document history and list archives, this document's been around for some time, and has had some editorial push already. The unintended consequences it highlights are interesting, and it will be useful to operators to know these possible causes of unexpected behavior. I encourage another strong editing pass before publication. This is being published as an IETF-stream document. When published it reflects IETF consensus. There are places in the text that I think are problematic given that status. The issues are editorial, and I expect they will be easy to address. The document uses we frequently. Originally, that meant the authors. It's ambiguous what it means in an IETF-stream document. I suggest editing out all occurrences. Try to avoid simply changing we to the authors - find a way to reflect what the IETF is saying here. Is the last paragraph of 4.1 an IETF consensus position on how operators might charge one another? It would be good to find a way to word this that look more like statements of fact and less like charging advice. The document draws some conclusions that I think are unnecessary. For instance, Therefore, we conclude that the reactive approach is the more reasonable recommendation to deal with unexpected flows. Why does the IETF need to say that (and is it
Re: [GROW] Genart Telechat review: draft-ietf-grow-filtering-threats-07
On 8/20/15 9:34 AM, Jari Arkko wrote: After some more staring of the data tracker settings, you are of course completely correct, Robert :-) The document is marked as having IETF consensus setting, so the text that you quoted will get inserted into the RFC. Pardon my mistake in assuming it wasn’t. On the IESG call we had a discussion about this issue. We saw two separate questions: 1) Substance: Is there a consensus behind the document’s recommendations? The sponsoring AD and the IESG believes so. 2) Editorial: Is it appropriate to use the “the authors recommend…” form for IETF-level consensus statements? The sponsoring AD took your comment about the formulation (also recommended by other ADs) and will work with the author to revise the document. However, this matter is indeed editorial, i.e., a Comment rather than a Discuss level requirement from the IESG. So the document will be approved, after some editorial modifications, and will become an RFC. That plan works for me. Thanks! Jari ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Genart Telechat review: draft-ietf-grow-filtering-threats-07
After some more staring of the data tracker settings, you are of course completely correct, Robert :-) The document is marked as having IETF consensus setting, so the text that you quoted will get inserted into the RFC. Pardon my mistake in assuming it wasn’t. On the IESG call we had a discussion about this issue. We saw two separate questions: 1) Substance: Is there a consensus behind the document’s recommendations? The sponsoring AD and the IESG believes so. 2) Editorial: Is it appropriate to use the “the authors recommend…” form for IETF-level consensus statements? The sponsoring AD took your comment about the formulation (also recommended by other ADs) and will work with the author to revise the document. However, this matter is indeed editorial, i.e., a Comment rather than a Discuss level requirement from the IESG. So the document will be approved, after some editorial modifications, and will become an RFC. Jari signature.asc Description: Message signed with OpenPGP using GPGMail ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Kathleen Moriarty's No Objection on draft-ietf-grow-filtering-threats-07: (with COMMENT)
Kathleen Moriarty has entered the following ballot position for draft-ietf-grow-filtering-threats-07: 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-grow-filtering-threats/ -- COMMENT: -- Please add in the proposed text from the SecDir review to address his questions: https://www.ietf.org/mail-archive/web/secdir/current/msg05855.html Additionally, I'd like to see the Security Considerations mention a point brought up earlier in the draft, namely that the filtering could cause traffic to be routed back through a path that doesn't have information for that more specific AS. As such, this essentially could cause a DoS on that traffic until the BGP route allows for the new path for the more specific AS. The importance of mentioning this int he security considerations section is to more explicitly call this out as a potential DoS attack method. The time for BGP to repropagate might be short(ish), but that could be a critical amount of time during an event and maybe the more specific AS is a web server farm or some other critical resource. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
