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

From: Magnus Westerlund <[email-masked]>
Date: Wed, 17 Nov 2010 11:25:18 +0100

Hi,

I am now back in the office after a few extra days in Beijing. I think
we should get going on preparing the update of the document so it is
ready after the WG last call ends. I did talk to Alexey about this
document. He does want rapid progression so that he can take care of it
before his current IESG term is up.

We have two comments requiring changes. The first one about fixing
inconsistencies in language. I have proposed Allocate, Michelle wasn't
that happy over it. More views on allocate vs. assign is appreciated.
But please provide them now rather than later.

The second changes are getting Paul hoffman's suggest two changes into
the document with potential some tweaking of the language.

Can anyone get started on these changes?

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Joe Touch <[email-masked]>
Date: Wed, 17 Nov 2010 16:45:08 -0800

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 ;-)

Thoughts? Leave it? Take it out because a non-consensus subset disagrees?

Joe

On 11/17/2010 2:25 AM, Magnus Westerlund wrote:
> _______________________________________________
> Port-srv-reg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/port-srv-reg

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 18 Nov 2010 08:46:41 +0100

> 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

---

From: Joe Touch <[email-masked]>
Date: Thu, 18 Nov 2010 11:44:32 -0800

Hi, Magnus,

Sure - maybe just changing the words throughout that section to imply 
less of a requirement than a recommendation would be sufficient.

I can take a stab at that if someone can email the source (sorry - I 
have problems getting at SVN from Windows)

Joe

---

From: Lars Eggert <[email-masked]>
Date: Fri, 19 Nov 2010 09:59:19 +0200

On 2010-11-18, at 21:44, Joe Touch wrote:
> I can take a stab at that if someone can email the source (sorry - I have problems getting at SVN from Windows)

You can download from the svn repository over HTTP: https://svn.tools.ietf.org/svn/area/tsv/draft-cotton-tsvwg-iana-ports

Lars

---

From: Joe Touch <[email-masked]>
Date: Mon, 22 Nov 2010 11:04:12 -0800

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
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 22 Nov 2010 11:01:34 -0800

Joe

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 23 Nov 2010 15:40:33 +0100

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

-- 

Magnus Westerlund

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 Nov 2010 09:07:17 -0800

Just tell me what the preferred phrase is, and I can do a pass.

Joe

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 24 Nov 2010 15:59:00 +0100

> 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

-- 

Magnus Westerlund

---

From: Lars Eggert <[email-masked]>
Date: Tue, 30 Nov 2010 16:47:26 +0200

Status check?

Lars

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 Nov 2010 06:53:50 -0800

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

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 Nov 2010 09:04:54 -0800

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

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 Nov 2010 13:20:12 -0800

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:
>>>>>>>> requests for nonsecure legacy services could result in a new,
>>>>>>>> secure
>>>>>>>> port.
>>>>>>>>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 1 Dec 2010 08:21:27 +0100

> If anyone objects, please let me know ASAP....

No, that is fine with me. I had no strong preference between the two words.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 1 Dec 2010 08:26:33 +0100

> allocation/assignment/regsitration issue (with maybe 1-2 other typos fixed).

I have commited this and the previous version to the SVN. I will now do
a review of the changes.

Cheers

Magnus Westerlund