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

[Alfred Hönes <[e-mail]>]

Replying to Joe and Magnus at once:

Magnus Westerlund wrote:

> I thought this was going to be covered in the reference that explains
> how the SRV is used with service X. I think that is the most appropriate
> place to indicate which protocols are expected to be supported and for
> which usages which is the most appropriate.

The registry serves to compile the information on services in a
concise form useful for many audiences.  You cannot defer the task
of information extraction from the basic application-specific
documents to each and every user of the registry.  Of course,
the many details and nuances will be in the specs.
But following the same argument, oh, we would arrive at:
   "The default port number assigned to a service are specified
    in the specification document(s) of the application, so the
    port numbers and supported protocols need not be listed either
    in the registry, it suffices to point to the references there.
    You are encouraged to collect yourself the information you need."
 :-)

Our document (draft-gudmundsson-dnsext-srv-clarify) is based on
{service name, transport protocol} pairs registered in the subject
registry.  If we cannot draw the information about transport protocols
supported by a service from the Service Names and Port Numbers registry,
we would be back at the need for an independent, specific
SRV Service Prefix registry, which you wanted to trade in, in favor of
improved content in your registry.

>
> From the Service name registry point of view this is not needed
> information. However, I agree that for the user of the service name it
> is clearly of interest. But as I said before, it is service specific.

I do not see the point.

You have come to the conclusion that for the purpose of the
registry, the transport protocol matters (as before), and that new
applications shall not be registered automatically for all such
protocols -- the set of which might well grow in the future --,
and listing improper, unsupported {protocol, port number} pairs
for any service is confusing, and in effect detrimental to the
purpose of a registry.

So where's the difference between an application with a default
port number assigned by IANA and/or port numbers assigned locally?

What matters in any case is that, whether or not you use default
port numbers, users of the registry list want a one-stop shop
for the most important information.  And this is always the
{service, protocol} pair, with (default) port numbers drawn
from the registry and/or acquired from local information.

It it important that such local information is taken into
account if and only if applicable, to avoid overhead at all
levels.  The presentation of precise basic information in the
registry should be the fundament for making decisions on whether
local information is to be taken into account, in the 'canonical'
case; of cause, exceptions will exist, but to a much more manageable
extent.

The application context must know which protocols are supported, and
clients should not be misled to make definitely useless DNS lookups
if either SRV support is not specified altogether, or information
can only be expected reasonably for specific transports of a service.

For instance, a firewall admin can take the default port numbers
from the registry where assigned, but he must be made aware of
the support for local service port assignment and dynamic service
discovery in order to acquire the relevant information.  If the
unified registry pretends service discovery support for all services
(by not tagging its applicability), these folks must resort again to
private lists.  Do you really want that?
Or do you expect them to look at the thousands of references in
the registry (I hope there will be!) to make the determination?


Joe Touch wrote:
[[ reordering a bit for clarity ]]

>>[AH] ...
>> 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

Yes, of course, but with the appropriate reference for each entry!
The registry should serve as a repository of what has been specified,
in order to be useful, isn't it?  Each entry has to be meaningful,
or else it will be subject to elimination in the garbage collection
passes you plan to be performed on the registry periodically.

The assignment of a default port number to a service and its
subsequent presentation in the registry is entirely orthogonal
to the set of supported transport protocols.

And equally, the support of dynamic service discovery is orthogonal
to the set of protocols, and in principle, on whether or not a
default port is assigned -- evidently, the combination of
"no default port"  and  "no service discovery"  is special,
it should be used for reserved names (placeholders) and
deprecated entries being phased out only.

>
> If so, why is this necessary?

See above.
For the same reasons that you describe in tsvwg-ian-ports for the
case where a default port number for a service is assigned.
You want to indicate a firewall admin to not open a hole for
JOE-NAME/sctp unless that's defined, and service discovery
folks should be pointed to what service prefixes should be
admitted routinely if requested.

And, besides, applying the same rules in an orthogonal manner
should make registry operations more regular and consistent.

The only difference between a request to IANA that seeks for a
registration without assignment of a default port number and
applying for a default port number as well should be to say so
in the latter case, but leaving the port number item empty in the
registration template in the former case.
That should not change any other rules.
Note that DCCP Service Code assignment is also independent from
and orthogonal to default port number assignment.


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

Exactly; and for DCCP, you would need a Service code entry,
independent of whether or not you have an assigned default port#.

I do not have an idea why that is questionable.
I guess, after all your strong opposition against
draft-gudmundsson-dns-srv-iana-registry-04, that you
had studied that draft, and that you now have read
draft-gudmundsson-dnsext-srv-clarify-00.
We have not received comments from you so far indicating that
something there was unclear, ambiguous, or underspecified.
If it is in your opinion, please speak.

I recall:  The assumption that any service making use of
DNS SRV based service discovery must have the appropriate
transport protocols registered with the service name
if such registry shall make sense at all, has never been
challenged before, it was self-evident.


Let's study a concrete multi-stage example, following my expectation
on reasonable and useful registry content and behavior.


The current Port Numbers registry contains the selected entries:

----snip----
smtp             25/tcp    Simple Mail Transfer
smtp             25/udp    Simple Mail Transfer
#                          Jon Postel <[e-mail]>
#
submission      587/tcp    Submission
submission      587/udp    Submission
#                          [RFC4409]
#
pop3            110/tcp    Post Office Protocol - Version 3
pop3            110/udp    Post Office Protocol - Version 3
#                          Marshall Rose <[e-mail]>
#
pop3s           995/tcp    pop3 protocol over TLS/SSL (was spop3)
pop3s           995/udp    pop3 protocol over TLS/SSL (was spop3)
#                          Gordon Mangione <[e-mail]>
#
imap            143/tcp    Internet Message Access Protocol
imap            143/udp    Internet Message Access Protocol
#                          Mark Crispin <[e-mail]>
#
imaps           993/tcp    imap4 protocol over TLS/SSL
imaps           993/udp    imap4 protocol over TLS/SSL
----snip----


After the installation of the Service Names and Port Numbers registry,
I expect to see something like shown below (note the deletion of
nonsensical UDP transport and the inclusion of useful references, and
the import that you plan of 'mail' from the RFC 952 / WKS registry):

----snip----
smtp             25/tcp    Simple Mail Transfer                [RFC5321]
mail             25/tcp    legacy alias for SMTP -- DEPRECATED
#                          # from legacy database
#
submission      587/tcp    Message Submission                  [RFC4409]
#
pop3            110/tcp    Post Office Protocol - Version 3    [RFC1939]
#
pop3s           995/tcp    POP3 protocol over TLS    [RFC1939],[RFC2592]
#
imap            143/tcp    Internet Message Access Protocol    [RFC3501]
#
imaps           993/tcp    IMAP4 protocol over TLS   [RFC3501],[RFC2592]
----snip----


Some time in the future, the following entries might be added by
an Experimental RFC "IMAPv4 Multi-Stream Operation over SCTP",
say RFC uuuu:

----snip----
imap            143/sctp   Internet Message Access Protocol    [RFCuuuu]
#
imaps           993/sctp   IMAP4 protocol over TLS             [RFCuuuu]
#
----snip----


After the approval for publication and IANA processing of
draft-daboo-srv-email (that adds, among other things, port
agility in support of multiple server instances per host
at an ISP) as say, RFC ssss, the above registry entries get
amended as follows (assuming, as an exercise, no IMAP SCTP support
added yet because that's Experimental and/or the authors have not
been aware of that variant) and, assuming the currently discussed
"umbrella service", 'email' gets accepted, a new entry.
Also assume the 'mail' Service Name has been subject to
registry maintenance action to phase it out.

----snip----
smtp             25/tcp *  Simple Mail Transfer                [RFC5321],
#                                                              [RFCssss]*
mail                       legacy alias for SMTP -- DEPRECATED
#                          # from legacy database
#
submission      587/tcp *  Message Submission                  [RFC4409],
#                                                              [RFCssss]*
pop3            110/tcp *  Post Office Protocol - Version 3    [RFC1939],
#                                                              [RFCssss]*
pop3s           995/tcp *  POP3 protocol over TLS    [RFC1939],[RFC2592],
#                                                              [RFCssss]*
imap            143/tcp *  Internet Message Access Protocol    [RFC3501],
#                                                              [RFCssss]*
imap            143/sctp   Internet Message Access Protocol    [RFCuuuu]
#
imaps           993/tcp *  IMAP4 protocol over TLS   [RFC3501],[RFC2592]
#                                                              [RFCssss]*
imaps           993/sctp   IMAP4 protocol over TLS             [RFCuuuu]
#
email               tcp *  email umbrella service              [RFCssss]*

...
...

Footnote:
  (*)  indicates support for dynamic service discovery via DNS SRV,
       see [RFC2782] and [RFC-srv-clarify], and the references
       specifying its use.

----snip----


Later on, say RFC vvvv is the Standards Track version successor
of (the then obsoleted) RFC uuuu, and it at the same time specifies
service discovery for multi-thread IMAP4 over SCTP, the following
result will be obtained:

----snip----
smtp             25/tcp *  Simple Mail Transfer                [RFC5321],
#                                                              [RFCssss]*
submission      587/tcp *  Message Submission                  [RFC4409],
#                                                              [RFCssss]*
pop3            110/tcp *  Post Office Protocol - Version 3    [RFC1939],
#                                                              [RFCssss]*
pop3s           995/tcp *  POP3 protocol over TLS    [RFC1939],[RFC2592],
#                                                              [RFCssss]*
imap            143/tcp *  Internet Message Access Protocol    [RFC3501],
#                                                              [RFCssss]*
imap            143/sctp*  Internet Message Access Protocol    [RFCvvvv]*
#
imaps           993/tcp *  IMAP4 protocol over TLS   [RFC3501],[RFC2592]
#                                                              [RFCssss]*
imaps           993/sctp*  IMAP4 protocol over TLS             [RFCvvvv]*
#
email               tcp *  email umbrella service              [RFCssss]*
email               sctp*  email umbrella service              [RFCvvvv]*

...
...

Footnote:  [... <<as above>> ...]

----snip----


To formalize the concept, let me try a strawman abstract pseudocode
data type model description of the registry content:

srvport-reg   SEQUENCE OF srvport-entry,
                 PRIMARY-INDEX   srvport-entry.service-name,
                 ALTERNATE-INDEX SEQUENCE {
                                    srvport-entry.default-port;
                                    srvport-entry.service-name;
                                 };

srvport-entry SEQUENCE {
                 service-name  name-label;
                 default-port  UINT16;     /* 0 means None */
                 description   STRING              OPTIONAL;
                 registrant    reg-clerical;
                 status        reg-status;
                 tcp-entry     protocol-info{tcp}  OPTIONAL;
                 udp-entry     protocol-info{udp}  OPTIONAL;
                 dccp-entry    SEQUENCE {
                                   common-entry    protocol-info{dccp};
                                   service-code    DccpSrvCode_type;
                               } OPTIONAL;
                 sctp-entry    protocol-info{sctp} OPTIONAL;
                 ...           /* extensible for future protocols */
              };

protocol-info(&&proto) SEQUENCE {
                 protocol      protocol-type ::= &&proto;
                 for-srv       srv-flag;
                 description   STRING  DEFAULT srvport_entry.description;
                               /* inherited from entry by default */
                 note          STRING;
                 status        reg-status  DEFAULT srvport-entry.reg-status;
                               /* inherited from entry by default */
                 refs          SEQUENCE of ref-entry;
              };

ref-entry     SEQUENCE {
                 ref-anchor    anchor-type;
                 for-srv       srv-flag;
              }

name-label   Case-Insensitive-STRING[15];

protocol-type    ENUM { tcp(6), udp(17), dccp(33), sctp(132) };

DccpSrvCode_type    ... ;

srv-flag         BOOLEAN;   /* TRUE for service discovery */

reg-clerical        ... ;   /* add administrative details,
                               timestamp for entry, by whom,
                               last change stamp, by whom,
                               or whole history of the entry
                               including pointers to archived
                               documents */

anchor-type         ... ;   /* pointer to bibliographic entry
                               or registrant email address */


Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+