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

[GangChen <[e-mail]>]

Hello Med,

2012/9/21, [e-mail] <[e-mail]>:
> Hi Gang,
>
> Thanks for the review.
>
> Please see inline.
>
> Cheers,
> Med
>
>>-----Message d'origine-----
>>De : GangChen [mailto:[e-mail]]
>>Envoyé : jeudi 20 septembre 2012 17:13
>>À : BOUCADAIR Mohamed OLNC/NAD/TIP
>>Cc : IPv6 Ops WG
>>Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update
>>
>>Hello Med,
>>
>>Thanks for the work. I read the draft.
>>In general, the requirements have been structured as Basic
>>Connectivity, Advanced and APIs & Applications
>>Just wondering to know what release of cellular host the requirements
>>are targeting?

In a cellular context, the IPv6 capability is closely depending on 3GPP Release.
I guess it would help if the draft could identify the particular
context.


>>What's the consideration to frame the context of each section?
>>I have noticed that some basic IPv6 capability is mentioned in the
>>part of Advanced Requirements.  That seems to me should belong to the
>>Basic part.
>>
>>More details are as following.
>>
>>2.  Basic Connectivity Requirements
>>REQ#1,
>>REQ#2,
>>REQ#3 and REQ#4 were already specified in 3GPP.
>>Not sure it would add much discussions to the draft.

Acknowledged. However, I guess the draft is supposed to document
something IETF-specific.Those requirements seem to belong
3GPP scope.

> Med: The purpose of the draft is to have one place where an IPv6 profile for
> cellular device is device. There are several requirements on the UEs spread
> in various specification document. Listing those 3GPP spec is one part of
> the puzzle to define an IPv6 profile for cellular hosts.
>
>>
>>REQ#6 and REQ#7 should be combined IMHO, because it provides same
>>outcome solving the issues related to compatibility of IPv4
>>applications.>

Answer is expected on this point.

>>REQ#8: I don't understand the purpose of embed a DNS64 function.
>>Especially, the sentence of "This allows to be compatible with DNSSEC"
>
> Med: I see Ted already answered to this comment.

Yes. That answers my question. Thanks

>>REQ#10 I guess I-D.ietf-behave-nat64-discovery-heuristic should be
>>ranked as first priority compared to
>>I-D.boucadair-pcp-nat64-prefix64-option
>
> Med: Please refer to
> http://www.ietf.org/mail-archive/web/pcp/current/msg02273.html for the
> discussion I had with Teemu on this item.

I-D.boucadair-pcp-nat64-prefix64-option is a individual I-D
Only concern is we can't tell what would be available in the future.

>>
>>REQ#11: Preferring native IPv6 doesn't always achieve good effect. It
>>may cause additional charge in some cases. Please refer to
>>http://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extens
>>ion-00#page-3
>>case 4 for further information
>
> Med: I added a pointer to the MIF draft to record the issue.
>
>>
>>One additional requirement maybe worth to add for the completeness:
>>
>>REQ#XX The cellular device SHOULD embed a BIH function [RFC6535]
>>facilitating the communication between IPv4 application and IPv6
>>server
>
> Med: As we have CLAT already listed there, what would be the motivation to
> include BIH?
> I added a discussion note to the draft to record this point.

They are working in a complementary way but different cases. 464xlat
is working for an IPv4 application talking to IPv4 servers going
through IPv6 network.
BIH is to enable an IPv4 application talking to IPv6 servers within an
IPv6 network.


>>
>>2.1.  WiFi Connectivity
>>
>>It may be complementary to add one additional requirement, like
>>
>>REQ#XX Prefix Delegation capabilities [RFC3633] MUST be supported on
>>the Wi-Fi interface.
>
> Med: Wouldn't this be redundant with what is the features discussed in
> Section 4?

It's not redundant because the requirements of DHCP-PD would apply to
different chips.

BRs

Gang
>>
>>
>>3.  Advanced Requirements
>>
>> REQ#16,
>> REQ#17,
>> REQ#18,
>> REQ#19 and REQ#20 may be proper to be shifted to "2. Basic
>>Connectivity Requirements", since those features are basic IPv6
>>capability
>
> Med: I will check.
>
>>
>>REQ#22:  it maybe proper to change the *SHOULD* to *MAY*
>
> Med: What is the rationale behind that change?

>>
>>Best Regards
>>
>>Gang
>>
>>2012/9/20, [e-mail] <[e-mail]>:
>>> Dear all,
>>>
>>> We submitted this new I-D.
>>>
>>> Review and comments are more than welcome.
>>>
>>> Cheers,
>>> Med
>>>
>>>
>>> -----Message d'origine-----
>>> De : [e-mail]
>>[mailto:[e-mail]] De
>>> la part de [e-mail]
>>> Envoyé : mercredi 19 septembre 2012 14:57
>>> À : [e-mail]
>>> Objet : I-D Action:
>>> draft-binet-v6ops-cellular-host-reqs-rfc3316update-00.txt
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>
>>>
>>> 	Title           : Internet Protocol Version 6 (IPv6)
>>for Cellular Hosts
>>> 	Author(s)       : David Binet
>>>                           Mohamed Boucadair
>>> 	Filename        :
>>> draft-binet-v6ops-cellular-host-reqs-rfc3316update-00.txt
>>> 	Pages           : 14
>>> 	Date            : 2012-09-19
>>>
>>> Abstract:
>>>    This document lists a set of IPv6-related requirements to be
>>>    supported by cellular hosts.
>>>
>>>    This document updates RFC3316.
>>>
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>>
>>https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-hos
>>t-reqs-rfc3316update
>>>
>>> There's also a htmlized version available at:
>>>
>>http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-reqs
>>-rfc3316update-00
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> [e-mail]
>>> 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
>>> _______________________________________________
>>> v6ops mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>