Subject: Re: Results of IETF-conflict review for draft-williams-exp-tcp-host-id-opt-07

From: Harald Alvestrand <[email-masked]>
Date: Wed, 27 Jan 2016 11:10:54 +0100

This one surprised me a bit.

Asking for blockage of an ind-sub is a fairly unusual thing.
I kind of expected to find in the IESG review would explain the nature
of the conflict, but the totality of the review is:

"The IESG has concluded that this document violates IETF procedures about
pervasive monitoring (RFC 7258) and should therefore not be published
without IETF review and IESG approval. This work is related to IETF work
done in the INTAREA WG."

The procedures I could find described in RFC 7258 are these:

   Those developing IETF specifications need to be able to describe how
   they have considered PM, and, if the attack is relevant to the work
   to be published, be able to justify related design decisions.  This
   does not mean a new "pervasive monitoring considerations" section is
   needed in IETF documentation.  It means that, if asked, there needs
   to be a good answer to the question "Is pervasive monitoring relevant
   to this work and if so, how has it been considered?"

   In particular, architectural decisions, including which existing
   technology is reused, may significantly impact the vulnerability of a
   protocol to PM.  Those developing IETF specifications therefore need
   to consider mitigating PM when making architectural decisions.
   Getting adequate, early review of architectural decisions including
   whether appropriate mitigation of PM can be made is important.
   Revisiting these architectural decisions late in the process is very
   costly.

The draft in question does have a "Pervasive Monitoring Considerations",
so the issue has certainly been considered by the authors. One may agree
or disagree with their conclusions, but one can't argue that they didn't
consider it.

Armchair lawyers will also note that the procedure refers to "IETF
specifications". An independent-submission RFC is *not* an IETF
specification.

Note: I'm not arguing that this particular idea is bad or good.

I'm saying that the IESG's justification for recommending it not be
published needs to be more explicit about what the problem is, and why
requesting an IESG note to be added saying "this is a Bad Idea" isn't a
better IESG response.

Harald

Den 26. jan. 2016 00:13, skrev The IESG:
> The IESG has completed a review of draft-williams-exp-tcp-host-id-opt-07
> consistent with RFC5742.
> 
> 
> The IESG recommends that 'Experimental Option for TCP Host
> Identification' <draft-williams-exp-tcp-host-id-opt-07.txt> NOT be
> published as an Experimental RFC.
> 
> 
> The IESG has concluded that this document violates IETF procedures about
> pervasive monitoring (RFC 7258) and should therefore not be published
> without IETF review and IESG approval. This work is related to IETF work
> done in the INTAREA WG.
> 
> The IESG would also like the Independent Submissions Editor to review the
> comments in the datatracker related to this document and determine
> whether or not they merit incorporation into the document. Comments may
> exist in both the ballot and the history log.
> 
> The IESG review is documented at:
> https://datatracker.ietf.org/doc/conflict-review-williams-exp-tcp-host-id-opt/
> 
> A URL of the reviewed Internet Draft is:
> https://datatracker.ietf.org/doc/draft-williams-exp-tcp-host-id-opt/
> 
> The process for such documents is described at
> https://www.rfc-editor.org/indsubs.html 
> 
> Thank you,
> 
> The IESG Secretary
> 
> 
>

---

From: John C Klensin <[email-masked]>
Date: Wed, 27 Jan 2016 06:06:41 -0500

I join Harald in objecting to this recommendation without
further explanation, although for a slightly different reason:

--On Wednesday, January 27, 2016 11:10 +0100 Harald Alvestrand
<[email-masked]> wrote:

> I kind of expected to find in the IESG review would explain
> the nature of the conflict, but the totality of the review is:
> 
> "The IESG has concluded that this document violates IETF
> procedures about pervasive monitoring (RFC 7258) and should
> therefore not be published without IETF review and IESG
> approval. This work is related to IETF work done in the
> INTAREA WG."
> 
>...
 
But it is even more than anything specific to 7258:   It might
be just a matter of poor phrasing, but the IESG objections
appears to say "this disagrees with an established IETF
position, therefore it should not be published without IETF
approval" and, by implication "approval that will never be
forthcoming because it agrees with an IETF established
position".  

I don't think the IESG should be saying such things and that, if
they do, the ISE should ignore them.  It has been an explicit
goal of what we now call the Independent Stream, since long
before we divided the streams up and gave them names or
established procedures for IESG review of independent
submissions, to be able to use the RFC Series to publish
specifications of, or dissents from, IETF (or NWG) positions.
If the IESG were to say "this isn't explicitly enough a dissent
or alternative" or "there is ongoing work with which this might
create confusion, please give us some months to finish up that
work so both can be published together" those would be entirely
reasonable statements/ requests and well within the bounds set
by RFC 4846.   But the statement above appears to be an attempt
by the IESG to censor material with which it disagrees and,
independent of the substantive merits of this particular
document (or of 7258), we just should not go there.

> I'm saying that the IESG's justification for recommending it
> not be published needs to be more explicit about what the
> problem is, and why requesting an IESG note to be added saying
> "this is a Bad Idea" isn't a better IESG response.

What he said, although I think "this is a Bad Idea" IESG notes
should require justification, explanation, and an author
opportunity to rebut the IESG view.

    john

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 Jan 2016 08:35:29 -0300

> or disagree with their conclusions, but one can't argue that they didn't

I agree with Harald.

Besides, if this proposal is knocked down for including a host_id option
(which, skimming through the I-D doesn't seem to be some global
identifier) in flows that traverse a nat, then I wonder:

   What would be the take on deploying IPv6 on such network, since that
   would obviously reveal host identity even more than a host_id option?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Jari Arkko <[email-masked]>
Date: Wed, 27 Jan 2016 16:02:07 +0200

Ack - thanks for the question/feedback. I’d have a personal perspective, but I wanted to get the reaction from the IESG. Stay tuned.

Jari

---

From: Ted Hardie <[email-masked]>
Date: Wed, 27 Jan 2016 07:50:16 -0800

> or disagree with their conclusions, but one can't argue that they didn't
​I think you missed "able to justify related design decisions" in the
text you pasted above.  The document does consider pervasive monitoring,
but the related design decisions (which make user tracking substantially
easier) are not justified in the draft.  Further, the draft appears to hint
that it has IETF approval when it clearly does not; here's the text from the
abstract:

   Recent proposals discussed in the IETF have identified benefits to
   more distinctly identifying the hosts that are hidden behind a shared
   address/prefix sharing device or application-layer proxy.  Analysis
   indicates that the use of a TCP option for this purpose can be
   successfully applied to some use cases.

​The proposals have identified benefits according to the authors,
but the IETF declined to adopt them because there were far bigger
downsides.  This abstract gives the opposite impression, which is not
exactly kosher.

> specifications". An independent-submission RFC is *not* an IETF
​Yes, and we have historically said that publishing things in
the ISE stream when they counter IETF specifications can
only be done when the IESG deems there to be no conflict
with IETF specifications.  This clearly does conflict with the
thrust of efforts in the IETF (e.g. tcpinc). ​

> requesting an IESG note to be added saying "this is a Bad Idea" isn't a
​I can certainly support a request to the IESG to be more clear on
its reasoning, but I also strongly support their decision in this case.
While this experimental code point is in use, encouraging its further
deployment and accepting this document's analysis of the tradeoff
with pervasive monitoring concerns is contrary to ongoing work
in the IETF.  A "do not publish" seems to me entirely warranted here.

Wearing no hats,

Ted​

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Jan 2016 08:43:56 +1300

John,

Just on one aspect of your comments:
On 28/01/2016 00:06, John C Klensin wrote:

...
> opportunity to rebut the IESG view.

Well, I thought the purpose of RFC 5742 was to limit the amount
of time (and therefore the depth of review) that the IESG "invests"
in independent submissions. They aren't obliged to provide a proposed
IESG Note. In this case they chose not to. Unarguably, that leaves the
decision with the ISE.

There is in fact considerable IESG discussion logged at
https://datatracker.ietf.org/doc/conflict-review-williams-exp-tcp-host-id-opt/history/
which I found from the link given in the IESG message.

There was also some discussion in TCPM but clearly no consensus to proceed.
Quite apart from privacy arguments, there was technical concern:
https://mailarchive.ietf.org/arch/msg/tcpm/IyRmcgoXFgWqIiAdNhGE7M4DMOw

Honestly I don't smell a rat here. There's no way to fix this document
to alleviate the privacy concern; the technical concern is quite
compatible with Experimental status. Both concerns are clear enought
in the IESG and TCPM records, and no doubt the authors are well aware
of them. The ISE gets to decide.

   Brian

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 Jan 2016 21:47:22 +0000

> which I found from the link given in the IESG message.

Actually, if people do find that sufficiently enlightening
or find it generates more questions, it'd be good to let
the IESG know eithr way, in case we miss stuff in crafting
a response (or to save us confusing matters more by trying
to clarify by adding words:-).

When I scanned the history, I think it did more or less
cover what I recall of the discussions (though that's easier
for me of course since I was part of 'em). The only missing
bit of info is that the IESG and ISE have arranged to have a
chat about all of our expectations for "returning items and
5742 review." We've had a couple of those recently, (one
that was easy-peasy and then this one:-), and people were a
bit confused about the right way to handle stuff. That chat
is planned to happen @ IETF95.

Cheers,
S.

---

From: S Moonesamy <[email-masked]>
Date: Fri, 29 Jan 2016 15:22:51 -0800

Hi Stephen,
>is planned to happen @ IETF95.

I am on the Independent Submissions Editorial Board.  The following 
is my opinion.

There are two points in the Conflict Review:

   (a) draft-williams-exp-tcp-host-id-opt-07 violates IETF procedures about
      pervasive monitoring (RFC 7258)

   (b) This work is related to IETF work done in the INTAREA WG.

BCP 188 does not apply to the Independent Stream as it would apply to 
a document in the IETF Stream.  The Conflict Review note is skimpy on 
the details.  As I don't know the right way to handle this stuff I 
thought that it would be better to have a conversation with you.  I 
would consider what is in RFC 4846 if I review the draft.  There is, 
for example: "

    'the [IESG] evaluation should focus exclusively on conflicts or
     confusion with IETF process and attempts to subvert ("end run")
     working group activities.'

Is it appropriate to DNP an Independent Stream draft because the IESG 
or the IETF does not agree to publication of the technical 
specification?  That would raise questions about the meaning of the 
word "Independent".

Regards,
S. Moonesamy

---

From: Eliot Lear <[email-masked]>
Date: Sat, 30 Jan 2016 09:28:06 +0100

Hi,

> downsides.  This abstract gives the opposite impression, which is not

I agree with Ted about the abstract; that at the very least it should be
reworded.  Referring to the IETF needs to be fairly done in the
independent series.  We already have enough problems with people
distinguishing IETF from independent work.  However...

> thrust of efforts in the IETF (e.g. tcpinc). ​

RFC 5742 is quite explicit.  BCP88 itself is not a specification but a
Best Current Practice, and limits its applicability to IETF, and not
independent, specifications.  As to whether this conflicts with "the
thrust of efforts in" tcpinc, that is not what the IESG wrote.  If it
had written it, the justification would have to again be based on what
is stated in RFC 5742, specifically in Section 3.  There should be at
least sufficient information to indicate what the nature of the conflict
is.  Having a different opinion than that of the IETF or a working group
is *not* a justification for non-publication, but rather a justification
for the existence of the ISE.

In short, I believe the IESG erred procedurally, and would suggest they
revisit their approach.  Haralds query about attaching an IESG note
seems entirely appropriate.

Eliot

---

From: "Dr. Sandeep Joshi [MU - Jaipur]" <[email-masked]>
Date: Sat, 30 Jan 2016 08:30:37 +0000

Hi,
Anyone can let me know our IETF group name.
Sandeep Joshi

From: ietf [mailto:[email-masked]] On Behalf Of Eliot Lear
Sent: 30 January 2016 13:58
To: Ted Hardie; Harald Alvestrand
Cc: IETF
Subject: Re: Results of IETF-conflict review for draft-williams-exp-tcp-host-id-opt-07

Hi,

I agree with Ted about the abstract; that at the very least it should be reworded.  Referring to the IETF needs to be fairly done in the independent series.  We already have enough problems with people distinguishing IETF from independent work.  However...

RFC 5742 is quite explicit.  BCP88 itself is not a specification but a Best Current Practice, and limits its applicability to IETF, and not independent, specifications.  As to whether this conflicts with "the thrust of efforts in" tcpinc, that is not what the IESG wrote.  If it had written it, the justification would have to again be based on what is stated in RFC 5742, specifically in Section 3.  There should be at least sufficient information to indicate what the nature of the conflict is.  Having a different opinion than that of the IETF or a working group is not a justification for non-publication, but rather a justification for the existence of the ISE.

In short, I believe the IESG erred procedurally, and would suggest they revisit their approach.  Haralds query about attaching an IESG note seems entirely appropriate.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 31 Jan 2016 08:10:45 +1300

Ted,

On 30/01/2016 21:28, Eliot Lear wrote:
...
...
>> with IETF specifications.

Not so. What the community has said (in RFC 4846) is that such a conflict
is a legitimate ground for the IESG to object to publication, with the IETF
procedures around this documented in BCP 92. It is then the ISE's prerogative
to decide whether to publish or not, after reviewing the IESG's objection
and any other relevant input.

That includes, but is not limited to, input from the Editorial Board, of which
I am a member.

   Brian

---

From: John C Klensin <[email-masked]>
Date: Sat, 30 Jan 2016 15:18:05 -0500

--On Saturday, January 30, 2016 09:28 +0100 Eliot Lear
<[email-masked]> wrote:

>> ​Yes, and we have historically said that publishing things
>> in the ISE stream when they counter IETF specifications can
>> only be done when the IESG deems there to be no conflict with
>> IETF specifications.  This clearly does conflict with the
> RFC 5742 is quite explicit.  BCP88 itself is not a
> specification but a Best Current Practice, and limits its
> applicability to IETF, and not independent, specifications.
> As to whether this conflicts with "the thrust of efforts in"
> tcpinc, that is not what the IESG wrote.  If it had written
> it, the justification would have to again be based on what is
> stated in RFC 5742, specifically in Section 3.  There should
> be at least sufficient information to indicate what the nature
> of the conflict is.  Having a different opinion than that of
> the IETF or a working group is *not* a justification for
> non-publication, but rather a justification for the existence
> of the ISE.

One clarification: independent of whatever 5742 has to say about
what complaints the IESG can make, the instructions and guidance
for the ISE are in 4846.  For all practical intents and
purposes, that document say that the IESG can only make two
types of "do not publish" requests and both, as Brian notes, are
_requests_:

(1) "If you decide to publish, please delay doing that for a
reasonable period of time until related IETF work can be
completed and published".

(2) "We think this is a dumb and/or dangerous idea and that the
ISE should consider whether or not to publish it."

As far as I know, the ISE (and the RFC Editor before we split
the ISE function out) have never declined to honor a delay
request that involved a reasonable and more or less fixed amount
of time.  As to the second, while I would expect the ISE to give
special consideration to such a comment from the IESG, any
member of the community can make similar comments and expect
them to be treated seriously.    I believe the general
expectation is that such comments will be taken seriously to the
extent to which they are well and clearly justified and that
comments based on assertions of authority are less likely to be
treated seriously.  The latter is, of course, consistent with
most of our expectations about arguments and statements of
positions in the IETF.

That is ultimately a key part of what "independent" is all
above.  The most powerful option that either the IESG or any
member of the community has is to prepare and submit a document
containing a dissenting view, one that explains why a particular
idea is a bad one.  

     john

(Like Brian, I'm a member of the Editorial Board and I hope it
is no surprise or secret that these issues are being discussed
there as well.)