We're preparing a post that summarizes all the open issues; we apologize
for not doing that earlier.
In some cases open issues were ones we didn't know how to address; in
other cases, we wanted to see if there was any other input in how to
address the issue raised, or whether there was consensus on the proposed
change.
That summary will be presented in rough form at the WG.
Joe
So, many of these comments have not been addressed.
I'm trimming my old message to include issues I still consider open.
------------------------------------------------------------------------
[anonsec] Comments on applicability statement
Sam Hartman <hartmans-ietf at mit.edu>
Tue, 9 Aug 2005 21:30:28 -0400 (EDT)
anonsec at postel.org
anonsec at postel.org
Overall I think the document is fairly good. I do have a few comments
I am submitting as an individual.
Section 3. Please sjeparate the applicability statement for SAB and
CBB even if you need to duplicate text. I think this will make it
much cleaner to evaluate when considering whether protocols meet the
applicability statement.
I don't tend to agree with the assertion that IKE is stronger than
CBB. That depends entirely on what's going on; I can think of
situations where CBB is stronger and situations where IKE is stronger.
I actually don't understand how https is similar to cbb at all in that
there is no channel binding.
I'm not sure that section 3.1 makes a good applicability statement.
In particular, it does not easily answer the two questions I would
expect from an applicability statement. As an operator considering
deploying BTNS, is BTNS appropriate for my use case. As a protocol
designer considering relying on BTNS, is BTNS appropriate for my
needs? I wonder whether we really need to break out all the
asymmetric cases. Instead I think it might be useful to focus on the
capabilities of a peer. That way you would need to describe when it
is acceptable to set up an association with an anonymous peer (SAB
applicability statement) and when it is acceptable to set up an
association to a peer you will bind at a higher layer (CBB
applicability statement).
Section 4.3 . I think ssh is a better example for leap of faith than
ssl. Section 4.3 should either rule this extension in scope or out of
scope. Currently it just mentions the extension but takes no
position.
In section 1.1 it seems odd to say that we use IPsec both because it is widely deployed and is facing deployment challenges.
I don't understand why the definition of CBB and SAB belongs in 1.1;
it seems like we want a section break between the assumptions and the
description of the two modes of operation.
Please cite a definition for DOS, DDOS and flash crowd.
_______________________________________________
------------------------------------------------------------------------
_______________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20051108/4eb8495a/signature.bin