Subject: [drinks] Your COMMENTs on draft-ietf-drinks-framework (Martin Stiemerling)

From: Alexander Mayrhofer <[email-masked]>
Date: Mon, 18 May 2015 15:43:16 +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

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 19 May 2015 09:13:13 +0200

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.
>
> 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.
>
> Same as the ones before: A transport protocol suitable for SPPF MUST
> allow responses to be correlated with requests.
>
> 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..."?
>
> 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
>