Re: [Gen-art] GEN-ART telechat review of draft-farrell-perpass-attack-05
On Friday, January 31, 2014, Sam Hartman wrote: > Thanks Scott. > In the interest of being clear about my position, I support publication > of 04 but do not support publication of 05. I don't know why you object 05. > > I think all the discussion that is useful has happened and all that > remains is the consensus call from the sponsoring AD. > The AD should read all comments from the community of practical statements and AD to follow/sponsor reasonable statements/discussions or policies, not sponsoring best future plan as best current practice ( it may be initial plan for BCP). IMHO, the AD powers are not to be used against reasonable engineering discussions/requests only if that AD has done sound reasonable engineering replies. AB ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] GEN-ART telechat review of draft-farrell-perpass-attack-05
Thanks Scott. In the interest of being clear about my position, I support publication of 04 but do not support publication of 05. I think all the discussion that is useful has happened and all that remains is the consensus call from the sponsoring AD. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] GEN-ART telechat review of draft-farrell-perpass-attack-05
On 1/31/2014 8:55 AM, Scott Brim wrote: First, there are good arguments for publication as Informational , but since it incrementally adds to BCP 72, it should be incorporated there, so BCP is slightly better. It does? It does not say it does. So that linkage is something the reviewer is creating. At the least, a claim that it does "add to" BCP 72 invites further debate about the nature and implications of the update. Again, making this a BCP confuses the nature of the document with those that give substantive operational guidance. This document does exactly what it should: It defines the topic and it says the IETF considers the topic important. It calls for practices, but doesn't -- and shouldn't -- define them. The job of providing substantive details about IETF practices associated with the topic will come later. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] GEN-ART telechat review of draft-farrell-perpass-attack-05
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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-farrell-perpass-attack-05 Reviewer: Scott Brim Review Date: 2014-02-01 IETF LC End Date: 2013-12-31 IESG Telechat date: 2014-02-06 Summary: This draft is ready for publication as a BCP. Major issues: Minor issues: Nits/editorial comments: Two comments: First, there are good arguments for publication as Informational , but since it incrementally adds to BCP 72, it should be incorporated there, so BCP is slightly better. Second, the only significant difference from -04 was the removal of "and be prepared to justify their decisions". There was a lot of discussion that led to this, and some concern that the statement on architectural considerations is not strongly enough worded without it. However, see the previous paragraph (both paragraphs are below). I believe that these two paragraphs, taken together, do what is desired. Those developing IETF specifications need to be able to describe how they have considered PM, and, if the attack is relevant to the work to be published, be able to justify related design decisions. This does not mean a new "pervasive monitoring considerations" section is needed in IETF documentation. It means that, if asked, there needs to be a good answer to the question "is pervasive monitoring relevant to this work and if so how has it been considered?" In particular, architectural decisions, including which existing technology is re-used, may significantly impact the vulnerability of a protocol to PM. Those developing IETF specifications therefore need to consider mitigating PM when making these architectural decisions. Getting adequate, early review of architectural decisions including whether appropriate mitigation of PM can be made is important. Revisiting these architectural decisions late in the process is very costly. Scott ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art