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

[Magnus Westerlund <[e-mail]>]

Alfred,

Alfred � skrev:
> At Thu, 12 Nov 2009 10:30:48 +0900,  Magnus Westerlund wrote:
>> Alfred,
>>
>>
>> Alfred  skrev:
>>>> 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
>>> sentence you quote.  However, this should have been disambiguated by
>>> 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.
> 
> 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.
> 

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

> 
>>>>> 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.
>>>> 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.
>> 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.

Yes, I have been educated by Olafur.

> 
>> >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.
> 
> 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.
> :-)
> 

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.

> 
> 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.
> 

Ok

> 
>>>> 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.
> 
> 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.
> 

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

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------