An IPv6 Profile for 3GPP Mobile Devices

Summary: Needs a YES.

Alvaro Retana No Record

Benjamin Kaduk No Record

Erik Kline No Record

Francesca Palombini No Record

John Scudder No Record

Lars Eggert No Record

Martin Duke No Record

Martin Vigoureux No Record

Murray Kucherawy No Record

Robert Wilton No Record

Roman Danyliw No Record

Warren Kumari No Record

Zaheduzzaman Sarker No Record

Éric Vyncke No Record

(Brian Haberman; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2014-10-31 for -13)
No email
send info
* 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.

(Joel Jaeggli; former steering group member) Yes

Yes ( for -04)
No email
send info

(Adrian Farrel; former steering group member) (was Discuss) No Objection

No Objection (2014-10-30 for -13)
No email
send info
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.

(Alia Atlas; former steering group member) No Objection

No Objection (2014-10-30 for -13)
No email
send info
I am supporting Brian's DISCUSS and Adrian's points for better communication to 3GPP.

(Barry Leiba; former steering group member) No Objection

No Objection (2014-10-29 for -13)
No email
send info
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...

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2014-12-02 for -14)
No email
send info
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:

(Spencer Dawkins; former steering group member) (was Abstain) No Objection

No Objection (2015-01-16 for -15)
No email
send info
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!)

(Jari Arkko; former steering group member) Abstain

Abstain (2014-10-30 for -13)
No email
send info
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.)

(Martin Stiemerling; former steering group member) Abstain

Abstain (2014-10-29 for -13)
No email
send info
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.