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

[Magnus Westerlund <[e-mail]>]

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]
----------------------------------------------------------------------