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.
On Jan 31, 2011, at 8:06 , Magnus Westerlund wrote:
Cullen Jennings skrev 2011-01-30 05:56:
I read the draft to say that there would only be one port allocated - I
took strive to mean that Joe would deny my port requests for two ports. If
the intention is actually for the draft to say that it strives for one port
but allows assignment of two where the that is what the protocol design
desire, then I have no problem. Perhaps we just need to clarify what
"strive" means. This definition of "strive" leads into exactly my other
complain that this draft provides no guidance on what the expert will or
will not approve.
We probably need to adjust text like
o IANA strives to encourage the deployment of secure protocols, and
so strives to avoid separate assignments for non-secure variants
and
The use of separate
service name or port number assignments for secure and insecure
variants of the same service is to be avoided in order to discourage
the deployment of insecure services.
and
Services are expected to include support for security, either as
default or dynamically negotiated in-band.
In band negotiation of security is applicable for some cases, but it adds
latency, bandwidth, and complicated multiplexing in non session based
transports. I think this is a bad idea in many cases. I also view
separation even for stream based protocols as something that helps
management and debugging as well as policy.
Well, the high level goal is to preserve a limited resource. We can't do
that without making the preference clear. But I think you have forgotten
to consider those statements trying to make clear that this is up to
review.
The review criterias can be expected to change overtime. They are also
hard to codify. Especially for this case, how do we measure
architectural uncleanness, implementation issues, and performance impact
to make a rule that judges if one or more port is allowed?
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf