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