Re: [drinks] Looking for 2-4 volunteers to review draft-ietf-drinks-usecases-requirements

[Peter Koch <[e-mail]>]

Alex, WG,

> we're looking for 2-4 additional volunteers for
> https://datatracker.ietf.org/doc/draft-ietf-drinks-usecases-requirements
> (outside of the core contributor team of the document). The document is

this is a coarse review of <draft-ietf-drinks-usecases-requirements-03.txt>.
Since I have (deliberately) not read the other comments on this version
of the draft, I apologize for potential duplications.

o UC INTERCONNECT #5  Provisioning of a delegated name server: An SSP
                       maintains a Tier 2 name server that contains the
                       NAPTR records that constitute the terminal step
                       in the LUF.  The SSP needs to provision a
                       registry to direct queries for the SSP's numbers
                       to the Tier 2 name server.  Usually queries to
                       the registry should return NS records, but in
                       cases where the Tier 2 uses a different domain
                       suffix from that used in the registry, CNAME and
                       NS records may be employed instead.
  (also REQ5)
    The rest of the use cases is rqther high level, so the apperance
    of "Tier 2" and the DNS RR types comes a bit out of the blue. Also,
    from a DNS perspective, the wording could benefit from a rephrase.
    (e.g., RR's aren't contained in a name server but in a DNS zone;
    "queries to the registry": the draft does not state that DNS is
    _the_ lookup protocol; CNAME+NS doesn't suggest how these would
    interact)  All in all, there are hidden assumptions here that
    would either need more explanation, more references - or maybe
    better even: an increased level of abstraction).
o UC SED EXCHANGE #1  SED Exchange and Discovery using unified LUF/LRF:
                       When establishing peering relationships some SSPs
                       wish to communicate or receive points of ingress
                       and other SED that contain LUF and LRF.
   What is meant by "points of ingress and other SED that contain LUF and LRF"?
o RN is not expanded in the draft (neither in RFC 5486.
o Capitalization of "destination group" is not consistent.
o The text below figure 3 misses a description of the relation between
  "SED record" and "PI".
o Page 9, 1st paragraph:
   to authorization.  However, the act of authorization is considered to
   be out of scope within this document.
  maybe "out of the scope of"? (see below for security implications)
o The term "lookup key", used in 3.6, is never defined.
  also: capitalization
o Routing Groups vs Route Groups (again: consistent capitalization)
  Routing Groups are defined under (1) Terminology and Route Groups
  are (re)defined under UC DATA #3. It is not clear to me that both
  definitions match 100%, but in any case terminology should be made
  consistent.
o IANA considerations: the list of non-actions should contain both
  registration and the creation of a registry (the absence thereof, of
  course).
o Security Considerations: the draft says "access" to data could compromise
  security without being clear whether this is read or write access.
  The document rules questions of authorization (for the provisioning
  mechanism) out of scope, so one of the major topics of protecting a
  registry is not addressed in the requirements.  Where are these aspects
  supposed to be covered?
o It is a bit unusual for an IETF document, albeit not completely without
  precedent, to list the affiliations in the Acknowledgements section.
o References: RFC 5486 (SPEERMINT terminology) should be a normative reference,
  since it is needed to understand this document.

-Peter