Subject: [clue] Review of framework-19

From: Stephan Wenger <[email-masked]>
Date: Wed, 17 Dec 2014 02:22:41 +0000

Hi all,
I'm one of the authors, but (as many of you know) have not actively contributed in a year or so.  Insofar, I think this review qualifies as a set of fresh eyes, though not one that is impartial.

I have no major technical comments, and I'm generally happy with the document.  I have, however, a minor non-editorial comments and a few nits.  As far as I am concerned, none are showstoppers.

Major issues:
None

Minor issues:

  1.  Page 3, last para "CLUE specific signaling".  At this point in the text, the term "CLUE" is undefined.  I don't think it is defined anywhere.  Since "CLUE signalling", "CLUE channel", ... are used elsewhere in the text, I think page 3 would be the right place to define "CLUE", probably as something like "a set of protocols described in this memo and accompanying documents (the term "CLUE stems from the IETF working group <clue deacronym>."  As an alternative, CLUE could also defined as a stand-alone term in section 3 (around page 4).
  2.  Page 8.motivation (1): I think that this motivation is generally correct when adding "in a cross-vendor interoperable way". I know from a number of systems that allowed a mix-and-match, some of them designed as early as 2003.
  3.  Page 10, second para, add reference to data model doc?
  4.  Page 15, MUST strength for providing physical dimensions of known to the system.  I like this philosophically, but I think it's meaningless in practice, as the knowledge of coordinates of a pProvider is known to the consumer only as a side effect of sending  the measurements, right?  Perhaps less draconian language is more appropriate?  Sounds to me like a good place for a "SHOULD"?
  5.  Page 20, Languages: is this coded using a universal language tag?  If yes, should that be mentioned here, with reference?
  6.  Page 69, second para, is SIP the *default* conferencing protocol or just simply "the conferencing protocol"?  As the following MUST is unqualified, the "default" is probably incorrect.
  7.  Page 69 DTLS/SRTP "MUST" level support.  I think that was our agreement in Hawaii-pacify the security people, knowing that industry practice may well look different.  In this light, I think the mandatory to implement, optional to use formulation here is about right.  Is my recollection correct?
  8.  Page 69, fifth para, reference to data model doc is missing.  Also, my understanding of XML is such that a schema is the grammar of an XML document, but not the content.  Insofar, the info is NOT represented by a schema, it just is in XML format following a schema that is defined in the data model, right?
  9.  Page 70, first paragraphs.  There are two unqualified "SHOULD" statements.  In the spirit of fast doc approval, I wouldn't object if those were changed to "MUST".  I don't recall that we discussed these points before, but I could easily have missed that discussion.

Possible editorial improvements

  1.  Throughout the doc, the spacing after a full stop is inconsistent between a single and double space.  (My personal preference is double space).
  2.  Hyphens are sometimes represented with double minus and no spaces, and sometimes single minus with spaces.  (My personal preference is double minus without spaces.)
  3.  In-doc cross-references are not hyperlinks in PDF version
  4.  In some cases, references to I-Ds are not hyperlinks.  In other cases, they are.
  5.  Bullets are sometimes shown as "o", sometimes as "."
  6.  Page 6, MCU, suggest to remove the acronym at the begin of the line.
  7.  Page 7, ampersand in headline of section 4: suggest to replace it with "and"
  8.  Page 13, second para, middle, "it MAY, but is not necessarily REQUIRED to, "  The "REQUIRED" part is redundant.
  9.  Page 21, types of Captured people: shouldn't there be an additional "Observer"?  "Members" have the right to speak up, "Observers" have not?  Or are these people types coming from some other doc?
  10. Page 26, Table 3 should not be split over two pages
  11. Page 27, Table 4 should not be split
  12. Page 30, third para, "In some cases, these multiple views would typically be used simultaneously" sounds awkward.  Can we do away with the "typically", as this does not appear a typical case, just one of many?
  13. Page 30, example should be on one page
  14. Page 33, rules, s/not important/insignificant/
  15. Page 40, first line, s/a n/an/
  16. Pages 54, 55, 60 one of the tables contains a page break
  17. Page 61 62, ditto, but that one is probably unavoidable due to the size of the tables

END