Summary: Needs a YES.
* Updated based on the discussion during the 2014-10-30 IESG Telechat * This document, in its current form, will be harmful if it is published. There are several issues that need to be addressed in order to make this a viable IETF consensus-based document. 1. This draft portrays itself as a viable alternative product profile to RFC 7066. This document should clearly state that the profile described in this document is a super set of the one defined in 7066. 2. The use of 2119 keywords should be stricken from the document. Their use (regardless of their capitalization) leads to confusion as to whether these are recommendations or requirements. 3. The recommendations in this draft are overly broad. It suffers from some of the problems that led to the re-publication of the IPv6 Node Requirements document, namely trying to provide guidance/requirements that go beyond the base specifications being referenced. Justification needs to be documented for functions that go above and beyond those described in 7066. 4. Given that this document is aimed at devices intended for use in 3GPP networks, 3GPP should be made aware of this work in order to facilitate collaboration on its development. This is a task for the WG chairs and sponsoring AD to work with our 3GPP liaison manager. 5. The addition of extended functionality will need to consider the implications for interoperability with legacy systems developed using RFC 7066. Consideration, guidance, or caveats need to be documented for interoperability issues.
I am supporting Brian's DISCUSS and Adrian's points for better communication to 3GPP.
Thank you for closing the loop with 3GPP. I'm moving to No Objection, as previously discussed. (I might be too sensitive about that, but I was the IAB liaison shepherd for 33GPP, so I'm aware that we needed to ask!)
I've been discussing my Discuss with Med offline. For me the resolution of this document should be: - Continue with publication process - Immediately send a liaison statement to 3GPP explaining the purpose of the document and inviting discussion - Handle any feedback as it comes - If it comes soon and shows an important hole, pull the doc back and fix the problem - Otherwise, work on a revision I-D for an update RFC if necessary For the future we should tighten up on our relationship with 3GPP to make sure that liaisons take place a little sooner in the process. With regard to my Discuss, I think I have achieved my objective - the discussion of this point. I will leave it to the ADs, the chairs, and the liaison manager to resolve the situation with the 3GPP. --- I also had an issue with the reference to RFC 2119 in Section 1.3. I think that paragraph should simply be removed.
in support of Brian's point: I find it curious that we are publishing a profile for 3GPP usage that differs from what 3GPP has produced. I'll let Brian pursue this...
Thank you for adding in the direct reference to requirementsA_req#1 and A_req#4 from the security considerations section on address privacy per my previous comment. Thanks for addressing the SecDir review coments: http://www.ietf.org/mail-archive/web/secdir/current/msg04190.html
I'm speaking mostly as an author of RFCs 3316 and 7066 and as a long-term contributor in these discussions. I am not raising a discuss, because Brian is already raising one. And one could perhaps argue that I should not be officially involved in a matter where I have been someone who has argued for particular direction in this space. Hence you should take these as comments only. I think a document in this space would be useful. Potentially very useful for IPv6 deployment. I think we desperately need a document! Unfortunately, we are not quite there with this document. Even if the document has a lot of excellent material. I think the issue is in part the way that the document has been written, partially how it is handled, part is about interoperability, and in part fundamental. As an example of the writing issues, the draft presents itself as a different profile. Casting the document as additional requirements on top of the existing very basic profile (7066) might be a better way to approach the situation. And this is not merely a piece of text to add to the front, the document should actually be structured so that the reader understands what is being added. Secondly, coordination with others who do things in this space would be necessary, i.e., 3GPP. Or at the very least, the document should be clear what its role is. The document could have been called "Extended IPv6 Profile for Mobile Devices in Foo, Bar, Snaap Operator Networks", and make it clear that it builds on 3GPP/IETF specifications but adds more functionality to deal with additional situations. Then it would have been a great contribution to make the case that these operators believe they can and should address those additional situations. And there'd be no confusion about what the role of the document is. Thirdly, I think we at IETF should care about interoperability. Brian already said it, but we should not create a fork. That would be bad for everyone. This part clearly needs more work. Some of the additional functions are fine; but I do not have a good understanding of what the rest of the text means for interoperability with existing devices, for instance. Finally, there are some fundamental differences to what has been done before or in 3GPP, like the specification of additional transition mechanisms. While I personally have disagreed with some of those choices in the past, I recognise that I have have been in the rough on this (at least in the IETF, not sure about elsewhere). In any case, with a proper scope for suggested additional requirements in some networks, this would be fine. (I wish I had the time to look at this document earlier. Sorry. All this input at the last moment feels bad. But we may also be repeating some of the discussions we had in V6OPS at the time that we wrote 7066.)
I am balloting Abstain: I do completely support Brian's DISCUSS that this document is not in the right place, given the current situation of not having 3GPP involved in this. The IETF cannot IMHO set requirements for other SDO's devices, unless there is explicit input from such SDO in writing such I-D/RFC.