Re: [v6ops] draft-ietf-v6ops-rfc3316bis WGLC

Jouni Korhonen <jouni.nospam@gmail.com> Thu, 23 May 2013 07:15 UTC

Return-Path: <jouni.nospam@gmail.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 5818011E81A6 for <v6ops@ietfa.amsl.com>; Thu, 23 May 2013 00:15:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level:
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqTCd1yey3c5 for <v6ops@ietfa.amsl.com>; Thu, 23 May 2013 00:15:51 -0700 (PDT)
Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id A79F711E81A1 for <v6ops@ietf.org>; Thu, 23 May 2013 00:15:49 -0700 (PDT)
Received: by mail-ee0-f42.google.com with SMTP id c50so1577059eek.1 for <v6ops@ietf.org>; Thu, 23 May 2013 00:15:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=57xZm44TDP9Ec3HxvqTOf02HzuthSblE/DnUB0hpB3w=; b=c1m03mvrGd+XVUtzgpWG9KdUh7kHEPI9EhZSI7iiojXn/iN6FFjP2bJeaAz1TUK9T6 rq27PH8yYH26T7aXsKPq3n+NNi2ys4JVJ4GkFDX3chgzLsyPC5mHBG+zSCA25Y2kcVXR jxNhGhxjBOfIRtBhrcH/ZDb75mr+KycrFIBKH0X6+d6LJ+jmlNuU6WbQhG0JsrO6UtZt wJPy75peLguqO1O7cT0TXc6kCrjHrpo9J7wh/nEuto4qpTN2r4/s/XsENR8rhsS1MJRR 9NYBuidLpZq/Is7IPAoHL/Vy64ZDzcma1sZKW3WuYUtOkRdRpjilkOf6KNZ7xYLqfZmR FCvA==
X-Received: by 10.14.95.4 with SMTP id o4mr23837699eef.2.1369293348550; Thu, 23 May 2013 00:15:48 -0700 (PDT)
Received: from [192.168.1.169] (hd5b9120a.seluldx.sta.perspektivbredband.net. [213.185.18.10]) by mx.google.com with ESMTPSA id x41sm14836692eey.17.2013.05.23.00.15.46 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 May 2013 00:15:47 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Jouni Korhonen <jouni.nospam@gmail.com>
In-Reply-To: <CAM+vMESxFfOb177u2nWN6v0xRO+47LGeQKv-hNL3txTdWpTvJQ@mail.gmail.com>
Date: Thu, 23 May 2013 10:15:45 +0300
Content-Transfer-Encoding: 7bit
Message-Id: <0E843E14-A844-4B87-8965-816CB963331A@gmail.com>
References: <8C48B86A895913448548E6D15DA7553B8EE5DB@xmb-rcd-x09.cisco.com> <CAM+vMESxFfOb177u2nWN6v0xRO+47LGeQKv-hNL3txTdWpTvJQ@mail.gmail.com>
To: GangChen <phdgang@gmail.com>
X-Mailer: Apple Mail (2.1503)
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6ops-rfc3316bis WGLC
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, 23 May 2013 07:15:56 -0000

Hi Gang,

Thanks for the review. See my initial comments inline.

On May 23, 2013, at 9:29 AM, GangChen <phdgang@gmail.com> wrote:

> wg,
> 
> The draft contains useful discussions to help shaping IPv6 profile on
> mobile phone. I support WGLC. The below comments are only for
> discussion/consult/clarification.
> 
> 1) section 2.2 Neighbor Discovery
> 
> Once we discuss NS/NA, I'm struggling with the usage of those two
> messages. The draft has very good description about notes on
> point-to-point interface. The texts teach me that neighbor discovery
> and NUD may be unnecessary, beacause the mobile phone doesn't rely on
> NS/NA to discover neighbor and NUD is desirable to be achieved through
> uppper layer guarantee. In some degree, audience may have impressions
> mobile phones can eliminate NS/NA to reduce additional signalling. I'm
> not sure if we could give those recommendations. Otherwise, it maybe
> helpful if the draft can clarify the usages of NS/NA to a mobile
> phone.

So you want even more NS/NA text? What else needs to be added? So far we
got the following:

 o no address resolution.. due no link-layer addresses
 o cellular host must support NUD (which then includes both
   upper layer mechanisms and the unicast NS/NA one)
 o DAD is not needed (and can be turned off using RFC4861 configuration
   mechanisms) but causes no harm either if done.

You can skip periodic unicast NS/NA NUD whenever you get the reachability
confirmation from the upper layers. I do not see how this leads to possible
elimination of NS/NA?

> In regard to NUD using upper layer protocol, I have observed some apps
> normally do keepalive/beacon message to fresh the link. Could those
> messages be a tool to maintain NUD?

Yes.. assuming the upper layer traffic is there all the time and
bidirectional. That does not justify removal of explicit NUD using
unicast NS/NA.

> 2) I guess both section 2.3 and 2.4 cover SLACC. Reading the contents,
> I feel section 2.4 seems a sub-section of 2.3. It may be good to
> assign a proper section number.

Ok. I'll give this a though.

> In section 2.4, there is texts "as each delegated prefix is unique".
> May I suggest to reword "delegated" to
> "advertised/configured/assigned" to avoid the ambiguity with DHCP-PD

Right. This was already agreed after Ales' review.

> 3) section 2.5
> It described the case of split mobile station. I guess it may help if
> the draft adds a example for MT. USB dongle can be a MT.You may add
> "(MT, e.g., a USB dongle)", like you did for TE. That also reminds me
> "a mobile phone handset" used in the section of Abbreviations. Should
> it be proper to use a USB dongle for the example. A mobile phone
> handset seems like a mobile station, which is comprised of MT and TE.

Ok. I'll draft something around this.

> 
> 4)section 2.7
> 
> If i remember coorectly, 3GPP label Privacy Extensions as the level of
> "MAY". This section use "should" and "may" in the same paragraph. I
> guess we may could align the statement(even that not have normative
> meaning)

Right. 3GPP has both "may" and "can" for privacy extensions, depending
on the specification (i.e. 23401 say may use mechanism defined in 23221,
which then says can use rfc4941). OK to lower the requirement language
here.

> 5)section 2.10
> 
> One typo maybe there. "me" should be corrected.
> 
> These options me be useful for cellular
>                      ^^

Ack.

> 6)section 2.11
> 
> DNS server address can also be provisioned through PCO option. Should
> it be mentioned in this section?

We say that the host may learn the DNS server address by lower layer
means.. the IP stack has no idea of PCOs and we have on purpose kept
the term PCO out of the document.

Thanks.

- Jouni



> 
> Best Regards
> 
> Gang
> 
> 
> 2013/5/20, Fred Baker (fred) <fred@cisco.com>:
>> The working group last call for this draft-ietf-v6ops-rfc3316bis announced
>> last week continues for another week. Please feel free to comment on it.
>> 
>> 
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops