Subject: [port-srv-reg] FW: Merging Stuart's registry with port-numbers

From: Michelle Cotton <[email-masked]>
Date: Mon, 11 Apr 2011 13:19:41 -0700

All:

We are in the process of officially combining the ports/service name
registries.

Stuart's registry (http://www.dns-sd.org/ServiceTypes.html) contains
these two entries:

panoply         Panoply multimedia composite transfer protocol
                Natarajan Balasundara <rajan at ipanoramii.com>
                Primary Transport Protocol: Proprietary
                Defined TXT keys: None

parabay-p2p     Parabay P2P protocol
                Vishnu Varadaraj <vishnuv at parabay.com>
                Primary Transport Protocol: Proprietary
                Defined TXT keys: None

There is a problem with the "Proprietary" transport protocol. The new
port-numbers registry accepts only UDP, TCP, SCTP, or DCCP as transport
protocol (according to draft-ietf-tsvwg-iana-ports-10 section 8.1.1).

How do we deal with this one?

Thanks,

--Michelle

---

From: Joe Touch <[email-masked]>
Date: Mon, 11 Apr 2011 15:35:08 -0700

That's a good question. I had argued that service names were independent 
of the transport protocol, but given the current text they aren't, so 
not clear how to handle it.

Maybe "other" or "proprietary" as the transport and leave it at that 
informally in the registry?

Joe

On 4/11/2011 1:19 PM, Michelle Cotton wrote:
>                  Natarajan Balasundara<rajan at ipanoramii.com>
>                  Vishnu Varadaraj<vishnuv at parabay.com>
> _______________________________________________
> Port-srv-reg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/port-srv-reg

---

From: Lars Eggert <[email-masked]>
Date: Tue, 12 Apr 2011 09:30:30 +0800

Hi,

if there are more cases like this, or more otherwise special cases, we may want to make edits during AUTH48. For example, allow "other" as a transport protocol tag in cases like this.

How far along with the merging are you?

Lars

On 2011-4-12, at 6:35, Joe Touch wrote:
> That's a good question. I had argued that service names were independent of the transport protocol, but given the current text they aren't, so not clear how to handle it.
> 
> Maybe "other" or "proprietary" as the transport and leave it at that informally in the registry?
> 
> Joe
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 11 Apr 2011 18:37:05 -0700

One question - how does proprietary even use an srv record? Or is this just name grabbing?

---

From: "David Harrington" <[email-masked]>
Date: Tue, 12 Apr 2011 10:18:58 +0200

+1

dbh 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Lars Eggert
> Sent: Tuesday, April 12, 2011 3:31 AM
> To: Joe Touch
> Cc: [email-masked]
> Subject: Re: [port-srv-reg] FW: Merging Stuart's registry 
> with port-numbers
> 
> Hi,
> 
> if there are more cases like this, or more otherwise special 
> cases, we may want to make edits during AUTH48. For example, 
> allow "other" as a transport protocol tag in cases like this.
> 
> > That's a good question. I had argued that service names 
> were independent of the transport protocol, but given the 
> current text they aren't, so not clear how to handle it.
> > 
> >> Stuart's registry 
> (http://www.dns-sd.org/ServiceTypes.html) contains
> >> these two entries:
> >>

---

From: Michelle Cotton <[email-masked]>
Date: Tue, 12 Apr 2011 12:57:10 -0700

FYI...we believe these 2 (mentioned below) are the only 2 exceptions.
How do you want to proceed?

--Michelle

---

From: Joe Touch <[email-masked]>
Date: Tue, 12 Apr 2011 14:27:28 -0700

The SRV spec requires the DNS entry use _tcp or _udp. I had a discussion 
with Gorry that sometimes these don't really matter (some use these 
entries and still use another transport, such as SCTP or DCCP).

We said in the ports doc that the transport must be listed, and only 
certain transports were accepted:

---
    o  Transport Protocol(s): The transport protocol(s) for which an
       assignment is requested MUST be provided.  This field is currently
       limited to one or more of TCP, UDP, SCTP, and DCCP.  Requests
       without any port assignment and only a service name are still
       required to indicate which protocol the service uses.
---

I would tell the applicant they have to pick a transport, e.g., the one 
they intend to lookup the service name under (even if they use a 
proprietary transport later).

 From IANA's viewpoint, it's just going to end up being a TCP or UDP or 
somesuch registration.

Joe

On 4/12/2011 12:57 PM, Michelle Cotton wrote:
> On 4/12/11 1:18 AM, "David Harrington"<[email-masked]>  wrote:
>
>> +1
>>
>> dbh
>>

---

From: Lars Eggert <[email-masked]>
Date: Wed, 13 Apr 2011 10:00:17 +0800

Hi,

On 2011-4-13, at 5:27, Joe Touch wrote:
> I would tell the applicant they have to pick a transport, e.g., the one they intend to lookup the service name under (even if they use a proprietary transport later).

sounds OK - but they aren't really an applicant, since they already got their service name. I think we should simply pick one for them that is likely being correct (i.e., UDP) and inform them of this, with an option to instruct us otherwise.

Lars

---

From: "David Harrington" <[email-masked]>
Date: Wed, 13 Apr 2011 08:11:42 +0200

Hi,

does anybody know if these protocols are actually in use? 
do we WANT to limit registration to the 4 ietf protocols?
can we reclaim these (by asking the companies to change their
registration/withdraw their registration?)
we don't have a registration date for these?

dbh

> From: Michelle Cotton [mailto:[email-masked]] 
> Sent: Tuesday, April 12, 2011 9:57 PM
> To: David Harrington; 'Lars Eggert'; 'Joe Touch'

---

From: "David Harrington" <[email-masked]>
Date: Wed, 13 Apr 2011 08:22:46 +0200

Overnight, I came to a similar conclusion about _tcp vs _udp.

We don't actually want the service tied to a specific transport, but I
like Joe's justification - which protocol will be used to do the
lookup. I think the document might do well to explain the tcp vs udp
issue as the name resolution transport. Does that make sense to
others?

dbh

> From: Joe Touch [mailto:[email-masked]] 
> Sent: Tuesday, April 12, 2011 11:27 PM
> To: Michelle Cotton
> Cc: David Harrington; 'Lars Eggert'; [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Tue, 12 Apr 2011 23:42:08 -0700

Everything except the document part. It's out the door at this point. Afaict this can be in the next doc or just a clarification to applicants by IANA. 

Joe

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 13 Apr 2011 08:35:35 +0100

Joe Touch wrote:

>Everything except the document part. It's out the door at this point.
>
Right. I would rather not reopen the document at this point.

>Afaict this can be in the next doc or just a clarification to applicants by IANA. 
>
>Joe
>

---

From: Michelle Cotton <[email-masked]>
Date: Wed, 13 Apr 2011 08:02:23 -0700

Please let me know what the consensus is on what to do with the registry so
we can continue merging.

Thanks,

Michelle

---

From: Joe Touch <[email-masked]>
Date: Wed, 13 Apr 2011 08:23:30 -0700

Hi, Michelle,

The few of us who have responded seem to have converged as follows:

- contact the service name assignee to confirm the following: (in 
advance, IMO, if possible)
	- register service names under the transport the assignee
	intends to use for lookup (which may have nothing to do
	with the transport actually used by the service)

	in the absence of other info, use UDP

Joe

On 4/13/2011 8:02 AM, Michelle Cotton wrote:
> On 4/13/11 12:35 AM, "Alexey Melnikov"<[email-masked]>  wrote:
>
>> Joe Touch wrote:
>>
>>> On Apr 12, 2011, at 11:22 PM, "David Harrington"<[email-masked]>  wrote:
>>>
>>>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 13 Apr 2011 17:37:27 +0200

> 	in the absence of other info, use UDP

That is fine with me.

Cheers

Magnus Westerlund

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