subject:"Last Call\: draft\-ietf\-tsvwg\-iana\-ports\-09.txt \(Internet Assigned Numbers Authority \(IANA\) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry\) to BCP"

On Tue, Feb 1, 2011 at 8:38 AM,  ned+i...@mauve.mrochek.com wrote:
 +1 to everything Magnus says here. THis is exactly how I view the multiple 
 port
 issue.

I'll respond to this separately.


 I will also add that at least part of this fuss seems to be concern about how
 human oversight is needed but what if the overseer misbehaves issue. 
 Speaking
 as someone who has been doing IANA reviews for well over a decade, it is
 absolutely the case that a reviwer's actions can screw up a registry. But the
 solution to this problem is not to overconstrain the review process - we've
 tried that approach and found it causes more problems than it solves - but
 rather to have proper checks and balances in the process itself. I believe the
 current specified process - once you understand the details, which
 unfortunately are a bit difficult to track through all the various
 specifications - is sufficient to deal with this.

Others may have that concern but it's not my concern.

My concern is rather that the reviewer get the correct guidance, and
in this case
that guidance appears to be that he ought to be pushing back on protocols which
desire to use one port for the insecure version and one port for the
secure version,
and I'm not really that comfortable with that.

-Ekr


                                Ned

 Cullen Jennings skrev 2011-01-31 18:44:
 
  Magnus, I agree with what you are saying here but you are avoiding the 
  issue I am concerned with. Is allocating a second port for the secure 
  version of a document a frivolous use case or not? I read this draft as 
  saying it is. Others read the draft as saying it is not and that type of 
  allocation is fine. This seems fairly easy to deal with - first lets agree 
  if particular 2nd port for secure version is a reason to reject requests 
  or not then see if any text needs to be adjusted in the draft to reflect 
  that.

 Well, frankly I don't know. I think it is something that can be avoided
 going forward in many use cases, but not all. Simply by thinking of this
 issue in the design phase. In addition there is clearly other solutions
 there other considerations, like NAT traversal has said, yes
 multiplexing is a must, thus live with even higher complexity costs.

 The issue I have a problem with is that is we say on general basis that
 due to negotiation of security protocols we are allowed to use different
 ports for negotiation or simply usage of it. Then why is that different
 from different versions of the protocol, or feature support. What is the
 difference for a security protocol compared to these other issues?

 What I am worried here is that we will see an increased port consumption
 rather than a decreased one. At the current run rate I think the
 estimate is 50 years+ before run out. That is something that I am
 reasonably comfortable, but if the consumption rate increases four
 times, then I am suddenly not comfortable. So I am pretty certain that
 we need to aim at lowering the consumption rather than raising it.

 As I see it there are only one way of doing it.

 - State clearly that you really need to do everything reasonable so that
 your application is only for one port.
 - Be reasonably tough from the expert reviewer to ensure that applicants
 has done this.

 And from that perspective I don't think security is special in anyway.
 It is only one of several things that could potentially require
 additional registered ports. Yes security is important, but as
 previously discussed it doesn't appear that the actual level of security
 provided is different if you are forced to use one port or two. It might
 affect the ease of implementation and deployment of security, which is
 another aspect of impact.


 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: magnus.westerl...@ericsson.com
 --
 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf
 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

2011-02-01 Thread Paul Hoffman


On 2/1/11 2:14 AM, Magnus Westerlund wrote:

Cullen Jennings skrev 2011-01-31 18:44:


Magnus, I agree with what you are saying here but you are avoiding the issue I 
am concerned with. Is allocating a second port for the secure version of a 
document a frivolous use case or not? I read this draft as saying it is. Others 
read the draft as saying it is not and that type of allocation is fine. This 
seems fairly easy to deal with - first lets agree if particular 2nd port for 
secure version is a reason to reject requests or not then see if any text needs 
to be adjusted in the draft to reflect that.


Well, frankly I don't know. I think it is something that can be avoided
going forward in many use cases, but not all. Simply by thinking of this
issue in the design phase. In addition there is clearly other solutions
there other considerations, like NAT traversal has said, yes
multiplexing is a must, thus live with even higher complexity costs.

The issue I have a problem with is that is we say on general basis that
due to negotiation of security protocols we are allowed to use different
ports for negotiation or simply usage of it. Then why is that different
from different versions of the protocol, or feature support. What is the
difference for a security protocol compared to these other issues?


As has been said many times before: downgrade attacks and essentially 
different transport. Each of those has very serious consequences, the 
first for the security of the communication, the second for the design 
of the underlying protocol.



What I am worried here is that we will see an increased port consumption
rather than a decreased one. At the current run rate I think the
estimate is 50 years+ before run out. That is something that I am
reasonably comfortable, but if the consumption rate increases four
times, then I am suddenly not comfortable. So I am pretty certain that
we need to aim at lowering the consumption rather than raising it.


No one is suggesting raising the consumption rate.


As I see it there are only one way of doing it.

- State clearly that you really need to do everything reasonable so that
your application is only for one port.
- Be reasonably tough from the expert reviewer to ensure that applicants
has done this.


At least one other way was proposed in the TSVWG, but did not get anywhere.


And from that perspective I don't think security is special in anyway.
It is only one of several things that could potentially require
additional registered ports. Yes security is important, but as
previously discussed it doesn't appear that the actual level of security
provided is different if you are forced to use one port or two. It might
affect the ease of implementation and deployment of security, which is
another aspect of impact.


Some people say it doesn't appear that the actual level of security 
provided is different if you are forced to use one port or two and 
others disagree.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

2011-02-01 Thread Cullen Jennings


So to summarize what you are saying, ports are allocated based on an arbitrary 
view of the expert review. When this person will say yes or no too can't be 
described and will change over time. 

If that's how it works, there is not even any grounds for appeal of any given 
decision. You can't even use precedence as an argument. My view was the IESG 
has been trying to move to having much more concrete advice for registries that 
required expert review. If you agree that is about the right summary, then I'm 
pretty sure I can find plenty of other people that would agree with me that 
this is not OK. I'm not a fan of the WG could not get consensus on if we should 
allow A or not so we are just going to let the expert review do whatever they 
want. If the IETF could not come to consensus on if X  or Y were reasons to 
deny a registration, then I don't think the expert review should be able to 
deny a registration due to X or Y. 



On Jan 31, 2011, at 8:06 , Magnus Westerlund wrote:

 Cullen Jennings skrev 2011-01-30 05:56:
 
  I read the draft to say that there would only be one port allocated - I 
  took strive to mean that Joe would deny my port requests for two ports. If 
  the intention is actually for the draft to say that it strives for one port 
  but allows assignment of two where the that is what the protocol design 
  desire, then I have no problem. Perhaps we just need to clarify what 
  strive means. This definition of strive leads into exactly my other 
  complain that this draft provides no guidance on what the expert will or 
  will not approve.
 
  We probably need to adjust text like
 
  o  IANA strives to encourage the deployment of secure protocols, and
   so strives to avoid separate assignments for non-secure variants
 
  and
 
   The use of separate
service name or port number assignments for secure and insecure
variants of the same service is to be avoided in order to discourage
the deployment of insecure services.
 
  and
 
   Services are expected to include support for security, either as
default or dynamically negotiated in-band.
 
 
  In band negotiation of security is applicable for some cases, but it adds 
  latency, bandwidth, and complicated multiplexing in non session based 
  transports. I think this is a bad idea in many cases. I also view 
  separation even for stream based protocols as something that helps 
  management and debugging as well as policy.
 
 
 Well, the high level goal is to preserve a limited resource. We can't do
 that without making the preference clear. But I think you have forgotten
 to consider those statements trying to make clear that this is up to
 review.
 
 The review criterias can be expected to change overtime. They are also
 hard to codify. Especially for this case, how do we measure
 architectural uncleanness, implementation issues, and performance impact
 to make a rule that judges if one or more port is allowed?




___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

2011-02-01 Thread Cullen Jennings


inline 

On Feb 1, 2011, at 5:14 , Magnus Westerlund wrote:

 Cullen Jennings skrev 2011-01-31 18:44:
 
  Magnus, I agree with what you are saying here but you are avoiding the 
  issue I am concerned with. Is allocating a second port for the secure 
  version of a document a frivolous use case or not? I read this draft as 
  saying it is. Others read the draft as saying it is not and that type of 
  allocation is fine. This seems fairly easy to deal with - first lets agree 
  if particular 2nd port for secure version is a reason to reject requests or 
  not then see if any text needs to be adjusted in the draft to reflect that.
 
 Well, frankly I don't know. I think it is something that can be avoided
 going forward in many use cases, but not all. Simply by thinking of this
 issue in the design phase. In addition there is clearly other solutions
 there other considerations, like NAT traversal has said, yes
 multiplexing is a must, thus live with even higher complexity costs.
 
 The issue I have a problem with is that is we say on general basis that
 due to negotiation of security protocols we are allowed to use different
 ports for negotiation or simply usage of it. Then why is that different
 from different versions of the protocol, or feature support. What is the
 difference for a security protocol compared to these other issues?

I've provided reason why I think this is needed for security in previous email 
on this thread. I'm not arguing you need more ports for versions or feature 
support - I don't think you do.

 What I am worried here is that we will see an increased port consumption
 rather than a decreased one. At the current run rate I think the
 estimate is 50 years+ before run out. That is something that I am
 reasonably comfortable, but if the consumption rate increases four
 times, then I am suddenly not comfortable. So I am pretty certain that
 we need to aim at lowering the consumption rather than raising it.
 

I'm far more worried about people just using ports without registering them 
than I am about running out. Keep in mind the allocation policy is more or less 
anyone can get one port for just about anything so if we are really worried 
about running out, we would change that. Most protocols will not need or 
request two ports.

 As I see it there are only one way of doing it.
 
 - State clearly that you really need to do everything reasonable so that
 your application is only for one port.

Reasonable here is the problem. I don't want the expert review to tell me a 
second port for security is not reasonable for cases where latency is a 
relevant. 

 - Be reasonably tough from the expert reviewer to ensure that applicants
 has done this.

Again - I want to be able to register ports for proprietary protocols without 
disclosing the details of the proprietary algorithm

 
 And from that perspective I don't think security is special in anyway.

 It is only one of several things that could potentially require
 additional registered ports. Yes security is important, but as
 previously discussed it doesn't appear that the actual level of security
 provided is different if you are forced to use one port or two. It might
 affect the ease of implementation and deployment of security, which is
 another aspect of impact.

It's not just an ease of anything - it's the real time performance of the 
resulting system that is an issue. 

 
 
 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: magnus.westerl...@ericsson.com
 --
 


Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

To clarify some of this discussion, providing some context that might be 
useful:


1) the current doc already explicitly states the procedures for 
assignment in each range of ports (see Sec 8.1.1).


2) Sec 8.1.1 *already* states that IESG approval through IETF process is 
a valid path for assignment, distinct from Expert Review. Since that 
appears to be a point of confusion, I'll quote it directly:


   o  Ports in the User Ports range (1024-49151) are available for
  assignment through IANA, and MAY be used as service identifiers
  upon successful assignment.  Because assigning a port number for a
  specific application consumes a fraction of the shared resource
  that is the port number registry, IANA will require the requester
  to document the intended use of the port number.  This
  documentation will be input to the Expert Review procedure
  [RFC5226], by which IANA will have a technical expert review the
  request to determine whether to grant the assignment.  The
  submitted documentation MUST explain why using a port number in
  the Dynamic Ports range is unsuitable for the given application.
  Ports in the User Ports range may also be assigned under the IETF
  ^^
  Review or IESG Approval procedures [RFC5226], which is how most
  ^^
  assignments for IETF protocols are handled.
  ^^^

   o  Ports in the System Ports range (0-1023) are also available for
  assignment through IANA.  Because the System Ports range is both
  the smallest and the most densely allocated, the requirements for
  new assignments are more strict than those for the User Ports
  range, and will only be granted under the IETF Review or IESG
 ^
  Approval procedures [RFC5226].  A request for a System Port
  ^
  number MUST document *both* why using a port number from the
  Dynamic Ports range is unsuitable *and* why using a port number
  from the User Ports range is unsuitable for that application.

3) section 7 has NOTHING TO DO with the procedures this document 
updates. That section has plenty of words to avoid any such impression. 
And no, we don't need to define strives, IMO - since NOTHING IN THAT 
SECTION IS BINDING.


Again, since this is a persistent cause of confusion, I quote from that 
section:


   This section summarizes the current principles by which IANA handles
   the Service Name and Transport Protocol Port Number Registry and
   attempts to conserve the port number space.  This description is
   intended to inform applicants requesting service names and port
   numbers.  IANA has flexibility beyond these principles when handling
 ^^
   assignment requests; other factors may come into play, and exceptions
   ^
  **
   may be made to best serve the needs of the Internet.
   
   ***

If you need more explicit words, the term non-binding can be added.

---

There's a doc I drafted in TSVWG which is a more appropriate venue to 
discuss this issue (draft-touch-tsvwg-port-use0. I encourage those 
interested in these issues to continue discussion on that list, not on 
this general list.


For this document, if this section is causing confusion, it should be 
removed, since it is already included in this other doc and can be 
vetted there.


Joe
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP




On 2/1/2011 9:19 AM, Cullen Jennings wrote:


So to summarize what you are saying, ports are allocated based on an
arbitrary view of the expert review. When this person will say yes or no
too can't be described and will change over time.


See my other post. Section 8.1.1 already states that there are other 
means besides expert review.



If that's how it works, there is not even any grounds for appeal of
any given decision.


The grounds are disagree with the advice of the Expert Review. The 
IESG can overturn those decisions on that basis alone. They can - and 
have - held up decisions that have come from community consensus as 
well. I.e., this is no different from other appeals process. It is based 
on the strength of the argument.


From your earlier post:


I put in a request for a latency sensitive protocol that uses DTLS
and request a different port for the secure version. Joe as expert
review says we should redesign the protocol to use something like
STARTLS and run on one port. I assert, with very little evidence,

   
 **

that will not meet the latency goals of the protocol. Joe does not
agree.


The burden of proof, especially when asking for multiple ports, ought to 
be on the applicant. very little evidence is the issue, and if that 
didn't convince me, then there's an appeals process listed in RFC 5226 
which you could have used to take that very little evidence to 
convince the IESG to overturn the decision.


Joe


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

On Tue, Feb 1, 2011 at 9:39 AM, Joe Touch to...@isi.edu wrote:
 To clarify some of this discussion, providing some context that might be
 useful:

 1) the current doc already explicitly states the procedures for assignment
 in each range of ports (see Sec 8.1.1).

 2) Sec 8.1.1 *already* states that IESG approval through IETF process is a
 valid path for assignment, distinct from Expert Review. Since that appears
 to be a point of confusion, I'll quote it directly:

   o  Ports in the User Ports range (1024-49151) are available for
      assignment through IANA, and MAY be used as service identifiers
      upon successful assignment.  Because assigning a port number for a
      specific application consumes a fraction of the shared resource
      that is the port number registry, IANA will require the requester
      to document the intended use of the port number.  This
      documentation will be input to the Expert Review procedure
      [RFC5226], by which IANA will have a technical expert review the
      request to determine whether to grant the assignment.  The
      submitted documentation MUST explain why using a port number in
      the Dynamic Ports range is unsuitable for the given application.
      Ports in the User Ports range may also be assigned under the IETF
      ^^
      Review or IESG Approval procedures [RFC5226], which is how most
      ^^
      assignments for IETF protocols are handled.
      ^^^

For the purposes of clarification, then, this document has no impact whatsoever
on ports assigned through the IESG process? I.e., if my WG submits a proposed
standard document to the IESG and it asks for two ports, I'm not going to get
pushback based on the claim that this document imposes a presumption that
that's wrong?

-Ekr
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP




On 2/1/2011 10:00 AM, Eric Rescorla wrote:

On Tue, Feb 1, 2011 at 9:39 AM, Joe Touchto...@isi.edu  wrote:

To clarify some of this discussion, providing some context that might be
useful:

1) the current doc already explicitly states the procedures for assignment
in each range of ports (see Sec 8.1.1).

2) Sec 8.1.1 *already* states that IESG approval through IETF process is a
valid path for assignment, distinct from Expert Review. Since that appears
to be a point of confusion, I'll quote it directly:

   o  Ports in the User Ports range (1024-49151) are available for
  assignment through IANA, and MAY be used as service identifiers
  upon successful assignment.  Because assigning a port number for a
  specific application consumes a fraction of the shared resource
  that is the port number registry, IANA will require the requester
  to document the intended use of the port number.  This
  documentation will be input to the Expert Review procedure
  [RFC5226], by which IANA will have a technical expert review the
  request to determine whether to grant the assignment.  The
  submitted documentation MUST explain why using a port number in
  the Dynamic Ports range is unsuitable for the given application.
  Ports in the User Ports range may also be assigned under the IETF
  ^^
  Review or IESG Approval procedures [RFC5226], which is how most
  ^^
  assignments for IETF protocols are handled.
  ^^^


For the purposes of clarification, then, this document has no impact whatsoever
on ports assigned through the IESG process? I.e., if my WG submits a proposed
standard document to the IESG and it asks for two ports, I'm not going to get
pushback based on the claim that this document imposes a presumption that
that's wrong?


The ONLY impact is in the format of information required for an assignment.

(i.e., yes, if you're asking that there's no change to the process, 
that's correct)


However, IANA can still pushback, and can use whatever advice it sees 
fit to do so, during IESG review. You can get that pushback now. This 
document doesn't change that AT ALL.


Joe
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

On Tue, Feb 1, 2011 at 10:26 AM, Joe Touch to...@isi.edu wrote:


 On 2/1/2011 10:00 AM, Eric Rescorla wrote:

 On Tue, Feb 1, 2011 at 9:39 AM, Joe Touchto...@isi.edu  wrote:

 To clarify some of this discussion, providing some context that might be
 useful:

 1) the current doc already explicitly states the procedures for
 assignment
 in each range of ports (see Sec 8.1.1).

 2) Sec 8.1.1 *already* states that IESG approval through IETF process is
 a
 valid path for assignment, distinct from Expert Review. Since that
 appears
 to be a point of confusion, I'll quote it directly:

   o  Ports in the User Ports range (1024-49151) are available for
      assignment through IANA, and MAY be used as service identifiers
      upon successful assignment.  Because assigning a port number for a
      specific application consumes a fraction of the shared resource
      that is the port number registry, IANA will require the requester
      to document the intended use of the port number.  This
      documentation will be input to the Expert Review procedure
      [RFC5226], by which IANA will have a technical expert review the
      request to determine whether to grant the assignment.  The
      submitted documentation MUST explain why using a port number in
      the Dynamic Ports range is unsuitable for the given application.
      Ports in the User Ports range may also be assigned under the IETF
      ^^
      Review or IESG Approval procedures [RFC5226], which is how most
      ^^
      assignments for IETF protocols are handled.
      ^^^

 For the purposes of clarification, then, this document has no impact
 whatsoever
 on ports assigned through the IESG process? I.e., if my WG submits a
 proposed
 standard document to the IESG and it asks for two ports, I'm not going to
 get
 pushback based on the claim that this document imposes a presumption that
 that's wrong?

 The ONLY impact is in the format of information required for an assignment.

 (i.e., yes, if you're asking that there's no change to the process, that's
 correct)

 However, IANA can still pushback, and can use whatever advice it sees fit to
 do so, during IESG review. You can get that pushback now. This document
 doesn't change that AT ALL.

I'm sorry, but I'm still not clear.

This document has an affirmative statement against the use of multiple
ports for TLS.

AFAIK that statement is not part of present written policy. Is that correct?

-Ekr
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP




On 2/1/2011 10:29 AM, Eric Rescorla wrote:
...

I'm sorry, but I'm still not clear.

This document has an affirmative statement against the use of multiple
ports for TLS.


I'm sorry, but it does not.

I states a goal, and a preference, and has plenty of wiggle room as I've 
repeatedly quoted, and will quote again here:


   This section summarizes the current principles by which IANA handles
   the Service Name and Transport Protocol Port Number Registry and
   attempts to conserve the port number space.  This description is
   intended to inform applicants requesting service names and port
   numbers.  IANA has flexibility beyond these principles when handling
   assignment requests; other factors may come into play, and exceptions
   may be made to best serve the needs of the Internet.


AFAIK that statement is not part of present written policy. Is that correct?


See the word above principles. That isn't policy.

IANA isn't bound by it (see the last sentence). The Expert Review team 
is not bound by any written policy - RFC 5226 does not require that we 
have one, and we don't.


Joe
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

2011-02-01 Thread Eliot Lear

I'll add my +1 to Ned's comments in a slightly different way.  As
someone who is a reviewer, I think we all owe a big debt to Joe Touch
and Pearl Liang for guiding applicants and reviewers through the process
(even if the applicants don't know it).

Eliot

On 2/1/11 5:38 PM, Ned Freed wrote:
 +1 to everything Magnus says here. THis is exactly how I view the multiple 
 port
 issue.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

2011-02-01 Thread Sam Hartman

 Joe == Joe Touch to...@isi.edu writes:

Joe On 1/27/2011 12:52 AM, Lars Eggert wrote:
Joe ...
 Small Issue #3: I object to anonymous review
 
 The current review is anonymous and this draft does not seem to
 change that. I don't like anonymous review - it's not how we do
 things at IETF and it encourages really bad behavior. I have
 several emails with an expert reviewer relayed via IANA where
 the conversation was going no where - once I knew the name of
 the reviewer, the whole conversation changed and stuff quickly
 came back to the realm of sane. I'm not willing to forward these
 emails to the list as that would just not be kind to anyone but
 I am happy to forward them to the IESG if they think looking at
 them is really critical.
 
 I can see your point, and I personally have no problem with
 disclosing the reviewer identity. What do others think?

Joe AFAICT, the experts team reports to IANA. We make
Joe recommendations to them. They are the ones who have the
Joe conversation with the applicant. They can take our advice or
Joe not - that's their decision.

Joe, the IESG had a fair amount of negative experience with this style
of review just before  I joined; this type of review was just about out
of the process leading to blocking objections when I joined as an AD.

I think that being able to discuss concerns with reviewers and being
able to consider potential conflicts and other issues mean that an open
dialogue with identified reviewers is an important part of our
process. Anonymous contributions may have their place in the WG process,
but I don't think they should have a place in expert review oor blocking
objections to documents.  So, as an individual I strongly support making
expert reviewers identities public.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP




On 2/1/2011 11:14 AM, Sam Hartman wrote:
...

Joe, the IESG had a fair amount of negative experience with this style
of review just before  I joined; this type of review was just about out
of the process leading to blocking objections when I joined as an AD.

I think that being able to discuss concerns with reviewers and being
able to consider potential conflicts and other issues mean that an open
dialogue with identified reviewers is an important part of our
process. Anonymous contributions may have their place in the WG process,
but I don't think they should have a place in expert review oor blocking
objections to documents.  So, as an individual I strongly support making
expert reviewers identities public.


Such reviews occur elsewhere in the IETF as well; it's not a requirement 
that every review include a list of all consulted parties. This is no 
different. IANA is the one making the decision of how to use the advice 
they receive.


I.e., please explain where in RFC 5226 that the process of Expert Review 
is expected to be a dialogue.


I.e., the dialogue is with IANA, not the reviewer.

The point isn't that reviewers MUST be anonymous; many of them do engage 
in direct conversation with the applicant. However, we try to avoid that 
because we want IANA involved in all conversation, and we want IANA to 
approve that conversation as it goes along. So, ultimately, the 
discussion is really, IMO, with IANA, not the reviewer per se, which is 
why the identity of the reviewer is irrelevant.


Joe
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

2011-02-01 Thread Sam Hartman

 Joe == Joe Touch to...@isi.edu writes:

Joe On 2/1/2011 11:14 AM, Sam Hartman wrote:
Joe ...
 Joe, the IESG had a fair amount of negative experience with this
 style of review just before I joined; this type of review was
 just about out of the process leading to blocking objections when
 I joined as an AD.
 
 I think that being able to discuss concerns with reviewers and
 being able to consider potential conflicts and other issues mean
 that an open dialogue with identified reviewers is an important
 part of our process. Anonymous contributions may have their place
 in the WG process, but I don't think they should have a place in
 expert review oor blocking objections to documents.  So, as an
 individual I strongly support making expert reviewers identities
 public.

Joe Such reviews occur elsewhere in the IETF as well; it's not a
Joe requirement that every review include a list of all consulted
Joe parties. This is no different. IANA is the one making the
Joe decision of how to use the advice they receive.

Joe, RFC 5226 disagrees with you fairly significantly.
I draw your attention in particular to section 3.2, and particularly
call our attention to several points made there:

* The designated expert is responsible for initiating and coordinating
  the review.

* Designated experts are expected to be able to defend their *decisions*
  to the IETf community

* The process is not intended to be secretive

* Experts make a single clear recommendation to IANA

* In cases of deadlock IESG may be pulled in to resolve disputes

* When IANA receives conflicting advice, chair of pool of experts  gives
  clear *instructions* to IANA.
On page 10, the expert review criteria  requires approval of a
  designated expert.

I submit based on the above that the experts rather than IANA are making
the decision; the expert has the responsibility of justifying and
defending their decision. Moreover anonymous expert reviews violate two
BCP requirements: they tend to a secretive process and they do not
facilitate the expert defending their decision to the IETF community.

Having read RFc 5226 my objection to anonymous expert reviews is much
stronger than when I first read Cullen's message.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP




On 2/1/2011 12:12 PM, Sam Hartman wrote:

Joe == Joe Touchto...@isi.edu  writes:


 Joe  On 2/1/2011 11:14 AM, Sam Hartman wrote:
 Joe  ...
   Joe, the IESG had a fair amount of negative experience with this
   style of review just before I joined; this type of review was
   just about out of the process leading to blocking objections when
   I joined as an AD.
 
   I think that being able to discuss concerns with reviewers and
   being able to consider potential conflicts and other issues mean
   that an open dialogue with identified reviewers is an important
   part of our process. Anonymous contributions may have their place
   in the WG process, but I don't think they should have a place in
   expert review oor blocking objections to documents.  So, as an
   individual I strongly support making expert reviewers identities
   public.

 Joe  Such reviews occur elsewhere in the IETF as well; it's not a
 Joe  requirement that every review include a list of all consulted
 Joe  parties. This is no different. IANA is the one making the
 Joe  decision of how to use the advice they receive.

Joe, RFC 5226 disagrees with you fairly significantly.
I draw your attention in particular to section 3.2, and particularly
call our attention to several points made there:

* The designated expert is responsible for initiating and coordinating
   the review.

* Designated experts are expected to be able to defend their *decisions*
   to the IETf community

* The process is not intended to be secretive

* Experts make a single clear recommendation to IANA

* In cases of deadlock IESG may be pulled in to resolve disputes

* When IANA receives conflicting advice, chair of pool of experts  gives
   clear *instructions* to IANA.
On page 10, the expert review criteria  requires approval of a
   designated expert.

I submit based on the above that the experts rather than IANA are making
the decision; the expert has the responsibility of justifying and
defending their decision. Moreover anonymous expert reviews violate two
BCP requirements: they tend to a secretive process and they do not
facilitate the expert defending their decision to the IETF community.

Having read RFc 5226 my objection to anonymous expert reviews is much
stronger than when I first read Cullen's message.


Well, based on the above, the Expert Team has a lot more power than I 
originally thought.  I agree that, given that power, making the reviewer 
known makes sense.


I will let you know that I will recommend to IANA that they should 
include a warning that any communication regarding an application made 
outside of the process (e.g., with IANA in the loop) will likely result 
in an application being rejected on a violation of the above open 
process. That should avoid my concerns about the team being deluged 
out-of-band ;-)


Joe
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

On Tue, Feb 1, 2011 at 2:14 AM, Magnus Westerlund
magnus.westerl...@ericsson.com wrote:
 Cullen Jennings skrev 2011-01-31 18:44:

 Magnus, I agree with what you are saying here but you are avoiding the issue 
 I am concerned with. Is allocating a second port for the secure version of a 
 document a frivolous use case or not? I read this draft as saying it is. 
 Others read the draft as saying it is not and that type of allocation is 
 fine. This seems fairly easy to deal with - first lets agree if particular 
 2nd port for secure version is a reason to reject requests or not then see 
 if any text needs to be adjusted in the draft to reflect that.

 Well, frankly I don't know. I think it is something that can be avoided
 going forward in many use cases, but not all. Simply by thinking of this
 issue in the design phase. In addition there is clearly other solutions
 there other considerations, like NAT traversal has said, yes
 multiplexing is a must, thus live with even higher complexity costs.

 The issue I have a problem with is that is we say on general basis that
 due to negotiation of security protocols we are allowed to use different
 ports for negotiation or simply usage of it. Then why is that different
 from different versions of the protocol, or feature support. What is the
 difference for a security protocol compared to these other issues?

 What I am worried here is that we will see an increased port consumption
 rather than a decreased one. At the current run rate I think the
 estimate is 50 years+ before run out. That is something that I am
 reasonably comfortable, but if the consumption rate increases four
 times, then I am suddenly not comfortable. So I am pretty certain that
 we need to aim at lowering the consumption rather than raising it.

 As I see it there are only one way of doing it.

 - State clearly that you really need to do everything reasonable so that
 your application is only for one port.
 - Be reasonably tough from the expert reviewer to ensure that applicants
 has done this.

 And from that perspective I don't think security is special in anyway.
 It is only one of several things that could potentially require
 additional registered ports. Yes security is important, but as
 previously discussed it doesn't appear that the actual level of security
 provided is different if you are forced to use one port or two. It might
 affect the ease of implementation and deployment of security, which is
 another aspect of impact.


 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: magnus.westerl...@ericsson.com
 --
 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

2011-01-31 Thread Lars Eggert

On 2011-1-30, at 17:12, Paul Hoffman wrote:
 The above emphatic statements means that IANA can reject a request for an 
 IETF-approved protocol that needs two ports without recourse.

I don't follow. Assignments through IETF-stream documents do not go through 
expert review. And I've never witnessed IANA rejecting requests coming through 
the IETF. But even if they did, there is an appeals procedure.

Lars 

smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

2011-01-31 Thread Magnus Westerlund

Cullen Jennings skrev 2011-01-30 05:56:
 
 I read the draft to say that there would only be one port allocated - I took 
 strive to mean that Joe would deny my port requests for two ports. If the 
 intention is actually for the draft to say that it strives for one port but 
 allows assignment of two where the that is what the protocol design desire, 
 then I have no problem. Perhaps we just need to clarify what strive means. 
 This definition of strive leads into exactly my other complain that this 
 draft provides no guidance on what the expert will or will not approve. 
 
 We probably need to adjust text like 
 
 o  IANA strives to encourage the deployment of secure protocols, and
  so strives to avoid separate assignments for non-secure variants
 
 and 
 
  The use of separate
   service name or port number assignments for secure and insecure
   variants of the same service is to be avoided in order to discourage
   the deployment of insecure services.
 
 and 
 
  Services are expected to include support for security, either as
   default or dynamically negotiated in-band.
 
 
 In band negotiation of security is applicable for some cases, but it adds 
 latency, bandwidth, and complicated multiplexing in non session based 
 transports. I think this is a bad idea in many cases. I also view separation 
 even for stream based protocols as something that helps management and 
 debugging as well as policy. 
 

Well, the high level goal is to preserve a limited resource. We can't do
that without making the preference clear. But I think you have forgotten
to consider those statements trying to make clear that this is up to
review.

The review criterias can be expected to change overtime. They are also
hard to codify. Especially for this case, how do we measure
architectural uncleanness, implementation issues, and performance impact
to make a rule that judges if one or more port is allowed?

We clearly can't, this will be up to human judgment.

I also think it is important that we separate the basic registry rules
from the review guidelines, as they will change. Thus this is a separate
document. One that we should make clear is going to exist.

And as pointed out in other parts of this discussion there are several
ways of challenging the reviewers recommendation resulting in an IANA
decision. First of all is the appeal process. Secondly, is to take it
through the IETF approval process where IETF makes the decision, not IANA.

As I see it, we either leave these high level goals in this document, or
we remove the completely and put everything in a separate document.

I rather leave them in, because I don't seem them changing. Only be
acted up in varying ways over the coming years.

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: magnus.westerl...@ericsson.com
--
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

2011-01-31 Thread Paul Hoffman


On 1/31/11 12:23 AM, Lars Eggert wrote:

On 2011-1-30, at 17:12, Paul Hoffman wrote:

The above emphatic statements means that IANA can reject a request for an 
IETF-approved protocol that needs two ports without recourse.


I don't follow. Assignments through IETF-stream documents do not go
through expert review.


Then this should be made *much* clearer in the document. In fact, the 
document says:


   A key element of the procedural streamlining specified in this
   document is to establish identical assignment procedures for all IETF
   transport protocols.

I assumed that all meant all, not all except those through 
IETF-stream documents; others might have read it the same way I did. 
Further, the wording throughout the template description in 8.1 makes it 
sound like that the restrictions in this document apply to everything 
that needs a template, which clearly includes IETF-stream documents.



And I've never witnessed IANA rejecting requests coming through the
IETF.


This document is about new restrictions for the future, not what has 
happened in the past.



But even if they did, there is an appeals procedure.


That is slim comfort to a WG that has designed a protocol that has good 
design reasons for needing two ports and, at the last minute is told 
that they either have to re-design from scratch or go through an appeals 
process to justify their design to IANA. It's fine that they have to 
justify it to the IESG (well, fine to me; other greybeards seem to not 
like that so much these days), but there should be no way that IANA can 
say you cannot get ports assigned because this new RFC says that you 
designed your protocol wrong. If what you say above about Assignments 
through IETF-stream documents do not go through expert review. is true, 
it should be plainly stated in the introduction to the document.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

2011-01-31 Thread Lars Eggert

Hi,

On 2011-1-31, at 16:51, Paul Hoffman wrote:
 On 1/31/11 12:23 AM, Lars Eggert wrote:
 On 2011-1-30, at 17:12, Paul Hoffman wrote:
 The above emphatic statements means that IANA can reject a request for an 
 IETF-approved protocol that needs two ports without recourse.
 
 I don't follow. Assignments through IETF-stream documents do not go
 through expert review.
 
 Then this should be made *much* clearer in the document. In fact, the 
 document says:
 
   A key element of the procedural streamlining specified in this
   document is to establish identical assignment procedures for all IETF
   transport protocols.
 
 I assumed that all meant all, not all except those through IETF-stream 
 documents; others might have read it the same way I did.

The sentence you quote isn't related to the issue we're discussing. It is 
intended to say a goal is that the procedures to get ports and service names 
are the same for UDP, TCP, DCCP and SCTP. (Maybe it would be clearer by 
explicitly naming these protocols in the document.)

But I see the point you're raising. The document should somewhere say that 
Expert Review is the procedure used for assignment requests made directly to 
IANA, whereas for documents on the IETF Stream, IETF Consensus is sufficient 
to make the assignment. In other words, no expert review doesn't really need to 
happen for those, since IETF Review and IESG Approval are at least equivalent.

Did I get that right?

 But even if they did, there is an appeals procedure.
 
 That is slim comfort to a WG that has designed a protocol that has good 
 design reasons for needing two ports and, at the last minute is told that 
 they either have to re-design from scratch or go through an appeals process 
 to justify their design to IANA. It's fine that they have to justify it to 
 the IESG (well, fine to me; other greybeards seem to not like that so much 
 these days), but there should be no way that IANA can say you cannot get 
 ports assigned because this new RFC says that you designed your protocol 
 wrong. If what you say above about Assignments through IETF-stream 
 documents do not go through expert review. is true, it should be plainly 
 stated in the introduction to the document.

Right. I think the change I outlined above would address this.

Thanks!

Lars

smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

2011-01-31 Thread Paul Hoffman


On 1/31/11 7:06 AM, Lars Eggert wrote:

But I see the point you're raising. The document should somewhere say
that Expert Review is the procedure used for assignment requests
made directly to IANA, whereas for documents on the IETF Stream,
IETF Consensus is sufficient to make the assignment. In other
words, no expert review doesn't really need to happen for those,
since IETF Review and IESG Approval are at least equivalent.

Did I get that right?


Yes, that would greatly reduce the concern about where and when (and how 
often!) the review would happen.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP


On Jan 31, 2011, at 8:14 , Paul Hoffman wrote:

 On 1/31/11 7:06 AM, Lars Eggert wrote:
  But I see the point you're raising. The document should somewhere say
  that Expert Review is the procedure used for assignment requests
  made directly to IANA, whereas for documents on the IETF Stream,
  IETF Consensus is sufficient to make the assignment. In other
  words, no expert review doesn't really need to happen for those,
  since IETF Review and IESG Approval are at least equivalent.
 
  Did I get that right?
 
 Yes, that would greatly reduce the concern about where and when (and how
 often!) the review would happen.
 

Hmm ... I don't agree that solves the issue. 

Well lets say the request was coming from 3GPP for a protocol they designed - 
why should IANA be able to tell them no but IETF yes. 

I think the policy issue here is fairly clear. We do not have consensus that in 
all cases that one should not have a second port for security (I'm basing this 
assertion on Magnus read of WG consensus and my read of IETF LC consensus). 
Therefore that should not be a ground for the expert reviewer (or IANA) to 
reject the registration. The document needs to be updated to make that clear or 
it does not reflect consensus. If the authors of the draft want to propose text 
for conditions when it would be ok to reject a second port for security 
purposes and see if they can get consensus for that text, that seems perfectly 
reasonable. 

I'm sure that some people believe the draft, by using the word strives, 
actually means that this is not a grounds for rejection but given the push back 
from Lars and Joe, I believe that strives means that the decision is up to 
Joe. Given things could be read either ways, I think it's fair to ask for the 
draft to clarify this. 





___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

2011-01-31 Thread Eliot Lear



On 1/31/11 5:13 PM, Cullen Jennings wrote:
 Hmm ... I don't agree that solves the issue. 

 Well lets say the request was coming from 3GPP for a protocol they designed - 
 why should IANA be able to tell them no but IETF yes. 

Who, ultimately, is the steward of this precious resource?  If it is not
the IANA and it is not the IETF, then who?  To say that it is everyone's
responsibility is to avoid responsibility entirely.  Who gets to say
which standards organizations are stewards and which are not?

 I think the policy issue here is fairly clear. We do not have consensus that 
 in all cases that one should not have a second port for security (I'm basing 
 this assertion on Magnus read of WG consensus and my read of IETF LC 
 consensus). Therefore that should not be a ground for the expert reviewer (or 
 IANA) to reject the registration. The document needs to be updated to make 
 that clear or it does not reflect consensus. If the authors of the draft want 
 to propose text for conditions when it would be ok to reject a second port 
 for security purposes and see if they can get consensus for that text, that 
 seems perfectly reasonable. 

This is a VERY VERY dangerous approach you propose, Cullen.  It is akin
to saying, you can think about security later, because we'll have to
give you a port for it later.  We don't want to be saying that.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP


So IANA has a huge amount of technical expertise and takes maintaing the 
registries very seriously. I've seen them catch technical mistakes that made 
all the way through WG and IESG review. I've got huge respect for technical 
competence of IANA and in particular Michelle. So I'm not questions that but  I 
don't recall seeing them override an expert on a technical issue. I'd be happy 
to hear of examples but lets consider the example I am actually concerned about 
here. 
 
I put in a request for a latency sensitive protocol that uses DTLS and request 
a different port for the secure version. Joe as expert review says we should 
redesign the protocol to use something like STARTLS and run on one port. I 
assert, with very little evidence, that will not meet the latency goals of the 
protocol. Joe does not agree. 

So Michelle, in that case, would you be willing to override Joe? I'm sure you 
would be willing to help facilitate any conversations, bring in other people 
such as ADs that can help etc. I was sort of working on the assumption that you 
would not override Joe in this case and the the only path forward would be an 
appeal to Lars but perhaps that is just a bad assumption on my part. Appeals 
are really the worst way possible to resolve things. I have a hard time 
imagining that IANA would want to engage in a technical discussion to resolve 
this and instead relies on the expert reviewer. I'll note that the expert 
review may report to IANA but they are selected by and replaced by the IESG. 

The important point here is that I really don't care if it is Joe or IANA that 
is saying no - I think this document should be clear that this BCP can not be 
used as grounds for rejecting the request for a second port for security. 



On Jan 30, 2011, at 12:09 , Michelle Cotton wrote:

 David has said this well.  Thank you.
 
 Please let me know if there are any other questions.
 
 --Michelle
 
 
 
 On 1/30/11 10:52 AM, David Conrad d...@virtualized.org wrote:
 
 Cullen,
 
 On Jan 29, 2011, at 8:54 PM, Cullen Jennings wrote:
 AFAICT, the experts team reports to IANA. We make recommendations to
 them. They are the ones who have the conversation with the applicant.
 They can take our advice or not - that's their decision.
 
 I think you are pretty misrepresenting the situation. My impression of the
 reality of the situation is that if the IANA did not like the advice of the
 expert reviewer, they might ask the AD to override but short of that they
 pretty much do whatever the expert says.
 
 
 Joe is closer.  
 
 In general, IANA staff are not technical experts in any of the wide variety 
 of
 areas for which they are asked to provide registry services.  As such, they
 rely on technical experts to provide input/advice/recommendations.  In the
 past, there were some very rare cases in which the advice provided by the
 technical experts was deemed insufficient and IANA staff looked to the ADs or
 the IESG for additional input.  However, at least historically, IANA staff
 viewed the maintenance of the registries as their responsibility (at the
 direction of the IESG), not the technical experts' responsibility. I would be
 surprised if this had changed.
 
 Regards,
 -drc
 
 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf
 


Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

2011-01-31 Thread Paul Hoffman


On 1/31/11 8:13 AM, Cullen Jennings wrote:

Hmm ... I don't agree that solves the issue.

Well lets say the request was coming from 3GPP for a protocol they
designed - why should IANA be able to tell them no but IETF yes.


Because IANA is responsible for maintaining the usefulness of the 
registry. Part of that is don't hand out ports unnecessarily, and part 
of that is hand out ports without hassle to those who are trusted to 
ask for them wisely. If 3GPP can show it belongs in the latter 
category, great. Until then, the only body that is there is IETF 
consensus plus maybe IESG pressure.



I think the policy issue here is fairly clear. We do not have
consensus that in all cases that one should not have a second port
for security (I'm basing this assertion on Magnus read of WG
consensus and my read of IETF LC consensus). Therefore that should
not be a ground for the expert reviewer (or IANA) to reject the
registration. The document needs to be updated to make that clear or
it does not reflect consensus. If the authors of the draft want to
propose text for conditions when it would be ok to reject a second
port for security purposes and see if they can get consensus for that
text, that seems perfectly reasonable.

I'm sure that some people believe the draft, by using the word
strives, actually means that this is not a grounds for rejection
but given the push back from Lars and Joe, I believe that strives
means that the decision is up to Joe. Given things could be read
either ways, I think it's fair to ask for the draft to clarify this.


Fully agree.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

2011-01-31 Thread Magnus Westerlund

Cullen Jennings skrev 2011-01-31 17:13:

 Well lets say the request was coming from 3GPP for a protocol they designed - 
 why should IANA be able to tell them no but IETF yes. 

I am not certain I understand what your issue is here. Is it that they
can come to different conclusions, and that IETF can decided to override
the expert review team? I think that is the logical conclusion, as the
IETF's decision will have gone through a consensus process. One which
the expert can provide their view into this.

 
 I think the policy issue here is fairly clear. We do not have consensus that 
 in all cases that one should not have a second port for security (I'm basing 
 this assertion on Magnus read of WG consensus and my read of IETF LC 
 consensus). Therefore that should not be a ground for the expert reviewer (or 
 IANA) to reject the registration. The document needs to be updated to make 
 that clear or it does not reflect consensus. If the authors of the draft want 
 to propose text for conditions when it would be ok to reject a second port 
 for security purposes and see if they can get consensus for that text, that 
 seems perfectly reasonable. 


My reading of the WG last call consensus is that nobody is disagreeing
with the goal of trying minimize the port consumption. My interpretation
is that we do need to state that goal in the document. And the only way
of achieving this is to try to minimize the consumption by each protocol
that requires a registration. That includes trying to get all
multiplexing into that single socket, or at least use it for agreeing on
dynamic range port for this protocol.

 
 I'm sure that some people believe the draft, by using the word strives, 
 actually means that this is not a grounds for rejection but given the push 
 back from Lars and Joe, I believe that strives means that the decision is 
 up to Joe. Given things could be read either ways, I think it's fair to ask 
 for the draft to clarify this. 

It is a high level goal to minimize the port space consumption. I do
believe there is strong consensus for this. And I believe that the only
way of ensuring that this goal is meet is to take a pretty hard stance
against frivolous use of ports.

Thus, I still think there is clear grounds for rejecting requests for
multiple ports based on not sufficiently motivating why it is impossible
to not use one port. I do agree that these guidelines should be
documented, and that is the plans as far as I know.

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: magnus.westerl...@ericsson.com
--
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

2011-01-31 Thread Michelle Cotton

Cullen,

We do have some technical expertise within the IANA staff, however our
expertise is more aligned with the process of creating and maintaining
registries.  Part of that includes relying on the experts that the IESG
designates to make the decisions for requests that utilize the Expert
Review policy in RFC 5226.

In the past, if there is strong disagreement from an expert and the
requester disagrees, we have brought the Transport Area Directors into the
communications to see if all parties can come to an agreement.  In almost
all cases, this is where a final decision is made.  If that set of folks can
not come to a conclusion, we then would default to going to the IESG.  With
all requests, if there is any uncertainty as to what decision should be
made, we go to the IESG for guidance.

We do rely on the technical expertise of the appointed experts for all
registries, but we ALWAYS have the possibility to seek guidance form the
IESG.

I don't believe we have ever had an official appeals with ports (Knocking on
wood really hard!).

Does that help?

--Michelle



On 1/31/11 8:33 AM, Cullen Jennings flu...@cisco.com wrote:

 
 So IANA has a huge amount of technical expertise and takes maintaing the
 registries very seriously. I've seen them catch technical mistakes that made
 all the way through WG and IESG review. I've got huge respect for technical
 competence of IANA and in particular Michelle. So I'm not questions that but
 I don't recall seeing them override an expert on a technical issue. I'd be
 happy to hear of examples but lets consider the example I am actually
 concerned about here.
  
 I put in a request for a latency sensitive protocol that uses DTLS and request
 a different port for the secure version. Joe as expert review says we should
 redesign the protocol to use something like STARTLS and run on one port. I
 assert, with very little evidence, that will not meet the latency goals of the
 protocol. Joe does not agree.
 
 So Michelle, in that case, would you be willing to override Joe? I'm sure you
 would be willing to help facilitate any conversations, bring in other people
 such as ADs that can help etc. I was sort of working on the assumption that
 you would not override Joe in this case and the the only path forward would be
 an appeal to Lars but perhaps that is just a bad assumption on my part.
 Appeals are really the worst way possible to resolve things. I have a hard
 time imagining that IANA would want to engage in a technical discussion to
 resolve this and instead relies on the expert reviewer. I'll note that the
 expert review may report to IANA but they are selected by and replaced by the
 IESG. 
 
 The important point here is that I really don't care if it is Joe or IANA that
 is saying no - I think this document should be clear that this BCP can not be
 used as grounds for rejecting the request for a second port for security.
 
 
 
 On Jan 30, 2011, at 12:09 , Michelle Cotton wrote:
 
 David has said this well.  Thank you.
 
 Please let me know if there are any other questions.
 
 --Michelle
 
 
 
 On 1/30/11 10:52 AM, David Conrad d...@virtualized.org wrote:
 
 Cullen,
 
 On Jan 29, 2011, at 8:54 PM, Cullen Jennings wrote:
 AFAICT, the experts team reports to IANA. We make recommendations to
 them. They are the ones who have the conversation with the applicant.
 They can take our advice or not - that's their decision.
 
 I think you are pretty misrepresenting the situation. My impression of the
 reality of the situation is that if the IANA did not like the advice of the
 expert reviewer, they might ask the AD to override but short of that they
 pretty much do whatever the expert says.
 
 
 Joe is closer. 
 
 In general, IANA staff are not technical experts in any of the wide variety
 of
 areas for which they are asked to provide registry services.  As such, they
 rely on technical experts to provide input/advice/recommendations.  In the
 past, there were some very rare cases in which the advice provided by the
 technical experts was deemed insufficient and IANA staff looked to the ADs
 or
 the IESG for additional input.  However, at least historically, IANA staff
 viewed the maintenance of the registries as their responsibility (at the
 direction of the IESG), not the technical experts' responsibility. I would
 be
 surprised if this had changed.
 
 Regards,
 -drc
 
 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf
 
 
 
 Cullen Jennings
 For corporate legal information go to:
 http://www.cisco.com/web/about/doing_business/legal/cri/index.html
 
 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

Lars,

On 1/31/2011 7:06 AM, Lars Eggert wrote:

Hi,

On 2011-1-31, at 16:51, Paul Hoffman wrote:

On 1/31/11 12:23 AM, Lars Eggert wrote:

On 2011-1-30, at 17:12, Paul Hoffman wrote:

The above emphatic statements means that IANA can reject a request for an
IETF-approved protocol that needs two ports without recourse.

I don't follow. Assignments through IETF-stream documents do not go
through expert review.

Then this should be made *much* clearer in the document. In fact, the document
says:

A key element of the procedural streamlining specified in this
document is to establish identical assignment procedures for all IETF
transport protocols.

I assumed that all meant all, not all except those through IETF-stream
documents; others might have read it the same way I did.

The sentence you quote isn't related to the issue we're discussing. It is intended to say
a goal is that the procedures to get ports and service names are the same for UDP,
TCP, DCCP and SCTP. (Maybe it would be clearer by explicitly naming these protocols
in the document.)

But I see the point you're raising. The document should somewhere say that Expert
Review is the procedure used for assignment requests made directly to IANA, whereas for
documents on the IETF Stream, IETF Consensus is sufficient to make the assignment. In
other words, no expert review doesn't really need to happen for those, since IETF Review and IESG
Approval are at least equivalent.

RFC2434 already gives IANA these options.

Perhaps - at best - we should include a ref to that.

However, this document is not focused at changing what RFC2434 says, and
the above statement, IMO, does.

That's another can of worms, and should be reserved for a different
document.

Joe

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP



The procedures that are specified - for ALL assignments - are the 
PROCEDURES - the word itself is used specifically in the heading of 
section 8.


That does not refer to the principles - again for which there are more 
than sufficient wiggle words, and which already cite existing RFCs that 
have provisions that already limit the role of Expert Review and allow 
for appeals.


Again - this document is NOT focused on those principles. IANA - and 
more specifically its review team - is NOT required to publish any such 
principles (as per RFC 5226). If they continue to be a source of 
contention, then section 7 should be removed.


Joe

On 1/31/2011 6:51 AM, Paul Hoffman wrote:

On 1/31/11 12:23 AM, Lars Eggert wrote:

On 2011-1-30, at 17:12, Paul Hoffman wrote:

The above emphatic statements means that IANA can reject a request
for an IETF-approved protocol that needs two ports without recourse.


I don't follow. Assignments through IETF-stream documents do not go
through expert review.


Then this should be made *much* clearer in the document. In fact, the
document says:

A key element of the procedural streamlining specified in this
document is to establish identical assignment procedures for all IETF
transport protocols.

I assumed that all meant all, not all except those through
IETF-stream documents; others might have read it the same way I did.
Further, the wording throughout the template description in 8.1 makes it
sound like that the restrictions in this document apply to everything
that needs a template, which clearly includes IETF-stream documents.


And I've never witnessed IANA rejecting requests coming through the
IETF.


This document is about new restrictions for the future, not what has
happened in the past.


But even if they did, there is an appeals procedure.


That is slim comfort to a WG that has designed a protocol that has good
design reasons for needing two ports and, at the last minute is told
that they either have to re-design from scratch or go through an appeals
process to justify their design to IANA. It's fine that they have to
justify it to the IESG (well, fine to me; other greybeards seem to not
like that so much these days), but there should be no way that IANA can
say you cannot get ports assigned because this new RFC says that you
designed your protocol wrong. If what you say above about Assignments
through IETF-stream documents do not go through expert review. is true,
it should be plainly stated in the introduction to the document.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP




On 1/31/2011 9:16 AM, Joe Touch wrote:

Lars,

On 1/31/2011 7:06 AM, Lars Eggert wrote:

Hi,

On 2011-1-31, at 16:51, Paul Hoffman wrote:

On 1/31/11 12:23 AM, Lars Eggert wrote:

On 2011-1-30, at 17:12, Paul Hoffman wrote:

The above emphatic statements means that IANA can reject a request
for an IETF-approved protocol that needs two ports without recourse.


I don't follow. Assignments through IETF-stream documents do not go
through expert review.


Then this should be made *much* clearer in the document. In fact, the
document says:

A key element of the procedural streamlining specified in this
document is to establish identical assignment procedures for all IETF
transport protocols.

I assumed that all meant all, not all except those through
IETF-stream documents; others might have read it the same way I did.


The sentence you quote isn't related to the issue we're discussing. It
is intended to say a goal is that the procedures to get ports and
service names are the same for UDP, TCP, DCCP and SCTP. (Maybe it
would be clearer by explicitly naming these protocols in the document.)

But I see the point you're raising. The document should somewhere say
that Expert Review is the procedure used for assignment requests
made directly to IANA, whereas for documents on the IETF Stream, IETF
Consensus is sufficient to make the assignment. In other words, no
expert review doesn't really need to happen for those, since IETF
Review and IESG Approval are at least equivalent.


RFC2434 already gives IANA these options.


As does RFC 5226 - its update (there is no substantive change between 
the two in this regard, FWIW).



Perhaps - at best - we should include a ref to that.


And 5226 is already clearly cited.

No further action should be required.

Joe


However, this document is not focused at changing what RFC2434 says, and
the above statement, IMO, does.

That's another can of worms, and should be reserved for a different
document.

Joe

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP


Thanks - yes that makes it clear and I like the way IANA handles all of this.

On Jan 31, 2011, at 9:55 , Michelle Cotton wrote:

 Cullen,
 
 We do have some technical expertise within the IANA staff, however our
 expertise is more aligned with the process of creating and maintaining
 registries.  Part of that includes relying on the experts that the IESG
 designates to make the decisions for requests that utilize the Expert
 Review policy in RFC 5226.
 
 In the past, if there is strong disagreement from an expert and the
 requester disagrees, we have brought the Transport Area Directors into the
 communications to see if all parties can come to an agreement.  In almost
 all cases, this is where a final decision is made.  If that set of folks can
 not come to a conclusion, we then would default to going to the IESG.  With
 all requests, if there is any uncertainty as to what decision should be
 made, we go to the IESG for guidance.
 
 We do rely on the technical expertise of the appointed experts for all
 registries, but we ALWAYS have the possibility to seek guidance form the
 IESG.
 
 I don't believe we have ever had an official appeals with ports (Knocking on
 wood really hard!).
 
 Does that help?
 
 --Michelle
 
 
 
 On 1/31/11 8:33 AM, Cullen Jennings flu...@cisco.com wrote:
 
 
 So IANA has a huge amount of technical expertise and takes maintaing the
 registries very seriously. I've seen them catch technical mistakes that made
 all the way through WG and IESG review. I've got huge respect for technical
 competence of IANA and in particular Michelle. So I'm not questions that but
 I don't recall seeing them override an expert on a technical issue. I'd be
 happy to hear of examples but lets consider the example I am actually
 concerned about here.
 
 I put in a request for a latency sensitive protocol that uses DTLS and 
 request
 a different port for the secure version. Joe as expert review says we should
 redesign the protocol to use something like STARTLS and run on one port. I
 assert, with very little evidence, that will not meet the latency goals of 
 the
 protocol. Joe does not agree.
 
 So Michelle, in that case, would you be willing to override Joe? I'm sure you
 would be willing to help facilitate any conversations, bring in other people
 such as ADs that can help etc. I was sort of working on the assumption that
 you would not override Joe in this case and the the only path forward would 
 be
 an appeal to Lars but perhaps that is just a bad assumption on my part.
 Appeals are really the worst way possible to resolve things. I have a hard
 time imagining that IANA would want to engage in a technical discussion to
 resolve this and instead relies on the expert reviewer. I'll note that the
 expert review may report to IANA but they are selected by and replaced by the
 IESG. 
 
 The important point here is that I really don't care if it is Joe or IANA 
 that
 is saying no - I think this document should be clear that this BCP can not be
 used as grounds for rejecting the request for a second port for security.
 
 
 
 On Jan 30, 2011, at 12:09 , Michelle Cotton wrote:
 
 David has said this well.  Thank you.
 
 Please let me know if there are any other questions.
 
 --Michelle
 
 
 
 On 1/30/11 10:52 AM, David Conrad d...@virtualized.org wrote:
 
 Cullen,
 
 On Jan 29, 2011, at 8:54 PM, Cullen Jennings wrote:
 AFAICT, the experts team reports to IANA. We make recommendations to
 them. They are the ones who have the conversation with the applicant.
 They can take our advice or not - that's their decision.
 
 I think you are pretty misrepresenting the situation. My impression of the
 reality of the situation is that if the IANA did not like the advice of 
 the
 expert reviewer, they might ask the AD to override but short of that they
 pretty much do whatever the expert says.
 
 
 Joe is closer. 
 
 In general, IANA staff are not technical experts in any of the wide variety
 of
 areas for which they are asked to provide registry services.  As such, they
 rely on technical experts to provide input/advice/recommendations.  In the
 past, there were some very rare cases in which the advice provided by the
 technical experts was deemed insufficient and IANA staff looked to the ADs
 or
 the IESG for additional input.  However, at least historically, IANA staff
 viewed the maintenance of the registries as their responsibility (at the
 direction of the IESG), not the technical experts' responsibility. I would
 be
 surprised if this had changed.
 
 Regards,
 -drc
 
 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf
 
 
 
 Cullen Jennings
 For corporate legal information go to:
 http://www.cisco.com/web/about/doing_business/legal/cri/index.html
 
 
 


Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html


___
Ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP


On Jan 31, 2011, at 9:41 , Magnus Westerlund wrote:

 Cullen Jennings skrev 2011-01-31 17:13:
 
 Well lets say the request was coming from 3GPP for a protocol they designed 
 - why should IANA be able to tell them no but IETF yes. 
 
 I am not certain I understand what your issue is here. Is it that they
 can come to different conclusions, and that IETF can decided to override
 the expert review team? I think that is the logical conclusion, as the
 IETF's decision will have gone through a consensus process. One which
 the expert can provide their view into this.
 
 
 I think the policy issue here is fairly clear. We do not have consensus that 
 in all cases that one should not have a second port for security (I'm basing 
 this assertion on Magnus read of WG consensus and my read of IETF LC 
 consensus). Therefore that should not be a ground for the expert reviewer 
 (or IANA) to reject the registration. The document needs to be updated to 
 make that clear or it does not reflect consensus. If the authors of the 
 draft want to propose text for conditions when it would be ok to reject a 
 second port for security purposes and see if they can get consensus for that 
 text, that seems perfectly reasonable. 
 
 
 My reading of the WG last call consensus is that nobody is disagreeing
 with the goal of trying minimize the port consumption. My interpretation
 is that we do need to state that goal in the document. And the only way
 of achieving this is to try to minimize the consumption by each protocol
 that requires a registration. That includes trying to get all
 multiplexing into that single socket, or at least use it for agreeing on
 dynamic range port for this protocol.
 
 
 I'm sure that some people believe the draft, by using the word strives, 
 actually means that this is not a grounds for rejection but given the push 
 back from Lars and Joe, I believe that strives means that the decision is 
 up to Joe. Given things could be read either ways, I think it's fair to ask 
 for the draft to clarify this. 
 
 It is a high level goal to minimize the port space consumption. I do
 believe there is strong consensus for this. And I believe that the only
 way of ensuring that this goal is meet is to take a pretty hard stance
 against frivolous use of ports.
 
 Thus, I still think there is clear grounds for rejecting requests for
 multiple ports based on not sufficiently motivating why it is impossible
 to not use one port. I do agree that these guidelines should be
 documented, and that is the plans as far as I know.

Magnus, I agree with what you are saying here but you are avoiding the issue I 
am concerned with. Is allocating a second port for the secure version of a 
document a frivolous use case or not? I read this draft as saying it is. Others 
read the draft as saying it is not and that type of allocation is fine. This 
seems fairly easy to deal with - first lets agree if particular 2nd port for 
secure version is a reason to reject requests or not then see if any text needs 
to be adjusted in the draft to reflect that. 



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP


So first, we already have a BCP that says  more or less all protocols must 
implement a secure version but deployment is optional. This is a good BCP, and 
it comes from the right area to say that - security. It's probably impacts 
design work in working groups more than any other BCP. It has IETF consensus. 
The IESG holds protocols to this. 

Now - I am at loss to see why forcing people to use one port will make it more 
likely to have secure protocols. This seems crazy.  Please do enlighten me.

And on the topic, I'm still looking forward to an explanation of how the 
current CoAP design stomping all over the TLS code points would be an 
acceptable design. 


On Jan 31, 2011, at 9:27 , Eliot Lear wrote:

 
 
 On 1/31/11 5:13 PM, Cullen Jennings wrote:
 Hmm ... I don't agree that solves the issue. 
 
 Well lets say the request was coming from 3GPP for a protocol they designed 
 - why should IANA be able to tell them no but IETF yes. 
 
 Who, ultimately, is the steward of this precious resource?  If it is not
 the IANA and it is not the IETF, then who?  To say that it is everyone's
 responsibility is to avoid responsibility entirely.  Who gets to say
 which standards organizations are stewards and which are not?
 
 I think the policy issue here is fairly clear. We do not have consensus that 
 in all cases that one should not have a second port for security (I'm basing 
 this assertion on Magnus read of WG consensus and my read of IETF LC 
 consensus). Therefore that should not be a ground for the expert reviewer 
 (or IANA) to reject the registration. The document needs to be updated to 
 make that clear or it does not reflect consensus. If the authors of the 
 draft want to propose text for conditions when it would be ok to reject a 
 second port for security purposes and see if they can get consensus for that 
 text, that seems perfectly reasonable. 
 
 This is a VERY VERY dangerous approach you propose, Cullen.  It is akin
 to saying, you can think about security later, because we'll have to
 give you a port for it later.  We don't want to be saying that.
 


Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

2011-01-31 Thread Eliot Lear



On 1/31/11 6:51 PM, Cullen Jennings wrote:
 So first, we already have a BCP that says  more or less all protocols must 
 implement a secure version but deployment is optional. This is a good BCP, 
 and it comes from the right area to say that - security. It's probably 
 impacts design work in working groups more than any other BCP. It has IETF 
 consensus. The IESG holds protocols to this. 

But this isn't only about IETF process.  You just asked about why the
IETF is special and why 3GPP shouldn't be treated on equal footing. 
Well, then what about ITU, ISO, W3C, and Joe's Standards Body?

 Now - I am at loss to see why forcing people to use one port will make it 
 more likely to have secure protocols. This seems crazy.  Please do enlighten 
 me.

The vast majority of the requests I see have 0 security built in until I
ask the question.  A few come back with a plan.  Take away that lever
and I don't even get to ask the question.
 And on the topic, I'm still looking forward to an explanation of how the 
 current CoAP design stomping all over the TLS code points would be an 
 acceptable design. 

I missed a step there?  CoAP?


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

Fwiw please see sec 8.1 of our doc which states which procedures of RFC 5226 
are specified for each range, and already allows IESG approval as a path for 
user ports. 

Joe

On Jan 31, 2011, at 9:25 AM, Joe Touch to...@isi.edu wrote:

 
 
 On 1/31/2011 9:16 AM, Joe Touch wrote:
 Lars,
 
 On 1/31/2011 7:06 AM, Lars Eggert wrote:
 Hi,
 
 On 2011-1-31, at 16:51, Paul Hoffman wrote:
 On 1/31/11 12:23 AM, Lars Eggert wrote:
 On 2011-1-30, at 17:12, Paul Hoffman wrote:
 The above emphatic statements means that IANA can reject a request
 for an IETF-approved protocol that needs two ports without recourse.
 
 I don't follow. Assignments through IETF-stream documents do not go
 through expert review.
 
 Then this should be made *much* clearer in the document. In fact, the
 document says:
 
 A key element of the procedural streamlining specified in this
 document is to establish identical assignment procedures for all IETF
 transport protocols.
 
 I assumed that all meant all, not all except those through
 IETF-stream documents; others might have read it the same way I did.
 
 The sentence you quote isn't related to the issue we're discussing. It
 is intended to say a goal is that the procedures to get ports and
 service names are the same for UDP, TCP, DCCP and SCTP. (Maybe it
 would be clearer by explicitly naming these protocols in the document.)
 
 But I see the point you're raising. The document should somewhere say
 that Expert Review is the procedure used for assignment requests
 made directly to IANA, whereas for documents on the IETF Stream, IETF
 Consensus is sufficient to make the assignment. In other words, no
 expert review doesn't really need to happen for those, since IETF
 Review and IESG Approval are at least equivalent.
 
 RFC2434 already gives IANA these options.
 
 As does RFC 5226 - its update (there is no substantive change between the two 
 in this regard, FWIW).
 
 Perhaps - at best - we should include a ref to that.
 
 And 5226 is already clearly cited.
 
 No further action should be required.
 
 Joe
 
 However, this document is not focused at changing what RFC2434 says, and
 the above statement, IMO, does.
 
 That's another can of worms, and should be reserved for a different
 document.
 
 Joe
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

2011-01-31 Thread Eric Rescorla

On Mon, Jan 31, 2011 at 11:41 AM, Eric Rescorla e...@skype.net wrote:
 So first, we already have a BCP that says  more or less all protocols must 
 implement a secure version but deployment is optional. This is a good BCP, 
 and it comes from the right area to say that - security. It's probably 
 impacts design work in working groups more than any other BCP. It has IETF 
 consensus. The IESG holds protocols to this.

 Now - I am at loss to see why forcing people to use one port will make it 
 more likely to have secure protocols. This seems crazy.  Please do enlighten 
 me.

I don't think it does.

At a high level, there are three ways in which insecure and secure
versions (by which I mostly mean channel security mechanisms such as
TLS) of the same protocol can coexist:

1. They can operate on totally different transport parameters (e.g., ports)
2. They can be demuxable by some indicator that's simply sent by one
side and accepted or rejected by the other side. (E.g., If the first
byte is 20 this is TLS, else it's not)
3. It can be negotiated as in STARTTLS

In the first two of these, the client knows which version it wants
(secure or insecure) and there is no chance for the server to indicate
otherwise other than failing the connection. In the third, the sides
negotiate. So, I think the first question is which general design you
wish to have. Each of these have their merits: negotiation designs are
more complicated but allow for opportunistic security. Unfortunately,
they also allow for downgrade attack, as the experience with STARTTLS
for SMTP shows. By contrast, non-negotiation designs are easier to
implement and provide for referential integrity but not for
opportunistic security. IMO there is a place for both, though I
generally tend towards non-negotiated designs, in part out of a
feeling that the world would be better if people used encryption all
the time.

Clearly, if you're going to do a negotiation design you want a single port.
If you're going to do a non-negotiated design, then I don't see a huge
amount of value in using a single port. It's true that there is a port
consumption issue, but OTOH ports are there for protocol demuxing and
this is clearly another protocol. It's simply a lot easier to have
your TLS stack just start its thing rather than try to autodetect
whether you have TLS or some other protocol. So I would generally push
back on the claim that non-negotiated designs should have to have
demuxing in information in the dataflow rather than use the port.


 And on the topic, I'm still looking forward to an explanation of how the 
 current CoAP design stomping all over the TLS code points would be an 
 acceptable design.

I don't consider this an acceptable design and I've already told the
CoAP authors and chairs so. Speaking as chair, if the CoAP
authors/chairs wish to pursue this avenue they should bring it to the
TLS WG, which AFAIK they have not done.

-Ekr




 On Jan 31, 2011, at 9:27 , Eliot Lear wrote:



 On 1/31/11 5:13 PM, Cullen Jennings wrote:
 Hmm ... I don't agree that solves the issue.

 Well lets say the request was coming from 3GPP for a protocol they designed 
 - why should IANA be able to tell them no but IETF yes.

 Who, ultimately, is the steward of this precious resource?  If it is not
 the IANA and it is not the IETF, then who?  To say that it is everyone's
 responsibility is to avoid responsibility entirely.  Who gets to say
 which standards organizations are stewards and which are not?

 I think the policy issue here is fairly clear. We do not have consensus 
 that in all cases that one should not have a second port for security (I'm 
 basing this assertion on Magnus read of WG consensus and my read of IETF LC 
 consensus). Therefore that should not be a ground for the expert reviewer 
 (or IANA) to reject the registration. The document needs to be updated to 
 make that clear or it does not reflect consensus. If the authors of the 
 draft want to propose text for conditions when it would be ok to reject a 
 second port for security purposes and see if they can get consensus for 
 that text, that seems perfectly reasonable.

 This is a VERY VERY dangerous approach you propose, Cullen.  It is akin
 to saying, you can think about security later, because we'll have to
 give you a port for it later.  We don't want to be saying that.



 Cullen Jennings
 For corporate legal information go to:
 http://www.cisco.com/web/about/doing_business/legal/cri/index.html




___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

2011-01-31 Thread Eliot Lear

Eric,
 Clearly, if you're going to do a negotiation design you want a single port.
 If you're going to do a non-negotiated design, then I don't see a huge
 amount of value in using a single port. It's true that there is a port
 consumption issue, but OTOH ports are there for protocol demuxing and
 this is clearly another protocol.

Another way to look at this is that it's the same protocol running atop
a security layer.  Same protocol engine, perhaps in a slightly different
security context in terms of what is authorized.  And there's good
reason to look at it this way.  Aside from the leverage it gives
reviewers as I discussed previously, there's also the minor matter of
port consumption, which won't be so minor if we run short.  And don't
think that can't happen.  Additional ports are being approved for
reasons that are clearly architecture limitations.  I'm not even sure
this is an acceptable excuse.

For one, if we look at some of the examples that have been mooted, I
doubt that an additional port would have solved the downgrade problem. 
The case I have in mind is indeed SMTP.  The conditions that allow for
the downgrade attack have more to do with the realities of certificate
management than STARTTLS.

As I wrote in a different context there is also the draft that Paul has
written for HASTLS, which allows a server to express a policy without
having to require a port.  While some of us have some questions about
some of the choices Paul made in the design, on the whole I think
everyone agrees it's a good idea.  It may not, however, solve the entire
problem, because we now are forced to answer the question as to how host
policy should be conveyed.

  It's simply a lot easier to have
 your TLS stack just start its thing rather than try to autodetect
 whether you have TLS or some other protocol.

Maybe so (wasn't so hard for me), but there now is a whole lot of free
code out there that does just this.



  So I would generally push
 back on the claim that non-negotiated designs should have to have
 demuxing in information in the dataflow rather than use the port.

There is a cost that extends beyond the protocol.  That has to be taken
into account.

Eliot
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

2011-01-31 Thread Eric Rescorla

On Mon, Jan 31, 2011 at 2:11 PM, Eliot Lear l...@cisco.com wrote:
 Eric,
 Clearly, if you're going to do a negotiation design you want a single port.
 If you're going to do a non-negotiated design, then I don't see a huge
 amount of value in using a single port. It's true that there is a port
 consumption issue, but OTOH ports are there for protocol demuxing and
 this is clearly another protocol.

 Another way to look at this is that it's the same protocol running atop
 a security layer.  Same protocol engine, perhaps in a slightly different
 security context in terms of what is authorized.  And there's good
 reason to look at it this way.  Aside from the leverage it gives
 reviewers as I discussed previously, there's also the minor matter of
 port consumption, which won't be so minor if we run short.  And don't
 think that can't happen.  Additional ports are being approved for
 reasons that are clearly architecture limitations.  I'm not even sure
 this is an acceptable excuse.

Really? What fraction of the port space has been consumed?


 For one, if we look at some of the examples that have been mooted, I
 doubt that an additional port would have solved the downgrade problem.
 The case I have in mind is indeed SMTP.  The conditions that allow for
 the downgrade attack have more to do with the realities of certificate
 management than STARTTLS.

I didn't say it did, if you reread my message. What I said was that
not negotiating
addresses downgrade.


 As I wrote in a different context there is also the draft that Paul has
 written for HASTLS, which allows a server to express a policy without
 having to require a port.  While some of us have some questions about
 some of the choices Paul made in the design, on the whole I think
 everyone agrees it's a good idea.

Well, I'm not sure I see the relevance of this. The question is how
the server supports
both secure and insecure variants at once.




  It's simply a lot easier to have
 your TLS stack just start its thing rather than try to autodetect
 whether you have TLS or some other protocol.

 Maybe so (wasn't so hard for me),

Well, I have no idea what protocol you're thinking of, but all of the
upward negotiation
protocols have a significantly more complicated state machine than does HTTPS.


but there now is a whole lot of free
 code out there that does just this.

And it's generally all protocol specific, so we have this problem with
every new protocol.


  So I would generally push
 back on the claim that non-negotiated designs should have to have
 demuxing in information in the dataflow rather than use the port.

 There is a cost that extends beyond the protocol.  That has to be taken
 into account.

Of course. Which is why I'm not saying that you should ALWAYS do a
separate port.
But I don't agree there is consensus that it's bad either.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

2011-01-30 Thread Paul Hoffman


On 1/29/11 9:34 PM, Joe Touch wrote:



On 1/29/2011 8:54 PM, Cullen Jennings wrote:


On Jan 27, 2011, at 17:10 , Joe Touch wrote:

...

AFAICT, the experts team reports to IANA. We make recommendations to
them. They are the ones who have the conversation with the applicant.
They can take our advice or not - that's their decision.


I think you are pretty misrepresenting the situation. My impression
of the reality of the situation is that if the IANA did not like the
advice of the expert reviewer, they might ask the AD to override but
short of that they pretty much do whatever the expert says.


As per my other note:
RFC2780 specifies Expert Review as *one* of the viable means by which
IANA can decide on transport protocol port assignments. The term Expert
Review is defined in RFC 2434.

Neither document binds IANA to use the advice of a reviewer.

Further, there is no single reviewer - we have a team, consulting each
other on occasion, and all decisions are seen by multiple reviewers.
However, none of that is worth codifying. If IANA or the IESG doesn't
like how we serve them, they can replace us - at any time, for any
reason, and there is an appeals process for decisions of the expert team:

Any decisions made by the designated expert can be appealed using the
normal IETF appeals process as outlined in Section 6.5 of [IETF-
PROCESS].


Now that this has been made clear to me, I am *much* more worried about 
the wording in the current draft. The above emphatic statements means 
that IANA can reject a request for an IETF-approved protocol that needs 
two ports without recourse. As Cullen and others have pointed out, there 
are sometimes very good technical reasons for a particular protocol to 
need to have two ports.


The document should be amended to say that protocols with IETF consensus 
should get as many ports as it needs, regardless of what IANA or the 
expert reviewer thinks. This makes it the responsibility of the IETF 
consensus process to follow the guidelines in this document.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

2011-01-30 Thread Joe Touch


Paul (et al.),

See below.

Note that IANA can't just make its own decisions either and ignore IETF 
process *AND* expert review.


I wasn't trying to imply that, but it appears to have been inferred from 
my claim that neither document binds IANA to the advice of a reviewer. 
IANA is bound by the OR of basic IETF process and Expert Review. The 
former can override the latter (or vice versa), but there is an appeal 
process - through the IETF - as well.


If you have issue with these processes, then RFC 2434 and RFC 2780 are 
your targets, not this doc.


Joe

On 1/30/2011 7:12 AM, Paul Hoffman wrote:

On 1/29/11 9:34 PM, Joe Touch wrote:

...

As per my other note:
RFC2780 specifies Expert Review as *one* of the viable means by which
IANA can decide on transport protocol port assignments. The term Expert
Review is defined in RFC 2434.

Neither document binds IANA to use the advice of a reviewer.

Further, there is no single reviewer - we have a team, consulting each
other on occasion, and all decisions are seen by multiple reviewers.
However, none of that is worth codifying. If IANA or the IESG doesn't
like how we serve them, they can replace us - at any time, for any
reason, and there is an appeals process for decisions of the expert team:

Any decisions made by the designated expert can be appealed using the
normal IETF appeals process as outlined in Section 6.5 of [IETF-
PROCESS].


Now that this has been made clear to me, I am *much* more worried about
the wording in the current draft. The above emphatic statements means
that IANA can reject a request for an IETF-approved protocol that needs
two ports without recourse.


Repeating myself:

a) this document is NOT proscribing IANA processes for expert review of 
port requests


b) RFC 2790 describes MANY ways IANA decides how to allocate ports:

   Values in this namespace are assigned following a Specification
   Required, Expert Review, IESG Approval, IETF Consensus, or Standards
   Action.

Note the word *OR* above. Expert review doesn't override IETF process here.


The document should be amended to say that protocols with IETF
consensus should get as many ports as it needs, regardless of what
IANA or the expert reviewer thinks.


The above section already allows for that.


This makes it the responsibility
of the IETF consensus process to follow the guidelines in this
document.


This document says, quite clearly, at the front of Section 7.2:

   This section summarizes the current principles by which IANA handles
   the Service Name and Transport Protocol Port Number Registry and
   attempts to conserve the port number space.  This description is
   intended to inform applicants requesting service names and port
   numbers.  IANA has flexibility beyond these principles when handling
   assignment requests; other factors may come into play, and exceptions
   may be made to best serve the needs of the Internet.

It never says that this is a process that the IESG or IETF is required 
to follow. The language of the section has wiggle words throughout, and 
does not use RFC 2119 language. Thus nobody anywhere is bound by it.


c) RFC 2434 notes how expert reviewers are selected:

   Designated experts are appointed by the relevant Area Director of the
   IESG. They are typically named at the time a document that creates a
   new numbering space is published as an RFC, but as experts originally
   appointed may later become unavailable, the relevant Area Director
   will appoint replacements if necessary.

d) there is already a process to appeal decisions that are based on 
Expert Review:


   Any decisions made by the designated expert can be appealed using the
   normal IETF appeals process as outlined in Section 6.5 of [IETF-
   PROCESS]. Since the designated experts are appointed by the IESG,
   they may be removed by the IESG.

--
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

2011-01-30 Thread David Conrad

Cullen,

On Jan 29, 2011, at 8:54 PM, Cullen Jennings wrote:
 AFAICT, the experts team reports to IANA. We make recommendations to
 them. They are the ones who have the conversation with the applicant.
 They can take our advice or not - that's their decision.
 
 I think you are pretty misrepresenting the situation. My impression of the 
 reality of the situation is that if the IANA did not like the advice of the 
 expert reviewer, they might ask the AD to override but short of that they 
 pretty much do whatever the expert says. 


Joe is closer.  

In general, IANA staff are not technical experts in any of the wide variety of 
areas for which they are asked to provide registry services.  As such, they 
rely on technical experts to provide input/advice/recommendations.  In the 
past, there were some very rare cases in which the advice provided by the 
technical experts was deemed insufficient and IANA staff looked to the ADs or 
the IESG for additional input.  However, at least historically, IANA staff 
viewed the maintenance of the registries as their responsibility (at the 
direction of the IESG), not the technical experts' responsibility. I would be 
surprised if this had changed.

Regards,
-drc

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

2011-01-30 Thread Michelle Cotton

David has said this well.  Thank you.

Please let me know if there are any other questions.

--Michelle



On 1/30/11 10:52 AM, David Conrad d...@virtualized.org wrote:

 Cullen,
 
 On Jan 29, 2011, at 8:54 PM, Cullen Jennings wrote:
 AFAICT, the experts team reports to IANA. We make recommendations to
 them. They are the ones who have the conversation with the applicant.
 They can take our advice or not - that's their decision.
 
 I think you are pretty misrepresenting the situation. My impression of the
 reality of the situation is that if the IANA did not like the advice of the
 expert reviewer, they might ask the AD to override but short of that they
 pretty much do whatever the expert says.
 
 
 Joe is closer.  
 
 In general, IANA staff are not technical experts in any of the wide variety of
 areas for which they are asked to provide registry services.  As such, they
 rely on technical experts to provide input/advice/recommendations.  In the
 past, there were some very rare cases in which the advice provided by the
 technical experts was deemed insufficient and IANA staff looked to the ADs or
 the IESG for additional input.  However, at least historically, IANA staff
 viewed the maintenance of the registries as their responsibility (at the
 direction of the IESG), not the technical experts' responsibility. I would be
 surprised if this had changed.
 
 Regards,
 -drc
 
 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP


On Jan 27, 2011, at 17:29 , Michelle Cotton wrote:

 We are changing that process right now.  We have begun to report the
 reviewer (with the review) in the email to the requester.
 
 We just need to make sure this small change is communicated to those experts
 that are part of review teams as their individual names are not published
 on the main list of registries.
 
 I don't think it needs to go in this document as this is already in
 progress.
 
 Let me know if you have any questions.

As long as we agree that is the process, it's not a big deal to me if it is in 
or out of the document but I don't see any reason not to put it into the 
document. 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP


On Jan 27, 2011, at 17:10 , Joe Touch wrote:

 On 1/27/2011 12:52 AM, Lars Eggert wrote:
 ...
  Small Issue #3: I object to anonymous review
 
  The current review is anonymous and this draft does not seem to change 
  that. I don't like anonymous review - it's not how we do things at IETF 
  and it encourages really bad behavior. I have several emails with an 
  expert reviewer relayed via IANA where the conversation was going no where 
  - once I knew the name of the reviewer, the whole conversation changed and 
  stuff quickly came back to the realm of sane. I'm not willing to forward 
  these emails to the list as that would just not be kind to anyone but I am 
  happy to forward them to the IESG if they think looking at them is really 
  critical.
 
  I can see your point, and I personally have no problem with disclosing the 
  reviewer identity. What do others think?
 
 AFAICT, the experts team reports to IANA. We make recommendations to
 them. They are the ones who have the conversation with the applicant.
 They can take our advice or not - that's their decision.

I think you are pretty misrepresenting the situation. My impression of the 
reality of the situation is that if the IANA did not like the advice of the 
expert reviewer, they might ask the AD to override but short of that they 
pretty much do whatever the expert says. 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP


On Jan 27, 2011, at 8:12 , IETF Chair wrote:

 
 Originally, two ports were assigned for plain and over-TLS, which for HTTP 
 mapped to two different URL schemes: http and https.
 
 Many people thought that this was a waste of a port, and the STARTTLS 
 approach was developed.  You say that it does not work in some cases, and you 
 seem to be suggesting that we go back to the original way.
 
 Maybe it works in some cases and not others.  Can we say which is which?

I did misread the draft as saying that 2 ports were not allowed when clearly 
that was not what people meant but ...

I'm mostly concerned about cases where latency or bandwidth are an issue - 
basically protocols for real time protocols for internet of things. For things 
like email I'm less concerned. However, I think we can make some observation 
about which works best. Consider some of the most successful protocols on the 
internet

http, 2 ports

email, pop, imap, and smtp, -  more use on multi ports than STARTLS though many 
deployment support both 

sip, 2 ports 




___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP