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

[Joe Touch <[e-mail]>]

I was waiting for Michelle to confirm the language below; I wanted to 
give her a few days. Since I haven't heard back, I'll proceed as Magnus 
suggests below and have a mod ready shortly...

Joe

On 11/30/2010 6:47 AM, Lars Eggert wrote:
> 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
>