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

[Joe Touch <[e-mail]>]

See attached. This is the last fix of known issues.

I've included the .xml and a diff showing changes since my last proposed 
update. I.e., this one should be JUST the 
allocation/assignment/regsitration issue (with maybe 1-2 other typos fixed).

Joe

On 11/30/2010 9:04 AM, Joe Touch wrote:
> Hi, Magnus,
>
> I looked at the IANA site a bit further. It seems that:
>
> Allocation is the term used when a block of some resource is handed to
> an entity for further, fine-grained assignment (e.g., IP addresses).
>
> Assignment is the term used when an individual resource is registered
> for an entity's exclusive use.
>
> A Registry is the term for the table where assignments are indicated.
>
> Registration applications would then be "Assignment Applications" or
> "Assignment Requests".
>
> I propose using these terms to be consistent (and explaining them).
>
> If anyone objects, please let me know ASAP....
>
> Joe
>
> On 11/24/2010 6:59 AM, 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]
>>>>>>> ----------------------------------------------------------------------
>>>>>>>
>>>>
>>>>
>>>
>>
>>