Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.txt

From: <[email-masked]>
Date: Fri, 1 Feb 2013 09:52:00 +0100

Dear Warren,

If the document is adopted, then we will update the document to record what the wg want to see in it (some requirements will be removed, others added, justification for some requirements worked better, etc.).

The current situation is: there are few mobile devices which support IPv6 features, some of them are broken (see http://www.ietf.org/mail-archive/web/v6ops/current/msg14732.html or what we reported in http://tools.ietf.org/html/draft-boucadair-pcp-nat64-experiments-00#section-3.2), deploying IPv6 in mobile networks depends on the availability of IPv6-compliant devices, etc. 

We edited this document to fill a void: have a comprehensive list of IPv6 requirements for mobile device. 

Cheers,
Med 

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De 
>la part de Warren Kumari
>Envoyé : jeudi 31 janvier 2013 22:31
>À : Cameron Byrne
>Cc : IPv6 Ops WG
>Objet : Re: [v6ops] Test for adoption as a working group 
>document - Re: I-D Action: 
>draft-binet-v6ops-cellular-host-requirements-02.txt
>
>
>On Jan 31, 2013, at 2:05 PM, Cameron Byrne <[email-masked]> wrote:
>
>> On Thu, Jan 31, 2013 at 10:54 AM, james woodyatt 
><[email-masked]> wrote:
>>> On Jan 30, 2013, at 11:19 , joel jaeggli <[email-masked]> wrote:
>>>> 
>>>> This kicks of a request for adoption as a working group 
>document on draft-binet-v6ops-cellular-host-requirements-02.txt
>>> 
>>> 
>>> I'm going to echo the sentiments of others by questioning 
>whether 3GPP would be a better venue than IETF for defining 
>this sort of device profile.
>>> 
>>> As a supporting argument, I would point out that this draft 
>uses RFC 2119 normative keywords while asserting that it is 
>Informational category. That makes it a bit peculiar in the 
>same way that an early draft of what became RFC 6092 was 
>peculiar, which entailed adding section 1.2 during working 
>group deliberations.
>>> 
>>>>> 1.2.  Use of Normative Keywords
>>>>> 
>>>>>      NOTE WELL: This document is not a standard, and 
>conformance with
>>>>>      it is not required in order to claim conformance with IETF
>>>>>      standards for IPv6.  It uses the normative keywords 
>defined in the
>>>>>      previous section only for precision.
>>> 
>>> We added that language because there were several different 
>standards bodies that were interested in having a baseline of 
>IETF consensus defined about what sorts of requirements are a 
>reasonable starting point, and we were hoping to facilitate 
>all those external organizations at once in setting 
>requirements standards that could reference an IETF document 
>in common with specific amendments applicable in their own domains.
>>> 
>>> The way I see it, there is no need for IETF to do that in 
>this case. There is only one standards body with an ambit that 
>covers the topic of this draft, i.e. 3GPP, and it would be a 
>much better fit for this work to be done there.
>>> 
>> 
>> So, i cannot speak for others, but i will not be doing this 
>work in 3GPP.
>> 
>> Keep in mind, 3GPP is not an open standards group.
>
>Hmm.. Ok, good point.
>
>When I wrote that I though that this should be done somewhere 
>else, I didn't actually stop and figure out *where* else.
>
>If the choice is between it being adopted by v6ops or just not 
>being published, then I (somewhat reluctantly) support adoption.
>I still think that it will need some more fleshing out, but 
>that can be done by the WG (if it chooses to adopt, etc blah 
>blah blah.)
>
>W
>
>
>
>> 
>> CB
>> _______________________________________________
>> v6ops mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/v6ops
>> 
>
>-- 
>No man is an island, But if you take a bunch of dead guys and 
>tie them together, they make a pretty good raft.
>                --Anon.
>
>
>_______________________________________________
>v6ops mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 1 Feb 2013 19:36:12 +0900

On Thu, Jan 31, 2013 at 8:57 PM, Philipp Kern <[email-masked]> wrote:

> > The way I see it, the document's goal is not to define operational
> > practices, but to define a device profile ("you must support features X,
> Y,
> > and Z"). I think this sort of thing does not belong in the IETF: the IETF
> > should define the technology, not how it's integrated. I think this sort
> of
> > thing is best left to cellular standards bodies like 3GPP.
>
> *cough* RFC 6540. ;-)
>

Which, of course, is so successful that vendors all over are scrambling to
implement IPv6 in all their products, just because the IETF told them to.
Not.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 1 Feb 2013 19:43:04 +0900

On Fri, Feb 1, 2013 at 6:31 AM, Warren Kumari <[email-masked]> wrote:

> When I wrote that I though that this should be done somewhere else, I
> didn't actually stop and figure out *where* else…
>

The way I see it, it doesn't matter where else. The IETF has no authority
to mandate what vendors do and do not implement, only how they implement
it. And since the IETF has no authority over this, it follows that the
document will have a similar level of effect whether it's published as an
IETF RFC or as a text file in my home directory: in both cases,
approximately none.

If a collection of operators got together and drew up a certification
profile accompanied by a conformance test, and agreed to hold vendors to
it, then that would be more useful. But the IETF is not the place to do
that.

---

From: Vízdal Aleš <[email-masked]>
Date: Fri, 1 Feb 2013 12:07:23 +0100

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alexandru Petrescu
> Sent: Thursday, January 31, 2013 2:47 PM
> To: [email-masked]
> Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-D Action:
> HEllo,
> This draft had a competitor in the same space IIRC?  What was the name
> of that draft?

You're talking about draft-ietf-v6ops-rfc3316bis-00. These drafts are not
competing as each of them has a different goal.
 
> In this draft, there is a section about which I have high interest -
> "4. Cellular Devices with LAN Capabilities".  This approaches very much
> to what an IPv6 Mobile Router is, whose one particular interface is
> cellular and others are LAN.
> 
> In this respect, implementing an IPv6 Mobile Router there are several
> possibilities and each may have an impact on that cellular interface.
> 
> For example, the use of Prefix Delegation has an impact on the cellular
> interface - and that is already said as REQ#27.

> But there are others.  For example, the use of IPv6 Network Prefix
> Translation, or, not least, the use of Mobile IPv6 (with NEMO extensions
> if possible).  This latter is all the more important since it is
> mentioned in the IPv6 Node Requirements document, and this draft also
> mentions that in addition to the cellular interface there is a WiFi
> interface - only Mobile IPv6 is able to make handovers between the two
> interfaces.

It's a scope question. Can you please review the draft and provide us
with your comments?

> Regards,
> Alex

Ales

---

From: Vízdal Aleš <[email-masked]>
Date: Fri, 1 Feb 2013 12:43:59 +0100

Hi,

speaking as an Operator (not as a co-author) working on IPv6 introduction in Mobile.

I see this document useful as it

	* defines a cellular IPv6 profile not yet specified anywhere else
	* goes behind the 3GPP architecture using NAT64, 464xlat, etc. features that are not part of the 3GPP architecture
	* can serve as basis for testing / validation later on

As IPv6 has been 'invented' by the IETF, it seems to me to be the right place to look into 
what IPv6 means for these devices (as has already been done for CPEs in 6204, IPv6 Nodes 
in 6434).

Secondly, this group has the right skill set required for such a work.

Ales

> From: joel jaeggli [mailto:[email-masked]]
> Sent: Wednesday, January 30, 2013 8:19 PM
> To: IPv6 Ops WG; [email-masked]
> Subject: Test for adoption as a working group document - Re: I-D Action: draft-binet-
> v6ops-cellular-host-requirements-02.txt
> 
> Greetings,
> 
> This kicks of a request for adoption as a working group document on
> This document and a similar one were discussed during IETF 85 and were
> updated accordingly. Support was far from unanimous at the time and
> we're interested in seeing how far it has progressed.
> 
> The deadline for this discussion phase is two weeks from today, 2/13.
> 
> thanks
> joelja
> 
> On 1/30/13 4:28 AM, [email-masked] wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> >
> >
> > 	Title           : Internet Protocol Version 6 (IPv6) Requirements for Cellular Hosts
> > 	Author(s)       : David Binet
> >                            Mohamed Boucadair
> >                            Ales Vizdal
> >                            Cameron Byrne
> >                            Gang Chen
> > 	Filename        : draft-binet-v6ops-cellular-host-requirements-02.txt
> > 	Pages           : 17
> > 	Date            : 2013-01-30
> >
> > Abstract:
> >     This document lists a set of IPv6-related requirements to be
> >     supported by cellular hosts.
> >
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-host-requirements
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-requirements-02
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=draft-binet-v6ops-cellular-host-requirements-02
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > I-D-Announce mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> > Internet-Draft directories: http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >

---

From: "Diego R. Lopez" <[email-masked]>
Date: Fri, 01 Feb 2013 12:18:04 +0000

Hi,

Speaking as another operator (and not co-author at all) I fully support Ales' view on this.

When it comes to IPv6, IETF has much more influence than Lorenzo's home dir (or any other source) in operator decisions. I do believe having this document will be helpful.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Ted Lemon <[email-masked]>
Date: Fri, 1 Feb 2013 13:12:51 +0000

> We edited this document to fill a void: have a comprehensive list of IPv6 requirements for mobile device. 

I'm in favor of adopting this document.   It's worth noting that if the work is done here, it makes life really easy for 3GPP—they can just reference this document, or plagiarize it.   Either produces the right outcome—the document is defined by an open process, and it's adopted by a standards body that cell phone providers are tuned in to.   If 3GPP ignores it, it still serves as a standard for which support can be claimed as a differentiating factor if other devices don't follow the standard, so I think even in that case it's still worth doing.

---

From: "George, Wes" <[email-masked]>
Date: Fri, 1 Feb 2013 09:51:40 -0500

From: [email-masked] [mailto:[email-masked]] On Behalf Of Lorenzo Colitti

The IETF has no authority to mandate what vendors do and do not implement, only how they implement it. And since the IETF has no authority over this, it follows that the document will have a similar level of effect whether it's published as an IETF RFC or as a text file in my home directory: in both cases, approximately none.

If a collection of operators got together and drew up a certification profile accompanied by a conformance test, and agreed to hold vendors to it, then that would be more useful. But the IETF is not the place to do that.

[WEG] I agree that IETF has no authority to do anything more than publish a standard and hope that it's useful enough that more than one vendor implements it per our guidance such that it's interoperable. That said, you appear to be missing the point of both this document and 6540. In cases like these, the IETF provides an easily referenced document (unlike, say, a text file in your home directory), and then the collection of operators uses that document in things like RFPs and their own certification testing to make it clear to vendors exactly what they expect. It may even form the basis of a standard from another SDO that has more enforcement teeth. Specifically in the case of documents like these, we've found (and I assume that you have too) that you have to be significantly more specific than "must support IPv6" when it comes to asking vendors to implement it *properly*. This document helps address that need.
Keep in mind that a lot of the other potential SDOs in this space like to do things like require membership and or payment to even ACCESS their standards documents, making it a bit difficult to use them as a useful shorthand for conveying requirements to vendors. And as noted by previous folks, access to build a standard is similarly controlled, unlike IETF's open participation.

I think this document is useful as a WG doc, but I agree that it would be helpful to expand on the requirements with additional technical justification on why they are MUST, SHOULD, MAY.

Wes George

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "Heatley, Nick" <[email-masked]>
Date: Fri, 1 Feb 2013 12:35:25 -0000

+1

Speaking as an operator I see a document ratified by the IETF as extremely useful.
I would immediately use it in RFQ discussions, testing and ratification.
I need a requirements document (very soon) that carries the weight of consensus.

I wish for an IPv6 cellular profile document which sits above and is independent from the general release 8,9,10 approach of 3GPP. I fully agree 3GPP do standards for mobile bearer interoperability, as per their releases.
But I think I require standards on internet interoperability, who does this if not the IETF?

Best regards,
Nick Heatley
Senior Architect
EE

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Vízdal Aleš
> Sent: 01 February 2013 11:44
> To: [email-masked]
> Subject: Re: [v6ops] Test for adoption as a working group document -
> Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.txt
> 
> Hi,
> 
> 	* goes behind the 3GPP architecture using NAT64, 464xlat, etc.
> features that are not part of the 3GPP architecture
> As IPv6 has been 'invented' by the IETF, it seems to me to be the right
> place to look into what IPv6 means for these devices (as has already
> been done for CPEs in 6204, IPv6 Nodes in 6434).
> 
> > To: IPv6 Ops WG;
> > [email-masked]
> > Subject: Test for adoption as a working group document - Re: I-D
> > Action: draft-binet- v6ops-cellular-host-requirements-02.txt
> >
> > Greetings,
> >
> > > https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-host-
> req
> > > uirements
> > >
> > > http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-
> requireme
> > > nts-02
> > >
> > > http://www.ietf.org/rfcdiff?url2=draft-binet-v6ops-cellular-host-
> req
> > > uirements-02
> > >
> > >
> > > Internet-Draft directories: http://www.ietf.org/shadow.html or
> > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >
> 
NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named person(s).  If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose.  
 
We may monitor all incoming and outgoing emails in line with current legislation. We have taken steps to ensure that this email and attachments are free from any virus, but it remains your responsibility to ensure that viruses do not adversely affect you. 

Everything Everywhere Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Hatfield Business Park, Hatfield, Hertfordshire, AL10 9BW

---

From: <[email-masked]>
Date: Fri, 1 Feb 2013 17:19:48 +0100

Hi,

I support the adoption of draft-binet-v6ops-cellular-host-requirements as a v6ops WG document.

Cheers,

Christian.

NOTICE AND DISCLAIMER

Registered Office Address: Hatfield Business Park, Hatfield, Hertfordshire, AL10 9BW _______________________________________________

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Vízdal Aleš <[email-masked]>
Date: Fri, 1 Feb 2013 17:59:50 +0100

From: [email-masked] [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Friday, February 01, 2013 11:43 AM
To: Warren Kumari
Cc: IPv6 Ops WG
Subject: Re: [v6ops] Test for adoption as a working group document - Re: I-D Action: draft-binet-v6ops-cellular-host-requirements-02.txt

> If a collection of operators got together and drew up a certification profile accompanied by a conformance test, and agreed to hold vendors to it, then that would be more useful. But the IETF is no…

Operators got together to work on this draft to align their requirements. Conformance tests are happening internally ... further cooperation
may follow. Let's set this as a basis.

Ales

---

From: Tina TSOU <[email-masked]>
Date: Fri, 1 Feb 2013 17:07:45 +0000

Dear all,
I support the adoption.

Thank you,
Tina

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 01 Feb 2013 18:34:50 +0100

Le 01/02/2013 12:07, Vízdal Aleš a écrit :
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
>> Sent: Thursday, January 31, 2013 2:47 PM To: [email-masked]
>> This draft had a competitor in the same space IIRC?  What was the
>> name of that draft?
>
> You're talking about draft-ietf-v6ops-rfc3316bis-00. These drafts are
> not competing as each of them has a different goal.

I don't understand?

The abstract of one says:
"This document lists a set of IPv6-related requirements to be
  supported by cellular hosts."

and the abstract of the other includes:
"This document considers IPv6 for cellular hosts that attach to the
  General Packet Radio Service (GPRS), Universal Mobile
  Telecommunications System (UMTS), or Evolved Packet System (EPS)
  networks (Hereafter collectively referred to as 3GPP networks)."

As an example which makes me think they compete, in the running text one
draft says 'should' Prefix Exclude Option (of PD) and the other says
MUST for the same.  Both these recommendations are for cellular-enabled
Hosts, right?

>> In this draft, there is a section about which I have high interest
>>  - "4. Cellular Devices with LAN Capabilities".  This approaches
>> very much to what an IPv6 Mobile Router is, whose one particular
>> interface is cellular and others are LAN.
>>
>> In this respect, implementing an IPv6 Mobile Router there are
>> several possibilities and each may have an impact on that cellular
>>  interface.
>>
>> For example, the use of Prefix Delegation has an impact on the
>> cellular interface - and that is already said as REQ#27.
>
>> Translation, or, not least, the use of Mobile IPv6 (with NEMO
>> extensions if possible).  This latter is all the more important
>> since it is mentioned in the IPv6 Node Requirements document, and
>> this draft also mentions that in addition to the cellular interface
>> there is a WiFi interface - only Mobile IPv6 is able to make
>> handovers between the two interfaces.
>
> It's a scope question. Can you please review the draft and provide
> us with your comments?

Yes, in section "4. Cellular Devices with LAN Capabilities" lists a
number of requirements for Cellular Devices with LAN Capabilities.  Some
of these requirements request that that cellular-enabled device uses
DHCP Prefix Delegation in order to obtain a Prefix for the LAN.

But there exist other methods to achieve the same effect as assigning a
Prefix on the LAN from DHCP-PD: Network Prefix Translation, and Prefix
Delegation with Network Mobility.

My comment is - why aren't these mentioned in the list of requirements?

Regards,

Alex

---

From: Rui Paulo <[email-masked]>
Date: Fri, 01 Feb 2013 10:33:14 -0800

On 30 Jan 2013, at 11:19, joel jaeggli <[email-masked]> wrote:

> Greetings,
> 
> This kicks of a request for adoption as a working group document on draft-binet-v6ops-cellular-host-requirements-02.txt

Like others, I also don't think this should be an IETF document. 
If it ends up going forward, I would like it to mimic RFC 6092 in the use of normative keywords, like James pointed out.

--
Rui Paulo

---

From: Vízdal Aleš <[email-masked]>
Date: Fri, 1 Feb 2013 20:26:00 +0100

> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Friday, February 01, 2013 6:35 PM
> To: Vízdal Aleš
> Cc: [email-masked]

Section 1.1 provides the following explanation

This document lists the required features while

   [I-D.ietf-v6ops-rfc3316bis] is doing a good job in identifying issues
   and explaining how to implement basic IPv6 features in a mobile
   context.  Some of the features discussed in
   [I-D.ietf-v6ops-rfc3316bis] are also listed in this document as a
   requirement: the main reason is to collect in one single document a
   comprehensive list of requirements with the required language.
 
> My comment is - why aren't these mentioned in the list of requirements?

There has been no demand for anything else than DHCP-PD so far.

Ales

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 03 Feb 2013 17:26:22 +0100

Le 01/02/2013 20:26, Vízdal Aleš a écrit :
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[email-masked]] Sent: Friday, February 01,
>> 2013 6:35 PM To: Vízdal Aleš Cc: [email-masked] Subject: Re:
>> [v6ops] Test for adoption as a working group document - Re: I-D
>> Action: draft-binet-v6ops-cellular-host-requirements-02.txt
>>
>>>> [mailto:[email-masked]] On Behalf Of Alexandru
>>>> Petrescu Sent: Thursday, January 31, 2013 2:47 PM To:
>>>> [email-masked] Subject: Re: [v6ops] Test for adoption as a
>>>> working group document - Re: I-D Action:
>>>> This draft had a competitor in the same space IIRC?  What was
>>>> the name of that draft?
>>>
>>> You're talking about draft-ietf-v6ops-rfc3316bis-00. These drafts
>>> are not competing as each of them has a different goal.
>>
>> I don't understand?
>>
>> The abstract of one says: "This document lists a set of
>> IPv6-related requirements to be supported by cellular hosts."
>>
>> and the abstract of the other includes: "This document considers
>> IPv6 for cellular hosts that attach to the General Packet Radio
>> Service (GPRS), Universal Mobile Telecommunications System (UMTS),
>> or Evolved Packet System (EPS) networks (Hereafter collectively
>> referred to as 3GPP networks)."
>
> [I-D.ietf-v6ops-rfc3316bis] is doing a good job in identifying
> issues and explaining how to implement basic IPv6 features in a
> mobile context.  Some of the features discussed in

Thanks for pointing to that text.

I need to better understand it.  But I doubt [I-D.ietf-v6ops-rfc3316bis]
is _not_ trying to also have a comprehensive list of requirements.

I have some comments about this comprehensive list of requirements and I
would like to post them here in the v6ops list.  But not sure on which
draft will they go.

>> As an example which makes me think they compete, in the running
>> text one draft says 'should' Prefix Exclude Option (of PD) and the
>> other says MUST for the same.  Both these recommendations are for
>> cellular-enabled Hosts, right?
>>
>>>> In this draft, there is a section about which I have high
>>>> interest - "4. Cellular Devices with LAN Capabilities".  This
>>>> approaches very much to what an IPv6 Mobile Router is, whose
>>>> one particular interface is cellular and others are LAN.
>>>>
>>>> several possibilities and each may have an impact on that
>>>> cellular interface.
>>>>
>>>> But there are others.  For example, the use of IPv6 Network
>>>> Prefix Translation, or, not least, the use of Mobile IPv6 (with
>>>> NEMO extensions if possible).  This latter is all the more
>>>> important since it is mentioned in the IPv6 Node Requirements
>>>> document, and this draft also mentions that in addition to the
>>>> cellular interface there is a WiFi interface - only Mobile IPv6
>>>> is able to make handovers between the two interfaces.
>>>
>>> It's a scope question. Can you please review the draft and
>>> provide us with your comments?
>>
>> Yes, in section "4. Cellular Devices with LAN Capabilities" lists
>> a number of requirements for Cellular Devices with LAN
>> Capabilities.  Some of these requirements request that that
>> cellular-enabled device uses DHCP Prefix Delegation in order to
>> obtain a Prefix for the LAN.
>>
>> But there exist other methods to achieve the same effect as
>> assigning a Prefix on the LAN from DHCP-PD: Network Prefix
>> Translation, and Prefix Delegation with Network Mobility.
>>

Ok, I didn't know that.

Running DHCP-PD on the real interface is one way of obtaining addresses
for the LAN interface.  One other is to run DHCP-PD on a virtual tunnel,
whose other end is the Home Agent of (Mobile IP).  This way is specified
in RFC6276 "DHCPv6 Prefix Delegation for Network Mobility (NEMO)".  This
requires the use of protocol Mobile IP.  The protocol Mobile IP is
necessary when this Router has an additional egress WiFi interface (in
addition to the ingress LAN WiFi interface).

For the same problem (make addresses for devices on the LAN interface),
instead of using DHCP-PD, one may use NPTv6 "Network Prefix Translation"
RFC6296.

Alex

---

From: Geir Egeland <[email-masked]>
Date: Wed, 13 Feb 2013 12:15:45 +0100

Hi,
Speaking as a mobile operator I support this document.     
Personally, I do not feel comfortable having references to 3GPP TS documents in an IETF requirements document. I am aware that this has been done in other RFCs, but requirements on PDP contexts handling should IMHO be left to 3GPP (REQ 2&3). If this document gets accepted and the WG insists on keeping the 3GPP stuff,  we should at least specify the exact section in the TS we are refering to.

Geir Egeland
Telenor Group/Norway

---

From: joel jaeggli <[email-masked]>
Date: Wed, 13 Feb 2013 23:13:36 -0800

> The deadline for this discussion phase is two weeks from today, 2/13.
This test is completed.

Thanks
joel

>>     Filename        :

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sun, 17 Feb 2013 06:25:56 +0000

On Feb 13, 2013, at 11:13 PM, joel jaeggli <[email-masked]> wrote:

>> This document and a similar one were discussed during IETF 85 and were updated accordingly. Support was far from unanimous at the time and we're interested in seeing how far it has progressed.
>> 

Following up from the discussion.

In Joel's thread, I saw 27 emails from 18 people. Some comments didn't really take a position on the question, and some argued against adoption. However, the preponderance of speakers spoke in favor of adoption. So I believe that the working group consensus, albeit rough, supports that status.

As chair, this leaves me puzzled. We already have a working group draft updating RFC 3316: draft-ietf-v6ops-rfc3316bis. If this is also a working group document, and intended to give guidance and RFP air support to operators, IMHO either it has to merge with draft-ietf-v6ops-rfc3316bis or be obviously different from it, not only during our discussion but to purchasing agents that list it as a requirement in RFPs/RFIs. It will be up to this working group to draw that distinction. I'm hoping for a lot of help in getting that right.

---

From: <[email-masked]>
Date: Mon, 18 Feb 2013 10:48:38 +0100

Dear Fred,

Thanks for confirming there is consensus for the adoption of draft-binet-*. 

draft-binet-* already includes a section to position itself vs. draft-ietf-v6ops-rfc3316bis. This point was already raised in the last IETF meeting and it was clear from that discussion these two documents have two different goals: http://www.ietf.org/proceedings/85/minutes/minutes-85-v6ops. 

Is there anything else we can add to the draft to further clarify this? 

Cheers,
Med 

>De : Fred Baker (fred) [mailto:[email-masked]] 
>Envoyé : dimanche 17 février 2013 07:26
>À : IPv6 Ops WG
>Cc : [email-masked]
>>> This document and a similar one were discussed during IETF 
>85 and were updated accordingly. Support was far from 
>unanimous at the time and we're interested in seeing how far 
>it has progressed.
>>> 
>In Joel's thread, I saw 27 emails from 18 people. Some 
>comments didn't really take a position on the question, and 
>some argued against adoption. However, the preponderance of 
>speakers spoke in favor of adoption. So I believe that the 
>working group consensus, albeit rough, supports that status.
>
>As chair, this leaves me puzzled. We already have a working 
>group draft updating RFC 3316: draft-ietf-v6ops-rfc3316bis. If 
>this is also a working group document, and intended to give 
>guidance and RFP air support to operators, IMHO either it has 
>to merge with draft-ietf-v6ops-rfc3316bis or be obviously 
>different from it, not only during our discussion but to 
>purchasing agents that list it as a requirement in RFPs/RFIs. 
>It will be up to this working group to draw that distinction. 
>I'm hoping for a lot of help in getting that right.