Subject: [port-srv-reg] Comments on svn r32

From: Magnus Westerlund <[email-masked]>
Date: Wed, 25 Nov 2009 13:57:04 +0100

Hi,

I have the following comments. I will start edit on some of them, but I
do think we need answers on some before knowing how to edit.

1. Shouldn't the document update RFC 4960 also? It does update the SCTP
port registration procedures.

2. Based on the discussion in Hiroshima. Are we still going to update
RFC 2782 (SRV records) I thought this is going to be Olafur's documents
job to tie things together for SRV records.

3. Second to last paragraph in section 1 needs update to discuss SCTP.

4. Last paragraph in Section 1 will need update to correctly address the
slit with SRV definition.

5. Should this spec update the UDP-Lite spec also?

6. Remove section 5.1

7. References to the transport protocols at their first occurance.

8. Section 7.2: Shouldn't service name comes before port numbers? Need
initial paragraph about service names and their policy prior to all the
port stuff.

9. End of section needs a statement of intention that at the point there
are no unassigned ports left reserved ones may be handed out. This to
make it clear why you can't assume that another protocol will also be
available.

10. Section 8.1, the explanation of what the administrative contact is
missing.

11. Section 10. Are really this document deprecating the Protocol and
Service Names registry? I thought Olafur and Alfred was going to do
that? Remove that sentence? We have nothing in this document that
motivates this and concerns with the other usage of that registry.

12. Section 10, should the entries incorporated from the Protocol and
Service registries be noted as such in the Notes field?

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: Alexey Melnikov <[email-masked]>
Date: Wed, 25 Nov 2009 13:19:09 +0000

Hi Magnus,

Magnus Westerlund wrote:

>RFC 2782 (SRV records)
Yes, because you are unifying the two registries. People defining new 
SRV service names need to know which registry to use, so "Updates" is 
how they can find this out.

>I thought this is going to be Olafur's documents
Alfred's/Olafur's document might be updating RFC 2782 as well.
 [...]

>Service Names registry?
Do you mean <http://www.iana.org/assignments/service-names>?
If yes, then I agree that this is for Olafur and Alfred to sort out.

>I thought Olafur and Alfred was going to do
Sure, why not.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 25 Nov 2009 14:53:02 +0100

> port registration procedures.

I think so and have edited the document to do so.

> job to tie things together for SRV records.

I have started changing so that the actual utiliation of the service
name registry in SRV is defined by Olafurs document. Need title and
draft name to be able to do informational reference.

> 3. Second to last paragraph in section 1 needs update to discuss SCTP.

Fixed

> split with SRV definition.

Fixed

> 5. Should this spec update the UDP-Lite spec also?

I think so and have therefore introduced a paragraph to motivate that:

      The Lightweight User Datagram Protocol (UDP-Lite) [RFC3828]
      shares the port space with UDP. The UDP-Lite specification says:
      "UDP-Lite uses the same set of port number values assigned by the
      IANA for use by UDP".  Thus the update of UDP procedures result in
      an update also of the UDP-Lite procedures.

> 6. Remove section 5.1

Done

> 7. References to the transport protocols at their first occurance.

The first occurance they actually including references. So please ignore.

> initial paragraph about service names and their policy prior to all the

Have added the service name policy in its own paragraph directly after
first paragraph. Also makes it clear on the policy for port allocations
before giving all motivations.

> make it clear why you can't assume that another protocol will also be

Paragraph added, please review.

> 10. Section 8.1, the explanation of what the administrative contact is

Added a sentence.

> motivates this and concerns with the other usage of that registry.

removed the sentence on retiring the registry.

> Service registries be noted as such in the Notes field?

My thoughts is that if we ignore Alfreds view and simply does a complete
registrations, we should have some motivation why protocols ends up in
the registry. If we update this sentence to be more explicit about which
entries that are to be incorporated then it would be a difference.

When editing the XML I did notice the comments. I think that a lot of
the motivations can be removed, but it is important to make clear which
entries that was modified by the approval of this doc.

I have committed the modified version (r33).

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 26 Nov 2009 09:33:56 +0100

Hi,

Olafur, needs your input into this.

> how they can find this out.

I am kind of split here. If Olafurs document is the one that updates
RFC 2782 and says that DNS SRV shall use the name space defined in
draft-ietf-tsvwg-iana-ports then that works also.

I don't know what to write in registry document that makes it an update
of DNS SRV and still not addresses all the service name questions.

Olafur, what is the intended content in your document?

Cheers

Magnus Westerlund

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 26 Nov 2009 20:46:27 -0800

> Olafur, what is the intended content in your document?

Personally, I think it would be a good idea to unify the two documents.

Olafur and I have discussed his document, and have come to agreement  
on the things that were previous contentious, like some service names  
having the initial underscore and others not, and the 15-character  
limit. Once you take those things away, what's left is the  
specification of how to use service names in the contest of SRV  
records, which adds at most a page or two to our current draft. I  
think that's preferable to having an entirely separate document for it.

If others agree, I can take a crack at merging in the relevant text.

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* Internet Architecture Board
* www.stuartcheshire.org

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 27 Nov 2009 09:28:07 +0100

Hi,

I am kind of split on this. It is good to merge the text in as it makes
for a more contained solution and less back and forth pointers for SRV.
At the same time it adds text to the registry document on how it is
being used which can skew people view on the service registry.

Can you and Olafur get text together on this quickly it would be great.
I think we can't go forward without having the text for updating the SRV
reference anyway. I need that text to judge if what we have in the
registry doc is good or not.

/Magnus

Stuart Cheshire skrev:
> Olafur and I have discussed his document, and have come to agreement on
> the things that were previous contentious, like some service names
> limit. Once you take those things away, what's left is the specification
> of how to use service names in the contest of SRV records, which adds at
> most a page or two to our current draft. I think that's preferable to
> having an entirely separate document for it.
> 

-- 

Magnus Westerlund

---

From: Joe Touch <[email-masked]>
Date: Fri, 27 Nov 2009 09:02:45 -0800

> having an entirely separate document for it.

What specifically is needed that isn't already in RFC 2782?

As I noted, I have discussed this with Paul Vixie, and the intent of the
restrictive language in 2782 was to ensure that protocols that *require*
the use of SRVs for discovery so specify that explicitly, but not to
prevent the use of SRVs as optional.

Do we need to alter that requirement?

I agree that it might be useful to remind people that these names can be
used for SRVs, but unless we're actually changing a requirement in 2782
we aren't updating it and don't need more than a single sentence.

Joe

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 27 Nov 2009 17:33:44 +0000

Joe Touch wrote:
 [...]

>Do we need to alter that requirement?
RFC 2782 didn't establish an IANA registry for SRV service names, we 
want to update it to say that this registry is now the registry define 
by draft-ietf-tsvwg-iana-ports. This is updating RFC 2782, even if we 
are not updating the protocol bits.

---

From: Joe Touch <[email-masked]>
Date: Fri, 27 Nov 2009 10:04:30 -0800

> are not updating the protocol bits.

Sure - that's a single sentence, though.

Joe

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 27 Nov 2009 18:23:32 +0000

>Sure - that's a single sentence, though.
You might be right.

Stuart, if you propose the new text, it might be easier to agree what 
belongs to draft-ietf-tsvwg-iana-ports.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 30 Nov 2009 09:38:53 +0100

Hi,

My question to you and Olafur, is what more than was in the previous
version is really needed?

5.1.  Service Name Usage in DNS SRV Records

   [RFC2782] defines SRV records for the DNS system.  One part of the
   DNS name of an SRV record includes what is called "SERVICE", i.e., a
   symbolic name for the service.  This document updates [RFC2782] in
   order to clarify that the symbolic name ("SERVICE") SHALL only be a
   service name as defined in this document that has been registered
   with IANA and recorded in the port number and service name registry
   [PORTREG].  This to ensure that only a single registry exist and name
   collisions can be more easily avoided in the future.

/Magnus

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

-- 

Magnus Westerlund

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 30 Nov 2009 11:41:51 +0000

>   collisions can be more easily avoided in the future.
I think this should be left as is.

-- 
IETF Application Area Director, <http://www.ietf.org/IESGmems.html>
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 30 Nov 2009 13:28:49 +0100

> I think this should be left as is.

That is clearly possible, but what we are discussing is tearing up the
agreement from Hiroshima. I do want Olafurs input on this.

Cheers

Magnus Westerlund

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 30 Nov 2009 13:58:16 +0000

>agreement from Hiroshima. I do want Olafurs input on this.
Sure.
I just disagree that this is changing the Hiroshima agreement.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 30 Nov 2009 15:02:50 +0100

> I just disagree that this is changing the Hiroshima agreement.

Well, then I am clearly missing details on what Olafur's document is to
contain. I understood that it was that documents role to clarify SVN
records. I just want to understand what should be in our document and
that people agree that.

Cheers

Magnus Westerlund

---

From: Joe Touch <[email-masked]>
Date: Mon, 30 Nov 2009 08:14:14 -0800

> records. I just want to understand what should be in our document and

I thought there were several things, which can be grouped for the
purposes of discussion into two categories:

1) asserting that the new service names directory entries can be used in
SRV records

	IMO, 2782 already permits the use of /etc/services names,
	and allows for new names to be defined (but doesn't say where
	or how)

	Stuart's directory addresses the latter issue (new names)

The new statement would just be that the unified list would be
applicable to SRV records, which seems consistent with other statements
about how this document affects other separately-defined registries.
It's also basically what the doc already contains.

2) changes to how the SRV names are used/specified (the underscore part,
etc.)

I didn't think there was consensus to change the syntax of SRV names in
our doc. IMO, that proposal would need to be taken separately to the DNS
groups.

Joe