Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt

[<[e-mail]>]

Hi,

Some answers inline

________________________________
De : [e-mail] [mailto:[e-mail]] De la part de Lorenzo Colitti
Envoyé : lundi 19 novembre 2012 09:39
À : BOUCADAIR Mohamed OLNC/OLN
Cc : IPv6 Ops WG
Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt

I do not think this document is ready for WG adoption.

To start with, I see a few general issues.

First, the document is attempting to standardize behaviours that are already standardized by 3GPP. This is leads to many of the requirements being redundant because they are already included in 3GPP specs. If the manufacturer is violating those specs already, I doubt that an RFC that says "don't violate those specs" is going to have any effect at all. This also presents the problem that if the 3GPP standards are updated, the text becomes out of date.
[[david]] The goal of this document as indicated in several messages is to get a document where all IPv6 specifications for a mobile terminal are present. Actually it happens quite often that IETF documents have to be updated because of standards modifications and it is even the case for RFC3316.
And I do not understand the comment about the need to remove some requirements and to provide a link to RFC3316bis document. I do not understand why a RFCbis draft was proposed if the specifications were already present in draft-binet-* document.

Second, most of this document attempts to standardize feature sets, not protocols or interoperability. I'm not sure this is is in scope for the IETF, and even more so for an operations group inside the IETF.
[[david]] It is your opinion but as operator, it is something which is very important and there is a lack in standardisation documents where some IPv6 profile is defined. We receive a lot of support about such specifications.

Third, IETF work is supposed to proceed in parallel with running code, not in the absence of running code. I very doubt there are two interoperable implementations that satisfy all these requirements (actually, I doubt that any real implementation satisfies even half of them). Attempting to specify these requirements will not change that.
[[david]] You are right and we can imagine there is no implementation because there are no clear specifications and it is the gap we are trying to fill thanks to this document. If this document becomes a working group document, it amy be a first step in the process to get more and more IPv6 terminals and to lead some interoperable implementations. At this stage, the goal is to consider this document as a working group document. I think we can discuss about your specific comments below (even if I provided a global comment about some of them upper in the mail) when the document will be considered as a working group document.


Moving on, at least these requirements are redundant and should be removed or replaced by a reference to the appropriate specs:

REQ#3: Redundant with 3GPP specs.
REQ#4: Redundant with 3GPP specs.
REQ#5: Redundant with 3GPP specs.
REQ#6: Redundant with IPv6 node requirements.
REQ#7: Redundant with IPv6 node requirements.
REQ#7: Redundant with IPv6 node requirements and 3GPP specs.
REQ#15: Redundant with RFC 6724.
REQ#17: Redundant with 3GPP specs.


A few specific comments as well:

REQ#1: why do you need to cite RFC 5952? It has nothing to do with connecting to cellular networks, and it's already in RFC 6434 (IPv6 Node Requirements).

REQ#10: Not clear what happens if more than one provisioning method provides DNS. Should the phone just information from one of them? Or should it list all of them in priority order?

REQ#11: Not clear to me what this means. I understand the "implement the NAT64 discovery heuristic" requirement, but not the part that references RFC 6052. What does the host need to implement from RFC 6052?

REQ#18: Meaningless. Saying "MAY" in a requirements document is no better than saying nothing.

REQ#25: What is the point of supporting RFC 5175 if it defines no new flags?

REQ#27: Why support DHCPv6 PD if no mobile networks will support it for a number of years?

REQ#28: Duplicate of #12.

On Sun, Nov 11, 2012 at 10:47 PM, <[e-mail]<mailto:[e-mail]>> wrote:
Dear all,

As discussed in the v6ops meeting, we re-submitted a new version of the text which does not update RFC3316.

We hope this new version is ready for the WG adoption.

Cheers,
Med

-----Message d'origine-----
De : [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] De la part de [e-mail]<mailto:[e-mail]>
Envoyé : lundi 12 novembre 2012 07:42
À : [e-mail]<mailto:[e-mail]>
Objet : I-D Action: draft-binet-v6ops-cellular-host-requirements-00.txt


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-00.txt
        Pages           : 15
        Date            : 2012-11-11

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


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[e-mail]<mailto:[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]<mailto:[e-mail]>
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.