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

<mohamed.boucadair@orange.com> Thu, 15 November 2012 08:59 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1088421F869C for <v6ops@ietfa.amsl.com>; Thu, 15 Nov 2012 00:59:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.828
X-Spam-Level:
X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HrfNPRzwRX3 for <v6ops@ietfa.amsl.com>; Thu, 15 Nov 2012 00:59:10 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3C31D21F85CD for <v6ops@ietf.org>; Thu, 15 Nov 2012 00:59:10 -0800 (PST)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 8D62122D1E0; Thu, 15 Nov 2012 09:59:09 +0100 (CET)
Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 6D2F04C05D; Thu, 15 Nov 2012 09:59:09 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Thu, 15 Nov 2012 09:59:09 +0100
From: <mohamed.boucadair@orange.com>
To: Pete Vickers <pete@systemnet.no>, "v6ops@ietf.org" <v6ops@ietf.org>
Date: Thu, 15 Nov 2012 09:59:08 +0100
Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt
Thread-Index: Ac3CsznvtYo/1r2sT1itStpsPoEU+AAURYhw
Message-ID: <94C682931C08B048B7A8645303FDC9F36E95C9F626@PUEXCB1B.nanterre.francetelecom.fr>
References: <mailman.19.1352923203.31424.v6ops@ietf.org> <0FF1EF83-4776-47B4-85C9-CF0CACE03950@systemnet.no>
In-Reply-To: <0FF1EF83-4776-47B4-85C9-CF0CACE03950@systemnet.no>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314
Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Nov 2012 08:59:11 -0000

Dear Pete,

Thank you for your comment.

I updated REQ#21 to add a preference order for DNS information: (1) RA, (2) DHCPv6.

As for REQ#19, I updated it as follows:
* Add a reference to SLAAC
* Focus on the support of IPv6-only connectivity mode (as this is not well supported by some handsets).

Cheers,
Med 

>-----Message d'origine-----
>De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De 
>la part de Pete Vickers
>Envoyé : mercredi 14 novembre 2012 22:58
>À : v6ops@ietf.org
>Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt
>
>Hi,
>
><lurk mode off>
>
>I'm very please with the way this draft is starting to look, 
>just a follow up on Victor's note though: Given that the 'DNS 
>info' preference order is set for multiple values received 
>over cellular interface, I believe that in the interests of 
>consistent behaviour the same preference order should also be 
>mandated for wifi interface acquired values. I think this 
>effectively adds REQ 19.5 as SLACC, which is also fine by me. 
>
>
>regards,
>
>Pete Vickers
>
>
>
>
>
>
>
>
>On 14. nov. 2012, at 21.00, v6ops-request@ietf.org wrote:
>
>
>> 
>> 
>> Message: 3
>> Date: Tue, 13 Nov 2012 22:12:22 -0500
>> From: Victor Kuarsingh <victor.kuarsingh@gmail.com>
>> To: <fred@cisco.com>om>,	<v6ops@ietf.org>
>> Cc: draft-binet-v6ops-cellular-host-requirements@tools.ietf.org
>> Subject: Re: [v6ops] new draft:
>> 	draft-binet-v6ops-cellular-host-requirements
>> Message-ID: <CCC873A7.3A4D3%victor.kuarsingh@gmail.com>
>> Content-Type: text/plain;	charset="US-ASCII"
>> 
>> V6ops/Draft Authors,
>> 
>> Here are some comments on the updated draft (and it's relation to
>> draft-korhonen-v6ops-rfc3316bis-00).  I hope there is not 
>too much overlap
>> with other comments, I have not had time to review those as of yet.
>> 
>> I would agree with the WG discussion that this draft
>> (v6ops-cellular-host-requirements) is quite different then
>> draft-korhonen-v6ops-rfc3316bis-00 but there is some overlap 
>(does not
>> bother me as long as they are consistent where they overlap or it
>> references the 3316bis document and removes the local document text)
>> 
>> ON this draft:
>> 
>> 
>> SECTION 2.1 - Wi-Fi
>> IN section 2.1 (Wi-Fi) there is a very short set of 
>requirements stated
>> for the Wi-Fi interface.  Given that this document is 
>focused on the 3GPP
>> interface and operation, perhaps you can just point to RFC 
>6434 (IPv6 Node
>> Requirements).  
>> 
>> I note that since you don't mention SLACC in section 2.1, 
>but do mention
>> DHCPv6 (I would think that SLACC is likely a good idea to specify)
>> 
>> Perhaps to make it easy, put RFC 6434 in REQ#19?
>> 
>> 
>> OVERALL
>> 
>> The draft seems to have a definite parallel target for 
>464XLAT operation.
>> But most of the those requirements are SHOULDs in this document.
>> 
>> I would think that some operators and handsets will want 
>464XLAT and some
>> may not care (I am of the former myself - I want 464XLAT).
>> 
>> That said, if a cell host needs to operate on a 464XLAT 
>network, perhaps
>> we need MUSTs in there?
>> 
>> Would it make sense to spit off the requirements for 464XLAT 
>and make them
>> MUSTs within that section?  Since they would be in different 
>section, we
>> can say "If the cellular host is intended to support 464XLAT 
>operation,
>> then the following section applies". (or something to that effect).
>> 
>> Regards,
>> 
>> Victor Kuarsingh
>> 
>> 
>
>_______________________________________________
>v6ops mailing list
>v6ops@ietf.org
>https://www.ietf.org/mailman/listinfo/v6ops
>