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: ah@xxxxxxxxx | +------------------------+--------------------------------------------+ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf