On Thu, Oct 8, 2009 at 7:28 PM, Song Haibin <[email protected]> wrote: > Hi Eric, > > The only comment raised by you during the meeting and in the mailing list is > about the RFC 2119 language.
This is not correct. If you go listen to the meeting, I complained that this document seemed extremely generic and disconnected to RELOAD. Seeing as we already *have* an architecture and a proposed protocol with a whole bunch of its own security analysis and characteristics, I don't understand what the purpose of this document is. You can see this in the jabber log: 15:05:44] <ekr> mic: I'm sort of concerned by how generic this is. [15:05:45] <Ted(with knees)> Show of hands for readers: a few [15:05:51] <Cullen Jennings> 3 peopel had read it [15:06:28] <ekr> IT seems almost totally detached from RELOAD as it currently is. [15:07:57] <Adam Roach> Oh, wait. I figured it out. You use recvmsg, and then iterate the cmsghdrs until you find the one with a cmsg_type of IP_TTL [15:08:09] <Ted(with knees)> waiting by mic, ekr [15:08:09] <Adam Roach> So it looks like there's no problem doing the TTL trick on either end [15:09:16] <Ted(with knees)> okay heading back [15:09:20] <ekr> mic: I think Cullen has sort of hit my concern. This seems like a security analysis of some hypothetical unspecified protocol that sort of is vaguely connected to P2PSIP. But we're way beyond that point. We've got a specific architecture and protocol and so it's odd to have a security analysis that's unconnected to that. > Roni has replied and gave the authors' > explanation in the mailing list. We have not received any further comments > after your planned review. As I noted in my previous message, the whole tone of this document remains inappropriate. If you think you're going to do a purely informative document that's a tutorial on P2P/P2PSIP securing in general (which is what the WG hummed for), then while I personally don't see the value in it, I have no objection. However, this document is full of normative/requirements-type language, of which the use of words like must and should (even in lower case) is merely the most obvious manifestation. If you're writing a tutorial document, then it shouldn't be telling people what to do, period. My previous comment identified a number of these passages but what the document needs is a complete scrub of all such material. -Ekr _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
