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

["Pete Resnick" <[e-mail]>]

Pete Resnick 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:
----------------------------------------------------------------------

3.2: s/is not approved for use/MUST NOT be used

3.3: s/MUST/need to
     s/SHOULD/is expected to

4.1/4.2: s/MUST/will (These are both definitional, not requirements; how
could you possibly do otherwise?)

4.5:

   Refer to the Security Considerations section for further guidance.
   
Please use an xref in here in order to refer to the section number. There
are several of these named references throughout the document. Please fix
also 5.2.2, 6.1 (two occurrences), 6.3 (two occurrences), 6.4, 6.5 (two
occurrences), 6.6 (two occurrences), 7.1, 7.2, 7.4 (two occurrences), 7.5
(two occurrences), 7.6, 9.1 (two occurrences)

4.11: As written, this needs a (normative) reference to
-spp-protocol-over-soap. You can't have a MUST requirement without a
normative reference.

5.1: I think it's really awful practice to include protocol requirements
and syntax definitions inside IANA Considerations. IANA Considerations
are for *IANA*, not for the implementer and not for the folks entering
items in the registry. I strongly suggest moving the syntax requirements
and the ABNF from 11.2 into 5.1 and simply reverse the pointer so that
11.2 points to 5.1.

5.2: (I'm still trying to figure out how to non-normatively define
something. :-) ) Can name attributes really be non-ASCII? Aren't these
all protocol elements, not user-interface items? I am icked-out by having
to use toCasefold, and having to have a reference to specific Unicode
version.

5.2.1/5.2.2/5.3: I always find this construction bizzarre: "Any
conforming specification MUST define...". They're all MUSTs (save a few
MAYs in 5.3), and those MUSTs seem pretty unnecessary. For 5.3, you
should simply make the opening paragraph:

   The following table contains the list of response types that a
   transport protocol specification needs to provide. An SPPF server
   MUST implement all of the following at minimum.

And then strike "Any conforming specification MUST define a response to
indicate that" from all of the entries. Move the MAY bits out of the
table, as those aren't part of the description of each of those response
types. It'll shorten things up significantly.

5.3:

   o  The value for Attribute Value MUST be the value of the data
      element to which the preceding Attribute Name refers.

   o  Response type "Attribute value invalid" MUST be used whenever an
      element value does not adhere to data validation rules.

What other choice could an implementation make? In other words, if I were
to violate the first MUST, what do you think I'm going to put in to the
attribute value that I need to be instructed that I MUST NOT do?

6.4:

   hostName: Root-relative host name of the name server.

The additional term "root-relative" confused me. Are you somehow trying
to say that these names MUST NOT have a terminating "." (i.e., they must
be relative domain names)? If that's the point, then you should probably
say that. Otherwise, I would strike "root-relative". An absolute name
(with a terminating ".") should be OK in this context, yes?

10:

OLD
   Where human-readable languages are used in the
   protocol, those messages SHOULD be tagged according to [RFC5646]...

I think you mean that human-readable *messages* that might be displayed
to the user are to get language tags, but I don't see anywhere in the
spec where you produce human-readable messages. Can you point me to an
example. If so, you should probably say:

NEW
   Where human-readable messages that are presented to an end user are
   used in the protocol, those messages SHOULD be tagged with their
   language according to [RFC5646]...

Also:

   If tags are absent, the language of the message defaults to "en"
   (English).

That seems like a bad plan. If all of the characters are out of the
Arabic script, I'm pretty darn sure that an implicit default language tag
of "en" is unlikely to be helpful to an implementation. I would strike
that sentence.

11.2: See comment on section 5.1 above.