On Mon, 2010-08-02 at 09:09 -0700, Jarrett Lu wrote: > Paul Moore wrote: > > On Mon, 2010-08-02 at 10:32 -0400, David P. Quigley wrote: > > > >> On Mon, 2010-08-02 at 10:12 -0400, Paul Moore wrote: > >>> While leaving large chunks of the protocol out of the specification > >>> definitely makes it easier to draft (and review for that matter), it > >>> makes me very nervous when people start implementing the specification > >>> later down the line as the assumptions you make when developing > >>> implementation "A" might not work well with the assumptions I make with > >>> developing implementation "B". For something as critical as a security > >>> label protocol, this could have very serious repercussions for users. > >>> > >>> Granted, it is probably foolish (and perhaps not very desirable either) > >>> to ask for a specification that completely removes all ambiguity, but I > >>> think the IKE security label draft as currently written is far too vague > >>> to be useful. Look at the CALIPSO RFC or even the other IPsec/IKE RFCs > >>> to see the level of specification detail that, in my opinion, should be > >>> present in an IETF RFC. > >>> > >> We are accepting text for the document so if there is something you > >> believe that should be in it such as handling unauthorized labels feel > >> free to write up some text and send it our way. > >> > > > > Perhaps it would be better for you to document how you would assume the > > implementation to work with a level of detail similar to the other IKE > > and CALIPSO RFCs and then we can have another attempt at review? I'm > > saying this not to be difficult, but rather because I feel that > > providing the amount of additional text that I feel is needed would be > > roughly the same as writing a draft in the first place. To be honest, I > > look at this draft as an abstract for labeled IKE specification, not a > > draft specification itself. > > > > I suppose we can add more details / text on label validations and error > handling to avoid implementation ambiguities as much as possible. Our > intent is to add the label negotiation as a simple extension to IKEv2. It > really should be a short document.
Thanks, I think that should help. -- paul moore linux @ hp _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec