Subject: Re: [yam] draft-daboo-srv-email: POP3S/IMAPS?

From: Alfred Hönes <[email-masked]>
Date: Tue, 19 Jan 2010 21:42:11 +0100 (MEZ)

Please note that the Transport Area is in the process to update
the Port Numbers IANA registry -- see:
  <http://tools.ietf.org/html/draft-ietf-tsvwg-iana-ports-04>

In pursuit of long-standing IESG recommendations, the new unified
Service Names and Port Numbers registry will no longer allow
multiple port numbers to be registered for a single conceptual
service (and different service names for variants of a service),
and it intends to start applying the new policy on legacy registry
content during the planned (annual?) "garbage collection" phases
that IANA will conduct in the future.
So unless a specific use case can be shown to be supported by a very
strong momentum, the registry garbage collection phases will perhaps
some day start challenging the service name registrations and default
port assignments for 'imaps' and similar "services over TLS" that do
not use in-band security negotiation on the same port number as the
basic service and hence do not conform to the new registry rules for
service names and default port number assignment.

That draft says in the description of the new rules (Section 7.2):

   The process and protocol identifier use suggests that anything a
   single process can demultiplex, or that can be encoded into a single
   protocol, should be.  The firewall filtering use suggests that some
   uses that could be multiplexed or encoded must be separated to allow
|  for firewall management.  Note that this latter use is much less
|  sound, because port numbers have meaning only for the two endpoints
|  involved in a connection, and drawing conclusions about the service
|  that generated a given flow based on observed port numbers is not
|  always reliable.  Further, previous separation of protocol variants
|  based on security capabilities (e.g., HTTP on port 80 vs. HTTPS on
|  port 443) is not recommended for new protocols, because all should be
|  security-capable and capable of negotiating the use of security in-
|  band.

Please read draft-ietf-tsvwg-iana-ports-04 and comment on the
TSVWG list, if you want.  Releated discussion also happend on the
apps-discuss at ietf dot org mailing list.

Conclusion:

It might be worth adding a strong note to your draft that again
discourages further use of email-related "<someservice->s" service
names and related default port numbers.

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 19 Jan 2010 23:02:25 +0000

>service names and default port number assignment.
Alfred,
While I agree that imaps/pops wouldn't have been registered according to 
new rules, they represent widely deployed variants of IMAP/POP3, so I 
don't think IANA can just remove them from the registry.

---

From: Ned Freed <[email-masked]>
Date: Tue, 19 Jan 2010 14:47:14 -0800 (PST)

> service names and default port number assignment.

Sigh. We've attemped this sort of purity policing many times in the past. The
results can be summarized quite simply:

    IT DOES NOT WORK

I just don't understand why IETFers have such a grossly inflated belief in the
power of registries to influence developer behavior. In reality it's
astonishlngly difficult to get people to register stuff and/or to use
registered stuff even when the advantages of doing so are extremely clear and
obvious.

And that's when there are clear advantages to registration. When the registry
attempts to police out what they view as bad behavior, what invariably happens
is people simply ignore the rules and do whatever they feel they nave to do.

It is only through literally years of hard work that we've managed to mostly
overcome the effects of our deeply misguided attempt at purity policing when
the media types registry was first set up.

And while the situation with the charsets registry is a little more complex, a
nonnegligable part of its failure to *ever* recover relates to ongoing purity
policing efforts.

>    protocol, should be.

The ignorance in that statement is simply astonishing. Heck, this could be seen
sas saying that we should be ddoing everything with HTTP on port 80.

>    The firewall filtering use suggests that some

> apps-discuss at ietf dot org mailing list.

I'm sorry to have to say it, but if this represents where they are in terms of
their thinking they are so far off in the weeds there's no point in bothering.

> names and related default port numbers.

While I agree with the sentiment, I'll repeat for at least the third time that
this draft isn't the place to make the point. We're dealing (or at least
attempting to deal) with service discovery for a very limited set of existing
protocols. Even if someone was planning to define managesieves:, the chances of
them looming to this document for advice are for all intents and purposes zero.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Tue, 19 Jan 2010 15:50:10 -0800 (PST)

> don't think IANA can just remove them from the registry.

And more to the point, removing them from the registry won't have the slightest
effect on the huge number of deployments using them. Or the vast installed base
of clients that support them, sometimes to the exlcusion of other, better
schemes.

All it would accomplish is to damage the credibility and eventually the overall
value of the registry.

				Ned

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 20 Jan 2010 09:54:48 +0100

> results can be summarized quite simply:

IMO it works acceptably for new usage. It fails grandly when it tries to 
squeeze toothpaste back into the tube, but that's different.

Port 993 was a mistake IMO, but it's best to acknowledge our past 
mistakes, not sweep them under the carpet. Port 993 still exists, 
remains in use, and the name imaps refers to it. I don't like that, but 
I also don't think an IANA registry can list either 993 or imaps as 
being free for other use.

>> apps-discuss at ietf dot org mailing list.

My suggestion would be to add a section to that draft grandfathering 
ports 465, 993, 2000 and a few more (adding as much negative verbiage as 
seems wise; I don't think the exact amount makes any difference at all). 
IIRC port 2000 can be grandfathered a half-dozen times.

I didn't see a comment address in the draft, so I cc this message to the 
authors.

Arnt

---

From: Lars Eggert <[email-masked]>
Date: Wed, 20 Jan 2010 10:54:06 +0200

Hi,

I'm not on the yam list and this is the first message in this thread that I was CC'ed on. It seems like you are suggesting changes to draft-ietf-tsvwg-iana-ports, but due to the lack of context I'm at a loss as to what they are...

Lars

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 20 Jan 2010 10:28:43 +0100

Lars Eggert writes:
> I'm not on the yam list and this is the first message in this thread 
> that I was CC'ed on. It seems like you are suggesting changes to 
> draft-ietf-tsvwg-iana-ports, but due to the lack of context I'm at a 
> loss as to what they are...

Tthe thead in a nutshell: The iana-ports document says "one port for 
each purpose" etc. IMAP, POP3 and perhaps SMTP, however, exist in two. 
993 ("imaps") and 143 ("imap") for IMAP. Everyone on the list dislikes 
port 993. The question is whether port 993 should survive in the IANA 
registry.

My suggestion for the iana-ports document is to permit more than one 
port in those cases where that's currently deployed, and apply the 
one-port-per-purpose rule only to new allocations.

My rationale for that is that the extra ports/service names aren't 
really free. You can't use port 993 or service name imaps for anything 
else, and IMO that's reason enough to keep it in the registry.

The same argument applies to pop3s/995, and perhaps to smtps/465 (smtps 
is falling out of use).

Arnt

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Jan 2010 10:36:51 +0100

> The same argument applies to pop3s/995, and perhaps to smtps/465 (smtps

Our intention was never to force the already registered entries to
follow the new registration procedures. The document describes the
procedures that will be in place from the moment they are approved by
the IESG. Legacy is legacy, and I do agree that even if port 993 is
returned it will still be reserved for a long time.

Don't use the draft-ietf-tsvwg-iana-ports as an argument either way if
YAM should retire the the "secure" ports and instead focus on using a
START_TLS procedure. That has to be discussed in the context of the
existing protocol and its benefits and disadvantages.

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
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: Lars Eggert <[email-masked]>
Date: Wed, 20 Jan 2010 11:36:58 +0200

Hi,

thanks for the summary.

On 2010-1-20, at 11:28, Arnt Gulbrandsen wrote:

> each purpose" etc.

yes - as a guideline for *new* assignments. No existing assignment is modified by this document. (Maybe we need to explicitly say this if we aren't already.)

> IMAP, POP3 and perhaps SMTP, however, exist in two. 

It should and it will.

> one-port-per-purpose rule only to new allocations.

Exactly. The intent is not to revisit past assignments and check whether they comply with the new rules.

> else, and IMO that's reason enough to keep it in the registry.

Exactly.

Lars

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 20 Jan 2010 10:42:50 +0100

Magnus Westerlund writes:
> follow the new registration procedures.

Great. We agree completely then.

Arnt

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Wed, 20 Jan 2010 12:59:31 +0000

>> else, and IMO that's reason enough to keep it in the registry.

Deployment consideration is AFAIK the one and only reason to specify this usage.  I'm not asking for a definitive answer, but does the revocation procedure not give us a reason to discourage its usage altogether using at least some warning language?  It might be a flight of fancy, but if in a decade's time the world has migrated to IPSec, for instance, we'll be left with lots of obsolete port assignments and no documentation for them, which IMO is not so good.  Would like to think that, although we must not break existing deployments, we should try to observe current and future reservation guidelines.

Cheers,
Sabahattin

---

From: Joe Touch <[email-masked]>
Date: Wed, 20 Jan 2010 06:20:01 -0800

Sabahattin Gucukoglu wrote:
...
> Deployment consideration is AFAIK the one and only reason to specify
> this usage.  I'm not asking for a definitive answer, but does the
> revocation procedure not give us a reason to discourage its usage
> altogether using at least some warning language?  It might be a
> flight of fancy, but if in a decade's time the world has migrated to
> IPSec, for instance, we'll be left with lots of obsolete port
> assignments and no documentation for them, which IMO is not so good.
> Would like to think that, although we must not break existing
> deployments, we should try to observe current and future reservation
> guidelines.

The new ports doc provides a revocation procedure that could be used if
needed here, but the ports doc isn't the place where any such individual
decision would be made. That would happen after the ports doc were approved.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 20 Jan 2010 07:12:08 -0800

Lars Eggert wrote:
...
>> IIRC port 2000 can be grandfathered a half-dozen times.

There are two separate issues:

- - previous assignments that don't follow the proposed recommendations
	- as noted, there's no goal to fix that

- - 'squatting', or use of ports without registering through IANA
	- IMO, these should not be ignored, but clearly cannot be
	treated as equivalent to 'self assigned'

	i.e., IMO, IANA should list these as "unauthorized use",
	as a service to the community to help those using those
	ports as assigned.

I would expect the draft might address both issues.

Joe

---

From: Lars Eggert <[email-masked]>
Date: Wed, 20 Jan 2010 17:16:24 +0200

>>> IIRC port 2000 can be grandfathered a half-dozen times.

Just to be clear - it wasn't me who wrote what you're quoting...

Lars

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> 
> iEYEARECAAYFAktXHUgACgkQE5f5cImnZrur0wCgrEKpARNefyRROwqpZSLeS39H
> JlYAoPcevBtqqK0fW4kmR41xVKPqATm8
> =VHin
> -----END PGP SIGNATURE-----