Dave,
Thanks for the feedback. Responses inline.
On Tue, May 26, 2009 at 6:28 AM, Dave
Cridland<dave(_dot_)cridland(_at_)isode(_dot_)com> wrote:
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors. Document editors and WG chairs should treat these comments just
like any other last call comments.
(I note there is expected to be a new version coming for this draft).
Security Issues:
The Security Considerations section is reasonably complete, as far as I can
tell, however it is not terribly clear that it suggests authentication of
the clients (it says "preexisting credentials") - I think this could be
clearer. The description of XOR-RESPONSE-TARGET also doesn't include this,
it's mentioned most clearly in Section 6.1.
I made a lot of edits around XOR-RESPONSE-TARGET, in the process I
actually removed the phrase "pre-existing credentials", just leaving
it as authenticated. However, the term comes from 5389, which only
defines mechanisms for using "pre-existing credentials" for
authentication, meaning credentials that are obtained through a
mechanism outside STUN itself.
General comments:
I have a strong suspicion that this document is Experimental purely because
it failed to gain sufficient consensus to be Standards-Track. It's not clear
to me why this is not Informational, or why all the extensions described in
the document are within the same document. I'm dubious that they're all of
similar quality.
If there is an experiment here, then it's in the usage of these extensions
to determine whether, at least in some cases, NAT behaviour is sufficiently
stable as to be useful, and moreover, whether taking advantage of this is
practical. The extensions themselves clearly seem suitable for discovering
whether this is so.
As such, section 2.3 seems somewhat contrived and grasping. This isn't to
say that the hypothesis being tested is not valid, but the experiment, as
defined, seems like a matter of form rather than a useful test of the
hypothesis as outlined.
Section 2.3 doesn't describe an experiment, it describes conditions
for experimental success. Section 2.2 has been greatly expanded and
now describes in much more detail how such an application might work.
However, it's not the only application that could satisfy the
conditions.
Editorial Issues:
The use of the term "aprocyphal" is interesting, but conjures up
connotations that seem to be somewhat self-defeating. Perhaps "anecdotal"
would be more fitting, or "controversial". (It is this evidence, after all,
that forms the hypothesis mentioned above, and the hypothesis itself is
surely not aprocypha).
Another reviewer also brought this up. Technically, "aprocryphal"
could be interpreted as being contrary to IETF dogma, but I think
you're right that anecdotal is clearer here.
IANA section requests registration of CHANGE-REQUEST, but this is already
registered - the registration needs changing, as per section 6.1, where the
situation is detailed more clearly.
Numerous attempts by myself and others to determine the right way to
handle this have indicated that this is the appropriate way to handle
this, as the original registration has been obsoleted. But I'm always
open for advice as to the best way to handle it.
Bruce
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf