I propose some text for the draft near the bottom of this email....
On Feb 2, 2011, at 2:16 AM, Magnus Westerlund wrote:
Cullen Jennings skrev 2011-02-01 18:19:
So to summarize what you are saying, ports are allocated based on an
arbitrary view of the expert review. When this person will say yes or no too
can't be described and will change over time.
If that's how it works, there is not even any grounds for appeal of any
given decision. You can't even use precedence as an argument. My view was
the IESG has been trying to move to having much more concrete advice for
registries that required expert review. If you agree that is about the right
summary, then I'm pretty sure I can find plenty of other people that would
agree with me that this is not OK. I'm not a fan of the WG could not get
consensus on if we should allow A or not so we are just going to let the
expert review do whatever they want. If the IETF could not come to consensus
on if X or Y were reasons to deny a registration, then I don't think the
expert review should be able to deny a registration due to X or Y.
Cullen,
Apparently you like to twist what I am saying in most negative way and
without considering the checks that are in place.
Sorry Magnus ... I really did not mean to twist your words. I know you are very
straight up about this type of stuff. I suggested some text bellow.
- I think general guidelines can and should be developed. But other than
high level goals this isn't the document. Here Joe has the start of a
document. But I do think that in long term this guidance may change.
- There is an appeal process where the IESG and then IAB gets to sanity
check the arguments that the reviewer + IANA has given towards the
appealing requestor.
I understand that but we both know appeals are a painful tool to use and we
would like to avoid it where possible - they waste an incredible amount of time
for everyone involved and particularly the IESG.
- One can take a assignment request through the IETF process
I'm not as focused on drafts in IETF process but even in theses cases, WGs will
look to this BCP for guidance on what would be acceptable behavior. So even if
this draft might not "legally" block a WG from doing something, the WG will
still be influenced by the goals this draft "strives" for. That is a good thing
- BCP advice that applies to non IETF work should guide IETF process work too.
I hope that we can get consensus on the guidelines, because I think that
would give the reviewers a lot of comfort being able to rely on that
consensus.
Cullen, what are your suggestion for how to improve the document?
For the user ports the document should have some text along the lines of:
There is not IETF consensus on when it is appropriate to use a second port for
a secure version of protocol therefor the export reviewer should not reject a
request for a second port to run a secure variant of the protocol over.
The reason I think this needs to be in the draft is very simple. In my mind
there are clear and compelling cases for two ports - many of them involving
DTLS and real time protocols that actually care about number of round trips.
Joe Touch has already said he would reject an example use case that I think
should be accepted. I think this is much easier to resolve this issue now than
with an appeal.
The CORE WG, which I co-chair, needs clear advice now on what direction would
be acceptable and is not particular interested in waiting for a year or two for
the drafts to be done, appealed, and then redesigned.
Cheers
Magnus Westerlund
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB | Phone +46 10 7148287
Färögatan 6 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto:
magnus(_dot_)westerlund(_at_)ericsson(_dot_)com
----------------------------------------------------------------------
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf