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

Reply via email to