On Sat, Jan 30, 2016 at 11:10 AM, Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote:
The larger point is that we have tried to make sure that there is
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
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
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.
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:
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
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), 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