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

[Olafur Gudmundsson <[e-mail]>]

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 
>---------------------------------------------------------------------- 
>Multimedia Technologies, Ericsson Research 
>EAB/TVM 
>---------------------------------------------------------------------- 
>Ericsson AB                | Phone  +46 10 
>7148287 Färögatan 6                | Mobile 
>[phone] SE-164 80 Stockholm, Sweden| 
>mailto: [e-mail] 
>---------------------------------------------------------------------- 
>_______________________________________________ 
>Port-srv-reg mailing list [e-mail] 
>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