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

[Martin Stiemerling <[e-mail]>]

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
>