Re: [NSIS] AD review comments of draft-ietf-nsis-qos-nslp-16
Jukka Manner <jukka.manner@tkk.fi> Fri, 16 October 2009 09:42 UTC
Return-Path: <jukka.manner@tkk.fi>
X-Original-To: nsis@core3.amsl.com
Delivered-To: nsis@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 302F83A699E for <nsis@core3.amsl.com>; Fri, 16 Oct 2009 02:42:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.345
X-Spam-Level:
X-Spam-Status: No, score=-5.345 tagged_above=-999 required=5 tests=[AWL=1.254, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 0wIX-VBN6557 for <nsis@core3.amsl.com>; Fri, 16 Oct 2009 02:42:12 -0700 (PDT)
Received: from smtp-3.hut.fi (smtp-3.hut.fi [130.233.228.93]) by core3.amsl.com (Postfix) with ESMTP id C73203A69BB for <nsis@ietf.org>; Fri, 16 Oct 2009 02:42:11 -0700 (PDT)
Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-3.hut.fi (8.13.6/8.12.10) with ESMTP id n9G9gDwN017275; Fri, 16 Oct 2009 12:42:13 +0300
Received: from smtp-3.hut.fi ([130.233.228.93]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 20390-260-2; Fri, 16 Oct 2009 12:42:13 +0300 (EEST)
Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-3.hut.fi (8.13.6/8.12.10) with ESMTP id n9G9g1Bt017226; Fri, 16 Oct 2009 12:42:01 +0300
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 98F391E13F; Fri, 16 Oct 2009 12:42:01 +0300 (EEST)
X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi
Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JCf2zhB5lxNt; Fri, 16 Oct 2009 12:41:57 +0300 (EEST)
Received: from mailsrv.netlab.hut.fi (mailsrv.netlab.hut.fi [130.233.154.190]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 411B21E077; Fri, 16 Oct 2009 12:41:57 +0300 (EEST)
Received: from [130.233.154.59] (pc59.netlab.hut.fi [130.233.154.59]) by mailsrv.netlab.hut.fi (Postfix) with ESMTP id 311A9120050; Fri, 16 Oct 2009 12:41:57 +0300 (EEST)
Message-ID: <4AD83FE5.7030707@tkk.fi>
Date: Fri, 16 Oct 2009 12:41:57 +0300
From: Jukka Manner <jukka.manner@tkk.fi>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
References: <4AC4B492.6070005@ericsson.com> <4AD472FF.4060306@tm.uka.de> <2727_1255685491_ZZ0KRL007U6P4IG6.00_4AD83CE0.8010605@ericsson.com>
In-Reply-To: <2727_1255685491_ZZ0KRL007U6P4IG6.00_4AD83CE0.8010605@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi
Cc: draft-ietf-nsis-qos-nslp@tools.ietf.org, Roland Bless <bless@tm.uka.de>, NSIS <nsis@ietf.org>
Subject: Re: [NSIS] AD review comments of draft-ietf-nsis-qos-nslp-16
X-BeenThere: nsis@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Next Steps in Signaling <nsis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsis>
List-Post: <mailto:nsis@ietf.org>
List-Help: <mailto:nsis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Oct 2009 09:42:13 -0000
Hi Magnus, So is the next step that I do the mentioned edits, and submit a version for the IESG? cheers, Jukka Magnus Westerlund wrote: > Roland Bless skrev: >> Hi Magnus, >> >> I'll try to answer C. and D. >> >> Magnus Westerlund wrote: >>> B. Section 3.1.3 contains a reference to draft-manner-nsis-nslp-auth. >>> This is an informational reference. But I do wonder about the security >>> solution and its need to carry authentication information. No, I don't >>> want to make this a normative reference. But I do wonder how the WG >>> plans to present the lack of even one fully specified security solution, >>> even if this is going for experimental. >> This is indeed a good point. Without the session authorization object, >> there is only TLS transport security in a hop-by-hop manner, which is >> also not related to individual sessions or users. So the above draft >> is indeed very useful. > > I think there might be a point to admit openly that the security > solution for this behavior is currently not specified and do require work. > >>> C. Section 3.2.12.1: How long does it take to detect that a new down >>> stream peer exist, or that truncation has happened? >> Route change detections depends on the GIST route change detection >> mechanisms, at latest the next GIST probing Query message >> sent. Details are described in section 4.4.4. of the GIST draft, so >> in the default case of 30s routing state validity probing Querys are >> sent in the interval [15s...22.5s]. In some cases GIST may detect >> route changes faster and thus send a new Query earlier. Route change >> detection requires the three-way GIST handshake to be completed first >> though (i.e., at least RTT for GIST Query/Response pair). >> In case of path truncation, one must distinguish whether the new >> next hop is GIST aware or not. The draft describes the former case, >> so GIST will respond with "Unknown NSLPID" error in the GIST Response >> to the Query and the same duration as above can be expected. In the >> latter case of a non GIST-aware hop it takes longer, because the >> querying node may perform retransmissions and exponentially backup, >> so in this case we get a default 127*500ms=63.5s (T1=500ms, T2=64s) >> as worst case. But as indicated in 5.3.3 of the GIST draft, NSLPs may >> bound this response time by limiting T2 in the sendmessage() primitive >> explicitly. >> > Thanks for the answer. I don't think there is any need to do changes > here in the text. > > >>> D. Section 4.6, page 35, second paragraph. It is not clear to me how (1) >>> can be guaranteed to arrive prior to (2), or if both message are sent >>> width bound to the other one? >> That's exactly the motivation for the message binding. You cannot >> guarantee it, so both messages have to wait on each other. This case >> is described on p. 36: "Triggering message" (3) arrives before waiting >> (bound) message (1). Usually the waiting condition is then already >> satisfied, so (1) can be processed immediately. I'm not sure that I >> understand the last part of your question correctly, but (1) will >> contain a BOUND_MSG_ID and (2) and (3) will carry the corresponding >> MSG_ID. >> > > Hmm, clearly my thought process wasn't working. I don't see any issues > with the text when revisiting it. It seem to have the relevant > references to the mechanism used. So forget this comment. > -- Jukka MJ Manner, Professor, PhD. Phone: +358+(0)9+451 2481 Helsinki University of Technology Mobile: +358+(0)50+5112973 Department of Communications Fax: +358+(0)9+451 2474 and Networking (Comnet) Office: G320 (Otakaari 5A) P.O. Box 3000, FIN-02015 TKK E-mail: jukka.manner@tkk.fi Finland WWW: www.comnet.tkk.fi
- [NSIS] AD review comments of draft-ietf-nsis-qos-… Magnus Westerlund
- Re: [NSIS] AD review comments of draft-ietf-nsis-… Roland Bless
- Re: [NSIS] AD review comments of draft-ietf-nsis-… Jukka Manner
- Re: [NSIS] AD review comments of draft-ietf-nsis-… Jukka Manner
- Re: [NSIS] AD review comments of draft-ietf-nsis-… Georgios Karagiannis
- Re: [NSIS] AD review comments of draft-ietf-nsis-… Roland Bless
- Re: [NSIS] AD review comments of draft-ietf-nsis-… Roland Bless
- Re: [NSIS] AD review comments of draft-ietf-nsis-… Jukka MJ Manner
- Re: [NSIS] AD review comments of draft-ietf-nsis-… Magnus Westerlund
- Re: [NSIS] AD review comments of draft-ietf-nsis-… Jukka Manner
- Re: [NSIS] AD review comments of draft-ietf-nsis-… Magnus Westerlund