So first, we already have a BCP that says more or less all protocols must
implement a secure version but deployment is optional. This is a good BCP, and
it comes from the right area to say that - security. It's probably impacts
design work in working groups more than any other BCP. It has IETF consensus.
The IESG holds protocols to this.
Now - I am at loss to see why forcing people to use one port will make it more
likely to have secure protocols. This seems crazy. Please do enlighten me.
And on the topic, I'm still looking forward to an explanation of how the
current CoAP design stomping all over the TLS code points would be an
On Jan 31, 2011, at 9:27 , Eliot Lear wrote:
On 1/31/11 5:13 PM, Cullen Jennings wrote:
Hmm ... I don't agree that solves the issue.
Well lets say the request was coming from 3GPP for a protocol they designed
- why should IANA be able to tell them no but IETF yes.
Who, ultimately, is the steward of this precious resource? If it is not
the IANA and it is not the IETF, then who? To say that it is everyone's
responsibility is to avoid responsibility entirely. Who gets to say
which standards organizations are stewards and which are not?
I think the policy issue here is fairly clear. We do not have consensus that
in all cases that one should not have a second port for security (I'm basing
this assertion on Magnus read of WG consensus and my read of IETF LC
consensus). Therefore that should not be a ground for the expert reviewer
(or IANA) to reject the registration. The document needs to be updated to
make that clear or it does not reflect consensus. If the authors of the
draft want to propose text for conditions when it would be ok to reject a
second port for security purposes and see if they can get consensus for that
text, that seems perfectly reasonable.
This is a VERY VERY dangerous approach you propose, Cullen. It is akin
to saying, "you can think about security later, because we'll have to
give you a port for it later." We don't want to be saying that.
For corporate legal information go to:
Ietf mailing list