Ted,
On 02/02/2016 06:54, Ted Hardie wrote:
> On Sat, Jan 30, 2016 at 11:10 AM, Brian E Carpenter <
> brian.e.carpenter@xxxxxxxxx> 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.
Speaking personally, I have detested the idea of a non-cryptographic host ID
since it was first mooted:
https://mailarchive.ietf.org/arch/msg/int-area/Fd0Y0cX3_Ed8NAv75h0J8Z1Y5hI
In IPv6-land we've been working quite hard over the years to reduce privacy
risks without destroying end-to-end properties, e.g. RFC 4941, RFC 7217,
draft-ietf-6man-ipv6-address-generation-privacy and draft-ietf-6man-default-iids.
I would be unhappy to see a TCP option that nullifies these efforts in
widespread use.
However, in fairness to the draft in question, I think people do need to
re-read RFC 6967 (IETF stream) and RFC 7620 (Independent stream) first.
The draft wasn't written in a vacuum.
Brian
> 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
>