Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update

Hesham Soliman <hesham@elevatemobile.com> Fri, 21 September 2012 07:38 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 B14EA21F86B1 for <v6ops@ietfa.amsl.com>; Fri, 21 Sep 2012 00:38:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.486
X-Spam-Level:
X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, 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 n5zcO0acZBDb for <v6ops@ietfa.amsl.com>; Fri, 21 Sep 2012 00:38:51 -0700 (PDT)
Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 22B5921F86A1 for <v6ops@ietf.org>; Fri, 21 Sep 2012 00:38:43 -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 1TExot-0003nX-Mw; Fri, 21 Sep 2012 17:38:39 +1000
User-Agent: Microsoft-MacOutlook/14.2.3.120616
Date: Fri, 21 Sep 2012 17:38:32 +1000
From: Hesham Soliman <hesham@elevatemobile.com>
To: mohamed.boucadair@orange.com
Message-ID: <CC8252D3.290D7%hesham@elevatemobile.com>
Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update
In-Reply-To: <CAKD1Yr1xnF_mQwy-6OAyXRxkcpoNB099tVC+J89ni6wVA+bmSw@mail.gmail.com>
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 07:38:51 -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.

2. Same goes for the PCO. out of scope. It's no different than the IP
stack "finding" these parameters in a file that come from "somewhere".

3. Req 5, I suggest a MAY instead of a SHOULD.

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.

5. REQ 9 and 10 are also too strong. This is a MAY by the definition of
keywords. It's an optimisation.

6. REQ 18 repeats 3316, although the reference has changed, so it's
redundant. 

7. REQ 19 conflicts with REQ 5, MAY Vs SHOULD. If they're both MAY I'm ok
with that. 

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

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.


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-reqs-rfc3316upd
ate-00#ref-I-D.ietf-v6ops-464xlat>].

=> Why? Why SHOULD? Again, at best a MAY.

Thanks,
Hesham