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.westerlund@xxxxxxxxxxxx > ---------------------------------------------------------------------- _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf