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

Pete Vickers <pete@systemnet.no> Wed, 14 November 2012 21:58 UTC

Return-Path: <pete@systemnet.no>
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 D49A521F880F for <v6ops@ietfa.amsl.com>; Wed, 14 Nov 2012 13:58:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 eCozlBBPt-Um for <v6ops@ietfa.amsl.com>; Wed, 14 Nov 2012 13:58:35 -0800 (PST)
Received: from hk18-1.systemnet.no (hk18-1.systemnet.no [195.214.201.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC8321F8809 for <v6ops@ietf.org>; Wed, 14 Nov 2012 13:58:35 -0800 (PST)
Received: from [127.0.0.1] (pete@localhost.systemnet.no [127.0.0.1]) by hk18-1.systemnet.no (8.13.6/8.13.6) with ESMTP id qAELwTbu013367 for <v6ops@ietf.org>; Wed, 14 Nov 2012 22:58:29 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1085)
From: Pete Vickers <pete@systemnet.no>
In-Reply-To: <mailman.19.1352923203.31424.v6ops@ietf.org>
Date: Wed, 14 Nov 2012 22:58:29 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <0FF1EF83-4776-47B4-85C9-CF0CACE03950@systemnet.no>
References: <mailman.19.1352923203.31424.v6ops@ietf.org>
To: v6ops@ietf.org
X-Mailer: Apple Mail (2.1085)
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: Wed, 14 Nov 2012 21:58:36 -0000

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