Subject: Re: [apps-discuss] service names - one registry vs. two registries

From: Alfred Hönes <[email-masked]>
Date: Tue, 10 Nov 2009 21:48:01 +0100 (MEZ)

At Mon, 9 Nov 2009 11:21:18 +0900, Lars Eggert wrote:
> ...
>
> draft-gudmundsson-dns-srv-iana-registry advocates a creating new
> standalone registry for service names that are to be used with DNS
> SRV RRs (exclusively, in my reading) and seed it with only those
> 40 service names that are specifically called out in published RFCs.

Incorporation of non-RFC material has been excluded from our draft
on advice from the IESG, in order to avoid IETF procedural and IPR
concerns for a document intended to amend a Standards Track RFC (2782).
It was planned to co-author a second I-D with the maintainers of the
DNS-SD registry for bulk-registration of active entries in that
registry, once the establishment of the registry has been approved.
This way, garbage collection after an uncritical incorporation of
the material would not be necessary, thus presumably saving a lot of
work for many folks, including IANA.  Any entry in the registry is
to point to _current_ service discovery specs, and should hence be
coordinated with the original registrants, if not for other reasons
then for politeness.

Lars,
it sounds strange for you to blame us of following advice from
inside the IESG.

> There is no discussion on how the new registry relates to the
> three(*) existing places where service names have currently been
> registered.

The registry for WKS RR entries is out of scope of our draft and
should better be out of scope for draft-ietf-tsvwg-iana-ports as well,
for various reasons.
It has been hibernating since years and should better not be revived
(or have been revived) at all.
Would DNSOP have been more active in the past and have had no other
tasks to perform, formally closing that registry would perhaps have
been the preferable way to handle that legacy, but nobody made notice
of it.
Re-opening this registry by unification with another, life registry
is IMHO ill-advised.  The recent registration in that registry of
services that will not be assigned a port number from the WKS range,
and where the defining document does not even mention WKS RR usage,
is surprising, at best.

The relationship between the Service Label part of SRV Service
Prefixes and the Service Names in the Port Number registry is
covered exhaustively in our draft, including collision avoiding
procedures for services that once have been assigned a fixed port
number and later are amended with a specification of service
discovery using the DDDS over DNS or 'standalone' SRV RRs.
The converse case is much less likely but is mentioned as well,
and parallel registration of Service Prefix(es) and application
for IANA assignment of a port number is possible anyway.

> ...
> Lars
> ...

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| 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: Wed, 11 Nov 2009 13:02:41 +0900

Hi,

I expect we will continue to be at opposites sides of this debate. But I'd like to correct a few things that I think you're overstating.

...
> it sounds strange for you to blame us of following advice from

There has been no "advice from the IESG". You may have gotten advice from an individual AD, which is not the same. When we speak as "the IESG", we run a consensus call (such as when we approve documents). This hasn't happened here.

> (or have been revived) at all.

I assume you're referring to http://www.iana.org/assignments/service-names here.

We are not attempting to "revive" it. We're referring to it as a source of grandfathered service names, and our ID actually asks IANA to determine if that registry can be retired after that has happened (Section 10).

The reason we do this is that some of these may actually still be in use somewhere, and hence should not be available for new registrations.

Continuing with your second email:

On 2009-11-11, at 5:01, [email-masked] wrote:
> I still have not received any response from the protagonists
> of the 'unified', say, "service identifier" registry indicating
> how their proposal could properly match the needs of DDDS/DNS
> based (or only DNS SRV RR based) service discovery.

Speaking for myself only (and not my co-authors) that is because I don't understand what needs we aren't matching. We're having lunch with Olafur tomorrow, and I hope he will educate me.

> The allusion in draft-ietf-tsvwg-iana-ports of a service
> name alone identifying the service instance is misleading;
> the "Service Prefix" that needs to be registered is composed
> of a _combination_ of Service Label and Protocol Label;
> that's in general by no means orthogonal.

I'm not sure I'd readily agree here. There are several services (DNS itself, for example) that can be talked to over different transport protocols. Other existing TCP-based services are starting to grow support for being talked to over SCTP. In my mind, "service" is a concept that is de-coupled from transport.

> I could not find any hint in draft-ietf-tsvwg-iana-ports-03 of how
> the registration of SRV Service Prefixes in general, and the
> registration of such concrete examples could be pursued in the
> 'unified' registry you would like to establish.

That's because they are specific to the use of service names in DNS SRV RRs, which is *one such use only*. 

> Section 8.1 of draft-ietf-tsvwg-iana-ports still is stuck with
> the restriction of "Service Names" to 15 US-ASCII characters.
> Even RFC 3958 admits 32 characters for the service and protocol
> components of the NAPTR Service Parameter, and
> draft-gudmundsson-dns-srv-iana-registry accommodates the 'natural'
> DNS limit of 63 characters at most (including the added underscore)

Correct. This is again because service names have other uses than for DNS SRV RRs, and some of those uses require a stricter syntax.

> The same section requires "A reference document describing the
> protocol or application using this port, ..."
> This is but one example of text in this draft that does not contain
> proper provisions for registrations of services without assigned
> port usage.

Please realize that you are reading a *draft*. We have tried hard to be precise in when we talk about ports, when we talk about service names, and when we talk about both. You've demonstrated that we haven't managed to be precise yet in all cases, and any such cases will be fixed when found.

> Furthermore, draft-ietf-tsvwg-iana-ports aims at 'integrating'
> the DNS WKS registry, without even contacting working groups
> responsible for the DNS protocol and its operational aspects.
> Due to signicifant security concerns, there have not been any
> registrations for many years there until recently; it is assumed
> that DNS experts would rather prefer to close that registry in
> order to raise a 'stop sign' than re-opening that registry wide
> in absorbing it into the Port Number registry and thereby
> apparently sanctioning the use of any preexisting Service Names
> from the Port Numbers registry for use with WKS resource records.
> If at all used, WKS (standing for "Well Known Services") would
> perhaps need to be restricted to services with assigned Well-Known
> port numbers.

See above. We are *not* integrating the registry or the procedures. We're grandfathering in the few service names registered there, so they remain unavailable for new registrations. (Once that has happened, the WKS registry may be a candidate for retirement.)

> It has been observed with surprise that apparently the IESG has
> caused IANA to perform registrations in the WKS registry for a
> draft that did not even request that; that draft talks about SRV
> usage, not WKS, and hence the matching registrations would have
> been suitable for the DNS SRV Service Prefix registry sought by
> draft-gudmundsson-dns-srv-iana-registry.

I'm guessing that you are referring to draft-ietf-behave-turn. I don't know what information you base your allegation on, but it is incorrect; "the IESG" has not "caused" any registration in the WKS registry in this case.

What happened is this: IANA (ticket #272953) wanted to confirm whether their planned actions upon publication of the draft were correct, like they always do. Their interpretation of the draft text was that a registration in the WKS registry should happen. Magnus and me suggested to *instead* add an alias to the ports registry on the ports registered for STUN (since TURN is a STUN extension). One of the working group chairs disagreed with this and preferred what IANA had suggested (registration in the WKS registry). During the follow-on discussion, we agreed that there was no harm to do both of those actions.

> These and other details seem to confirm suspicion that the hastily
> performed misappropriation of subject matter out-of-scope for TSVWG
> did not even carefully pay attention to the needs of these topics.

I'm not going to respond to this.

Lars

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 11 Nov 2009 14:12:35 +0900

> I'm guessing that you are referring to draft-ietf-behave-turn. I don't know what information you base your allegation on, but it is incorrect; "the IESG" has not "caused" any registration in the WK…

Actually I think this is in regard to the MIPSHOP document that resulted
in the adding of the following entries.

MIHCS               - MIH Command Services
[RFC-ietf-mipshop-mos-dns-discovery-07.txt]
MIHES               - MIH Event Services
[RFC-ietf-mipshop-mos-dns-discovery-07.txt]
MIHIS               - MIH Information Services
[RFC-ietf-mipshop-mos-dns-discovery-07.txt]

This is the result of IESG discussion around this. The document
requested getting service names. If you look at RFC 2782 it points to
RFC 1700 in the following way:

Service
        The symbolic name of the desired service, as defined in Assigned
        Numbers [STD 2] or locally.

The only registry that can be interpreted as being the service name in
RFC 1700 is the registry that currently are in:
http://www.iana.org/assignments/service-names

Due to the very fuzzy reference and lack of clear registration rules has
resulted in the registrations in other registries and the setup of an
non IANA registry.

So I don't think IESG was wrong to make the registration we did.
However, service names clearly needs to be clarified and thus working
towards approval and publication of a RFC that has IETF consensus is
clearly need.

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: Alfred Hönes <[email-masked]>
Date: Wed, 11 Nov 2009 12:19:51 +0100 (MEZ)

Lars,
thanks for your response.
A few clarifications in-line.
I defer to Olafur for more information on specific details and
requirements.

Lars Eggert wrote:

> I expect we will continue to be at opposites sides of this debate.
> But I'd like to correct a few things that I think you're overstating.
>
> There has been no "advice from the IESG". You may have gotten advice
> from an individual AD, which is not the same. When we speak as
> "the IESG", we run a consensus call (such as when we approve
> documents). This hasn't happened here.

Indeed, I did not want to confuse the two different kind of statement,
and actually had intended to type "from within the IESG" in the first
sentenc you quote.  However, this should have been disambiguated by
the second quote, "advice from inside the IESG".

> I assume you're referring to
>  http://www.iana.org/assignments/service-names here.

Right, the one you quote in the tsvwg-iana-ports draft and in your
posting.
These services are represented by the mnemonics in the registry
in the presentation (zone/master file) format of WKS RRs and by a
bit map in the WKS RR binary / on-the-wire format, and in practice,
the translation is built in into DNS server implementations.

>
> We are not attempting to "revive" it.  We're referring to it as a
> source of grandfathered service names, and our ID actually asks IANA
> to determine if that registry can be retired after that has happened
> (Section 10).
>
> The reason we do this is that some of these may actually still be
> in use somewhere, and hence should not be available for new
> registrations.

Acknowledged, if that is the intention; but that was not clear from
the draft currently under WGLC in TSVWG.

> ... [snip] ...
> I'm guessing that you are referring to draft-ietf-behave-turn.
> ...

Magnus already has clarified the context here of MoS (RFC-to-be 5679).

Kind regards,
  Alfred.

--

---

From: Alfred Hönes <[email-masked]>
Date: Wed, 11 Nov 2009 12:36:25 +0100 (MEZ)

Magnus,
thanks for your clarifications and contributions.

>> I don't know what information you base your allegation on, but
>> it is incorrect; "the IESG" has not "caused" any registration
>> in the WKS registry in this case.
>

Thanks for this clarification. I did not want to go too deep into
the details for not blaming anybody publicly wrt RFC-to-be 5679.

> requested getting service names. If you look at RFC 2782 ...

We once had agreed with the authors of that document that the
SRV Service Prefix registry would be the proper target for the
registration, and had promised to include them in the initial
contents of that registry if that draft would be published
earlier than ours -- which now will happen.  The entries for the
above services already linger in our draft's XML, but are still
commented out, because the agreement was to refer to RFCs and only
a few already widespread services in the initial registry content.
Therefore, the registration in the WKS registry came to our surprise.

> ... it points to RFC 1700 in the following way:
>
> Service

That reasoning has been 100% correct at the time of publication
of RFC 1700, because it predates NAPTR and SRV by years.

> resulted in the registrations in other registries and the setup of an

That's been part of the motivation for Olafur to write up the
srv-iana-registry draft last year.

> towards approval and publication of a RFC that has IETF consensus is

It is not expected that DNS server software will adopt these
registrations because it would blow up the bit map in WKS to
unreasonable size, that was intended for "Well-Known" services
(ports 0..255 at the time of RFC 1035).  Therefore I question
the utility of performing this registration.

> Fdrvgatan 6                | Mobile +46 73 0949079

Kind regards,
  Alfred Hönes.

--

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 12 Nov 2009 10:30:48 +0900

Alfred,

> the second quote, "advice from inside the IESG".

I think it would been clearer if you simple pointed at the source of the
input, i.e. the AD.

> the translation is built in into DNS server implementations.

I would classify this as unintentional effects. However, if that is how
DNS SRVs was setup in this way, I don't know what to do about that
side-effect.

>From my perspective I tried to avoid blocking the document from being
published due to that the service name registry fix wasn't ready. Also I
had come to realization that we do need to pull in the names in Protocol
and Service registry. However, at the time of performing this action our
draft did not yet reflect that.

> the draft currently under WGLC in TSVWG.

We are not yet in WG last call. We know that we need another round of
changes to clarify additional things. Then I hope we will be ready for
WG last call.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 12 Nov 2009 10:59:49 +0900

Alfred,

See inline.

> Therefore, the registration in the WKS registry came to our surprise.

I think there has been communication issues here. If anyone of the
authors or doc shepherd had raised this when we proposed the fix to the
 error in the IANA section. We didn't allow the document to be published
without a registration that actually would ensure that the three service
names needed ended up in a registry. If the authors had made a normative
reference to your registry document, we would have been aware of that.
Which would have raised the overlap with our WG document. It would also
have signaled the authors and WGs willingness to have the document hang
until the registration would have finished.

> of RFC 1700, because it predates NAPTR and SRV by years.

Well, I don't know how much we need to continue this discussion. We can
only state that it is unfortunate that the SRV RFCs wasn't very clear on
what the registry was to be used.

So lets make progress on getting a new well defined service name in
place and take care of the issues that we know about that. We definitely
appreciate input and suggestions for improvements.

> srv-iana-registry draft last year.

Yes, and the author team had service name discussions in Irland, with
Stuart Cheshire. Unfortunately we clearly failed to make the larger
community aware of our efforts.

> the utility of performing this registration.

Ok, I will talk to Olafur about these issues.

Cheers

Magnus Westerlund

---

From: Alfred Hönes <[email-masked]>
Date: Thu, 12 Nov 2009 04:26:55 +0100 (MEZ)

At Thu, 12 Nov 2009 10:30:48 +0900,  Magnus Westerlund wrote:
> Alfred  skrev:
>> sentence you quote.  However, this should have been disambiguated by

I didn't talk to any AD personally in the early stages;
when I joined Olafur's caravana before IETF 73, there was no
contention, and when Olafur eventually was able to resume work
on the draft, the responsibility in the IESG had changed.
So I was not aware of the details, and saying "some AD" instead
seemed a bit too stupid.

> I would classify this as unintentional effects. However, if that is
> how DNS SRVs was setup in this way, I don't know what to do about
> that side-effect.

Oh, please do not confuse the leagacy WKS RR with SRV, invented
roughly a decade later!  Both are as different as could be.

SRV carries the Service to look for in the owner name, i.e. its
location in the DNS database tree, and it returns the FQDN of the
host offering that service for the whole domain (identified in the SRV
owner name as well, after the Service Prefix), whereas WKS simply
returns the bit map of Well-Known Services offered at a given host
(its owner name) -- these were indeed the services in the 0..255 port
number range dedicated to Well-Known Services in the age of
RFC 1035 and 1122.

> draft did not yet reflect that.

I recognize the good will behind the action, but ...

Since the IEEE MoS services do not have a fixed port number
assigned by IANA (RFC-to-be 5679 didn't ask for), entering MIHIS,
MIHES, and MIHCS into the registry for WKS does not make sense.

The heading of   http://www.IANA.ORG/assignments/service-names
is rather explicit:

 "Note:
  These are the Official Protocol Names as they appear in the Domain
  Name System WKS records and the NIC Host Table.  Their use is
  described in [RFC952]."

WKS had been created in the effort to migrate the data from the
ARPANET "NIC Host Table" into the DNS and thereby separating address
info from Well-Known Service info.
(BSD created the /etc/hosts file that did not contain the list of
WKSes for all listed hosts any more, and /etc/services listing the
service_name-to-port mappings for locally "interesting" services --
no more per-known-host offered WKS lists; that information was fed
into the DNS via the WKS RR.)

It looks like you also got caught in one of the temptive traps
awaiting visitors of the IANA site, with so many registries having
titles making it hard to guess correctly at first glance what they
are good for.
:-)

The SRV Service Prefix now seems to find creative use, adding
more labels to the left, e.g. in a recent I-D (already challenged)

       _nfsv4._domainroot._tcp.bigbank.example.
and:   _nfsv4._write._domainroot._tcp.bigbank.example.

>>> in use somewhere, and hence should not be available for new

Exactly, a domain server conforming to RFC 1035 needs to be able to
read zone (master) files containing WKS records in the presentation
form and to translate the keywords (commonly uppercase-only) into
bit positions. Whenever a secondary authoritative server transfers
a zone copy from a prmary server, it needs to translate from
on-the-wire format to presentation format to store the zone content
into a local file that can be used to reload the zone after a server
restert.
Given the infrastructure nature of the DNS and the underspecified
syntax of the IANA registry file making it rather unsuitable for
automated lookup, online lookup of the registry whenever a DNS
server starts up or updates a zone file does not make sense.
That's why in many DNS server implementations the WKS table is
hardcoded or loaded from a file shipped by the vendor and rarely
updated in deployments.

> changes to clarify additional things. Then I hope we will be ready for

Oh sorry, you are right. I must have confused some of the WGLCs called
out recently.

Kind regards,
  Alfred Hönes.

--

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 12 Nov 2009 13:26:25 +0900

Alfred,

> So I was not aware of the details, and saying "some AD" instead

Well, it would have been more correct as saying IESG implies some
consensus from us as a group.

> number range dedicated to Well-Known Services in the age of

Yes, I have been educated by Olafur.

> titles making it hard to guess correctly at first glance what they

Well, I am not the only one that has made this interpretation of the RFC
2782 to point at the Protocol and Services list.

However, but this will be clarified when we can make progress on the
document. Creating the service registry and then have your and Olafurs
document update RFC 2782 will solve things.

> and:   _nfsv4._write._domainroot._tcp.bigbank.example.

Ok

> hardcoded or loaded from a file shipped by the vendor and rarely

Olafur explained that it has been recommended against using WKS for over
20 years. We should grandfather that registry as soon as have created
the service registry.

Cheers

Magnus Westerlund

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 12 Nov 2009 14:14:00 +0900

> I think it would been clearer if you simple pointed at the source of the
I believe I gave the advice and I was talking as myself only (but maybe 
it wasn't entirely clear).

---

From: Eliot Lear <[email-masked]>
Date: Thu, 12 Nov 2009 12:15:11 +0100

Before we get hung up so high in WKS, I have an alternate suggestion.  
Simply deprecate the registry.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 19 Nov 2009 17:16:48 +0100

> Simply deprecate the registry.

I don't have any opinion on such an action. But from what Olafur
explained it seems an appropriate action for someone to do that.

Want to make it clear that we intended to populate the service registry
with all the names from the Protocol and Services registry used by WKS
to avoid issues with applications/protocols that has been registered and
think they have name they can use in for example DNS SRVs.

Cheers

Magnus Westerlund

---

From: Eliot Lear <[email-masked]>
Date: Thu, 19 Nov 2009 17:22:02 +0100

Magnus,

What you write below below makes sense to me.

Eliot