Subject: Re: Last Call: draft-allbery-afs-srv-records

From: Alfred Hönes <[email-masked]>
Date: Fri, 8 Jan 2010 20:02:14 +0100 (MEZ)

Cyrus Daboo wrote:

> Hi,
>
> --On January 8, 2010 7:28:51 AM -0800 The IESG wrote:
>
>     The IESG has received a request from an individual submitter to
>     consider the following document:
>
>     - 'DNS SRV Resource Records for AFS '
>        <draft-allbery-afs-srv-records-03.txt> as a Proposed Standard
>
> This spec needs to wait on the IANA SRV registry document
> (draft-ietf-tsvwg-iana-ports) that is being revised and also
> blocking a couple of SRV-related drafts I have been working on too.
> Once that is done it should register its new services using the
> new procedure.
>
> --
> Cyrus Daboo

I do not think so.

Rationale:

This draft aligns perfectly with the present RFCs, and it has been
pro-actively aligned with draft-gudmundsson-dnsext-srv-clarify-00
(disclaimer: of which I am a co-author) and the last working copy
of draft-ietf-tsvwg-iana-ports circulated early in December
(unfortunately an updated official version is still not out yet).

draft-ietf-tsvwg-iana-ports aims at feeding into the new unified
"Service Names and Port Numbers" IANA registry all existing, well
documented use cases, including a big bunch of non-IETF service
names held so far in a private registry.
A new RFC or I-D accepted for publication wouldn't matter much
in the multi-thousands of entries to be populated in the new
registry, and the services for which this draft now specifies DNS
SRV record based service discovery have been registered in the
present "Port Numbers" registry since almost two decades.

Past experience seems to indicate that processes in TSVWG aren't
very fast; I would be positively surprised if tsvwg-iana-ports
would make it faster than the average 4 years or so in TSVWG.

It therefore seems not reasonable to penalize other useful work
that is carefully crafted to align with present and -- as far as
can be expected -- ongoing work on a revised IANA registry, and
stall that work indefinitely.

Last year, three documents have passed the IESG performing
unreasonable assignments, or even have been directed to do so,
in the RFC 952 (ARPANET Hosts File and DNS WKS record) IANA
registry (as discussed on apps-discuss and tsvwg).

We now need to do extra work to back out these inappropriate
additions before freezing that WKS registry (one of the tasks to be
fulfilled by the "Service registries cleanup" draft Olafur and I am
working on, as agreed upon at IETF in Hiroshima.

In contrast, there is no 'damage' done by a document like the
AFS SRV Usage draft under IETF LC, since the services for which this
draft now specifies DNS SRV based service discovery have been IANA-
registered (and assigned default port numbers) many many years ago.
The draft does not change these registrations in any way, and the
entries will be carried over by IANA to the new registry per the
planned procedures for the implementation of tsvwg-iana-ports.

Further, AFAICS, our proposals to add specific fields related to
the support of service discovery to the new registry have not been
accepted; we have not even be confirmed that it indeed will be
possible to file, as specifically tagged references in that new
registry, documents detailing service discovery procedures for
existing application protocols that do not change these
applications/services.
Thus, according to the current state-of-work-in-progress, the draft
under IETF LC at most could perform a contact information update,
if it were approved after tsvwg-iana-ports.

Therefore, I support publishing this document, essentially "as is",
and without delays.  IMO, we should not hold off such work that could
well live without the new "Service Names and Port Numbers" registry.

The issues I had found in that memo in the past all have been
resolved in the most recent draft iterations.

Because of the impending delays with tsvwg-iana-ports, IANA
considerations have been cut off the current draft intentionally.
A dummy IANA Cons. section might perhaps be supplied for conformance
to the formal rules.

I'm sure the authors are willing to provide the proper registration
if and when that new registry will be finalized, should that still
be deemed necessary after the data harvesting by IANA for the initial
population of that registry.
Please note well that there are many (hundreds, if not thousands) of
much more obscure entries to be imported into the new registry that
will cause much more work for IANA than the four entries affected by
this draft.

Procedural note:
  There als are precedents for RFCs published with new registrations
  during pending fundamental revision of a registry.
  For instance, RFC 5333 has been published recently (and known
  deficiencies in it have been accepted) although the Enumservices
  registry is currently undergoing major changes, simply because the
  implementation plan of the new registry foresees migration of all
  existing registrations to the new format and the registered objects
  were deemed necessary and useful.

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: Russ Allbery <[email-masked]>
Date: Fri, 08 Jan 2010 13:57:05 -0800

> population of that registry.

I'm happy to revise this document for any SRV record changes in the future
and produce new RFCs as needed to align with new procedures.
Unsurprisingly, I selfishly would prefer not to wait on significant
re-engineering of SRV record management if it's going to take some time.
As Alfred says, I don't think this document adds new problems that would
have to be taken into account by such work.  It tries to align as closely
as possible with how SRV records are used for other existing services.

I suspect I'd argue that Cyrus's work also shouldn't be blocked.  :)

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>