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

[Hesham Soliman <[e-mail]>]

>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.


Hesham

> 
>
>Thanks. 
>
>Cheers,
>Med 
>
>>-----Message d'origine-----
>>De : [e-mail] [mailto:[e-mail]] 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 <[e-mail]>
>>>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
>>>[e-mail]
>>>https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>>_______________________________________________
>>v6ops mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/v6ops