Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update

 Dear Hesham,

Some answer below
BR
David

> -----Message d'origine-----
> De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] 
> De la part de Hesham Soliman
> Envoyé : lundi 24 septembre 2012 08:09
> À : BOUCADAIR Mohamed OLNC/NAD/TIP; Ted Lemon; IPv6 Ops WG
> Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update
> 
> 
> 
> 
> >Dear Hesham,
> >
> >Which alternative(s) to CLAT you are referring to?
> 
> => I don't think I suggested alternatives to CLAT 
> specifically, can't see that in the email quoted anyway.
> I was questioning the wisdom/concensus/debate/ that went on 
> before those mechanisms were selected. I didn't see any 
> discussion, especially in other WGs who own those docs. As to 
> alternatives to CLAT specifically I don't really care what 
> they are, I don't like the approach being taken to create 
> requirements on cellular hosts without any serious debate or 
> IETF/3GPP consensus behind it.

Actually, you are right that there is a lack of IETF/3GPP debate about requirements on cellular hosts. 
The goal of this draft is to instantiate this debate and to get an updated RFC about IPv6 cellular hosts profile. 
Regarding CLAT support, we are thinking it could be a solution to ensure that IPv4 communications can still be enabled when some IPv6 only connectivity is provided to the UE. We want to tackle IPv4 service continuity requirement while some IPv6 connectivity is set up and we are open to alternative solutions if any. 

> 
> 
> Hesham
> 
> > 
> >
> >Thanks. 
> >
> >Cheers,
> >Med
> >
> >>-----Message d'origine-----
> >>De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] 
> De la part 
> >>de Hesham Soliman Envoyé : samedi 22 septembre 2012 03:01 À : Ted 
> >>Lemon; IPv6 Ops WG Objet : Re: [v6ops] 
> >>draft-binet-v6ops-cellular-host-reqs-rfc3316update
> >>
> >>>
> >>>On Sep 21, 2012, at 9:19 AM, Hesham Soliman 
> >>><hesham@elevatemobile.com>
> >>>wrote:
> >>>> And has there been on consensus on that mechanism? Because
> >>if there is
> >>>> consensus on one approach then lets remove a few more
> >>requirements. The
> >>>> current draft seems to select two approaches from what I 
> remember.
> >>>
> >>>It would be inappropriate for the v6ops working group to pick
> >>a winner.
> >>>We are just supposed to talk about operations.   In that
> >>context, saying
> >>>"you probably ought to support DNS64" is meaningful 
> advice, because a 
> >>>device that doesn't support it isn't going to be able to do DNSSEC.
> >>>This would rule out an entire transition technology, or 
> else rule out 
> >>>DNSSEC.
> >>>
> >>>The situation is similar for other recommendations this
> >>document makes.
> >>>Can you maybe offer some motivation for your resistance to these 
> >>>requirements other than "this is too strong"?
> >>
> >>=> My point is that we're effectively picking a winner. I 
> didn't see 
> >>any discussion before about which mechanisms would be 
> recommended and 
> >>suddenly we're saying CLAT is effectively a must implement 
> in devices. 
> >>The consequences if this are grave and that's why we need to have 
> >>consensus on one or two approaches that would be 
> recommended. If you 
> >>think this WG can't pick a winner then let BEHAVE do it 
> with IPv6 for 
> >>example. The outcome of this draft should be a couple of 
> mechanisms at 
> >>most. So there needs to be a discussion about what those 
> are with 3GPP 
> >>as well.
> >>
> >>My argument doesn't boil down to "this is too strong" as 
> you put it. 
> >>It boils down to "where is the consensus on chosen mechanisms?"
> >>where is the
> >>discussion with other WGs and 3GPP? This needs to happen as it 
> >>happened with similar RFCs in the past like 3314, 3316 or 3574.
> >>
> >>Hesham
> >>
> >>>
> >>>_______________________________________________
> >>>v6ops mailing list
> >>>v6ops@ietf.org
> >>>https://www.ietf.org/mailman/listinfo/v6ops
> >>
> >>
> >>_______________________________________________
> >>v6ops mailing list
> >>v6ops@ietf.org
> >>https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 
_________________________________________________________________________________________________________________________

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.