[drinks] Martin Stiemerling's No Objection on draft-ietf-drinks-spp-framework-09: (with COMMENT)

["Martin Stiemerling" <[e-mail]>]

Martin Stiemerling has entered the following ballot position for
draft-ietf-drinks-spp-framework-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-drinks-spp-framework/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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. 

- 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". 

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.

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. 




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..."?

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. 

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?