Re: [Mobopts] IESG 3932 review of draft-irtf-mobopts-mmcastv6-ps

"Koodli, Rajeev" <rkoodli@starentnetworks.com> Thu, 24 September 2009 17:09 UTC

Return-Path: <rkoodli@starentnetworks.com>
X-Original-To: mobopts@core3.amsl.com
Delivered-To: mobopts@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D5D628C121 for <mobopts@core3.amsl.com>; Thu, 24 Sep 2009 10:09:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.071
X-Spam-Level:
X-Spam-Status: No, score=-2.071 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqPkuzfotdLo for <mobopts@core3.amsl.com>; Thu, 24 Sep 2009 10:09:13 -0700 (PDT)
Received: from mx1.starentnetworks.com (mx1.starentnetworks.com [63.118.244.150]) by core3.amsl.com (Postfix) with ESMTP id 756403A6877 for <mobopts@irtf.org>; Thu, 24 Sep 2009 10:09:13 -0700 (PDT)
X-ASG-Debug-ID: 1253811410-23e600520002-hAkvSY
X-Barracuda-URL: http://63.118.244.150:8000/cgi-bin/mark.cgi
Received: from exchtewks1.starentnetworks.com (localhost [127.0.0.1]) by mx1.starentnetworks.com (Spam & Virus Firewall) with ESMTP id E547DEFC64A; Thu, 24 Sep 2009 12:56:50 -0400 (EDT)
Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx1.starentnetworks.com with ESMTP id JleC79yI93fgZKCC; Thu, 24 Sep 2009 12:56:50 -0400 (EDT)
X-Barracuda-Envelope-From: rkoodli@starentnetworks.com
Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Sep 2009 12:55:10 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-ASG-Orig-Subj: RE: [Mobopts] IESG 3932 review of draft-irtf-mobopts-mmcastv6-ps
Date: Thu, 24 Sep 2009 12:44:57 -0400
Message-ID: <4D35478224365146822AE9E3AD4A26660C21B8C3@exchtewks3.starentnetworks.com>
In-Reply-To: <4ABB39DF.10609@piuha.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Mobopts] IESG 3932 review of draft-irtf-mobopts-mmcastv6-ps
Thread-Index: Aco8+BFUzu5Wu8KWTvGo+fZXGlGmmAAP0CXg
References: <4ABB39DF.10609@piuha.net>
From: "Koodli, Rajeev" <rkoodli@starentnetworks.com>
To: <draft-irtf-mobopts-mmcastv6-ps@tools.ietf.org>, "IESG" <iesg@ietf.org>, "ml-mobopts" <mobopts@irtf.org>
X-OriginalArrivalTime: 24 Sep 2009 16:55:10.0960 (UTC) FILETIME=[C74BA700:01CA3D37]
X-Barracuda-Connect: exchtewks1.starentnetworks.com[10.2.4.28]
X-Barracuda-Start-Time: 1253811410
X-Barracuda-Virus-Scanned: by Barracuda Spam & Virus Firewall at starentnetworks.com
Cc: 16ng-chairs@tools.ietf.org, multimob-chairs@tools.ietf.org, ipdvb-chairs@tools.ietf.org
Subject: Re: [Mobopts] IESG 3932 review of draft-irtf-mobopts-mmcastv6-ps
X-BeenThere: mobopts@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobility Optimizations <mobopts.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/mobopts>
List-Post: <mailto:mobopts@irtf.org>
List-Help: <mailto:mobopts-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Sep 2009 17:09:14 -0000

 
Hi Jari,

Thanks for your review. The authors will find your input useful and will
address them.

> I have not found any collision with this work and IETF work, 
> though obviously, this work has been one of the inputs for 
> the formation of the MOBOPTS working group, and also talks 
> about IP over a number of link layers.

Perhaps you meant MULTIMOB above.

Regards,

-Rajeev


> 
> I have recommended the standard RFC 3932 boilerplate IESG 
> note about non-IETF work. Once the 3932bis work is concluded 
> we will be able to make use of the new style of headers and 
> boilerplates which do not require IESG notes. I have written 
> to the tracker that if this happens before this document 
> comes out of the RFC Editor queue then no note is needed.
> 
> The document will be under the entire IESG's review in two 
> weeks to confirm my recommendation. Please remember that 
> neither my review or the IESG review is a technical review. 
> In other words, the RG is fully responsible for the 
> correctness of the document. As a personal note I wanted to 
> say nevertheless that I was reasonably happy with the 
> document. Thank you for writing this.
> 
> In any case, I have included a few personal review comments 
> below. Also, as the document contains quite a bit of material 
> relating to IP over
> 802.16 and IP over DVB, I have Cced the relevant working 
> group chairs in case they have further comments.
> 
> Jari Arkko
> 
> > obility management may issue
> >    traffic directives that lead to suboptimal routing, 
> i.e., erroneous
> >    subscriptions following predictive handover operations, or slow
> >    effective leaves caused by MLD querying, or by departure 
> of the MN
> >    from a previous network without leaving the subscribed groups.
> >   
> 
> I had a hard time parsing this. Maybe say instead: "Mobility 
> management may impact routing by, e.g., erroneous ... or by 
> MNs leaving networks without unsubscribing form the groups 
> they were receiving.". What's a "slow effective leave"?
> 
> > IP multicast deployment in general has been hesitant over 
> the past 15
> >    years
> 
> s/hesitant/slow/?
> 
> > a strong business case for IP
> >    portables
> ... portable IP-based devices.
> 
> > Current packet filtering practice causes inter-working 
> problems between Mobile IPv6 nodes connected via GPRS [46 
> <http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps-08#
> ref-46>].
> >   
> This is incorrect AFAIK. There are filtering procedures in 
> IMS that cause problems for Mobile IPv6 and other things. 
> However, those filtering mechanisms are not a part of the 
> link layer nor are they applied for regular Internet access. 
> I would suggest this statement be deleted from the draft, 
> along with the reference.
> 
> > PTM uses an
> >    unidirectional common channel, operating in 
> unacknowledged without
> >    adjustment of power levels and no reporting on lost packets.
> >   
> 
> ... unacknowledged mode?
> 
> >  Mobility services transport for MIH naturally reside
> >    on the network layer and are currently in the process of
> >    specification [55 
> <http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps-08#
> ref-55>].
> >
> >   
> draft-ietf-mipshop-mstp-solution is an approved specification 
> (though not yet out of the RFC Ed queue).
> 
> Also, I believe 802.21 specifies both network and link layer 
> transport, so its not clear why you say "naturally" above.
> 
> In general Section 4 wanders off a little bit to topics 
> outside multicast. I understand that some amount of 
> explanation is needed about what each L2 technology does, but 
> I'd consider tightening the text in
> AUTH48 in some places.
> 
> > MLD
> >    router querying will allow the multicast forwarding state to be
> >    restored in case of an erroneous prediction (i.e., an anticipated
> >    move to a network that is not fulfilled).
> fulfilled?
> 
> >    Mobility protocols need to consider the implications and 
> requirements
> >    for AAA. AAA binding records may change between 
> attachments, or may
> >    be individually chosen prior to network 
> (re-)association. The most
> >    appropriate network path may be one that satisfies user 
> preferences,
> >    e.g., to use/avoid a specific network, minimize monetary 
> cost, etc,
> >    rather than one that only minimizes the routing cost. 
> Consequently,
> >    AAA bindings cannot be treated at a pure level of 
> context transfer.
> >   
> It was not clear to me why AAA is relevant. And what's an 
> "AAA binding record"? I must say that I don't understand the 
> rest of the paragraph either.
> 
> The term AAA was not defined or expanded. Please check the 
> other terms too.
> 
> > Due to lack of feedback, the admission [83 
> <http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps-08#
> ref-83>] and binding
> >    updates [84 
> <http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps-08#
> ref-84>] of mobile multicast sources require autonomously
> >    verifiable authentication as can be achieved by Cryptographically
> >    Generated Addresses (CGAs).
> >   
> And presumably with other means as well. I would suggest 
> saying "... be achieved by, for instance, ...".
> 
> It would have been interesting if Section 8 listed some of 
> the multicast specific issues around security. For instance, 
> I would presume that a HA operating tunneled multicast 
> service by n-casting is more vulnerable to a DoS attack than 
> some other more native multicast solution.
> 
> Jari
> 
> _______________________________________________
> Mobopts mailing list
> Mobopts@irtf.org
> http://www.irtf.org/mailman/listinfo/mobopts
>