[16NG] Re: review of the new revision (ipv6 over ipcs)

Basavaraj Patil <basavaraj.patil@nokia.com> Tue, 23 January 2007 20:19 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9S72-0008Ji-FI; Tue, 23 Jan 2007 15:19:24 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9S70-0008Jc-Fl for 16ng@ietf.org; Tue, 23 Jan 2007 15:19:22 -0500
Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9S6y-0001D6-Vy for 16ng@ietf.org; Tue, 23 Jan 2007 15:19:22 -0500
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0NKGOPB006471; Tue, 23 Jan 2007 22:16:52 +0200
Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jan 2007 22:19:40 +0200
Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jan 2007 14:19:38 -0600
Received: from 10.162.253.241 ([10.162.253.241]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Tue, 23 Jan 2007 20:19:38 +0000
User-Agent: Microsoft-Entourage/11.3.3.061214
Date: Tue, 23 Jan 2007 14:21:02 -0600
From: Basavaraj Patil <basavaraj.patil@nokia.com>
To: ext Jari Arkko <jari.arkko@piuha.net>
Message-ID: <C1DBCA4E.2CCDA%basavaraj.patil@nokia.com>
Thread-Topic: review of the new revision (ipv6 over ipcs)
Thread-Index: Acc/LABUPwgEjKsfEduYWwARJNUNiA==
In-Reply-To: <45B65C47.9020802@piuha.net>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 23 Jan 2007 20:19:38.0599 (UTC) FILETIME=[CE9E8F70:01C73F2B]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Cc: 16ng@ietf.org
Subject: [16NG] Re: review of the new revision (ipv6 over ipcs)
X-BeenThere: 16ng@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 16ng working group discussion list <16ng.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/16ng>
List-Post: <mailto:16ng@ietf.org>
List-Help: <mailto:16ng-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=subscribe>
Errors-To: 16ng-bounces@ietf.org

Hi Jari,

Responses inline:


On 1/23/07 1:04 PM, "ext Jari Arkko" <jari.arkko@piuha.net> wrote:

> Basavaraj, all
> 
> I reviewed the new version of this spec, and
> I'm generally quite happy with it. I found three
> small remaining issues which are listed below:
>>          +-----+   CID1    +-----+          +-----------+
>>          | MS1 |----------/| BS1 |----------|     AR    |-----[Internet
>> 
<http://tools.ietf.org/html/draft-ietf-16ng-ipv6-over-ipv6cs-06#ref-Internet>>>
]
>>          +-----+         / +-----+          +-----------+
>>             .           /        ____________
>>             .     CIDn /        ()__________()
>>          +-----+      /            L2 Tunnel
>>          | MSn |-----/
>>          +-----+
>> 
>> 
>>    Figure 5: The IPv6 AR is separate from the BS, which acts as a bridge
>>   
> The part about the BS acting as a bridge seems surprising.
> Is this really the case? A standard bridge function?

I did'nt mean bridge from the "standard bridge function" definition. I will
delete it from the document. Basically the BS is an L1/L2 entity, but I do
not believe I will not to elaborate on that.

> 
>>  This
>>  section presents a model for the last mile link, i.e. the link to
>>  which MSs attach themselves.
> I would remove this sentence. You need to explain
> how the link looks like from an IP perspective.
> And I think you are doing that. Whether there
> is a distributed or integrated BS/AR at the other
> end is really not a key issue.

Okay. Will work on this text as suggested.

> 
>>  IEEE
>>    802.16 also defines a secondary management connection that can be
>>    used for host configuration.  However support for secondary
>>    management connections is not mandatory.  A transport connection has
>>    the advantage of it being used for host configuration as well as for
>>    user data.
> Are you specifying something about the use of the
> management connections? If not, take it out.
>

Not really specifying anything w.r.t the management connection. This came up
during discussion with Alex Petrescu and I added it just for the sake of
completeness. Within the scope of this I-D, the management connection has no
relevance. I can take it out.
 
>> Each MS belongs to
>>    a different link.  No two MSs belong to the same link.
> Duplication. Remove the first sentence.
>

Okay. Editorial fix.

Will submit a revised version with these changes.

-Raj
 
> Jari
> 


_______________________________________________
16NG mailing list
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng