Re: [port-srv-reg] Updating the draft with WGLC comments

[Lars Eggert <[e-mail]>]

Status check?

Lars

On 2010-11-24, at 16:59, Magnus Westerlund wrote:

> Joe Touch skrev 2010-11-23 18:07:
>> Just tell me what the preferred phrase is, and I can do a pass.
> 
> Thanks Joe,
> 
> I have proposed that we use Allocation as it appears to be slightly more
> matching from an english language point of view than Assign. However,
> Michelle had a preference for Assign. Frankly I don't think it matters,
> as long as we use only one of the terms.
> 
> When it comes to registration: We could call it "Allocation Request" and
> remove registration completely.
> 
> Cheers
> 
> Magnus
> 
> 
>> 
>> Joe
>> 
>> On 11/23/2010 6:40 AM, Magnus Westerlund wrote:
>>> Hi,
>>> 
>>> I think these changes are fine. That still leaves the changes regarding
>>> the usage of allocation vs assign and register. Is anyone willing to
>>> take this on. I would love, however, my son has been sick (just a cold)
>>> but it has resulted in me missing a number of work hours making it
>>> difficult for me to keep up with things. So I would love if someone was
>>> willing to do this pass.
>>> 
>>> Cheers
>>> 
>>> Magnus
>>> 
>>> Joe Touch skrev 2010-11-22 20:04:
>>>> PS - attached is a diff of the two XML files, which may make the changes
>>>> more clear.
>>>> 
>>>> Joe
>>>> 
>>>> 
>>>> On 11/22/2010 11:01 AM, Joe Touch wrote:
>>>>> See attached as a way to address the concerns.
>>>>> 
>>>>> Basically, I clarified that these are NOT binding (many times), and
>>>>> changed the word to "strives" (i.e., implying a goal), rather than
>>>>> indicating it as a hard rule.
>>>>> 
>>>>> Let me know if it answers the mail, or if I can help adjust further.
>>>>> 
>>>>> Joe
>>>>> 
>>>>> On 11/17/2010 11:46 PM, Magnus Westerlund wrote:
>>>>>> Joe Touch skrev 2010-11-18 01:45:
>>>>>>> Hi, Magnus,
>>>>>>> 
>>>>>>> The feedback from Paul suggests it would be useful to update Sec 7.
>>>>>>> 
>>>>>>> Despite the explicit warning - already in the doc - that these
>>>>>>> principles are NOT binding, it might be useful to discuss the issue of
>>>>>>> whether separate ports should be allocated for requests for new
>>>>>>> protocols.
>>>>>>> 
>>>>>>> I.e., http vs https is currently legacy. We already expect that new
>>>>>>> requests for nonsecure legacy services could result in a new, secure
>>>>>>> port.
>>>>>>> 
>>>>>>> The question is whether a brand new service should be allocated separate
>>>>>>> ports for secure and nonsecure variants.
>>>>>>> 
>>>>>>> The document discusses this point as follows:
>>>>>>> 
>>>>>>> o IANA will allocate only one assigned port number for all versions
>>>>>>> of a service (e.g., running the service with or without a security
>>>>>>> mechanism, or for updated variants of a service)
>>>>>>> 
>>>>>>> ...
>>>>>>> - Further,
>>>>>>> previous separation of protocol variants based on security
>>>>>>> capabilities (e.g., HTTP on TCP port 80 vs. HTTPS on TCP port 443) is
>>>>>>> not recommended for new protocols, because all new protocols should
>>>>>>> be security-capable and capable of negotiating the use of security
>>>>>>> in-band.
>>>>>>> 
>>>>>>> Here's the TLS summary
>>>>>>> for:
>>>>>>> Mike D'Errico
>>>>>>> Nico Williams
>>>>>>> against:
>>>>>>> Paul Hoffman
>>>>>>> Marsh Ray - really just wants default to secure
>>>>>>> Richard Hartman
>>>>>>> 
>>>>>>> Some just wanted security all the time:
>>>>>>> Geoffry Keating
>>>>>>> Mike D'Errico
>>>>>>> 
>>>>>>> I didn't see that they came to consensus on this issue. We can easily
>>>>>>> omit the security text altogether from this text if preferred, and let
>>>>>>> the TLS community make a final BCP recommendation.
>>>>>>> 
>>>>>>> However, despite their status as security experts, I find their logic
>>>>>>> disturbing. Port numbers themselves have no inherent security, so
>>>>>>> ultimately only the application can require a service to be secure
>>>>>>> anyway. Using port number blocking to assume security is laughable at
>>>>>>> best, so I stand by the current text.
>>>>>>> 
>>>>>>> IMO we already have enough wiggle words that this section isn't binding
>>>>>>> anyway. IMO, let the TLS folk create a BCP to the contrary, at which
>>>>>>> point some of us (me at least) will write a doc explaining why port
>>>>>>> numbers aren't security anyway ;-)
>>>>>> 
>>>>>> My view is that there seem to be no real security benefit from running
>>>>>> separate ports generally. One anyway has to live with the downgrade
>>>>>> attacks etc. Thus I think port space preservation is still the main goal.
>>>>>> 
>>>>>>> 
>>>>>>> Thoughts? Leave it? Take it out because a non-consensus subset
>>>>>>> disagrees?
>>>>>>> 
>>>>>> 
>>>>>> I would do some minor tweaks, at least to the following sentence:
>>>>>> 
>>>>>> IANA will allocate only one assigned port number for all versions
>>>>>> of a service (e.g., running the service with or without a security
>>>>>> mechanism, or for updated variants of a service)
>>>>>> 
>>>>>> People interpret the "will allocate only" very strict. I think we can
>>>>>> reword this to be one degree less strict. like:
>>>>>> 
>>>>>> IANA will with extremely few exceptions allocate only one assigned port
>>>>>> number for all versions of a service (e.g., running the service with or
>>>>>> without a security mechanism, or for updated variants of a service)
>>>>>> 
>>>>>> 
>>>>>> Cheers
>>>>>> 
>>>>>> Magnus Westerlund
>>>>>> 
>>>>>> ----------------------------------------------------------------------
>>>>>> Multimedia Technologies, Ericsson Research EAB/TVM
>>>>>> ----------------------------------------------------------------------
>>>>>> Ericsson AB | Phone [phone]
>>>>>> Färögatan 6 | Mobile [phone]
>>>>>> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
>>>>>> ----------------------------------------------------------------------
>>> 
>>> 
>> 
> 
> 
> -- 
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------
> _______________________________________________
> Port-srv-reg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/port-srv-reg