[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