Subject: [port-srv-reg] Service names/ports/codes discussion

From: "Phelan, Tom" <[email-masked]>
Date: Tue, 18 Mar 2008 09:04:35 -0400

Hi All,

I sent this to Lars and Magnus after our meeting on Wednesday.  Here's
my understanding of what I heard...

Tom P.

----------------------------------------------------------------------
Hi Lars/Magnus,

Here's a quick recap of what I think I just heard in our discussion.
Since we don't have the mailing list setup yet, please forward this to
the other participants.  I'm much more encouraged by the result of this
discussion that I was by the Vancouver discussion -- I think we're on
the path of something that'll work.

In summary, we're going to create a single registry; I'll call it the
"Services" registry (we're not stuck with that name).  Each row will
have the following fields:

 o Service Name -- A 14-max-character name for the service.
 o Port Number -- A port in the well-known or registered ports ranges
 o Protocol -- One of the transport protocols
 o Service Code -- A 32-bit DCCP-style service code
 o Description -- Free-form text describing the service
 o Reference -- A pointer to a document that defines the service
 o Contact (?) -- Who's responsible for the service (we didn't discuss
this, but do we need it?)

Some of the fields can be empty, values in some fields can be
constrained by values in other fields, all subject to rules that we will
specify.  Here's a stab at some rules for Protocol == DCCP:

If Protocol==DCCP:
	Service Code MUST NOT be empty and its value MUST be unique (one
that doesn't appear in any other row as Service Code), also MUST NOT be
0 or 0xffffffff.
	Port Number MAY be empty.  If it is not empty, its value SHOULD
be unique, but MAY, subject to expert review, duplicate an already used
value.
	Service Name MAY be empty, subject to rules for other fields.

These rules are based on some assumptions about rules for other fields.
Some examples:
	Description, Reference and Contact MUST NOT be empty
	If Port Number is not empty, Service Name MUST NOT be empty

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

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Mar 2008 10:46:00 -0700

Hi, all,

The following is a good start. I'd like to suggest that we require at 
least one field to be filled for every protocol, i.e,, one "key". That 
may require adding values to existing entries, e.g., providing a service 
name for every entry.

Here's a compact representation of what I understand:

Protocol-specific rules:

		TCP or UDP	DCCP	other

Service Name 	MUST		MUST*	MUST* (*IMO this is the "key")
Port Number	MUST		MAY	MAY
Protocol	MUST		MUST	MUST
Service Code	MUST NOT	MUST	MAY
Description	MUST		MUST	MUST
Reference	SHOULD		SHOULD	SHOULD
Contact		MAY		MAY	MAY

General rules:

Service Name	MUST be unique

Port Number	SHOULD be unique
		MUST be explained if not unique

Protocol 	MUST be one of {TCP,UDP,DCCP,SCTP} (any others?)

Service Code	MUST be unique

Description	MUST NOT be empty

Reference	SHOULD NOT be empty
		MUST NOT be empty for added entries

Contact		SHOULD NOT be empty
		MUST NOT be empty for added entries

I think reserved values should be handled in the table, not in the rules.

I think contact is useful to include, but not required.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Mar 2008 10:50:33 -0700

Oh ick. Here it is with spaces rather than tabs:

------------------------

Protocol-specific rules:

                 TCP or UDP    DCCP      other

General rules:

Joe

---

From: "Phelan, Tom" <[email-masked]>
Date: Tue, 18 Mar 2008 14:14:04 -0400

Hi Joe,

I can buy the MUST for Service Name with DCCP.  I agree that it makes a
good universal key for the table.

> I think reserved values should be handled in the table, not in the
rules.

So by this do you mean that each column should have data format rules?
So then the Service Code format would be:

	One of the "SC" formats defined in RFC 4340 (SC:, SC=, SC=x or
SC=X).
	SC=0 and SC=xffffffff (and their equivalents) are not allowed.

Tom P.

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> Sent: Tuesday, March 18, 2008 1:46 PM
> To: Phelan, Tom
> Cc: [email-masked]
> Subject: Re: [port-srv-reg] Service names/ports/codes discussion
> 
> Hi, all,
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 18 Mar 2008 18:31:43 +0000

Tom,

Of course, in DCCP the definitive value is the DECIMAL value of the 
Service Code,  a number in the range 0-4294967294 (as used in SC 
registry) - other representations, if present, should probably be part 
of a free-form text comment.

Gorry

---

From: "Phelan, Tom" <[email-masked]>
Date: Tue, 18 Mar 2008 15:05:08 -0400

Hi Gorry,

Well, the definitive format is 32-bit binary; all the SC formats are for
human readability.  I don't have a problem with limiting the Services
table to one form, though.  It'll make it easier to detect duplicates.

Tom P.

> From: Gorry Fairhurst [mailto:[email-masked]]
> Sent: Tuesday, March 18, 2008 2:32 PM
> To: Phelan, Tom
> Cc: Joe Touch; [email-masked]
> >>> Since we don't have the mailing list setup yet, please forward
this
> > to
> >>> constrained by values in other fields, all subject to rules that
we
> > will
> >>> that doesn't appear in any other row as Service Code), also MUST
NOT
> > be

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Mar 2008 12:37:58 -0700

> 	SC=0 and SC=xffffffff (and their equivalents) are not allowed.

Format would be 32-bit, decimal or hex as preferred.

Format does not include excluded values as above; it would include 
excluded formats, e.g., "ASCII A-Z0-9_ case insensitive".

Excluded values ought to be entered into the table, not prohibited by 
format rules.

Joe

---

From: "Phelan, Tom" <[email-masked]>
Date: Tue, 18 Mar 2008 15:40:03 -0400

Hi Joe,

> Excluded values ought to be entered into the table, not prohibited by

[Tom P.] OK

this
we
NOT

---

From: Lars Eggert <[email-masked]>
Date: Wed, 19 Mar 2008 08:39:21 +0200

On 2008-3-18, at 21:37, ext Joe Touch wrote:
> Excluded values ought to be entered into the table, not prohibited  
> by format rules.

Unless you sort the table by service code, such that things like "XXX- 
YYY Invalid value" works, this approach will create a *huge* number of  
table entries. Even with that sort of aggregation, it will create a  
large number of entries.

I'd prefer to have IANA check the well-formedness of entries at entry  
time. I'm an XML-newbie, but I think it's also possible to constrain  
XML values by regexp, which adds another check.

Lars

---

From: "Phelan, Tom" <[email-masked]>
Date: Wed, 19 Mar 2008 09:11:40 -0400

Hi Lars,

Where are you thinking that you need to have a range of invalid values?
For Service Codes there are only two invalid values, 0 and
4,294,967,295.  Oh yah, there are the codes that begin with ASCII '?'
that are reserved for private use and I guess therefore shouldn't be
registered.

And looking again at RFC 4340, there's the restriction that if you want
a code with bytes in the uppercase, digit and few other characters
range, you need to have a standards document -- IETF or otherwise.

Tom P.

> From: Lars Eggert [mailto:[email-masked]] On Behalf Of
Lars
> Eggert
> Sent: Wednesday, March 19, 2008 2:39 AM
> To: ext Joe Touch
> Cc: Phelan, Tom; [email-masked]

---

From: Lars Eggert <[email-masked]>
Date: Wed, 19 Mar 2008 15:27:11 +0200

> range, you need to have a standards document -- IETF or otherwise.

Maybe I didn't have sufficient coffee this morning. It sounded like  
Joe wanted to exclude based on character patterns, which is what I  
responded to. But maybe I misunderstood?

Lars

PS: I committed the XML of the current draft-cotton to the svn  
repository.
_______________________________________________
Port-srv-reg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/port-srv-reg

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Mar 2008 06:29:55 -0700

Lars Eggert wrote:
> Unless you sort the table by service code, such that things like 
> "XXX-YYY Invalid value" works, this approach will create a *huge* number 
> of table entries. Even with that sort of aggregation, it will create a 
> large number of entries.

Sure - ranges should be OK.

> time. I'm an XML-newbie, but I think it's also possible to constrain XML 
> values by regexp, which adds another check.

That's true too, but it ought to be possible to check well-formedness 
(i.e., in the 0-65535 range) in the XML, and valid values (not 0, not 
65535, etc.) against the existing list. I would not code the invalid 
values within the valid range in XML, but rather in the table.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Mar 2008 06:33:21 -0700

Lars Eggert wrote:
> Maybe I didn't have sufficient coffee this morning. It sounded like Joe 
> wanted to exclude based on character patterns, which is what I responded 
> to. But maybe I misunderstood?

I want two things:

1) a check based on the ranges and text

2) a check to exclude invalid values

IMO, service codes 0 and 0xffffffff ought to be called "reserved" or 
"prohibited" in the table; I don't consider prohibiting two values in a 
32-bit space a "syntax check".

Joe

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Mar 2008 11:01:28 +0100

Hi Joe,

The below does not seem to take serivce name only registrations into 
account. It doesn't seem to match the "other" column to my 
understanding. The one that I have problem with I think is the MUST for 
protocol. To my understanding, although it may be wrong the protocol 
part of a DNS request for an SRV record includes the protocol as a 
separate field, and the protocol may be any of the registered ones.

So are the protocol field really required, a hint on what protocol was 
expected to be supported at time of registration, or simply not needed 
for a service name only registration?

To me it seems not required at all or a hint. But Stuart probably knows 
more on this.

Cheers

Magnus

Joe Touch skrev:
> * PGP Signed by an unverified key: 03/18/2008 at 06:50:33 PM
> * Joe Touch <[email-masked]>
> * 0x89A766BB - Unverified (L)
> 
> 
> ------------------------------------------------------------------------
> 

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Mar 2008 09:59:50 -0700

Hi, Magnus,

> for a service name only registration?

The table below is intended to say that "service name only" 
registrations are for specific protocols, not for all future protocols. 
This is for the table registration.

For SRV requests, one could ask for all the protocols with SRV records 
that match the service name; i.e., the protocol rules don't need to be 
captured in the table that way.

The protocol is (IMO) required on registration with IANA, and is 
required in a SRV reply (IMO), but not in a SRV request (AFAICT).

Does that clarify the idea?

Joe

---

From: Michelle Cotton <[email-masked]>
Date: Wed, 26 Mar 2008 14:29:31 -0700

Jumping in a little late on this...but I think the Contact should be a MUST or SHOULD.
We would be using the contact information for all the port numbers in the current registry.
Any time someone registers a new service name or port number IANA requires a point of contact in case someone has questions.

Michelle

On 3/18/08 10:50 AM, "Joe Touch" <[email-masked]> wrote:

------------------------

Protocol-specific rules:

                 TCP or UDP    DCCP      other

General rules:

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 26 Mar 2008 21:07:07 -0700

Michelle Cotton wrote:
> Any time someone registers a new service name or port number IANA 
> requires a point of contact in case someone has questions.
> 
> Michelle

MUST/SHOULD/MAY for description, reference, and contact are all policy 
issues, not protocol issues. We might then remove such words from that 
table altogether, as a result.

If we keep them, then the entries under MUST or SHOULD need to be 
relatively archival, i.e., to published documents, or a description 
contained therein. For references, e.g., URLs should not be acceptable 
except as supplemental to an archival reference. Names are never 
archival, nor are email addresses, so making persistent contact info a 
requirement may not be meaningful.

IANA can always indicate which values must be submitted in conjunction 
with an application (lower case 'must'), though.

Does that work?

Joe

---

From: Lars Eggert <[email-masked]>
Date: Thu, 27 Mar 2008 09:53:59 +0200

Hi,

I think it should be MUST.

On 2008-3-27, at 6:07, ext Joe Touch wrote:
> MUST/SHOULD/MAY for description, reference, and contact are all  
> policy issues, not protocol issues. We might then remove such words  
> from that table altogether, as a result.

Much of the document is about policy. The data in the reference,  
description and contact info are important to IANA, but they are also  
useful to the general public, if someone needs to find out what app  
might generate traffic on that port and who to talk to about it.

> contained therein.

I agree that the document should strongly suggest that stable  
references be provided (maybe even up to the point of stating that "if  
IANA can't reach you for a long time, your port may be reclaimed"),  
but I don't think we can require a stable reference for anything other  
than the contact email. We do want ports to remain relatively easy to  
register.

> For references, e.g., URLs should not be acceptable except as  
> supplemental to an archival reference. Names are never archival, nor  
> are email addresses, so making persistent contact info a requirement  
> may not be meaningful.

I don't think it's productive to turn someone away, because their  
protocol description is at a URL rather than in some other stable  
form. The only thing this would do is encourage port grabbing. But I  
agree that the document should suggest that implementors should  
strongly consider to document their protocol in an archived format,  
such as through an independent submission to the RFC Editor.

Lars

---

From: Joe Touch <[email-masked]>
Date: Thu, 27 Mar 2008 01:22:04 -0700

> might generate traffic on that port and who to talk to about it.

I don't debate the utility of policy in this doc, or in general. IMO, 
however, RFC2119 applies primarily to protocol specifications, not 
procedural or policy issues. Lower-case 'must' suffices for the latter.
> I agree that the document should strongly suggest that stable references 
> be provided (maybe even up to the point of stating that "if IANA can't 
> reach you for a long time, your port may be reclaimed"),

I don't think that's tenable, which is why having such a contact is moot 
except on the instant the port is entered into the table.

> but I don't 
> think we can require a stable reference for anything other than the 
> contact email. We do want ports to remain relatively easy to register.

What's a stable contact email? how often is it checked, and what happens 
when it fails? if not revocation, then "MUST" or "must" is meaningless 
anyway.

> protocol description is at a URL rather than in some other stable form. 

A URL is not a stable form; that's the point.

> The only thing this would do is encourage port grabbing. But I agree 
> that the document should suggest that implementors should strongly 
> consider to document their protocol in an archived format, such as 
> through an independent submission to the RFC Editor.

Published papers, publicly available tech reports, etc. also suffice. I 
don't expect an RFC is required, just that an archival reference is.

Joe

---

From: Lars Eggert <[email-masked]>
Date: Thu, 27 Mar 2008 11:16:15 +0200

Hi,
On 2008-3-27, at 10:22, ext Joe Touch wrote:
> I don't debate the utility of policy in this doc, or in general.  
> IMO, however, RFC2119 applies primarily to protocol specifications,  
> not procedural or policy issues. Lower-case 'must' suffices for the  
> latter.

I agree that the intent of 2119 was that it only apply to  
specifications, but practice has changed. But whether we use 2119  
language or not is orthogonal to this discussion, and I don't feel  
strongly about it.

>> references be provided (maybe even up to the point of stating that  
>> "if IANA can't reach you for a long time, your port may be  
>> reclaimed"),
>
> I don't think that's tenable, which is why having such a contact is  
> moot except on the instant the port is entered into the table.

The information isn't valid only at the instant the entry is created,  
it's typically valid for longer than that. Sure, people change email  
addresses etc. at some time, but I do think there is value to include  
this information even though it's not guaranteed to be stable for all  
eternity.

>> but I don't think we can require a stable reference for anything  
>> other than the contact email. We do want ports to remain relatively  
>> easy to register.
>
> What's a stable contact email? how often is it checked, and what  
> happens when it fails? if not revocation, then "MUST" or "must" is  
> meaningless anyway.

I don't know and I don't think we need to precisely define this; it  
may be sufficient for the document to say "provide a contact email  
address that you don't expect to change in the future."

>>> supplemental to an archival reference. Names are never archival,  
>>> nor are email addresses, so making persistent contact info a  
>> form.

I know, but requiring something that is stable is a significantly  
higher bar than what is current practice. We need to find a sweet spot  
between making it easy to register a port and having enough  
information available to the expert reviewer and after that in the  
registry.

>> The only thing this would do is encourage port grabbing. But I  
> Published papers, publicly available tech reports, etc. also  
> suffice. I don't expect an RFC is required, just that an archival  
> reference is.

That's significantly more involved than current IANA practice, and  
it's not practical. Application developers don't publish papers. As  
far as I know, oftentimes the only information that is available about  
a port use is what is entered into the web form on the IANA site.

We seem to have hit a bit a of a conflict here. In my opinion, port  
grabbing needs to be minimized, because of the great pains associated  
with such conflicts. If that means that we're sometimes giving away a  
port to an application that doesn't have an archival (or maybe even a  
stable) spec, that's OK with me. (As long as its a single port and  
there aren't too many of those cases.)

Lars

---

From: Joe Touch <[email-masked]>
Date: Thu, 27 Mar 2008 09:14:28 -0700

Hi, Lars,

I think we're on the same page, the question is in the details...

> language or not is orthogonal to this discussion, and I don't feel 

Others should probably weigh-in...

>>> "if IANA can't reach you for a long time, your port may be reclaimed"),
>>

This is why whether it's a "must" to register does not imply it's a 
"must" or a "MUST" in the table, IMO. The distinction may be subtle, but 
I think it's worth noting that the entries in the table are NOT ensured 
to be up-to-date, and thus that having email fail isn't necessarily a 
reason to remove an entry. If it's a must/MUST, then IANA *must* remove 
entries when the email fails - e.g., periodically checking them yearly 
or so. I don't think that is necessary, esp. since most of the entries 
don't have emails anyway (legacy).

> I don't know and I don't think we need to precisely define this; it may 
> be sufficient for the document to say "provide a contact email address 
> that you don't expect to change in the future."

That language is fine, but that also implies (to me) that the doc 
doesn't need stronger language for such entries.

> I know, but requiring something that is stable is a significantly higher 
> bar than what is current practice. We need to find a sweet spot between 
> making it easy to register a port and having enough information 
> available to the expert reviewer and after that in the registry.

Agreed. However, remember that these port numbers are a public resource. 
If you want truly private numbers, you can arrange them in other ways 
out of other parts of the namespace. IMO, requesting a public resource 
requires public disclosure.

>> Published papers, publicly available tech reports, etc. also suffice. 
>> I don't expect an RFC is required, just that an archival reference is.
> 
> That's significantly more involved than current IANA practice, and it's 
> not practical. Application developers don't publish papers. As far as I 
> know, oftentimes the only information that is available about a port use 
> is what is entered into the web form on the IANA site.

App developers can publish informational RFCs if they want. Again, the 
hurdle for requesting a public resource is public disclosure. If people 
are requesting ports for truly private reasons, then they ought not play 
in the "well-known" portion of the namespace, IMO.

> stable) spec, that's OK with me. (As long as its a single port and there 
> aren't too many of those cases.)

See above; right now, the requirement is disclosure of enough info for 
IANA review. We could require an archival doc OR that the IANA-use 
documentation be accessible for public access (i.e., effectively making 
the application materials the archival doc).

Joe