Re: [drinks] Your COMMENTs on draft-ietf-drinks-framework (Martin Stiemerling)
Martin Stiemerling <mls.ietf@gmail.com> Tue, 19 May 2015 07:14 UTC
Return-Path: <mls.ietf@gmail.com>
X-Original-To: drinks@ietfa.amsl.com
Delivered-To: drinks@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01D41AC436 for <drinks@ietfa.amsl.com>; Tue, 19 May 2015 00:14:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdPPONjUbsO4 for <drinks@ietfa.amsl.com>; Tue, 19 May 2015 00:14:45 -0700 (PDT)
Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21FE21ACD37 for <drinks@ietf.org>; Tue, 19 May 2015 00:14:45 -0700 (PDT)
Received: by wicmc15 with SMTP id mc15so106127107wic.1 for <drinks@ietf.org>; Tue, 19 May 2015 00:14:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=dY2u/87MuHOjBa/UJND9hgkp6Zvl9VYU7YsWFM5eX5Q=; b=hgrjszv7PQQUf5aersEFSmqUI/dAWpUnAwNV1mPNpfDIAwYurQtLJW/73VNX4kqwSE gCRw70ysLtJP4jBKvgFNec3wzKSGjd/n+kbmiujs9570Nm8lT0TloxdVgVZyJjwKQkVf FzEb9fCsVtLGJDOEwSX+ZBAYelZVAUH3yTdPq9t5YZIfZKBIH06lXITuhw2ecR820r1E wjk+2JLLGQDpIcVoGnhWk1wxwcNHyYqHhq6wYeSZDz+PO146m6IVO2w4k0ZqdYp1nPEb JmaJJjP7NW9r/EjPjoENxkbkV0mcLuy0Cwjv5KrW6Px9gQy4EEtBBVDDl+cWDn6Izss+ ydLg==
X-Received: by 10.181.6.37 with SMTP id cr5mr28669412wid.18.1432019683878; Tue, 19 May 2015 00:14:43 -0700 (PDT)
Received: from Martins-MacBook-Pro.local (ip-109-42-1-46.web.vodafone.de. [109.42.1.46]) by mx.google.com with ESMTPSA id w5sm15883588wiz.11.2015.05.19.00.14.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 May 2015 00:14:43 -0700 (PDT)
Message-ID: <555AE289.9020603@gmail.com>
Date: Tue, 19 May 2015 09:13:13 +0200
From: Martin Stiemerling <mls.ietf@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Alexander Mayrhofer <alexander.mayrhofer@nic.at>
References: <19F54F2956911544A32543B8A9BDE075467F753A@NICS-EXCH2.sbg.nic.at>
In-Reply-To: <19F54F2956911544A32543B8A9BDE075467F753A@NICS-EXCH2.sbg.nic.at>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/drinks/iWPkPhbc98zzMffv-r-ZUPT3LZc>
Cc: "drinks@ietf.org" <drinks@ietf.org>
Subject: Re: [drinks] Your COMMENTs on draft-ietf-drinks-framework (Martin Stiemerling)
X-BeenThere: drinks@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DRINKS WG <drinks.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/drinks>, <mailto:drinks-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/drinks/>
List-Post: <mailto:drinks@ietf.org>
List-Help: <mailto:drinks-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/drinks>, <mailto:drinks-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 May 2015 07:14:47 -0000
Hi Alexander, Thanks for considering my comments and all your proposed changes are addressing my concerns. Thanks, Martin Am 18.05.15 um 17:43 schrieb Alexander Mayrhofer: > Hello Martin, > > Thanks for your IESG evaluation COMMENTs on > draft-ietf-drinks-framework. Please find our responses inline, marked > with "->": > > ---- I have a number of comments and one big near DISCUSS point: > > The definition of your meaning of " transport protocols" is stated > just in Section 4.11 and you mean for instance SOAP. However, SOAP is > not a transport protocol in the sense as the rest of the world AFAIK > is using the term transport protocol. A transport protocol is a layer > 4 protocol and not something that is running on top. > > Can you please change your terminology? Otherwise, all my points > below become a DISCUSS, as your requirements basically rule out > transport protocols to run over. > > -> We have changed the terminology to "Substrate Protocol", as > suggested by Spencer. > > - Section "4.4. Authentication" > > authenticated SPP Client is a Registrar. Therefore, the SPPF > transport protocol MUST provide means for an SPPF server to > authenticate an SPPF Client. > > This MUST requirement basically lets you without any transport > protocol choice left. None to me known transport protocol is > supporting the authentication between client and server. Unless you > will wait for TCPINC. > > Perhaps you mean this: "Therefore, SPPF MUST leverage appropriate > mechanisms provided by underlying protocol layers for an SPPF server > to authenticate an SPPF Client". > > -> Ah, well, we've taken a few years to create these drafts > (seriously!), so, we'd rather not Wait for TCPINC. I can see that > this is due to the unclear terminology regarding "transport". > > -> The sentence now reads: " the SPPF substrate protocol MUST provide > means for an SPPF server to authenticate an SPPF Client." > > This will allow to use TLS which is not a transport protocol, but > running on top of it. In case you have a different defintion of > transport protocol, it would be good to state this. > > - Section "4.6. Confidentiality and Integrity" Therefore, the > transport protocol MUST provide means for data integrity protection. > > -> now reads " Therefore, the substrate protocol MUST provide means > for data integrity protection." > > Similar discuss to the point above: None of the IETF transport > protocols is providing means for data integrity protection. So you > won't ge too far. > > - Section "4.9. Request and Response Correlation": > > Same as the ones before: A transport protocol suitable for SPPF MUST > allow responses to be correlated with requests. > > TCP, UDP and SCTP will not offer this. > > -> Changed to "substrate protocol" again. > > In Section "4.2. Request and Response Model" > > Therefore, a transport protocol for SPPF MUST follow the request- > response model by allowing a response to be sent to the request > initiator. > > The last part is worded a bit strange: "allowing a response to be > sent..". How about saying "my ensuring a response to be sent to > the..."? > > -> changed to "substrate" and "ensuring". > > In Section "4.3. Connection Lifetime": > > What is in a quantity short and long-lived? This sentence does not > make any sense, unless it is state what a short time period for such > a protocol and what a long time period is. > > -> I've added text that clarifies "short-lived" means sub-seconds to > a few seconds, And that the other extreme of "long-lived" would mean > several hours or even days. I know it's still vague - would that > work? > > In Section "Near Real Time" I am not sure how good or bad one can > determine if any protocol is reacting in near real-time. And what is > realtime anyhow? Measured in nano seconds, milliseconds, etc? > > -> I've added text that "near-real-time" would mean "in the range of > a few multiples of round-trip-times Between client and server". > Again, vague - does that work? > > Thanks, Alex >
- [drinks] Your COMMENTs on draft-ietf-drinks-frame… Alexander Mayrhofer
- Re: [drinks] Your COMMENTs on draft-ietf-drinks-f… Martin Stiemerling