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:
I would encourage you to publish the LFS draft as soon as possible so
that we can take a look at both specifications together since the IKE
draft does have some reliance on the LFS draft.
That's a good idea. I just published the document. You can find it at
the link below[1]. I also posted an email about it to the SAAG so
hopefully there will be some review from there as well.

[1]http://www.ietf.org/id/draft-quigley-label-format-registry-00.txt

Thank you.

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.

Jarrett

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to