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

From: Alfred Hönes <[email-masked]>
Date: Fri, 15 Jan 2010 19:40:39 +0100 (MEZ)

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 <[email-masked]>
#
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 <[email-masked]>
#
pop3s           995/tcp    pop3 protocol over TLS/SSL (was spop3)
pop3s           995/udp    pop3 protocol over TLS/SSL (was spop3)
#                          Gordon Mangione <[email-masked]>
#
imap            143/tcp    Internet Message Access Protocol
imap            143/udp    Internet Message Access Protocol
#                          Mark Crispin <[email-masked]>
#
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: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 18 Jan 2010 13:14:14 +0100

Hi Alfred,

I have now read draft-gudmundsson-dnsext-srv-clarify-00 again.

Me personally hasn't really digged into the issues that you bring up in
your document, I don't think I am alone in this. Thus, I think it would
be jumping to conclusions that there are agreement on your suggested
approach simple because you haven't received comments on them yet.

>From the perspective of trying to advance draft-ietf-tsvwg-iana-ports,
we do come down to trying to find the reasonable interface between our
documents.

On the issue of the protocol label for a given service name. I find it
reasonable that your document do extended the registry with an
additional column that enumerates any non-default protocol label order.
I get the impression that you want this to be described in
draft-ietf-tsvwg-iana-ports due to that it should be included in any
service name registration request.

I had hoped that we could avoid normative dependencies from IANA ports
towards draft-gudmundsson-dnsext-srv-clarify. This to enable
draft-ietf-tsvwg-iana-ports to be approved and published as soon as
possible.

>From my perspective I see three ways forward:

1. We write nothing about the protocol label in regards to Service name
registrations and lets draft-gudmundsson-dnsext-srv-clarify update the
Registration RFC.

2. We include some text about the need to specify protocol label
priority list unless the default one (also included listed in
draft-ietf-tsvwg-iana-ports) but pushing of the explanation about the
issues to your document using a normative reference.

3. We fudge something together in the middle trying to avoid a normative
reference.

I think I am leaning towards 1 personally even if it has some obvious
downside in that the registration rules information will not be
contained to a single document. However, I think IANA's registration
template can clearly make it clear to applicants that you need to read
things in both.

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 21 Jan 2010 11:24:49 -0500

Magnus,

Can someone kill the signature on this list, it 
messes up messages that are sent
in base64 encoding like your messages, this is what they look like in my
email reader.
Comments on message at the end.

At 07:14 18/01/2010, Magnus Westerlund wrote:
>Hi Alfred, I have now read 
>draft-gudmundsson-dnsext-srv-clarify-00 again. 
>Me personally hasn't really digged into the 
>issues that you bring up in your document, I 
>don't think I am alone in this. Thus, I think it 
>would be jumping to conclusions that there are 
>agreement on your suggested approach simple 
>because you haven't received comments on them 
>yet. From the perspective of trying to advance 
>draft-ietf-tsvwg-iana-ports, we do come down to 
>trying to find the reasonable interface between 
>our documents. On the issue of the protocol 
>label for a given service name. I find it 
>reasonable that your document do extended the 
>registry with an additional column that 
>enumerates any non-default protocol label order. 
>I get the impression that you want this to be 
>described in draft-ietf-tsvwg-iana-ports due to 
>that it should be included in any service name 
>registration request. I had hoped that we could 
>avoid normative dependencies from IANA ports 
>towards draft-gudmundsson-dnsext-srv-clarify. 
>This to enable draft-ietf-tsvwg-iana-ports to be 
>approved and published as soon as possible. From 
>my perspective I see three ways forward: 1. We 
>write nothing about the protocol label in 
>regards to Service name registrations and lets 
>draft-gudmundsson-dnsext-srv-clarify update the 
>Registration RFC. 2. We include some text about 
>the need to specify protocol label priority list 
>unless the default one (also included listed in 
>draft-ietf-tsvwg-iana-ports) but pushing of the 
>explanation about the issues to your document 
>using a normative reference. 3. We fudge 
>something together in the middle trying to avoid 
>a normative reference. I think I am leaning 
>towards 1 personally even if it has some obvious 
>downside in that the registration rules 
>information will not be contained to a single 
>document. However, I think IANA's registration 
>template can clearly make it clear to applicants 
>that you need to read things in both. Cheers 
>Magnus Westerlund IETF Transport Area Director 
>Ericsson AB                | Phone  +46 10 
>7148287 FÃ¤rÃ¶gatan 6                | Mobile 
>+46 73 0949079 SE-164 80 Stockholm, Sweden| 
>mailto: [email-masked] 
>_______________________________________________ 
>Port-srv-reg mailing list [email-masked] 
>https://www.ietf.org/mailman/listinfo/port-srv-reg

References and updates: there are two issues
draft-gudmundsson-dnsext-srv-clarify  updates RFC2782
draft-ietf-tsvwg-iana-ports also updates RFC2782
Is it necessary that both update 2782 ?

draft-gudmundsson-dnsext-srv-clarify has normative reference to
draft-ietf-tsvwg-iana-ports and -ports- should have a Informational reference
to the first one.
Both documents should be advanced at the same time IMHO, as they are
complementary. -srv-clarify- is roughly complete, just pending
resolving issues related to what document does what.

I think the only action that -ports- is performing on 2782 is to link the
registry (and restrict the length), that same action and more are
performed in srv-clarify.
We should work out exactly which document does what and where text
and actions need to be moved around.

I find it strange that by reading -ports- I do not get a any idea
what the registry will look like, thus I can not judge if the registry
is meeting expectations :-)

Please update section 10 to include a list of columns in the
registry and what the role of each column is.
Here is what I think it should at least be included:
Service name | Port number(s) | Transports (list) | Notes | Reference

Reference can be RFC or the application
Transports could be one column or multiple ones.
If Transports is a single column then it can incorporate the
priority order that we talk about in -srv-clarify- as that
applies to ports usage as well.

Any text/ideas related to the format of the registry should be in -ports-
and we would prefer not the change the format of the registry, all we want to
is to explain how to use it.
This is basically your suggestion #2.

As soon as we see the format of the registry we 
can crack out the third document
in this series that takes actions on old RFC and registries to move the
registrations into the new registry and close the sub-SRV registries that have
created due to the lack of real SRV registry.

         Olafur