[drinks] Barry Leiba's Discuss on draft-ietf-drinks-spp-framework-09: (with DISCUSS and COMMENT)

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

Barry Leiba has entered the following ballot position for
draft-ietf-drinks-spp-framework-09: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

-- 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 you use terminology
defined elsewhere, those references (3261 and 5486) need to be normative
(they're required in order to understand the terms used in this
doument).

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

-- Section 11.2 --

Why does the policy need to be RFC Required?  Why not Expert Review?  For
that matter, why not FCFS?  You can either point me at mailing list
archives where this was discussed, or explain the necessity in response
to this comment.

While we're talking 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"?  Shouldn't the document say something about that?


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

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

-- Section 11.2 --
The ABNF allows an OrgIdType Namespace identifier to end with "-"; is
that intentional?