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

[Ted Hardie <[e-mail]>]

On Sat, Jan 30, 2016 at 11:10 AM, Brian E Carpenter <
[e-mail]> wrote:

> Ted,
>
> On 30/01/2016 21:28, Eliot Lear wrote:
> ...
> > On 1/27/16 4:50 PM, Ted Hardie 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.
>
> 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,

You are right; I wrote in haste and should have said can only be
done after consultation with the IESG on delay or commentary.

The larger point is that we have tried to make sure that there is
a flow of communication between the IESG (and IETF) and the
ISE about the relationship of work brought to the ISE and ongoing work,
as well as on what John called the question of whether a particular
candidate document is 'dumb or dangerous'.

It is on this latter point that  I hope that the editorial board and
ISE spend their time.  The document before the ISE represents
an example of a pattern of behavior that is deeply inimical to privacy
on the network: identifying metadata insertion by middleboxes
("The information conveyed in the HOST_ID option is intended to uniquely
identify the sending host
​").  It is certainly not the first time we have
seen this pattern nor the first time it has been documented in an RFC.
But supporting it again, as an option to TCP itself, carries a very high
risk.
That risk is that users' trust in the network, already eroded by government
action, will erode further or fail.  If this document flatly described what
is being done or spoke in depth about the risks, it might still be worth
publishing.  It does not.  It speaks about this in terms of an experiment,
which it is
not, and it speaks about the value in terms far more laudatory than are
warranted.
That is the point of danger I believe the IESG saw clearly, and that is the
point
on which I support their recommendation.

If the ISE and the editorial board remain conflicted on this point, I note
that
the ISE may ask for further advice from the IAB:

   The RFC Editor or the author may request that the IAB review the
   IESG's request to delay or not publish the document and request that
   the IAB provide an additional opinion.  Such a request will be made
   public via the RFC Editor Web site.  As with the IESG review itself,
   the IAB's opinion, if any, will be advisory.  And, as with author
   requests for an IAB technical review (see Section 4.5
<https://tools.ietf.org/html/rfc4846#section-4.5>), the IAB is
   not obligated to perform this type of review and may decline the
   request.

While I do not speak for the IAB on this point, I would personally work to
see that it
did not decline and provided a response promptly, should the ISE request
one.

As noted above, this would be advisory and it may well not be
necessary given the review no doubt being done now by the advisory board.

regards,

Ted