Subject: Re: [tsvwg] port registration (was: Re: [VCARDDAV] Lars DISCUSS on draft-ietf-vcarddav-carddav)

From: Alfred Hönes <[email-masked]>
Date: Sun, 25 Oct 2009 22:43:42 +0100 (MEZ)

At Fri, 23 Oct 2009 10:31:45 +0300, Lars Eggert wrote:

> On 2009-10-23, at 1:26, SM wrote:
>
>     draft-ietf-tsvwg-iana-ports and
>     draft-gudmundsson-dns-srv-iana-registry are set on a collision course.
>
> True. I note that the first is an adopted IETF work item in TSVWG
> and the other one isn't.
>
> (Disclaimer: I'm an author of the first one.)
>
> Lars

The TSVWG Charter mentions this subject only in a milestone:

|  December 2009   Request publication of 'IANA Procedures for the
|                  Transport Protocol Port Number Space' as BCP RFC

This corresponds to the scope of the individual draft that had been
adopted by the group and that has been maintained in the wg -00 and
-01 revisions of the draft.  It was the recent -02 draft version
that grossly extended the scope after the authors had been asked
to delineate and coordinate with the DNS SRV IANA registry draft.

The "Transport Protocol Port Number Space" quoted above is different
from the "DNS SRV Service Prefix" name space, and as far as I can see,
guidelines for service discovery and the application and use of the
Nomain Name System (DNS) do not fall under the chartered scope of
TSVWG (see: http://www.ietf.org/dyn/wg/charter/tsvwg-charter.html)
nor the Transport Area in general.

I therefore suggest that the scope of draft-ietf-tsvwg-iana-ports
indeed be restricted to what it has been previously, in accordance
with the milestone in the TSVWG charter..

(Disclaimer: I'm co-author of draft-gudmundsson-dns-srv-iana-registry)

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: Lars Eggert <[email-masked]>
Date: Mon, 26 Oct 2009 09:44:30 +0200

Hi,

> |                  Transport Protocol Port Number Space' as BCP RFC

What do you mean "only?" It's not like there are several classes of WG  
work items.

> -01 revisions of the draft.

Of course we're going to ask the WG if there is consensus for the  
changes that were made since the last meeting in -02 (and -03, which  
should be available soon.)

>  It was the recent -02 draft version

This sounds like you're saying that we purposefully made huge changes  
to the document in order to create a conflict with draft-gudmundsson.  
That is not the case. It was the intent that this work item would also  
define rules for service names, and this was clearly communicated the  
entire time, see for example "Open Issues" on https://www.ietf.org/proceedings/72/slides/tsvwg-3/tsvwg-3.htm 
.

I'm not going to argue that it has taken us longer than expected to  
write this stuff up, however.

> nor the Transport Area in general.

We are in disagreement whether there actually is a separate "DNS SRV  
Service Prefix" namespace.

There certainly are service names, most of which are recorded in the  
"short name" column of the ports registry, some of which are recorded  
in the "protocol and service names" registry, and some of which are  
listed in a private registry maintained by Stuart. Our intent is to  
merge these registries into one, and the (to us) logical place is the  
ports registry, because it already has the vast majority of such  
entries in it; and we need to create rules that define how ports and  
service names interrelate, esp. if a set of management actions happens  
over time to the entries associated with one service. (First you  
register just a service name, then later you register a port for one  
protocol, etc.)

Now, service names are certainly used for DNS SRV RRs, but that is  
*not their only use*. This is why I think that creating a new registry  
and set of registration procedures just for DNS SRV RRs isn't going to  
solve the problem.

Lars

>  Alfred HÎnes.
> +------------------------ 
> +--------------------------------------------+
> +------------------------ 
> +--------------------------------------------+
>