[drinks] Ben Campbell's Yes on draft-ietf-drinks-spp-framework-11: (with COMMENT)

["Ben Campbell" <[e-mail]>]

Ben Campbell has entered the following ballot position for
draft-ietf-drinks-spp-framework-11: Yes

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 https://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:
https://datatracker.ietf.org/doc/draft-ietf-drinks-spp-framework/



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

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

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

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

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


*** 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/