Subject: [port-srv-reg] RFC Editor notes for draft-ietf-tsvwg-iana-ports

From: Alexey Melnikov <[email-masked]>
Date: Sun, 13 Mar 2011 18:55:11 +0000

Hi,
I've talked to IESG about the reference to [I-D.touch-tsvwg-port-use] 
and based on the feedback I've added some RFC Editor notes to remove any 
references to it.

Below is the full list of RFC Editor notes. If I don't hear any 
objections, I will approve the document with these RFC Editor notes 
within 1 week.

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

Add to the end of Abstract a new paragraph:

At the time of writing of this document internal procedures of the IANA
ports and services Expert Review team are not documented in an RFC
and this document doesn't change that.

In Section 7.2, 1st paragraph, last sentence:

OLD:
These principles and general advice to users on
port use are expected to change over time and are therefore
documented separately, please see [I-D.touch-tsvwg-port-use].

NEW:
These principles and general advice to users on
port use are expected to change over time and are going
to be documented in a future document.

In Section 7.2, 5th paragraph:

OLD:
o IANA strives to assign only one assigned port number per service
or application

NEW:
o IANA strives to assign only one assigned port number per service
or application

Note: At the time of writing of this document there is no IETF consensus
on when it is appropriate to use a second port for a secure version of
a protocol. Therefore, an expert reviewer should not reject a proposal
for a protocol that uses a second port to run a secure variant for
the sole reason that it is using two ports.

In Section 7.2, 13th paragraphs:

OLD:
These principles of port conservation are explained further in
[I-D.touch-tsvwg-port-use]. That document explains in further detail
how ports are used in various ways, notably:

NEW:
Ports are used in various ways, notably:

In Section 8.1.1, 13th paragraph, last sentence:

OLD:
Note that
the applicant MUST NOT use the requested port prior to the
completion of the assignment.

NEW:
Note that the applicant MUST NOT use the requested port
in implementations deployed for use on the public Internet prior to the
completion of the assignment, because there is no guaranty that
IANA will assign the requested port.

Please make the following reference Normative:

[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.

Please delete the following Informative reference:

[I-D.touch-tsvwg-port-use]

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 14 Mar 2011 09:15:47 +0100

Hi,

I am fine with these changes.

Cheers

Magnus

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

-- 

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: Joe Touch <[email-masked]>
Date: Mon, 14 Mar 2011 10:52:56 -0700

Hi, all,

Speaking as an individual, not for the entire authors team, some notes 
below. Please let me know how to proceed.

Joe

> objections, I will approve the document with these RFC Editor notes

I disagree to this addition.

First, there are no RFCs that document the internal processes of any 
Expert Review team, AFAIK (if there are, please let me know). Every RFC 
would need such a statement if so. It directly contradicts some text 
below as well.

At best, the statement should be in the intro, not the abstract, and 
should be corrected to:

--
The internal procedures of Expert Review teams, including that of IANA's 
port review team, are not documented in RFCs and this document doesn't 
change that.
--

> to be documented in a future document.

This document should not promise something without a specific pointer. 
At best, this should be corrected to:

--
These principles and general advice to users on port use are expected to 
change over time.
--

> the sole reason that it is using two ports.

We went to great lengths NOT to mention the security issue or whether it 
impacts this principle. I see no reason for the note. At best, it should 
focus on the need for second ports for insecure versions, as we would 
expect security to be addressed:

--
Note: At the time of writing of this document there is no IETF consensus 
on when it is appropriate to use a second port for an inecure version of 
a protocol.
--

The second sentence needs to be dropped, as per the initial suggested 
note to the abstract.

Further, I disagree that it is within the IESG's purvue to proscribe how 
an Expert Review team makes decisions at all; the IESG already has 
override authority on Expert Review decisions. That's yet another reason 
the second sentence is inappropriate.

> Ports are used in various ways, notably:

Agreed,

> IANA will assign the requested port.

Agreed.

> RFC 4960, September 2007.

Agreed.

> [I-D.touch-tsvwg-port-use]

Agreed.

----

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 14 Mar 2011 22:13:57 +0000

> Hi, all,

Hi Joe,

> Expert Review team, AFAIK (if there are, please let me know).

This is a distinction without a practical difference. There is no 
document that details this specific review team process, whether a 
general (covering all design teams), or just this one.

> Every RFC would need such a statement if so. It directly contradicts 
> some text below as well.
>
> The internal procedures of Expert Review teams, including that of 
> IANA's port review team, are not documented in RFCs and this document 
> doesn't change that.
> -- 
>
> These principles and general advice to users on port use are expected 
> to change over time.
> -- 

I am Ok with this change.

> We went to great lengths NOT to mention the security issue or whether 
> it impacts this principle. I see no reason for the note. At best, it 
> should focus on the need for second ports for insecure versions, as we 
> would expect security to be addressed:
>
> -- 
> Note: At the time of writing of this document there is no IETF 
> consensus on when it is appropriate to use a second port for an 
> insecure version of a protocol.

I am Ok with this part.

There was sufficient mailing list consensus to say exactly that. I don't 
think this sentence should be removed.

> Further, I disagree that it is within the IESG's purvue to proscribe 
> how an Expert Review team makes decisions at all; the IESG already has 
> override authority on Expert Review decisions. That's yet another 
> reason the second sentence is inappropriate.

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Mar 2011 15:24:20 -0700

Hi, Alexey,

> general (covering all design teams), or just this one.

My point is that the Expert Review team is appointed with IESG approval, 
but does not follow any proscribed process - that holds for all review 
teams.

I don't see a reason for this document to declare that specifically for 
this document's content, or for the ports review team.

> think this sentence should be removed.

Although I appreciate that the mailing list consensus was to have the 
IESG direct the Experts Review team, that is outside the IESG's purvue. 
The IESG already has override authority, and there is no precedence for 
the IESG to give directions to any expert review team in this manner.

Whether there was consensus or not, it is, AFAICT, a procedural error to 
insert this text. The IESG simply does not have that authority to 
preemptively direct an expert review team's decisions.

Joe

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 14 Mar 2011 22:33:54 +0000

>> general (covering all design teams), or just this one.
I don't particularly like your proposed replacement. I can live with it 
if it is prefixed with "At the time of writing of this document", i.e.

At the time of writing of this document the internal procedures of 
Expert Review teams, including that of IANA's port review team, are not 
documented in RFCs and this document doesn't change that.

I think this is my last offer.

> My point is that the Expert Review team is appointed with IESG 
> approval, but does not follow any proscribed process - that holds for 
> all review teams.
>
> I don't see a reason for this document to declare that specifically 
> for this document's content, or for the ports review team.

This document is only concerned with a particular registry, I don't see 
a reason to make wider statements.

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Mar 2011 15:41:08 -0700

Hi, Alexey,

> I think this is my last offer.

That sounds fine. Can I put that in the intro, rather than the abstract?

Where are we on the statement that basically undermines this, i.e., that
gives IESG direction to the team on their reviews of secure/nonsecure
ports? Can we drop that, and just assume that the IESG will
reflect community consensus (that's it's role, AFAICT)?

(FWIW, I doubt we can squeak these mods in before the deadline at 5pm, 
but I don't think that's a big issue... they can also be corrected 
during AUTH-48, if preferred).

Joe

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 14 Mar 2011 22:46:35 +0000

> That sounds fine. Can I put that in the intro, rather than the abstract?

Sure.

> reflect community consensus (that's it's role, AFAICT)?

I am still thinking how unhappy I am with your statement ;-).
I am likely to reply tomorrow.

> during AUTH-48, if preferred).

No rush. I will edit RFC Editor notes.

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Mar 2011 16:49:08 -0700

Hi, Alexey,

On 3/14/2011 3:46 PM, Alexey Melnikov wrote:
...
> I am likely to reply tomorrow.

AOK. For context, my view - with my ports team chair hat on - is that 
the expert review process is intended to reflect technical judgment, but 
not necessarily reflect community consensus.

IMO, the community consensus would be that everyone gets as many ports 
as they ask for, regardless of rationale. AFAICT, the expert team - in 
this case, as elsewhere - is intended to balance that sort of view with 
the long-term health and welfare of the Internet as a whole and the 
resources they manage.

When the two positions collide, the IESG has the ability to override. 
They can reflect community consensus if necessary, when they feel that 
such needs override the technical judgment of the experts team.

I.e., to me these two forces are *supposed* to balance each other to 
some extent. I don't expect to see huge tension between the two, but it 
can happen - and I don't think that's a bad thing. When the IESG 
disagrees that an expert reviewer is doing their job sufficiently, they 
can always replace them.

Joe

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 18 Mar 2011 15:20:50 +0000

> Hi, Alexey,

Hi Joe,
I had to discuss this topic in IESG before replying to you.

> On 3/14/2011 3:13 PM, Alexey Melnikov wrote:
 [...]

>>>> consensus
> IESG direct the Experts Review team, that is outside the IESG's 
> purvue. The IESG already has override authority, and there is no 
> precedence for the IESG to give directions to any expert review team 
> in this manner.
>
> Whether there was consensus or not, it is, AFAICT, a procedural error 
> to insert this text. The IESG simply does not have that authority to 

This issue is complicated and some ADs supported your view. However at 
least 2 other ADs indicated that they would put a DISCUSS on the 
document if the RFC Editor note is deleted.

So the choice is between - no RFC Editor note and this document doesn't 
get published during my AD term, or we publish it now. I am sorry to 
say, but I am choosing the latter (and after some moaning within IESG 
ADs who supported your view decided to withdraw their objection.)

---

From: Joe Touch <[email-masked]>
Date: Fri, 18 Mar 2011 09:25:14 -0700

Hi, Alexey,

> ADs who supported your view decided to withdraw their objection.)

I do not accept the note.

I don't care what threats the IESG places on this document to get a note 
in that, IMO, is not in their scope to add.

Joe

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 18 Mar 2011 16:33:16 +0000

Joe Touch wrote:

> I don't care what threats the IESG places on this document to get a 
> note in that, IMO, is not in their scope to add.

If you prefer for the document to be stuck in limbo with DISCUSSes and 
which also result in a need to find another shepherding AD, then I can 
easily arrange that. However I don't believe this to be in the interest 
of the community.

---

From: Joe Touch <[email-masked]>
Date: Fri, 18 Mar 2011 09:38:20 -0700

> easily arrange that. However I don't believe this to be in the interest

I don't believe inserting that text is in the interest of the community 
either.

This doc has taken a while to get where it is, and I'd like to see it 
move forward to. But it also could open a door - one where the IESG 
directs the actions of Expert Review teams - and that door has never 
been opened before. I won't accept opening it here.

Joe

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 18 Mar 2011 16:46:21 +0000

Joe Touch wrote:

> I don't believe inserting that text is in the interest of the 
> community either.
>

Joe, you can't have it both ways. The section in question already says 
that the guidelines in the whole section are non binding on IANA.

---

From: Joe Touch <[email-masked]>
Date: Fri, 18 Mar 2011 10:16:48 -0700

IANA != expert review team

If you want to replace the team name with "IANA" it would be ok (but frankly as nonsensical, but that's fine by me)
Joe

On Mar 18, 2011, at 9:46 AM, Alexey Melnikov <[email-masked]> wrote:

>> I don't believe inserting that text is in the interest of the community either.
>> 
>> This doc has taken a while to get where it is, and I'd like to see it move forward to. But it also could open a door - one where the IESG directs the actions of Expert Review teams - and that door has never been opened before. I won't accept opening it here.
> 
> Joe, you can't have it both ways. The section in question already says that the guidelines in the whole section are non binding on IANA.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 18 Mar 2011 17:33:30 +0000

>If you want to replace the team name with "IANA" it would be ok (but frankly as nonsensical, but that's fine by me)
I think we need to have this discussion face-to-face in Prague. Please 
find me during the IETF reception. I would also like to have at least 
Lars, Michelle, Robert Sparks and Peter Saint-Andre in this discussion.

In the meantime, I invite all interest parties to contemplate the fate 
of this document and how strongly they feel about this issue. If we 
can't make any progress in Prague, then I will decide whether to approve 
the document with the RFC Editor note as previously proposed (noting 
objections), or to block the document until some bright and shiny future.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 18 Mar 2011 17:34:55 +0000

>> IANA != expert review team
This is a good point and I am not convinced I want to make this change. 
I need to reread the whole section.

>> If you want to replace the team name with "IANA" it would be ok (but 
>> frankly as nonsensical, but that's fine by me)
>
> can't make any progress in Prague, then I will decide whether to 
> approve the document with the RFC Editor note as previously proposed 
> (noting objections), or to block the document until some bright and 
> shiny future.
>
>> Joe
>>
>>>> This doc has taken a while to get where it is, and I'd like to see 
>>>> it move forward to. But it also could open a door - one where the 
>>>> IESG directs the actions of Expert Review teams - and that door has 
>>>> never been opened before. I won't accept opening it here.
>>>
>>> Joe, you can't have it both ways. The section in question already 
>>> says that the guidelines in the whole section are non binding on IANA.
>>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 22 Mar 2011 15:01:57 +0100

Hi,

First of all I don't like that this is only discussed on the author team
list and not on the WG mailing list.

Alexey, when you have thought things through, can you please post to the
TSVWG mailing list?

I think meeting in Prague can help the issue and sort out what the
issues are. Both from the ADs that want to discuss this and from us
authors and the WG.

Alexey, I think you likely will need to hand this over. Because just
approving it without ensuring that the WG has had its say on the changes
would be opening the door for an appeal.

Cheers

Magnus Westerlund

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 22 Mar 2011 14:57:32 +0000

>Alexey, when you have thought things through, can you please post to the
Will do.

Agreed.

>would be opening the door for an appeal.
The proposed change was posted to the IETF mailing list. People should 
have been paying attention.

---

From: Joe Touch <[email-masked]>
Date: Tue, 22 Mar 2011 09:06:00 -0700

Hi, all,

> list and not on the WG mailing list.

I agree. The WG mailing list needs to be cc'd on all messages on this 
doc. Merely posting to the main IETF list means messages get lost and/or 
ignored.

Case in point: the original proposed text to address secure ports ONLY 
addressed the desire to allow additional secure ports for current 
insecure assignments.

That has since morphed into direction to the Expert Review team as to 
what they can and cannot recommend in general, without any rationale as 
to why the ports ER team should require such micromanagement when no 
other ER team has similar explicit direction - and when the IESG already 
controls the appeal process.

Joe

---

From: "David Harrington" <[email-masked]>
Date: Tue, 22 Mar 2011 12:06:43 -0400

Hi,

This is a TSVWG document.
The proposed change is controversial.
The proposed changes should be explicitly reviewed by TSVWG,
especially since this is a transport-related issue.
This change was not a part of any version of the draft circulated to
TSVWG - which needs to be highlighed in a note, 
if this proceeds.
I am not convinced you will see WG consensus for this text.
I also doubt you would see consensus from the TSV-DIR, and the
proposed text has not had a TSV-dir review.

I objected during the telechat, and Lars missed the telechat because
he was/is on vacation.
I agreed to hold my nose because a number of ADs insisted it be
approved with the proposed text.
But I think this is a bad decision.
and since another AD is shepherding this, and my co-AD is an author, I
have not followed this very closely.
I was not aware until after the telechat that the proposed text had
never been through a TSVWG WGLC.
I spoke with Gorry (the TSVWG chair and the document shepherd) and he
thinks this text is a bad idea.

Do you really believe this text should be forced through despite the
objections of TSV at multiple levels?
You have objections from the ADs (now the ex-AD as well), the document
shepherd and  WG chair, WG members, the authors, and the review team?
(lots of overlap of course)

Hmmm, do I see a pattern here?

David Harrington
Director, IETF Transport Area
[email-masked] (preferred for ietf)
[email-masked]
+1 603 828 1401 (cell)

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alexey Melnikov
> Sent: Tuesday, March 22, 2011 10:58 AM
> To: Magnus Westerlund
> Cc: [email-masked]
> Subject: Re: [port-srv-reg] RFC Editor notes for 
> draft-ietf-tsvwg-iana-ports
> 
> Magnus Westerlund wrote:
> 
> >Hi,
> >

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 22 Mar 2011 17:09:55 +0000

Joe Touch wrote:

> doc. Merely posting to the main IETF list means messages get lost 
> and/or ignored.

Fair point.

> what they can and cannot recommend in general, without any rationale 
> as to why the ports ER team should require such micromanagement when 
> no other ER team has similar explicit direction - and when the IESG 
> already controls the appeal process.

The text proposed in the RFC Editor note was exactly as suggested on the 
IETF mailing list (by Peter Saint-Andre or Paul Hoffman). The only 
change I've made was to change "secure" to "insecure" as per your feedback.

---

From: Joe Touch <[email-masked]>
Date: Tue, 22 Mar 2011 10:30:34 -0700

> change I've made was to change "secure" to "insecure" as per your feedback.

If you can find that, please do. I can't locate it, but I may have been 
discussing only the point that the additional port of concern was the 
second insecure port, never the second secure one (i.e., that takes the 
legacy port issue off the table).

--

What I found was Cullen claiming that he didn't like previous decisions 
of the ER team, and that he didn't want disagreements on this point to 
need to be raised to the level of an appeal. His words were "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."

It's way out of line for the IESG to setup a straw man for review, and - 
on the basis of that discussion - claim that they need to jump in and 
preemptively direct decisions of the ER team.

Joe

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 22 Mar 2011 11:51:20 -0600

> The proposed change is controversial.

Just so that we're all on the same page, I assume that the proposed
change you're referring to is this:

   Note: At the time of writing of this document there is no IETF
   consensus on when it is appropriate to use a second port for an
   insecure version of a protocol. Therefore, an expert reviewer should
   not reject a proposal for a protocol that uses a second port to run
   a secure variant for the sole reason that it is using two ports.

> especially since this is a transport-related issue.

That seems quite reasonable (along with IETF-wide review).

> TSVWG 

And it seems to me that's because (1) this feedback was received during
IETF Last Call and (2) the authors did not publish a revised I-D
addressing the IETF LC feedback on this particular point.

> - which needs to be highlighed in a note, 
> if this proceeds.

Again, that seems reasonable.

> proposed text has not had a TSV-dir review.

And I'm not sure we will see IETF consensus for a document that doesn't
include this text, given the strong pushback received during IETF LC.

> I objected during the telechat, and Lars missed the telechat because

Naturally it would be good to have input from Lars.

> thinks this text is a bad idea.

I do think it would make sense to have a continued discussion about this
issue and the proposed text. Given that this issue arose during IETF
Last Call, discussion on the [email-masked] list seems appropriate at
some point (although perhaps after TSVWG discussion).

> objections of TSV at multiple levels?

First, I don't think it's productive to introduce "us vs. them" thinking
here.

Second, "force" is a very strong word, given that this issue arose
during IETF Last Call.

Third, ignoring what appeared to be IETF consensus against a hard
"no-two-ports" policy seems problematic to say the least.

> (lots of overlap of course)

I completely agree that we need to have discussion about this topic, and
I think it needs to be IETF-wide (at some point) instead of solely
within the Transport Area or the TSVWG. The IETF LC produced a lengthy
discussion, so clearly there is interest in this topic across areas.

> Hmmm, do I see a pattern here?

Again, I don't find that to be a productive comment.

Enough about procedure.

As to substance, the proposed change makes two points:

1. There is no IETF consensus on when it is appropriate to use a second
port for an insecure version of a protocol.

2. An expert reviewer may reject a port registry request that asks for
both a secure port and an insecure port, but not for the sole reason
that it requests two ports.

IMHO it might be appropriate for an expert reviewer to reject a two-port
request on the grounds that the particular protocol for which two ports
are requested includes (or could reasonably be expected to include) the
ability to upgrade an insecure version of the protocol to a secure
version of the protocol, for example via STARTTLS. However, the proposed
change does not rule out such a decision. All that the proposed change
says is that it's inappropriate for the expert reviewer to look at the
request, see that it asks for a secure port and insecure port, and as a
matter of policy reject the request simply and solely because the
request asks for two ports.

This exact point was the bone of contention during IETF Last Call: some
folks thought that it would be perfectly fine for an expert reviewer to
have a policy of rejecting all two-port requests solely because they ask
for a secure port and an insecure port, whereas other folks pointed to
the lack of IETF consensus about when it's appropriate for a protocol to
use a secure port and an insecure port, and therefore objected to a
hard-and-fast policy that rejects outright all two-port requests.

Now, perhaps the proposed text could be worded more clearly along the
lines I've suggested above (and I would be happy to work on better
text). However, if I've captured the issue accurately, then we might in
fact have two hardened camps here:

1. Those who say that it is never appropriate to assign a secure port
and an insecure port to a protocol, and thus who say that it is fully
appropriate for an expert reviewer to reject outright any port request
that asks for a secure port and an insecure port.

2. Those who say that we don't have IETF consensus about when it is
appropriate for a protocol to use both a secure port and an insecure
port, and thus who say that a policy of outright rejection for such
requests is unwarranted.

I'd like to hear from folks on the cc list if the foregoing
characterization is accurate.

If so, then we need to find consensus here. I'm not saying that will be
easy, but we need to try to get to consensus. And given the IETF Last
Call discussion, I really think that the consensus we achieve needs to
be IETF consensus, not only TSV Area or TSVWG consensus (naturally,
since this is a TSVWG document, TSVWG consensus is also important).

On behalf of no one but myself,

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Joe Touch <[email-masked]>
Date: Tue, 22 Mar 2011 11:27:11 -0700

Hi, all,

To be clear, from my view, there are separate issues here:

1) whether a service should warrant two ports

Legacy insecure services clearly can warrant a new port for a secure 
variant; that's not a point of contention.

New services, IMO, should be secure. The real question is whether a 
second port should be allocated for an insecure version, or whether the 
burden of dealing with possibly insecure connections should fall on the 
service to manage.

Yes, there is disagreement within the IETF as to whether, in this latter 
case, two ports are warranted or not. The current ER team advise is 
based on "first, conserve ports", i.e., given an ambivalent position, 
favor the view that conserves ports.

There are *always* exceptions, and the doc has many wiggle words to 
enable such exceptions.

2) whether the document should make specific advice on how many ports 
are permitted

It currently says that IANA strives to conserve ports, with one per 
service. That leaves the window open on several counts:
	- strives is intentionally vague
	- service is intentionally undefined; one could
	argue that the insecure version is a different service
	- the entire section has a caveat that recommendations
	are not binding

3) whether the document should direct IANA

The IESG already has the ability to override IANA recommendations upon 
appeal. It already directs IANA on how to handle various assignments.

4) whether the document should direct the ER team

The IESG already has the ability to override IANA recommendations upon 
appeal, and to remove ER team members as needed.

Ultimately, these last two points boil down to whether the IESG should 
have the ability to preemptively direct IANA or the ER team on a point 
that for which there is no consensus, simply to avoid the need for an 
appeal.

There is no other place where I could find specific IESG limitations to 
decisions by an ER team.

If the goal is simply to allow two ports where warranted, that's simply 
already covered.

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 22 Mar 2011 18:35:23 +0000

My concern with the text to which Dave Harrington referred was in 
relation to the last added sentence that  "prescribed" a review pattern 
from the Expert Review Team on one particular topic, rather than 
formally stating the lack of consensus.

My other "shepherd" comments to my AD were procedural, these are now 
already captured below.

So: I can increase the Agenda time in TSVWG to cover this discussion, 
but PLEASE PLEASE all think about getting some text proposed that the 
few people who objected strongly in IETF LC could agree to.

In the past, this document has touched on other sensitive issues and 
found solutions, let's try and get this quickly resolved.

Gorry
(Co-Chair of TSVWG/Doc Shepherd)

---

From: "David Harrington" <[email-masked]>
Date: Tue, 22 Mar 2011 14:48:15 -0400

Hi Joe,

I am going to disagree with you that no ER team has such explicit
direction.
RFC 5226 says:
   Designated experts are expected to be able to defend their
decisions
   to the IETF community, and the evaluation process is not intended
to
   be secretive or bestow unquestioned power on the expert.  Experts
are
   expected to apply applicable documented review or vetting
procedures,
   or in the absence of documented criteria, follow generally accepted
   norms, e.g., those in Section 3.3.

note the "documented review or vetting procedures"
This is a normal thing for ER teams.
For example:
See RFC3365, Strong Security Requirements for Internet Engineering
Task Force Standard Protocols, applied during Security Directorate
expert reviews.
See RFC4181, Guidelines for MIB Documents, applied during MIB Doctor
Expert reviews.
See RFC5706, applied during Operations Directorate expert reviews.
and there are many others.

David Harrington

> [mailto:[email-masked]] On Behalf Of Joe Touch
> Sent: Tuesday, March 22, 2011 12:06 PM
> To: Magnus Westerlund

---

From: Joe Touch <[email-masked]>
Date: Tue, 22 Mar 2011 11:55:31 -0700

Hi, David,

> and there are many others.

Yes; how many (if any) of these actually say what an ER team should decide?

What they say is "what an applicant needs to do", not how the ER team 
should make final decisions. It's the ER team's decision to determine to 
what extent the doc is followed or not.

We have NO such doc stating how whether a service should use one or two 
ports at all, or whether insecure ports are even appropriate at this 
time. At best, the IESG should be directing the applicant, i.e., "the 
applicant may apply for multiple ports, subject to sufficient 
justification".

I don't think the doc should direct ER decisions explicitly. That 
preempts the ER process and the appeals process.

Joe

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 22 Mar 2011 19:34:55 +0000

>and there are many others.
Indeed.
In Apps, I've processed and written many documents that prescribe how 
expert reviewers should behave. This is very typical.

>>>First of all I don't like that this is only discussed on 
>>>      
>>>
>>the author team
>>    
>>
>>I agree. The WG mailing list needs to be cc'd on all messages on
>>    
>>
>this 
>  
>
>>That has since morphed into direction to the Expert Review team as
>>    
>>
>to 
>  
>

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

---

From: Joe Touch <[email-masked]>
Date: Tue, 22 Mar 2011 12:44:03 -0700

On 3/22/2011 12:34 PM, Alexey Melnikov wrote:
...
> expert reviewers should behave. This is very typical.

What we have here is a doc that specifically directs ER decisions. I 
have not found that in any other document. I have found docs that direct 
what applicants should be doing - with the expectation that the ER team 
would consider that doc, as all other relevant IETF requirements - in 
their decision.

If you can point to a specific case where a doc says what an ER team can 
and cannot approve, please provide it.

In this case, FWIW, what we have is an IETF whose consensus is that 
there is no consensus - on whether multiple ports for secure protocols 
are generally approved, and an ER team whose current assumption is that 
- in the absence of specific justification - insecure ports are not 
appropriate, especially when a secure port is already available. This is 
both for security and to conserve ports.

The current proposed text ought to be toward the applicants, not the ER 
team. It is implied that the ER team will take such information into 
consideration.

However, if there is any view at all that the ER team serves the IESG 
directly and implements their policies verbatim, then there would not be 
a need for an appeals process.

Joe

---

From: "David Harrington" <[email-masked]>
Date: Tue, 22 Mar 2011 16:07:38 -0400

> From: Peter Saint-Andre [mailto:[email-masked]] 

You are absolutely right. I apologize for my tone.
I missed the 2/17 telechat and the discussion of the IETF LC that led
to this text being proposed.
I came into the middle of an ongoing argument, and it looks to me like
this change is being rushed through the process.
It appears to me people have issues with this proposed text for a
variety of reasons.

Let's slow down a bit and make sure we really do have consensus.

Again, I apologize for my tone.

dbh

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 22 Mar 2011 14:13:57 -0600

Hi Dave,

> Let's slow down a bit and make sure we really do have consensus.

Agreed. Probably some folks have felt rushed because Alexey was
understandably trying to finish this task before his term ends next
week. I completely agree that we need to make sure we have consensus on
these points, and as we know consensus can take time.

> Again, I apologize for my tone.

It's OK! We all get worked up about some of this stuff at times. At
least you care enough to be passionate. :)

The messages from Joe and Gorry seem to be very constructive (sorry, I
was in a meeting and haven't reviewed them yet in depth), so let's take
those as a basis for forward progress.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "David Harrington" <[email-masked]>
Date: Tue, 22 Mar 2011 16:34:45 -0400

Hi Joe,

from RFC4181:
 "Some time ago, the IESG instituted a policy of requiring expert
   review of IETF standards-track specifications containing MIB
modules..."
 "The purpose of this memo is to document the guidelines that are
followed in such reviews."

Let me provide a little history behind RFC4181.
Working groups would write MIB modules, and a MIB Doctor review would
get done, and the WG would adjust the module.
Which issues came up during the review were very largely dependent on
which MIB Doctor did the review.
And that especially showed up when the reviewer for a document
changed.
"Pet peeves" were a common source of "late surprises" during Expert
review.
MIB Doctor reviews became a significant sticking point in the approval
process.

So we leveled the playing field. With RFC4181, we
1) spelled out what authors of MIB documents should make sure to
address before submission,
2) we the rules clear enough to enable automation 
3) we constrained the MIB Doctors to use consistent rules in their
reviews, 
4) we made MIB Doctors clearly justify concerns that were not in the
guidelines, and
5) made it much easier for the ADs to see which comments were worthy
of discusses.

MIB Doctor reviews cause far fewer late surprises, and cause much less
delay during the approval process.
SECDIR and OPSDIR have certain guidelines they are expected to follow
as well, documented in RFCs.
The ENUM review process is documented. The YANG Doctors are working on
review guidelines.
It is very common to have dpcumented guidelines for expert reviews,
applicable to both the requesters and the reviewers.
I have asked the TSVDIR to produce a similar set of guidelines so
authors and WGs know what they need to address, and to document what
the reviewers will look for.

I strongly support such an approach for any expert team, including the
ports expert review team.
It is simply part of the desire for transparency that has strong IETF
consensus.
 
dbh

> From: Joe Touch [mailto:[email-masked]] 
> Sent: Tuesday, March 22, 2011 3:44 PM
> To: Alexey Melnikov
> Cc: David Harrington; 'Magnus Westerlund'; [email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 22 Mar 2011 21:55:08 +0100

Hi,

I think the guidelines for what is the recommended usage of ports is a
needed document. But I don't think we should include that in the
registry creation document. Also I think including one little small
snippet of such a recommendation in that document is the right thing.

There might even be parts which discusses how the review team is
working, but I think one can separate process from guidelines and
recommendations on port usages which is something that the protocol
designer should take to heart.

Which are the ADs that think the small part of the guidelines needs to
be in this document? Can they be convinced that this isn't smart?

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 22 Mar 2011 22:03:20 +0100

> snippet of such a recommendation in that document is the right thing.
is NOT the right thing is what is should say.

Magnus

-- 

Magnus Westerlund