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

["Barry Leiba" <[e-mail]>]

Barry Leiba 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:
----------------------------------------------------------------------

Former DISCUSS points, which are now left in "I trust the authors and AD
to do the right thing" state:

-- Section 2 --

   This document reuses terms from [RFC3261], [RFC5486], use cases and
   requirements documented in [RFC6461] and the ENUM Validation
   Architecture [RFC4725].

These are all listed as informative references.  If this terminology is
required in order to understand the terms used in this document, those
references (3261 and 5486) need to be normative.  Left to judgment to
decide.

-- Section 4.11 --

   At the time of this writing, a choice of transport protocol has been
   provided in SPP Protocol over SOAP document.

This would be a good place for a reference to that draft.  I think the
reference is important, as you've made it MTI; I think it's a normative
one.  I don't think "At the time of this writing" is necessary, though if
you really like it I don't object.  It's also missing a "the" and some
quotes, as thus:

NEW
   One choice of transport protocol has been provided in the document
   "SPP Protocol over SOAP" [reference].
END

About OrgIdType, I don't think the document makes it clear what this is,
and why new ones would be registered in the first place.  Why would we
ever need an OrgIdType Namespace other than "iana-en"?  Maybe add a
sentence or two about that?


The rest of these have already been reviewed and accepted by the authors;
thanks for taking the time to consider them:

-- Section 1 --

   1.  A resolution system returns a Look-Up Function (LUF) that
       comprises the target domain to assist in call routing (as
       described in [RFC5486]).

I don't know that it means for a LUF to "comprise the target domain";
perhaps its a meaning of "comprise" with which I'm unfamiliar. 
(Similarly for bullet 2.)

Also, where in 5486 is this described?  Is it Section 4.3.3?  It'd be
helpful to include that.

-- Section 2 --

   In addition, this document specifies the following additional terms:

You can get rid of "In addition," (my preference) or "additional"; you
don't need both.  (I would also use "defines" rather than "specifies".)

   Server:   In the context of SPPF, this is an application that
      receives a provisioning request and responds accordingly.  It is
      sometimes referred to as a Registry.

   Registry:   The Registry operates a master database of Session
      Establishment Data for one or more Registrants.

The latter sentence in the first definition seems to say that "Server"
and "Registry" are synonymous.  How does it, then, make sense to have
separate definitions that are different?  And if they're not synonymous,
perhaps it's unwise to sometimes refer to a Server as a Registry.

In the definition of Registrant:

      Within the confines of a Registry, a Registrant is uniquely
      identified by a well-known ID.

What is a "well-known ID"?  What is well known about it?  I ask because
the term isn't otherwise used in this document.

-- Section 4 subsections --
These subsections are inconsistent in how they refer to the transport
protocol (and see Martin's comments about that).  Some of those
differences don't matter, but I think some do, and I think we'd be better
off making the terminology consistent.
4.1, 4.2, 4.10: "a transport protocol for SPPF"
4.3: "a protocol suitable for SPPF" [is the word "suitable" significant
here?]
4.4: "the SPPF transport protocol"
4.6: "the transport protocol" [doesn't mention SPPF]
4.7: "a DRINKS transport protocol" [DRINKS, as opposed to SPPF?]
4.8: "a suitable transport protocol for SPPF"
4.9: "a transport protocol suitable for SPPF"

You're in a maze of little twisting passages, all different.
I suggest picking one phrasing and using it in all nine subsections.

-- Section 5.2 --

   "Name" attributes that are used as components of object key types
   MUST be treated case insensitive, more specifically, comparison
   operations MUST use the toCasefold() function, as specified in
   Section 3.13 of [Unicode6.1].

It's a small point, but I think it would be better to lead with the more
specific requirement, which makes the other unnecessary except by way of
explanation:

NEW
   "Name" attributes that are used as components of object key types
   MUST be compared using the toCasefold() function, as specified in
   Section 3.13 of [Unicode6.1].  That function performs
case-insensitive
   comparisons.
END