Re: [port-srv-reg] "assigned" ( vs. "registered"), and related issues

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Alfred � wrote:
...
>>> There's a third variant, and it isn't covered above:
>>>
>>>   requester usually proposes a code point, and IANA
>>>   can either approve it or propose a different one.
>>>   IANA usually confirms the requester's acceptance
>>>   of the code point offered.
>> Maybe I'm dense, but I don't understand how that is a third option.
>> Either IANA views "registered" and "assigned" as synonyms or they
>> don't :-)
> 
> OOOPS!
> 
> Back to square one!
> 
> No!   To 'register' is not a synonym for 'assign'.

The "third option" is whether IANA suggests the alternate or the
requester does.

...
> When it comes to what IANA is being requested to do, it's always been,
> and still is, a huge difference between "assign" and "register" !
> 
> 
> To "register" means to archive and give a signature on the act,
> not to operate in any way on the content.

IANA ends up registering what the requester agrees to. Sometimes IANA
suggests a number, sometimes they don't. It's never binding anyway, so
it's never an "assignment", regardless. It's always a "registration".

However, IANA does sometimes suggest. I wasn't sure whether that was
worth mentioning, but it does happen, and doesn't seem inappropriate.

...
>>>>> (3)
>>>>> Furthermore, to make sensible use of Service Names w/o assigned
>>>>> port number, the Transport Protocol(s) field should not be made
>>>>> optional (as in the predraft I got), but mandatory; otherwise
>>>>> the clarified rules for SRV owner naming would lack a fundament.
>>>> Why? A service name is a name for a service, and not for a
>>>> service/transport combination.
>>> IMO, this basically treats SRV names as old port numbers were treated -
>>> i.e., ask for a name, get ALL transports. That's how port number
>>> assignments were done until recently, where now only the needed
>>> transport is assigned.
> 
> Why making that silly distinction?

It's an issue as to whether you would register an SRV name:

	JOE-NAME

or
	JOE-NAME	TCP
	JOE-NAME	UDP

I have no idea why you would want to do the latter, except to know that
if you got "_JOE-NAME._DCCP" in an SRV it must be an error.

...
> No.  I strongly oppose.
> 
> You have made good progress for port numbers, by having IANA only
> register a service for the specific transport protocols used.
> 
> The same expectation holds for services without an assigned port number.
> The entity managing a zone with SRV resource records does not want to
> admit nonsensical owner names.  One of the primary purposes of the
> proposed independent Service Prefix registry was to give just that
> list to admins.
> 
> You have insisted on a unified registry, and we have accepted, because
> we have been assured that the requirements spelled out multiple times
> before IETF 76 in Hiroshima would mostly be fulfilled by the unified
> registry.
> 
> You also have insisted on only using transport protocols registered
> with a service for service discovery DNS name construction. That's why
> we are working on advice for RFC authors, WGs, and other SDOs, on how
> to migrate previously documented use cases of SRV records not adhering
> to these restrictions to other naming schemes following these rules.
> 
> Therefore, as agreed upon in Hiroshima, our "SRV Clarify" draft,
>   http://tools.ietf.org/html/draft-gudmundsson-dnsext-srv-clarify-00
> spells out that the Service Prefix in the owner name of SRV records
> MUST be constructed from the entries in the unified Service Names and
> Port Numbers registry:
>   -  the Service Label is to be constructed from the Service Name
>      in the entry, and
>   -  the Protocol Label is to be built from the transport Protocol
>      name in the registry entry (by prefixing an underscore to the
>      supported protocol acronym, currently 4 choices).
> 
> We also have repeatedly asked for an optional per-entry tag indicating
> the support of dynamic service discovery via DNS SRV records.
>
> To repeat:  Not having the proper protocol name associated with the
> Service Name -- independent of whether or not there is an assigned
> (default) port number -- would make the registry useless for those
> who want to make use of it to determine which Service Prefixes
> should be admitted in DNS zones routinely.

Can you clarify what this means? I.e., does this mean you WANT to
specify the valid protocols for each service name?

	JOE-NAME	TCP

If so, why is this necessary?

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAktOj90ACgkQE5f5cImnZrtK4gCg8jboAUAR+F/rVtTDTJVavwGr
WdEAoPu7jGFc3LijZREjHAarArGSufML
=7og/
-----END PGP SIGNATURE-----