Re: draft-ietf-tsvwg-iana-ports-09: How we have resolved WG last call comments

["t.petch" <[e-mail]>]

Some possible, insubstantial corrections.

 The UDP-Lite specification [RFC5237] says: "UDP-Lite
**RFC3828 I think

   Furthermore, "Assigned Numbers" is now obsolete [RFC3232]
** I still see it as INFORMATIONAL - should we obsolete it? or do you mean that
RFC3232 obsoleted RFC1700?

HYPHEN  = %x2d              ; "-"
**%x2D would be consistent with the other statements

separating protocol variants based on security capabilities (e.g., HTTP on TCP
port 80 vs. HTTPS on TCP port 443) is not recommended for new protocols
** NOT RECOMMENDED ??

and MUST accompanied by a statement
** //be/ ??

Yes, I have read it:-)

Tom Petch

----- Original Message -----
From: "Magnus Westerlund" <[e-mail]>
To: "tsvwg" <[e-mail]>; "Paul Hoffman" <[e-mail]>; "Eliot
Lear" <[e-mail]>; "t.petch" <[e-mail]>
Sent: Thursday, December 02, 2010 1:42 PM
Subject: draft-ietf-tsvwg-iana-ports-09: How we have resolved WG last call
comments


> Hi,
>
> A new version has been submitted that intends to address all the issues
> we have consensus on addressing. I have attempted to list all the
> individual comments here and their resolution as I view them.
>
> New draft version:
> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-iana-ports-09.txt
>
> Diff from previous version.
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-iana-ports-09
>
> In addition to the below issues raised, the authors has done some
> editorial fixes to improve the language.
>
> Paul Hoffman's comments on 22 Nov
> ---------------------------------
>
> 1. Proposal to make the system port range equal to the registered range.
>
> Outcome: No clear consensus on making the change. There was some support
> for this change. But also push back on doing the change. The push back
> can be summarized as: Agreement that in theory there should be no
> differences, however in reality there are a number of implementations,
> mostly UNIX dialects that do make a difference. Thus there is anyway
> need to differentiate the system ports range from the regular. This
> document isn't the one to make a statement that systems should be
> implemented without any real difference between the ranges.
>
> I hope this issue is closed, but I recognize that the all has not been
> given sufficient time to respond to it. If the outcome changes a new
> version will be submitted.
>
> 2. References with URLs that point to pearl script for the forms.
>
> Outcome: Removed the explicit URLs, now only pointing to IANA.
>
> 3. Concern over the few WG last call reviews.
>
> Outcome: Noted, and agree that more reviews are desirable. It is clear
> that at least 2 has done a review beyond the author team. The number of
> different people engaging in discussion issues has been more than 10.
>
> Paul Hoffman's comments around security on the 4th of Nov
> ---------------------------------------------------------
>
> Summary of concern: Strong recommendations for only using one port, this
> has security impact on protocols that needs to run both with and without
> TLS.
>
> Outcome: Major discussion including people from the TLS WG mailing list.
> Views on the issue was diverse. In the end only minor changes had
> consensus along the lines:  The policy is to try to conserve port space
> as much as possible, it is not impossible to get a second port for TLS
> usage. However, you need to convince the expert review team that you
> have a real problem otherwise.
>
> The draft has been changed in the following way:
> - Changed the policy description so it uses "strive" to make it clear
> that it is an strong goal not a unbudging requirement.
> - Changed the introductory wording in Section 7.2 to make it clear that
> there are room for discussion.
>
>
> Tom Petch's comment on the 3 of Nov
> -----------------------------------
>
> Mixed usage of assignment, allocation and registration.
>
> Outcome: Fixed in new draft, using assignment.
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------