Subject: 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

From: Magnus Westerlund <[email-masked]>
Date: Tue, 1 Feb 2011 11:14:10 +0100

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: [email-masked]
----------------------------------------------------------------------

---

From: [email-masked]
Date: Tue, 01 Feb 2011 08:38:25 -0800 (PST)

+1 to everything Magnus says here. THis is exactly how I view the multiple port
issue.

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.

				Ned

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 1 Feb 2011 08:56:40 -0800

> +1 to everything Magnus says here. THis is exactly how I view the multiple port

I'll respond to this separately.

> 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

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 01 Feb 2011 09:01:03 -0800

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

> we need to aim at lowering the consumption rather than raising it.

No one is suggesting raising the consumption rate.

> - Be reasonably tough from the expert reviewer to ensure that applicants

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

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

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 1 Feb 2011 12:19:06 -0500

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?

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 1 Feb 2011 12:19:15 -0500

inline 

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

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

> 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

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

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

> Magnus Westerlund

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

---

From: Joe Touch <[email-masked]>
Date: Tue, 01 Feb 2011 09:39:15 -0800

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

---

From: Joe Touch <[email-masked]>
Date: Tue, 01 Feb 2011 09:49:16 -0800

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 1 Feb 2011 10:00:33 -0800

On Tue, Feb 1, 2011 at 9:39 AM, Joe Touch <[email-masked]> wrote:
> 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:
>

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

---

From: Joe Touch <[email-masked]>
Date: Tue, 01 Feb 2011 10:26:54 -0800

On 2/1/2011 10:00 AM, Eric Rescorla wrote:
> On Tue, Feb 1, 2011 at 9:39 AM, Joe Touch<[email-masked]>  wrote:

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 1 Feb 2011 10:29:31 -0800

On Tue, Feb 1, 2011 at 10:26 AM, Joe Touch <[email-masked]> wrote:
>>> a
> (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

---

From: Joe Touch <[email-masked]>
Date: Tue, 01 Feb 2011 10:37:05 -0800

On 2/1/2011 10:29 AM, Eric Rescorla wrote:
...
> This document has an affirmative statement against the use of multiple

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:

> 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

---

From: Eliot Lear <[email-masked]>
Date: Tue, 01 Feb 2011 20:11:10 +0100

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

---

From: Sam Hartman <[email-masked]>
Date: Tue, 01 Feb 2011 14:14:47 -0500

>>>>> "Joe" == Joe Touch <[email-masked]> 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.

---

From: Joe Touch <[email-masked]>
Date: Tue, 01 Feb 2011 11:25:31 -0800

On 2/1/2011 11:14 AM, Sam Hartman wrote:
...
> 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

---

From: Sam Hartman <[email-masked]>
Date: Tue, 01 Feb 2011 15:12:01 -0500

>>>>> "Joe" == Joe Touch <[email-masked]> 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.

---

From: Joe Touch <[email-masked]>
Date: Tue, 01 Feb 2011 13:06:25 -0800

On 2/1/2011 12:12 PM, Sam Hartman wrote:
>>>>>> "Joe" == Joe Touch<[email-masked]>  writes:
>

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 1 Feb 2011 13:12:10 -0800

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 2 Feb 2011 10:16:32 +0100

> 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 mor…

Cullen,

Apparently you like to twist what I am saying in most negative way and
without considering the checks that are in place.

- I think general guidelines can and should be developed. But other than
high level goals this isn't the document. Here Joe has the start of a
document. But I do think that in long term this guidance may change.

- There is an appeal process where the IESG and then IAB gets to sanity
check the arguments that the reviewer + IANA has given towards the
appealing requestor.

- One can take a assignment request through the IETF process

I hope that we can get consensus on the guidelines, because I think that
would give the reviewers a lot of comfort being able to rely on that
consensus.

Cullen, what are your suggestion for how to improve the document?

Cheers

Magnus Westerlund

---

From: "t.petch" <[email-masked]>
Date: Wed, 2 Feb 2011 12:22:57 +0100

----- Original Message -----
From: "Joe Touch" <[email-masked]>
To: "Paul Hoffman" <[email-masked]>
"IETF discussion list" <[email-masked]>; <[email-masked]>; "IESG IESG"
<[email-masked]>
Sent: Tuesday, February 01, 2011 6:39 PM

Joe

I think that it is a point of confusion because the text is confused
(well, it confuses me:-(.

If you know in advance that there are two independent paths that
can be taken, then you can read that meaning into it.

If you do not know that, then having read
                                                                     "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"

then it is obvious that Expert Review always happens, even when a later
sentence talks about 'may also be assigned'.

To make the two paths clear, the text should be reordered eg

         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.

For most IETF protocols, ports in the User Ports range will be assigned under
the "IETF
Review" or "IESG Approval" procedures [RFC5226] and no further
documentation is required.

Where these procedures do not apply, then the requester must
input the documentation to

                                                            the "Expert Review"
procedure

Tom Petch

---

From: "t.petch" <[email-masked]>
Date: Wed, 2 Feb 2011 12:27:27 +0100

----- Original Message -----
From: "Paul Hoffman" <[email-masked]>
To: "Magnus Westerlund" <[email-masked]>
Cc: "Cullen Jennings" <[email-masked]>;  "IESG IESG" <[email-masked]>; "IETF
discussion list" <[email-masked]>
Sent: Tuesday, February 01, 2011 6:01 PM

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

<snip>.
> provided is different if you are forced to use one port or two" and

This did get a thorough airing on the TLS list
in the second week of November
"[TLS] Security concerns around co-locating TLS and non-secure on same port
(WGLC: draft-ietf-tsvwg-iana-ports-08)"

As Paul said, some say yea and others nay.

Tom Petch

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Feb 2011 11:38:36 -0800

Hi, Tom,

Thanks - yes, I can see where reordering the sentences in that paragraph 
could make the issue much clearer. I'll do that in the pending update ...

Joe

On 2/2/2011 3:22 AM, t.petch wrote:
> From: "Joe Touch"<[email-masked]>
> To: "Paul Hoffman"<[email-masked]>
> "IETF discussion list"<[email-masked]>;<[email-masked]>; "IESG IESG"
> <[email-masked]>

---

From: Joe Touch <[email-masked]>
Date: Mon, 07 Feb 2011 20:31:32 -0800

Regardless, we're already moving forward to make the identities public 
(not sure if it's happening, or already happened).

Regardless, though, again, this is out of scope for this doc to address 
in detail, IMO.

Joe

On 2/7/2011 1:24 PM, Chris Benson wrote:
> Hi folks,
>
> Sam Hartman wrote (and others suggest):
>>>
> I don't see that "public identity" (of expert reviewers) is
> required for "interactive discussion".  Or would anonymous
> interaction fail a Turing test of some kind?
>
> Chris Benson.

---

From: Chris Benson <[email-masked]>
Date: Mon, 7 Feb 2011 13:24:52 -0800 (PST)

Hi folks,

Chris Benson.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 8 Feb 2011 20:41:36 +0000

> I don't see that "public identity" (of expert reviewers) is required for "interactive discussion".  
> Or would anonymous interaction fail a Turing test of some kind?

Public identity is required for reviewer accountability. It is easy to imagine how withholding registration of some required numbers may delay a competitor's products. The best protection against shade is sunlight.

-- Christian Huitema

---

From: Bob Hinden <[email-masked]>
Date: Wed, 9 Feb 2011 07:38:36 +0100

> Public identity is required for reviewer accountability. It is easy to imagine how withholding registration of some required numbers may delay a competitor's products. The best protection against s…

+1

Bob

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 12 Feb 2011 20:01:07 +0000

Hi Paul (and Cullen),

Paul Hoffman wrote:

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

I think the document (-10) was amended as requested, but can you please 
double check?

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 12 Feb 2011 20:02:34 +0000

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.

I believe this was clarified in -10.

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

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 15 Feb 2011 20:34:38 -0700

I propose some text for the draft near the bottom of this email....

> without considering the checks that are in place.

Sorry Magnus ... I really did not mean to twist your words. I know you are very straight up about this type of stuff. I suggested some text bellow. 

> check the arguments that the reviewer + IANA has given towards the

I understand that but we both know appeals are a painful tool to use and we would like to avoid it where possible - they waste an incredible amount of time for everyone involved and particularly the IESG. 

> - One can take a assignment request through the IETF process

I'm not as focused on drafts in IETF process but even in theses cases, WGs will look to this BCP for guidance on what would be acceptable behavior. So even if this draft might not "legally" block a WG from doing something, the WG will still be influenced by the goals this draft "strives" for. That is a good thing - BCP advice that applies to non IETF work should guide IETF process work too. 

> Cullen, what are your suggestion for how to improve the document?

For the user ports the document should have some text along the lines of:

There is not IETF consensus on when it is appropriate to use a second port for a secure version of protocol therefor the export reviewer should not reject a request for a second port to run a secure variant of the protocol over. 

The reason I think this needs to be in the draft is very simple. In my mind there are clear and compelling cases for two ports - many of them involving DTLS and real time protocols that actually care about number of round trips. Joe Touch has already said he would reject an example use case that I think should be accepted. I think this is much easier to resolve this issue now than with an appeal. 

The CORE WG, which I co-chair, needs clear advice now on what direction would be acceptable and is not particular interested in waiting for a year or two for the drafts to be done, appealed, and then redesigned.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 15 Feb 2011 19:59:20 -0800

On 2/15/11 7:34 PM, Cullen Jennings wrote:
> There is not IETF consensus on when it is appropriate to use a second
> port for a secure version of protocol therefor the export reviewer
> should not reject a request for a second port to run a secure variant
> of the protocol over.

That feels close, but too prescriptive. Also, the requests are usually 
for a protocol with two ports, not a later request for a second port. 
How about:

There is not IETF consensus on when it is appropriate to use a second 
port for a secure version of protocol. Therefore, an expert reviewer 
should not reject a proposal for a protocol that uses a second part to 
run a secure variant for the sole reason that it using two ports.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 15 Feb 2011 21:02:30 -0700

Paul's text is much better than mine. That was what I trying to get at. 

On Feb 15, 2011, at 8:59 PM, Paul Hoffman wrote:

> That feels close, but too prescriptive. Also, the requests are usually for a protocol with two ports, not a later request for a second port. How about:
> 
> There is not IETF consensus on when it is appropriate to use a second port for a secure version of protocol. Therefore, an expert reviewer should not reject a proposal for a protocol that uses a second part to run a secure variant for the sole reason that it using two ports.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 15 Feb 2011 21:07:34 -0700

Agreed, thanks to Paul for the proposed text.

On 2/15/11 9:02 PM, Cullen Jennings wrote:
>>> I propose some text for the draft near the bottom of this
>>> email.... For the user ports the document should have some text
>>> along the lines of:
>>> 
>>> There is not IETF consensus on when it is appropriate to use a
>>> second port for a secure version of protocol therefor the export
>>> reviewer should not reject a request for a second port to run a
>>> secure variant of the protocol over.
>> 
>> That feels close, but too prescriptive. Also, the requests are
>> usually for a protocol with two ports, not a later request for a
>> second port. How about:
>> 
>> There is not IETF consensus on when it is appropriate to use a
>> second port for a secure version of protocol. Therefore, an expert
>> reviewer should not reject a proposal for a protocol that uses a
>> second part to run a secure variant for the sole reason that it
>> using two ports.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 15 Feb 2011 21:31:29 -0700

I've been thinking more about this thread and my concerns about this draft. I was originally looking for the draft to have advice for the expert review team that gave them guidance on what the IETF thought was all right to approve or not approve. It's become clear that this draft does not have that advice and is not likely to get it in the very short term. This BCP will empower the expert reviewer to reject or approve just about any request. Appeals are not the best way to balance putting that power because they are incredibly corrosive and time consuming to everyone involved. I think this thread somewhat suggests an alternative approach for a check and balance. 

What do people think of the idea of: for all ports requests, the request and the expert reviewer reposes including reason for accepting or rejecting them need to be posted to a public email list. This seems like a simple way to help mitigate this issue and it will help educate people writing a port request to know what types of issues they need to address and what would be appropriate or not. 

Pros & cons of this idea?

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 16 Feb 2011 11:11:36 +0000

>>Paul's text is much better than mine. That was what I trying to get
Agreed, I will add this as an RFC Editor's note.

>>>is using two ports.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 16 Feb 2011 07:13:51 -0500

Cullen, there's a lot of history with port registrations.  As you're
probably aware in the past, there was a procedure for experts to sign an
NDA before reviewing port requests.  It's my understanding that is no
longer done.  However, it does suggest there's strong desire for
proprietary protocol support.
So, there's lots of complexity specific to this registry here that I
don't know about.

However, the general idea of having experts reviews on a public list, or
even soliciting comments on a public list is well supported. There's
specific discussion of this in RFC 5226. We've done it successfully in a
number of cases.  So, there's reason to believe that things in this
space could be effective for IANA registries.  I think soliciting public
comments on port requests would be bad; I think your proposal of having
the request/response be published would be as far as we should go for
this registry at this time.

So, I don't have the background to say this would be a good fit for the
port registry, but to the extent that my background supports something
like this I can support your idea. It's worked elsewhere at lesat.

---

From: "t.petch" <[email-masked]>
Date: Wed, 16 Feb 2011 12:13:18 +0100

---- Original Message -----
From: "Cullen Jennings" <[email-masked]>
To: "Christian Huitema" <[email-masked]>
Cc: <[email-masked]>; "Paul Hoffman" <[email-masked]>; "Chris Benson"
<[email-masked]>; "IESG IESG" <[email-masked]>; "Sam Hartman"
<[email-masked]>; "IETF discussion list" <[email-masked]>
Sent: Wednesday, February 16, 2011 5:31 AM
>
> I've been thinking more about this thread and my concerns about this draft. I
was originally looking for the draft to have advice for the expert review team
that gave them guidance on what the IETF thought was all right to approve or not
approve. It's become clear that this draft does not have that advice and is not
likely to get it in the very short term. This BCP will empower the expert
reviewer to reject or approve just about any request. Appeals are not the best
way to balance putting that power because they are incredibly corrosive and time
consuming to everyone involved. I think this thread somewhat suggests an
alternative approach for a check and balance.

Cullen

My understanding of this draft is that Expert Review only applies when "IETF
Review" or "IESG Approval" does not apply, so a duly approved Standards
Track RFC trumps all Experts.

I proposed text on 2nd February to make this clearer, and understand that this
change was accepted.

Where the request is not via "IETF Review" or "IESG Approval", then I have
less concern as to what the Expert may or may not allow.

My  text is

"For most IETF protocols, ports in the User Ports range will be assigned under
the "IETF Review" or "IESG Approval" procedures [RFC5226] and no further
documentation is required.

Where these procedures do not apply, then the requester must
input the documentation 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."

Tom Petch

> What do people think of the idea of: for all ports requests, the request and
the expert reviewer reposes including reason for accepting or rejecting them
need to be posted to a public email list. This seems like a simple way to help
mitigate this issue and it will help educate people writing a port request to
know what types of issues they need to address and what would be appropriate or
not.
> > Public identity is required for reviewer accountability. It is easy to
imagine how withholding registration of some required numbers may delay a
competitor's products. The best protection against shade is sunlight.