An IPv6 Profile for 3GPP Mobile Devices
draft-ietf-v6ops-mobile-device-profile-24

(Via drafts-eval@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-v6ops-mobile-device-profile-24 and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

ISE write-up for: draft-ietf-v6ops-mobile-device-profile-24

Abstract:
  "This document defines a profile that is a superset of that of the
    connection to IPv6 cellular networks defined in the IPv6 for Third
    Generation Partnership Project (3GPP) Cellular Hosts document.  This
    document defines an IPv6 profile that a number of operators recommend
    in order to connect 3GPP mobile devices to an IPv6-only or dual-stack
    wireless network (including 3GPP cellular network) with a special
    focus on IPv4 service continuity features.

    Both mobile hosts and mobile devices with capability to share their
    3GPP mobile connectivity are in scope."

This draft was extensively discussed in the 6man WG, version -13 was
submitted to IESG with a writeup by Fred Baker.  Fred said "Arguably,
it should be published by an association of mobile operators, but the
obvious one (3GPP) says it doesn’t write such documents."  The IESG
parked the draft, then it was submitted to the Independent Stream by
its lead author, Mohamed Boucadair; it has authors from six large
mobile providers.

This draft was reviewed for me by Mikael Abrahamson and Luis Murillo;
its authors have made many changes in response to that feedback.

This draft has no IANA Considerations.

- - - - - - -

The earlier version of this draft's writeup follows below ...


(1) This is intended to be an informational RFC. It specifies a set of requirements that might be referred to in an RFP or RFI for a specific type of service.

(2)

Technical Summary

  This document defines an IPv6 profile that a number of operators
  recommend in order to connect 3GPP mobile devices to an IPv6-only or
  dual-stack wireless network (including 3GPP cellular network and IEEE
  802.11 network).

  This document defines a different profile than the one for general
  connection to IPv6 cellular networks defined in the IPv6 for Third
  Generation Partnership Project (3GPP) Cellular Hosts document.  In
  particular, this document identifies also features to deliver IPv4
  connectivity service over an IPv6-only transport.

  Both hosts and devices with capability to share their WAN (Wide Area
  Network) connectivity are in scope.

Working Group Summary

IPv6 Operations contains a number of sub-communities, which include operators of various categories, vendors of various categories, academics, researchers, and others. This document, which is intended to describe a specific category of IPv6 service and serve in RFPs and RFIs as a set of operational requirements, was primarily of interest to the operators of 3GPP and related mobile networks. It was also reviewed by the Mobile Network vendors, including several of the authors of RFC 7066, which was developed at the same time. While there were comments and improvements made on the draft, it was not particularly controversial in the working group.

In IETF Last Call in September 2013, some comments that had been made and dropped in the working group were made with force. Several objections raised have been resolved in this version. There are three remaining objections: one person objects to the use of PCP, one person objects that the document should have come from 3GPP, and one person objects that the requirements differ a bit from those of an IPv6 node attached using a different network. In the opinion of the chairs, who are tasked with reviewing consensus, consensus is rough on those points, but none-the-less holds. With two exceptions, those who comments in the IETF LC in 2013 have signed off on the document.

Document Quality

There were a number of thorough reviews, including reviews from operators and from vendors.

Personnel

The Document Shepherd is Fred Baker. The AD is Joel Jaeggli.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.

I read it. Mobile networks are not specifically my expertise, but I solicited reviews from folks who have that expertise, and they were given.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization?

No. This is purely operational, and had operational review in the working group.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of?

The working group did not want to recommend this as a BCP. It none-the-less contains normative language. This was discussed several times in the working group, and the working group accepted it as is as they are requirements for the service in question.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.

Yes

(8) Has an IPR disclosure been filed that references this document?

No

(9) How solid is the WG consensus behind this document?

This represents joint concurrence of the mobile network operators and vendors in the working group.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

No

(13) Have all references within this document been identified as
either normative or informative?

yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?

no

(15) Are there downward normative references references (see RFC 3967)?

no

(16) Will publication of this document change the status of any
existing RFCs?

no


(17) Describe the Document Shepherd's review of the IANA considerations
section.

It is correct

[Ballot comment]
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!)

[Ballot comment]
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

[Ballot discuss]
* 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.

[Ballot comment]
I'm an Abstain specifically because of the issue other ADs raised about the 3GPP interaction.

I see that the 3GPP liaison manager has involved his 3GPP counterpart, and I'm happy to change my ballot position based on what we get back.

[Ballot comment]
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.)

[Ballot comment]
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.

[Ballot discuss]
* Updated text based on feedback on other ballot positions and private e-mail from the authors *

This is a DISCUSS for the IESG for the time being.  No need for author/chair actions at this time...

I believe that this document will be harmful if it is published.  It portrays itself as a viable product profile for 3GPP networks. However, this was done without interactions with 3GPP and creates a situation where user-equipment vendors may be confused as to what profiles are valid for their 3GPP devices.  Despite referring to itself as a set of recommendations, it uses 2119 keywords to turn these recommendations into requirements.  Given that RFC 7066 exists and that this type of profile should be developed within the GSM Association, I don't believe we should be publishing this document.

The following was sent to me from one of the authors:

I can eventually understand the resistance to see a profile document published, but I thought this first sentence from the draft would softened that:

  This document defines an IPv6 profile that a number of operators
  recommend in order to connect 3GPP mobile devices to an IPv6-only or
  dual-stack wireless network (including 3GPP cellular network and IEEE
  802.11 network).

The above text clearly illustrates why this document is a problem.  How broad is this "number of operators"?  Does it go beyond the 4 operators listed as document authors?  If a vendor implements this profile, will they be capable of operating on a 3G/4G/WLAN network managed by some other operator?  As Adrian noted, the convoluted use of 2119 keywords is troubling and having them couched in an Informational profile document is dubious at best.

I support Adrian's notion that 3GPP should at least be notified of this work formally.  The previous work, like RFC 3314, was driven by a partnership between 3GPP and the IETF (https://datatracker.ietf.org/documents/LIAISON/file725.txt) and we should continue that partnership *if* the consensus is to publish this document as a consensus-based RFC.

It is also unclear if the people who raised earlier concerns feel that their concerns were addressed.  I spoke with several of them and they do not think their concerns were addressed, but were tired of fighting over fundamental differences.

If a group of operators wants to document a profile that highlights what they want vendors to implement, that should be documented somewhere else besides the IETF. At best, I could see this documented as an ISE document (with all the appropriate warnings).

[Ballot comment]
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.

[Ballot discuss]
I'm entering this as a Discuss as input to the debate the IESG will have on this document. I do not expect any action from the document authors at this stage. I will either update the Discuss to show the appropriate actions, or will remove it.

It is clear to me that a number of people working across a broad set of network operators have driven this work, and also that there is consensus in the WG as reported by the chairs. Also I see the consensus called by the AD for IETF last call.

The document doesn't use RFC 2119 language (although the first paragraph of Section 1.3 was a surprise to me, if just weird IMHO, and would probably best be removed).

But I agree that it is unfortunate to have developed this document in isolation from 3GPP. That is not to say that the IETF should not publish such a document. But to do so without even notifying 3GPP of the work in progress and giving them the chance to comment seems to be regrettable.

While it is clear that there is a perceived need for a profile that is different from what the 3GPP previously developed, it would have been good to hear from 3GPP what concerns they have with this new profiles.

[Ballot comment]
I am balloting Abstain:

I do completely support Brian's DISCUSS that this document is not in the right place. The IETF cannot IMHO set requirements for other SDO's devices.

[Ballot comment]
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...

[Ballot discuss]
* Clarified my statement based on private feedback *

This is a DISCUSS for the IESG for the time being.  No need for author/chair actions at this time...

I believe that this document will be harmful if it is published.  It portrays itself as a viable product profile for 3GPP networks. However, this was done without interactions with 3GPP and creates a situation where user-equipment vendors may be confused as to what profiles are valid for their 3GPP devices.  Despite referring to itself as a set of recommendations, it uses 2119 keywords to turn these recommendations into requirements.  Given that RFC 7066 exists and that this type of profile should be developed within the GSM Association, I don't believe we should be publishing this document.

[Ballot discuss]
This is a DISCUSS for the IESG for the time being.  No need for author/chair actions at this time...

I believe that this document will be harmful if it is published.  It portrays itself as a viable product profile for 3GPP networks. However, this was done without interactions with 3GPP and creates a situation where user-equipment vendors may be confused as to what profiles are valid for their 3GPP devices.  Despite referring to itself as a set of recommendations, it uses 2119 keywords to turn these recommendations into requirements.  Given that RFC 7066 exists and device profiles have been developed by other SDOs, I don't believe we should be publishing this document.

[Ballot comment]
There are several requirements, in particular A_req#1 and A_req#4 that should be referenced from the security considerations section.  The security consideration section just points to another RFC for IP address privacy (also referenced in the A-req#1), but the explanation in the requirement is helpful and I think it should be referenced as well or instead.

Thanks for addressing the SecDir review coments:
http://www.ietf.org/mail-archive/web/secdir/current/msg04190.html

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-v6ops-mobile-device-profile-13, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are still no IANA Actions that need completion.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-10-16. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

This is the second iteration of this document to be IETF Last Called having
previously been here at draft 04. Substantial changes to the document have
occurred inclusive of the removal of much of the normative language.

Abstract


  This document defines an IPv6 profile that a number of operators
  recommend in order to connect 3GPP mobile devices to an IPv6-only or
  dual-stack wireless network (including 3GPP cellular network and IEEE
  802.11 network).

  This document defines a different profile than the one for general
  connection to IPv6 cellular networks defined in the IPv6 for Third
  Generation Partnership Project (3GPP) Cellular Hosts document.  In
  particular, this document identifies also features to deliver IPv4
  connectivity service over an IPv6-only transport.

  Both hosts and devices with capability to share their WAN (Wide Area
  Network) connectivity are in scope.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) This is intended to be an informational RFC. It specifies a set of requirements that might be referred to in an RFP or RFI for a specific type of service.

(2)

Technical Summary

  This document defines an IPv6 profile that a number of operators
  recommend in order to connect 3GPP mobile devices to an IPv6-only or
  dual-stack wireless network (including 3GPP cellular network and IEEE
  802.11 network).

  This document defines a different profile than the one for general
  connection to IPv6 cellular networks defined in the IPv6 for Third
  Generation Partnership Project (3GPP) Cellular Hosts document.  In
  particular, this document identifies also features to deliver IPv4
  connectivity service over an IPv6-only transport.

  Both hosts and devices with capability to share their WAN (Wide Area
  Network) connectivity are in scope.

Working Group Summary

IPv6 Operations contains a number of sub-communities, which include operators of various categories, vendors of various categories, academics, researchers, and others. This document, which is intended to describe a specific category of IPv6 service and serve in RFPs and RFIs as a set of operational requirements, was primarily of interest to the operators of 3GPP and related mobile networks. It was also reviewed by the Mobile Network vendors, including several of the authors of RFC 7066, which was developed at the same time. While there were comments and improvements made on the draft, it was not particularly controversial in the working group.

In IETF Last Call in September 2013, some comments that had been made and dropped in the working group were made with force. Several objections raised have been resolved in this version. There are three remaining objections: one person objects to the use of PCP, one person objects that the document should have come from 3GPP, and one person objects that the requirements differ a bit from those of an IPv6 node attached using a different network. In the opinion of the chairs, who are tasked with reviewing consensus, consensus is rough on those points, but none-the-less holds. With two exceptions, those who comments in the IETF LC in 2013 have signed off on the document.

Document Quality

There were a number of thorough reviews, including reviews from operators and from vendors.

Personnel

The Document Shepherd is Fred Baker. The AD is Joel Jaeggli.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.

I read it. Mobile networks are not specifically my expertise, but I solicited reviews from folks who have that expertise, and they were given.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization?

No. This is purely operational, and had operational review in the working group.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of?

The working group did not want to recommend this as a BCP. It none-the-less contains normative language. This was discussed several times in the working group, and the working group accepted it as is as they are requirements for the service in question.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.

Yes

(8) Has an IPR disclosure been filed that references this document?

No

(9) How solid is the WG consensus behind this document?

This represents joint concurrence of the mobile network operators and vendors in the working group.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

No

(13) Have all references within this document been identified as
either normative or informative?

yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?

no

(15) Are there downward normative references references (see RFC 3967)?

no

(16) Will publication of this document change the status of any
existing RFCs?

no


(17) Describe the Document Shepherd's review of the IANA considerations
section.

It is correct

Have confirmed to my satisfaction that  my assumption stated on 2013/09/03 still stands I'm setting aside the advancement of this document unless it comes back from the working group in some fashion less divisive then the present one.

imho, james, lorenzo and owen have a signficant concern with this
document which I belive should be addressed. it seems to me that the audiences for which this draft is intended do not have a great deal of concordance on the contents.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-v6ops-mobile-device-profile-04, which is
currently in Last Call, and has the following comments:

We understand that,  upon approval of this document, there are no IANA
Actions that need completion. IANA requests that the IANA
Considerations section of the document remain in place upon
publication.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-09-02. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies an IPv6 profile for 3GPP mobile devices.  It
  lists the set of features a 3GPP mobile device is to be compliant
  with to connect to an IPv6-only or dual-stack wireless network
  (including 3GPP cellular network and IEEE 802.11 network).

  This document defines a different profile than the one for general
  connection to IPv6 cellular networks defined in
  [I-D.ietf-v6ops-rfc3316bis].  In particular, this document identifies
  also features to deliver IPv4 connectivity service over an IPv6-only
  transport.

  Both hosts and devices with capability to share their WAN (Wide Area
  Network) connectivity are in scope.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

The Document Shepherd is Fred Baker. The AD is Joel Jaeggli.

Technical Summary:

This document specifies an IPv6 profile for 3GPP mobile devices. It
lists the set of features a 3GPP mobile device is to be compliant
with to connect to an IPv6-only or dual-stack wireless network
(including 3GPP cellular network and IEEE 802.11 network).

This document defines a different profile than the one for general
connection to IPv6 cellular networks defined in
[I-D.ietf-v6ops-rfc3316bis]. In particular, this document identifies
also features to deliver IPv4 connectivity service over an IPv6-only
transport.

Both hosts and devices with capability to share their WAN (Wide Area
Network) connectivity are in scope.

2. Review and Consensus

IPv6 Operations contains a number of sub-communities, which include operators of various categories, vendors of various categories, academics, researchers, and others. This document, which is intended to describe a specific category of IPv6 service and serve in RFPs and RFIs as a set of operational requirements, was primarily of interest to the operators of 3GPP and related mobile networks. It was also reviewed by the Mobile Network vendors, including several of the authors of draft-ietf-v6ops-rfc3316bis, which was developed at the same time. While there were comments and improvements made on the draft, it was not particularly controversial.

3. Intellectual Property

Each author has stated that their direct, personal knowledge of any IPR related to this document has already been disclosed. Per the data tracker, there is no filed IPR statement.