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 > >