Subject: [port-srv-reg] Fwd: Re: [Fwd: Additional DCCP SCs for draft-ietf-dccp-rtp-07]

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 02 Dec 2008 08:54:25 +0000

Dear port people,

Here is what Colin and I discussed regarding introducing a unique key 
per protocol line for the ports registry. Joe, others, does Colin's 
comment concern you, or may we ask IANA to do it this way?

Thoughts?

Gorry

-------- Original Message --------
Subject: Re: [Fwd: Additional DCCP SCs for draft-ietf-dccp-rtp-07] - 
updated registry format
Date: Mon, 1 Dec 2008 18:23:56 +0000
From: Colin Perkins <[email-masked]>
To: [email-masked]
References: <[email-masked]>

On 18 Nov 2008, at 19:17, Gorry Fairhurst wrote:
> The port_srv group met today, and I think we made some good  
> progress. Michele is ready to do an update to the registry format,  
> and we'd like to now insert the RTP/DCCP entries.
>
> We agreed on the enclosed values previously, but after the meeting  
> today, we now have a format that would like each line to be keyed  
> by a unique combination of {transport,port/service name}. That  
> would mean that each line in your registration would require a  
> unique name.
<snip>

The correct table should be:

   avt-profile-1A   5004    dccp    1381257281    RTPA     RTP audio
   avt-profile-1V   5004    dccp    1381257302    RTPV     RTP video
   avt-profile-1T   5004    dccp    1381257300    RTPT     RTP text
   avt-profile-1O   5004    dccp    1381257295    RTPO     RTP other
media

> Does this work for you? - This is a kind of test-case, so if you  
> have questions or foresee issues, we'd love to know.

The only issue I see is that the service name is different for DCCP
than for UDP and TCP (which use "avt-profile-1").  It's not clear if
that's a problem, but it is a change, and presumably impacts anything
that does a getservbyname() call (but, then again, it's not clear how
getservbyname() interacts with DCCP at all...).

Colin

> Gorry
>
>
> -------- Original Message --------
>
> I've checked with Colin, about the requested allocations in
> http://tools.ietf.org/html/draft-ietf-dccp-rtp-07
> (currently with RFC-Ed awaiting a REF).
>
> If we put a SC value for DCCP server ports in the port registry, then
> the following DCCP service code values are to be registered for  
> port 5004:
>
> avt-profile-1    5004    dccp    1381257281    RTPA     RTP audio
> avt-profile-1    5004    dccp    1381257302    RTPV     RTP video
> avt-profile-1    5004    dccp    1381257300    RTP      RTP
> avt-profile-1    5004    dccp    1381257295    RTPO     RTP text
>
> The following DCCP service code values are to be registered for  
> port 5005:
>
> avt-profile-2	 5005    dccp    1381253968    RTCP     RTP control
> protocol (RTCP)
>
> Note this would create multiple entries for different SC using the  
> same
> server port, which is of course fine for a DCCP SC.
>
> Gorry

-- 
Colin Perkins
http://csperkins.org/

_______________________________________________
Port-srv-reg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/port-srv-reg

---

From: Thomas Narten <[email-masked]>
Date: Tue, 02 Dec 2008 09:10:04 -0500

> comment concern you, or may we ask IANA to do it this way?

I may be jumping into this late, but...

What is the purpose of having such a key? Which other registries have
(or need it)? Is this going to set a precedent?

Thomas

---

From: Joe Touch <[email-masked]>
Date: Fri, 05 Dec 2008 11:17:31 -0800

Hi, Thomas (et al.),

The goal for the key is to uniquely identify an entry in the table; if
the key is the [transport protocol, namestring] pair, then we don't need
to create a new mechanism for encoding tuples within a DNS SRV record, e.g.

Colin's comment demonstrates, IMO, that this sort of keying is useful.
When a service is available for multiple transports, I have always
expected that the service is *identical* on those transports except only
for transport adaptation layers (framing, flow signalling, etc.). I.e.,
DNS over UDP and TCP. IMO, using a custom 'ping' on UDP to discover a
true service on TCP should require that these services have different
names, since they are different services (i.e., myservice vs.
myservice-discovery).

In the case of DCCP, there are different codepoints available. The
question is whether those codepoints are a single service or different
services; if different, then they should require different service
names. That also means that the corresponding TCP service is either
specific (-1A, -1V, etc.), or aggregate and specified by some in-band
flag. In the latter case, that's a different application service than
- -1A, -1V, etc. - it's -1-group or somesuch. I don't know what just "-1"
would mean in this case...

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 09 Dec 2008 17:51:59 +0000

So...

Should I now instruct IANA to make the port allocations in the way that 
was discussed with Colin?

Gorry

Joe Touch wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi, Thomas (et al.),
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkk5fksACgkQE5f5cImnZrvR4wCg9Vf0VkBkp5++g2/gCAr+Zw8U
> D60AnipOK0HlviIgDGS2BeftTt2w3Xn5
> =2fDV
> -----END PGP SIGNATURE-----
> 
>

---

From: Thomas Narten <[email-masked]>
Date: Tue, 09 Dec 2008 13:15:57 -0500

I'm probably just being dense on this one...

> >>>    avt-profile-1O   5004    dccp    1381257295    RTPO     RTP other

To be clear, the 4th column (13812572*) are values in the registry,
and are *not* the unique key. The unique key is column 1, right?

If so, I was just confused and am fine with the table.

I.e., what exactly are the column headings? I think I made bad
assumptions about what the headings were..

What I am missing is the fuller IANA considerations section with clear
instructions about which registry is being updated, so I can see what
typical registry entries contain... :)

Thomas

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 09 Dec 2008 19:58:42 +0000

Whoops sorry Thomas, you're been catapulted into the middle of a complex 
thread - let me see if I can help with a little context...

These "odd" numbers are the encoding of the DCCP Service Code, which is 
unique within DCCP-world. The first 4 characters of the comment also are 
the ASCII representation of this 32-bit number as 4 8-bit characters. 
(For info, that's where the "magic numbers come from.) However, after 
all that, the service-code field is only used by DCCP, and is not 
supported in other transports!

The "unique key", is therefore the combination of column-1 and column-3

Gorry

>>>>> The correct table should be:

          service-name     port  transport service-code  Comment........