[drinks] Your COMMENT on draft-ietf-drinks-spp-framework

[Alexander Mayrhofer <[e-mail]>]

Hello Ben,

you made the following COMMENTs on draft-ietf-spp-framework - my responses inline, tagged with "ALEX-->". Generally, I'd like advice whether we should supply these changes as an RFC editor note, or roll a new version of the document? COMMENT discussion follows:


Hi, I've looked over the framework doc, and think it's almost ready to be approved. A have a few minor comments and questions first. 

-- 3.2, last paragraph:

That new "MUST NOT" is not appropriate.  The actual normative requirement was in the previous paragraph, and this paragraph is an example. I suggest "... is a valid UTC time, but not acceptable for use in SPPF messages".

(I know Pete suggested that, and normally I would not think to argue with him on 2119 matters. But in this case I think the change was an error.)

ALEX--> I'm happy to revert that. 

-- section 4, and subsequent:

Is there a real need to keep using the word "transport", even in quotes? 
I suggest changing the first sentence as follows, and then change all other mentions of "transport" to "substrate". (Except when referring to actual transport layer protocols)

OLD
   This section provides requirements for substrate protocols suitable
   as "transports" for SPPF.
NEW
   This section provides requirements for substrate protocols suitable
   to carry SPPF.
END

ALEX--> Sounds perfect to me, I can change that.

-- 8, 2nd paragraph: "XML specifications and _examples_ ... MUST be interpreted..."

Does this imply that the examples are normative?

Also I'm not sure what you mean by "interpreted in the character case presented"

ALEX--> The intention behind this is that casing of the XML must be preserved. The examples are not normative. Therefore, I propose to simply remove "and examples" from this sentence. Furthermore the word "interpreted" is maybe the culprit here, and I suggest to change that to "Unless stated otherwise, the character casing of XML specifications in this document MUST be preserved to develop a conforming specification" - would this work?

-- 9.7:

Jari and Peter had a comment on this section, where I think the MiTM terminology is getting in the way. I _think_ you are talking about a potentially compromised known intermediary that can see/modify data. I think he is talking about a MiTM attack on the protected substrate between the client and that intermediary, or that intermediary and a server. While MiTM is a fuzzy term, enough people think of it as an attack on crypto that it might be better to use a different term here. (e.g. "Compromised or Malicious Intermediary")

ALEX--> Agreed - our intention was to describe the case of a compromised intermediary. I will change the term.

*** nits ***

-- 4.1, '... in the IPv4 headers, of "Next Header" ... '

s/of/or

-- 4.1, 2nd paragraph:

s/that agree with/that support/  ; (or "that comply with")

-- 4.3
s/ensuring a response to be sent/ensuring a response is sent/

ALEX--> Thanks, will change that.

Please advice whether you would like to see a revised document, or an RFC Editor note writeup, and I can produce the respective text later tonight.

Thanks for the review!
Alex