Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update
Hesham Soliman <hesham@elevatemobile.com> Fri, 21 September 2012 13:04 UTC
Return-Path: <hesham@elevatemobile.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 4779921F8710 for <v6ops@ietfa.amsl.com>; Fri, 21 Sep 2012 06:04:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AWL=-0.323, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, SARE_SUB_OBFU_Q1=0.227]
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 VRTZ3p2VblH3 for <v6ops@ietfa.amsl.com>; Fri, 21 Sep 2012 06:04:24 -0700 (PDT)
Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 6059621F8568 for <v6ops@ietf.org>; Fri, 21 Sep 2012 06:04:23 -0700 (PDT)
Received: from [60.242.128.199] (helo=[192.168.0.6]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1TF2u3-0004Fs-Gj; Fri, 21 Sep 2012 23:04:20 +1000
User-Agent: Microsoft-MacOutlook/14.2.3.120616
Date: Fri, 21 Sep 2012 23:04:08 +1000
From: Hesham Soliman <hesham@elevatemobile.com>
To: mohamed.boucadair@orange.com
Message-ID: <CC82A1A5.29137%hesham@elevatemobile.com>
Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E5B1235A3@PUEXCB1B.nanterre.francetelecom.fr>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Authenticated-User: hesham@elevatemobile.com
Cc: IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update
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: Fri, 21 Sep 2012 13:04:25 -0000
>> >>A few quick comments on the drat having gone through it quickly. >> >>1. Requirements 1 and 2 are sort of redundant in an IETF document. The >>purpose od RFC 3316 was t specify IETF protocols that should >>be supported >>by the cellular host. PDP context has nothing to do with IETF protocols >>and functionally speaking it's outside of the IP stack. >>Therefore, I see >>no reason for specifying this in an RFC. It's not harmful, but >>since it's >>specified elsewhere, having such redundancy can lead to >>confusion if 3GPP >>specs change for example. So it's best to remove them. > >Med: I see the point but we consider it from another perspective: We >tried to answer to the question "What a device should support in order to >be IPv6-compliant + be able to be connected to a3GPP network". => So why don't you talk about the radio interface? :) It's out of scope. The PDP context is the same. It's out of scope for IETF. >There is no single document defining an IPv6 profile for cellular >hosts/devices. We wanted a single document listed both IETF and 3GPP >specification. => There is, RFC 3316, which you're trying to update and it doesn't talk about link layers. > >> >>4. for req 6 and 7. Are we sure this is a SHOULD? Are we effectively >>requiring these functions for all deployments? It seems like a big >>mandate, who's pushing for this? Just need to see that we have >>consensus >>on this. I think Req 8 has the right keyword "MAY" and the same should >>apply to 6 and 7 IMO. > >Med: These are important features to support if we want IPv6-only >connectivity model to fly. => But they're not the only way to support IPv6-only. There are many different variations therefore SHOULD/MUST is way too strong. Please check the definitions of should and must. > > >> >>5. REQ 9 and 10 are also too strong. This is a MAY by the definition of >>keywords. It's an optimisation. > >Med: There are various reasons to have PCP as SHOULD: save the battery >consumption, reduce keepalive message, Control and retrieve the lifetime >of NAT bindings, ease NAT and firewall traversal for application >embedding IP address and/or port number(s) in the application payload, >allow for successful inbound communications and for the capability to >control outgoing connections, control and retrieve the lifetime of NAT >bindings (including implicit ones), allow NAT binding recovery, trigger >applications to repairs their bindings whenever this is required. => I wasn't discussing the features of PCP, it's more about the keyword used. Should means you basically have to support it unless you know better. In practice everyone follows a should. It's not optional. >> >>8. REQ 21 is completely redundant because this behaviour is >>mentioned in >>RFC 3314, 3316 and 3GPP specs. >> >>9. REQ 27: For 3GPP specs there are defined standards for discovering >>their servers. Why would you list another mechanism not >>related to 3GPP? > >Med: This is an optional feature which would solve an issue of >bootstrapping in a non-3GPP network. I have added a note in >http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-reqs-rfc3316upd >ate-01: > > [DISCUSSION NOTE: Since this is still an individual submission, > should we remove this item?] > > >>The purpose of the draft is to address a specific deployment. >>General IETF >>specs are available to all implementers and they can decide >>for themselves >>what they want to implement on top of the base. >> >>10. I disagree with REQ 28. This is an experimental RFC. If >>someone does >>it that's fine, but no need to mandate it here. > >Med: This is for a CPE-like service. We need a solution for the issue >discussed in that REQ. RFC4389 is what we have now. If there is any >better ref, I can add it. => I think I responded to this separately. > >> >>11. REQ#29: "The cellular device MUST support Prefix Delegation >> capabilities [RFC3633 <http://tools.ietf.org/html/rfc3633>]. >>Particularly, it MUST behave as a >> Requesting Router." >> >>=> Why? Where did this come from? I disagree with this >>requirement. It's >>up to each implementation to decide that. At best, you could have a MAY >>but it's completely redundant. And as a consequence, so is REQ 30. >> > >Med: REQ#29 and REQ#30 have been merged in -01 >(http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-reqs-rfc3316up >date-01) > >> >>12. REQ#31: The cellular device SHOULD support Customer Side >>Translator >> (CLAT) [I-D.ietf-v6ops-464xlat >><http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-req >>s-rfc3316upd >>ate-00#ref-I-D.ietf-v6ops-464xlat>]. >> >>=> Why? Why SHOULD? Again, at best a MAY. > >Med: This is for the case where there is an IPv4 host connected behind >the cellular CPE. => Again, I'm objecting to the level of support not the use case. Hesham > >> >>Thanks, >>Hesham
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… Hesham Soliman
- [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3… mohamed.boucadair
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… GangChen
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… Ted Lemon
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… mohamed.boucadair
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… Lorenzo Colitti
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… mohamed.boucadair
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… Hesham Soliman
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… Lorenzo Colitti
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… Hesham Soliman
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… mohamed.boucadair
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… mohamed.boucadair
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… Hesham Soliman
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… Lorenzo Colitti
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… GangChen
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… Hesham Soliman
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… jouni korhonen
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… mohamed.boucadair
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… Ted Lemon
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… mohamed.boucadair
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… mohamed.boucadair
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… mohamed.boucadair
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… Hesham Soliman
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… Ted Lemon
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… mohamed.boucadair
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… Hesham Soliman
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… mohamed.boucadair
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… Ted Lemon
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… Behcet Sarikaya
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… mohamed.boucadair
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… Hesham Soliman
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… Hesham Soliman
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… Hemant Singh (shemant)
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… mohamed.boucadair
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… Hesham Soliman
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… david.binet
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… david.binet
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… mohamed.boucadair
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… MAWATARI Masataka
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… jouni korhonen
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… Rajiv Asati (rajiva)
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… jouni korhonen
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… mohamed.boucadair
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… Lorenzo Colitti
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… mohamed.boucadair
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… Rajiv Asati (rajiva)
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… Anupam Kapoor
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… david.binet
- Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-… mohamed.boucadair