Hi Avri, On 09/25/2013 01:08 PM, Avri Doria wrote: > Hi > > Very much support the draft and the idea of creating a BCP. > > Have also appreciated the discussion on opportunistic encryption, > which I consider akin to a holy grail. Been thinking about it in a > DTN context for a while, but don't feel like I ever got very far. > > I am, however, looking at another part of the text. I appreciate > that the requirements are a MUST and that reads well, but, doesn't > including a statement "Note that this is contingent on practicality" > really downgrade it to a SHOULD?
Well, I'd rather keep the MUST, but yes, it needs some kind of modulation and so is quite like a SHOULD. However, there are a bunch of people in the IETF who (wrongly, but nonetheless) only ever pay attention to MUSTs. What I think we're aiming for is something that's fairly strict but usable for new protocols but doesn't cause us silly problems e.g. if we want to revise RFC5322 again. We also want something that doesn't become an RFC6919 "MUST, but we know you won't." That's a tricky balance to achieve. > I think that "really has to be sent in clear for a protocol to be > able to operate" is too hand wavy as a guideline. Perhaps the > draft could go deeper in the kinds of conditions that indicate that: > > a) it was really necessary - what are the reasonable conditions for > necessity? b) an indication of what practical actions have been taken > to avoid this insurmountable obstacle and a discussion of which > particular requirements could not be met. c) a guideline that > indications be given on how can these instances be mitigated > > This could well be a clue to what sort of information is needed to > meet the requirement of explaining why the protocol does not fill the > other requirements for protecting private data. > > While I think that perhaps that I should go a little further breaking > down a-c above, Irealized I would not get this sent of for several > weeks if I were to try and go further and actually recommend text on > a-c above. Good points. I suspect we won't be done with this one in the next week so if you can get the time to propose something that'd be great. BCP107 does that by saying you MUST have auomated key management if any of <6 conditions> are met, not sure if that's a way to go about this though. S. > > > avri > > _______________________________________________ ietf-privacy mailing > list ietf-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-privacy > > _______________________________________________ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
