[drinks] Your COMMENTs on draft-ietf-drinks-framework (Martin Stiemerling)
Alexander Mayrhofer <alexander.mayrhofer@nic.at> Mon, 18 May 2015 15:43 UTC
Return-Path: <alexander.mayrhofer@nic.at>
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 B43EB1AC3DC for <drinks@ietfa.amsl.com>; Mon, 18 May 2015 08:43:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.741
X-Spam-Level:
X-Spam-Status: No, score=-5.741 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 zl2Fvk0GCZf5 for <drinks@ietfa.amsl.com>; Mon, 18 May 2015 08:43:25 -0700 (PDT)
Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E4CF1AC3E1 for <drinks@ietf.org>; Mon, 18 May 2015 08:43:24 -0700 (PDT)
Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.50 ; Mon, 18 May 2015 17:43:22 +0200
Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0224.002; Mon, 18 May 2015 17:43:17 +0200
From: Alexander Mayrhofer <alexander.mayrhofer@nic.at>
To: "mls.ietf@gmail.com" <mls.ietf@gmail.com>
Thread-Topic: Your COMMENTs on draft-ietf-drinks-framework (Martin Stiemerling)
Thread-Index: AdCRf4xWvGcnQaTOSkmE2BrZvTVt3w==
Date: Mon, 18 May 2015 15:43:16 +0000
Message-ID: <19F54F2956911544A32543B8A9BDE075467F753A@NICS-EXCH2.sbg.nic.at>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.10.0.163]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-XWALL-BCKS: auto
Archived-At: <http://mailarchive.ietf.org/arch/msg/drinks/1wNnezc1J47wVHNLUtlEfv24AZA>
Cc: "drinks@ietf.org" <drinks@ietf.org>
Subject: [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: Mon, 18 May 2015 15:43:26 -0000
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