Hi Paul,
On 04/02/16 16:15, Paul Hoffman wrote:
FWIW, the reason I'm pushing on this is that it feels like the IESG is
violating the spirit of RFC 5742 by saying "The IETF doesn't want to
work on this draft, so you should not publish it". That removes a lot of
the independence from the ISE.
That wasn't the IESG's conclusion but see below...
The TCP option detailed in draft-williams-exp-tcp-host-id-opt is
extending an IETF protocol, and a very important IETF protocol, i.e.,
TCP, that requires IETF review and consensus. Furthermore, the
proposed mechanism allows middleboxes to tag TCP connections with
additional identifiers that persistently can mark users. Therefore,
the IESG concluded that this draft violates RFC 7258, and does so
while extending an IETF protocol.
To reiterate what some others have said on this thread: please specify
how this draft "violates" RFC 7258. My reading of that RFC and the
discussion that lead to it, comes to a very different conclusion.
"violates" comes from 5742, option #4.
I think one could indeed argue that the formal IESG response text
isn't at all clear, but it's one of the 5742 options - we don't have
an option for "this extends an IETF protocol in ways that require
IETF review, and it has in fact already had such review (though
not an IETF LC) which rejected progressing with the work, so there
doesn't seem to be any point in sending it back to the IETF, but
since we think this does conflict with BCP188 as well, we're formally
going with option 4."
But I think all of that is clear from the comments and other links
that Martin sent, isn't it? I hope, and assume, it's clear to
the ISE. (Who was cc'd on much of the IESG email on this by the
tracker.)
I should also point out that 5742 email responses to the ISE do
always include pointers to the tracker comments, and do ask the ISE
to consider those, so while the formal response text is I agree
so terse as to be misleading, one has to also read the comments
etc. in the tracker to get the context here.
The draft was reviewed in the TCPM working group and received negative
feedback:
http://mailarchive.ietf.org/arch/msg/tcpm/lM9-Frq945LP12GKbp02hnynuWw
Note that this is a pointer to a message about a much-earlier version of
the draft that has less explanatory text than the one being reviewed by
the ISE. To me, this is an indicator that the draft needed fixing in
order to meet the requirements of RFC 7258 of documenting the design
decisions, and that the authors may have done so between -04 and -07.
So that brings up an independent problem for the IESG with this, which
is the one about which we hope to chat with the ISE: It seems wrong to
ask the IESG to do a full IESG review of the modifications that the
authors have made after a first DNP response was sent, for text that
has not had an IETF LC. If the IESG do such a review, then this
basically becomes an IETF stream document as the DNP ends up the same
as a DISCUSS with the IESG and authors haggling about the text
(possibly via the ISE).
So, since the document obviously hadn't undergone major change, I
(and I think other ADs) felt that we had to re-send the same response.
Doing otherwise would I think be damaging to the independence of the
ISE.
Note though that we have had one other 5742 review recently where we
sent a DNP, but where the fix (to remove text about extending IKEv1)
was simple and obvious. In that case we didn't go around the full 5742
review again. So there's stuff to chat about to make that bit of
process work better I reckon, or at least so folks have the same
expectations of what'll happen with a returning item, after a DNP
response.
There have been also other places in the IETF where this draft was
presented and rejected.
If that's true, why did the IESG say that this draft is related to work
in INTAREA? I interpreted that as a request that the authors take this
draft to INTAREA, but now you're saying because the draft was
(Was your mail truncated?) Anyway, the intent was not to say "please
send this to the IETF" as explained above.
Cheers,
S.
--Paul Hoffman