[drinks] use cases document: background info on -04

[Alexander Mayrhofer <[e-mail]>]

As you might know, we received very useful reviews of the use cases
document from 3 contributors shortly after Maastricht (based on our call
for volunteers). Sumanth as the document editor has modified the use
cases draft based on the comments - the result of that work is version
-04 of the use cases document (for which the WG chairs intend to issue
WGLC shortly):

https://datatracker.ietf.org/doc/draft-ietf-drinks-usecases-requirements
/

The text below is background information about the individual issues
raised by the reviewers, and how they were addressed in -04. 

Alex

--------

Sohel's Review:
===============

> Some general comments: { 
> 
> Will it be addressed in a use case or say this is how it is done but 
> outside of scope. 
> 
> 8xx-xxx-xxxx translation to NPA-Nxx-xxxx. 

==> Alex: If i understand correctly, this is about mapping "service"
numbers
(such as toll-free) to geographic numbers (it's done in a similar way in
most countries, i guess). Honestly, i don't have enough insight into 
whether there's any special case in *routing* those numbers - the
"internal"
translation in the carrier's destination network from 0800 to NPA number

is IMHO out of scope - but i'm happy about feedback from anyone with 
more insight into that.

> 911-location-specific-information-(caller address, and emergency 
> provider of the caller location). 

==> Alex: I think this must be out of scope, because it has little to do

with the actual session setup. 

> (If Geo location related documents cover it, we may need to refer to 
> those documents). 

==> Alex: It might very well be the other way around - GEOPRIV could
define 
extensions to the DRINKS protocol once everything's a bit clearer

> The CNAME is another attribute that we use. Will there be a use case? 

==> Alex: CNAME is already mentioned in "UC INTERCONNECT #6". I do
therefore 
think this is covered.

> Will mobility related use case be included? (e.g., home domain,
visited 
>domain)? 

==> Alex: I have no idea whether this is relevant or not. Again, a
person with
more insight could help? My rough guess is that this is supposed to be 
some kind of dynamic mechanism where sessions get always routed to the 
visited domain? 

> Open numbering plan use case... 

==> Alex: This is covered in "UC MISC #2"

> We do not have to say, "In this version of this document...", instead 
> "This document..." 

==> Alex: This is right - corrected in draft -04.

> Can we borrow Figure 1 of draft-mule-drinks-proto-02 to replace Figure
1 
> of the use case draft? 

==> Alex: Figure 2 of the usecases draft already contains a "dotted
registry". Since 
we don't have any explicit inter-registry use cases in this document, i 
think it might make sense to keep just the "primary" components in
figure 1.
Figure 2 contains an indication that registry-registry provisioning
might 
be possible.

> For figure 2, some providers have another data repository in between
LDR 
> and Registry. I do not know whether you want to add it. 

==> Alex: I wouldn't. It complicates the picture, and is strictly an
internal
detail (and choice) of the respective SSP.

> In UC PROV 1: In real time provisioning it is not mentioned whether it

> is a single provisioning, multi provisioning, or bulk provisioning. It

> is okay because in UC PROV 3 actually explains that provisioning can
be 
> multi-provisioning. 

==> Alex: I understand that UC PROV 1 is hence fine.

> In UC PROV 2: it talks about non-realtime provisioning but in bulk 
> sense. 
>
> Can Prov 1, 2, 3 be written as: 
>
> 1) Real-time single provisioning 
> 
> 2) Real time multi provisioning 
> 
> 3) Realtime bulk provisioning 
>
> 4) Non-Real-time single provisioning 
>
> 5) Non-Real time multi provisioning 
>
> 6) Non-Realtime bulkprovisioning 

==> Alex: Note that the use cases that we have are only examples.
Nobody prevents an implementer to create a registry that 
supports real-time bulk processing (even though it might be hard), 
or even real-time multi bulk
processing. I don't think that we should describe all
combinations, though.

The definition of "bulk" is a little weak, though..

> LUF and LRF referred from RFC 5486. These are neither re-defined in
the 
> draft nor shown in a figure. Thus, section (3.3) use cases become 
> confusing. A figure in section 3.3 to show these functions will be 
> helpful. 

==> Alex: They are not redefined by purpose. RFC 5486 contains all the
definitions,
and is important to understand the proposed requirements.

I have moved RFC 5486 from "Informative" to "Normative". I don't think
it's a 
downref problem when an informative document refers normatively to
another 
informative doc (skimmed through RFC 3967..)

> Section 5 security needs to explain the need for integrity and privacy

> of data. May suggest to use encryption on the interface between LDR
and 
> registry. 

==> Alex: Section 4 of the *protocol* document covers some requirements
for the 
transport protocol, however, it's right that we don't have any 
requirements on the security of the protocol itself. 

I have therefore added a paragraph to the Security Considerations 
section of the document.

> Route Group (page 12-13): a small tree figure with root and branches 
> will be helpful to clear up the definition. 

==> Alex: I am not convinced that a figure helps here. I have, however 
changed something else - we have "routING groups" and "routE groups", 
i have now changed all into "routE groups", since that is what we've 
been talking about all the time (and also what the protocol doc uses).

Otmar's review
==============

> #1
> >
> >   This document reuses terms from [RFC3261] (e.g., SIP), [RFC5486]
> >   (e.g., LUF, LRF, SED) and [RFC5067] (carrier-of-record and transit
> >   provider).  In addition, this document specifies the following
> >   additional terms.
>
> I'm missing a definition of RN (Routing Number?).
>
> ===
> [S] Hmmm, I guess we are missing a reference to RFC4694. 
> ===

==> Alex: I have added a definition for "RN", and included a reference
to RFC4694.

> #2
> >   Registry:   The authoritative source for provisioned session
> >      establishment data (SED) and related information.
> 
> It is explained later, but at that stage it would have been helpful to

> state whether that Regstry is 
> part of a SSP or whether it is an independent body.
>
> ===
> [S] We can add the clarification.
> ===

==> Alex: I have added a note.

> #3
> >   Registrar  An entity that provisions and manages data into the
> >      registry.
> 
> That term appears only once in the rest of the document, and in 
> most cases its "SSP provisions...".
> 
> So perhaps junk it?
> 
> >   Registrant  An entity whose data is provisioned into the registry.
> >      The registrant can act as its own registrar or - additionally
or
> >      alternatively - delegate this function to a third party who
acts
> >      as its registrar.
> 
> Never appears in the document.
> ===
> [S] This is probably my bad. We agreed to use registrar and 
> registrant to the use cases (at the interim meeting), but 
> it is not used as expected.
> ===

==> Alex: I have now left the definitions in the document - this is an 
open issue.

[Sumanth] I left the term registrar in the document, and removed
registrant. I did add the text contained in the term 'registrant' so
that we don't lose sight of it.

> #4
> >
> >   Local Data Repository:   The data store component of an addressing
> >      server that provides resolution responses.
> 
> Is this run by the SSP it serves?
> 
> ===
> [S] Yes. See Figure 2.
> ===

==> Alex: I haven't changed anything, i consider this solved.

> > #5
> >>   Public Identifier:   A public identifier refers to a telephone
number
> >>      (TN), an email address, or other identity as deemed
appropriate,
> >>      such as a globally routable URI of a user address (e.g.,
> >>      mailto:john.doe at example.net).
> > 
> > Why an email address? Or is this just to a hint in the 
> > direction of email-like sip URIs like sip:lendl at nic.at?
> > ===
> > [S] The idea here was to allow for additional associations 
> > with a public identity, outside of TNs. Email was referenced
> >  as an example (not as a look-up key). 
> > ===
>
> This is confusing. From the rest of the use-cases one would assume
that the
> PI is always the key to the lookup. While I can see the utility of
> returning the email-address associated to a TN (e.g. for MMS or
> voice-mail), IMHO that address should then be part of the Route-Set
and not
> part of the PI.
> 
> Perhaps the best way forward is to provide an example on where
> email-addresses could appear in a use-case, and use SIP URIs as
examples of
> a PI.

==> Alex: I agree with Otmar. We need to be clear in distinguishing the
"input"
data type from the "output" data type. Additionally, i'm sure the group 
doesn't want to touch the politically sensitive topic of "email
portability"
at all. 

I have now changed the text from "email" to "sip".

> > #6
> >>   TN Range:   A numerically contiguous set of telephone numbers
whose
> >>      SED can be looked up (resolved).
> 
> As per the Maastricht session: you should explicitly state both that
this
> could be a range in a closed numbering plan, or a prefix in an open
> numbering plan setting.

==> Alex: i have changed the text accordingly.

> > #7
> >>   Destination Group:   An aggregation of a set of public
identifiers,
> >>      TN Ranges, or RNs that share common SED.
> > 
> > good. perhaps not just SED, but also the "who sees what" properties.
> > 
> > === ************
> > [S] Can you elaborate on this (as it applies to the description),
please?
> > === ************
> 
> If I take a look at the overview diagram, then all the selective
> peering/visibility features do not apply to a single TN/RN/PI, but are
> connected to DG. so "..that share common SED" is just one part, a DG
is
> also atomic in respect to the selective peering features. IMHO that
should
> be part of the definition.

==> Alex: I'm appending "which is exposed to a common set of peers" to
the 
sentence. 

> 
> 
> #8
>>   Routing Group:   An aggregation that contains a related set of SED
>>      records, and is associated with a set of destination groups.
>>      Routing groups facilitate the management of SED records - which
>>      are common to a large number of public identifiers, TN Ranges or
>>      RNs - for one or more data recipients.
> 
> DGs are intuitively right and important, but for RGs I have more
difficulties understanding the argument. I guess it makes sense, but
this text does not convince me.
> 
> Please leave the PIs, TN ranges and RN out of the definition, RGs are
only connected to Destination Groups.
> ===************
> [S] RGs associate DGs to SED. We discussed some of the rationale at
the meeting. Do you still have questions about its applicability?
> ===************

As you say, RGs associate DGs to SED, so PIs, TN ranges and RN should
not
be in the definition.

As I wrote, I don't think the idea is wrong. I just think that you don't
make the case for the idea overall in this document.


(Somehow this reminds me of file system permissions: The simple unix
user-group-world system can do anything, but some settings are tricky to
do. Other systems (e.g. windows), provide other abstractions as well,
that
can be helpful in simplifying some rules. But as you made the TN-DG
relationship 0..n:1, you will probably need the ability to do
route-groups.)

So some more explanations or examples would be helpful.

==> Alex: I suppose Otmar and Sumanth discuss this? I haven't touched
the text.

[Sumanth] I removed the terms from the explanation, in agreement with
Otmar's comments.


#9
>   SED is typically created by the terminating SSP and consumed by the
>   originating SSP.  To avoid a multitude of bilateral exchanges, SED 
> is

"terminating" is perhaps the wrong word for the transit case, as the
it's the transit SSP, and not the final, terminating SSP that creates
the SED entries.

===************
[S] That's true. Design Team: any suggestions on how to word this better
for direct and transit cases?  
===************

==> Alex: I have changed this to "... created by the terminating or
next-hop SSP..." - Is this 
a way forward?

[Sumanth] Yes! :)

#10
>   often shared via intermediary systems - termed registries within
this
>   document.  Such registries receive SED via provisioning transactions
>   from other SSPs, and then distribute the received data into Local
>   Data Repositories.  These local data repositories are used for call
>   routing by outgoing SBEs.  This is depicted in Figure 1.

I don't want to pick nits, but the SED alone are useless unless you also
provision and distribute the TN-Ranges / PIs / .. to which these SED
records apply.


The diagram is fine und useful, just be a bit more careful about the
terminology.

===
[S] Fair point.
===

==> Alex: I have simply replaced "SED" with "data". I have also removed
the word "other".

#11

>   In this version of the document, we primarily address the use cases
>   and requirements for provisioning registries.  Future revisions may
>   include data distribution to local data repositories.  The resulting
>   provisioning protocol can be used to provision data into a registry,
>   or between registries.  This is depicted in Figure 2.
>
>

The fact that there could be multiple registries operating in parallel
should be stressed somewhere else.

The dotted lines make this diagram slightly confusing.

Perhaps do a version with the current focus only, and then add a second
one that explains what future revisions might do.

===
[S] K
=== 

==> Alex: I have changed this text slightly: 

"The resulting provisioning protocol can be used to provision data into
a registry, or between multiple registries operating in parallel. In
<xref target="FunctionalOverview"/>, the case of multiple registries is
depicted in dotted lines."

#12
>   In addition, this document proposes the following aggregation groups
>   with regards to SED (refer to the use cases in Section 3.5 for the
>   rationale):
>
>   o  Aggregation of public Identifiers into a destination group.
>
>
>   o  Aggregation of SED records into a Routing Group.

As before, some more explanations on the RG, perhaps with some examples
might be helpful.

===************
[S] In addition to the use cases?
==************

==> Alex: I think this one is related to #8 - i haven't changed anything
in the document..

> 
> 
> #13
>>
>>   The data model depicted in Figure 3 shows the various entities,
>>   aggregations and the relationships between them.
>>
> 
> I think the direct PI-SED link should be removed. It just leads to
endless special-cases in all the code.

One idea on how one might simplify this:

Perhaps provide for an RN/TN/PI -> RN/TN/PI mapping for these cases? The
actual routing could then go via the normal way.

==> Alex: This was discussed at the interim meeting as a way to include
additional, 
per-user specific SED (for example, email address?), when the remaining
SED is 
identical for a large number of PIs. I was convinced that this is
needed. 
Regarding Otmar's proposal, i don't think there's any difference whether
this 
"additional link" refers to the SED or the RN/TN/PI object. From the
"input"/"output" 
logic it seems useful to keep the SED object. One thing that i guess
*could* help
is that "directly linked" SED cannot be contained in a RG? However, this
could 
also be local server policy..

I have for now not changed anything in the document. Opinions on the
above?

[Sumanth] Based on the interim meeting, I am inclined to leave this
as-is :).

==> Alex: I agree, i think this is useful in certain scenarios.

> #14
>>   UC INTERCONNECT #4  Selective Peering (a.k.a. per peer policies):
>>                       SSPs create peering relationships with other
SSPs
>>                       in order to establish interconnects.  However,
>>                       SSPs peering relationships often result in
>>                       different points of ingress or other SED for
the
>>                       same set of public identifiers.
> 
> Please clarify the level of selectiveness supported:
> by PI, by TN-Range, by RN or just by Destination-Group.
> 
> ===
> [S] Destination Group is an internal structure, so it would be by PI,
RN or TN Range. We can clarify.
> ===

Hu?

Do DG feature in the protocol? if yes, then it is better to tell users
right here that DGs are atomic with respect to the selective peering
features.

==> Alex: I agree with Otmar here - selective peering is "per-DG", since
there's no 
relation between peers and individual TN/TN-Range. The "tool of the
trade" to achieve 
this is the relation between RG and Peer. However, looking at the
overview diagram, 
this could actually be achieved in two ways:

- Either create one route group per group of peers that have seperate
routing policy, 
and then add the Destination Groups that shall be visible into that
route group. 
This would be the case where different groups of peers receive different
SED 
(different ingress points).

- Or create a single route group, and only associate those peers to this
route 
group that shall have access (so just a single entrance point, probably
the case 
how smaller SSPs might handle it).

I sense that we really need to describe this into greater detail to not
confuse 
people - opinions?

[Sumanth] I agree with your explanation, but I don't know if we really
need to specify this in the use case. The protocol document is where
this may need to be explained, no?

#15
>   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.

WTF?

The rest of the draft talk about generic SED, does not specify a query
protocol, and now, out-of-the-blue, we're on NAPTR, NS, CNAME level?

This makes no sense at this level. If there is a use-case, describe it
at the same abstraction level as the others.


===
[S] OK :)! I think we agreed to make this abstract at the meeting.
===

==> Alex: See my proposal on Peter's comment below.

#16
>3.3.  Category: SED Exchange and Discovery Models

>   UC SED EXCHANGE #2  SED Exchange and Discovery using LUF's Domain
>                       Name: When establishing peering relationships
>                       some SSPs may not wish to communicate or receive
>                       points of ingress and other SED using a
registry.
>                       They wish to only communicate or receive domain
>                       names resolvable via [RFC3263], and this query
>                       will then return the points of ingress or other
>                       SED that form the LUF.

I think this is ok, but the text confuses me. Please describe (perhaps
using examples) what the query is and what the answer will be.

(Examples would be helpful for all these 4 types.)


===
[S] We could add some small examples.
===

==> Alex: I agree with Otmar - this does confuse me as well.
Particularly, it's 
the second sentence. I have now changed this as follows:

"SED Exchange and Discovery using LUF's Domain Name:  When establishing
peering relationships some SSPs may not wish to communicate or receive
points of ingress and other SED using a registry.  They wish to only
communicate or receive domain names (LUF only), and then independently
resolvable those domain names via [RFC3263] to the final points of
ingress data (and other SED)."

Feel free to change - this is just a proposal.

#17
>3.5.  Category: Separation and Facilitation of Data Management
>
>   UC DATA #1  Separation of Provisioning Responsibility: An SSP's
>               operational practices often separate the responsibility
>               of provisioning the points of ingress and other SED,
from
>               the responsibility of provisioning public identifiers
(or
>               TN ranges or RNs).  For example, a network engineer can
>               establish a physical interconnect with a peering SSP's
>               network and provision the associated domain name, host,
>               and IP addressing information.  Separately, for each new
>               subscriber, the SSP's provisioning systems provisions
the
>               associated public identifiers.

This is good.

Perhaps clarifiy that one is the LUF data (PI/TN -> DG mapping) and that
the other is the LRF data (DG -> SED).


===************
[S] Do we really want to add LUF and LRF distinction within the use
case?
===************

==> Alex: I don't think we should. It opens up a can of worms, and i
think the use case is pretty clear already without mentioning LUF/LRF.

#18
>
>   UC DATA #3  Route Groups: SSPs often provision identical SED for
>               large numbers of public identifiers, and then expose 
> that

^^^ this is handled via the DG abstraction.


===
[S] Yes...
===

==> Alex: I understand there's no change to text proposed?

#19
>               relationship between a group of SED records and a group
>               of public identifiers to one or more SSPs.  This
combined
>               grouping of SED records and Destination Groups
>               facilitates management of public identity SED
>               relationships and the list of peers (data recipients)
>               that can lookup those public identifiers and receive
that
>               SED.  This dual set of SED Records and Destination
Groups
>               is termed as a Route Group.

Once again, the idea is good, but the explanation for the RG rationale
is more confusing than helpful.


===************
[S] Any suggestions (Otmar or the design team)?
===************

==> Alex: Ah, ok. Well, honestly, i don't have any suggestions at the
moment to make the general approach clearer. However, i noticed some
discrepancy between the usecases and protocol document: What's called
"SED Record" in the usecases document is termed "Route Record" in the
protocol document - should we change the term to "Route Record" in the
usecases draft as well?

[Sumanth] Good catch on the 'SED record' v/s 'Route Record'. We should
go with the SED record in the protocol document. This may need to be a
review comment.

#20
>3.7.  Category: Number Portability
>
>   UC NP #1  EDITOR's NOTE: Need to clarify this further.
>
>
>             The SSP wishes to provide in query response to public
>             identifiers an associated routing number or RN.  This is
>             the case when a set of public identifiers is no longer
>             associated with original SSP but have been ported to a
>             recipient SSP who provides access to these identifiers via
>             a switch on the SS7 network identified by the RN.  In this
>             case a destination group containing all numbers that
should
>             be routed to this RN needs to be created and the route
>             group associated with this DG needs to contain the RN

I do not think this is a good idea.

===
[S] :)
===

==> Alex: I'm pretty open about this. Important for me is that the RN is
*not* contained in the DG itself, but in a SED Record - otherwise we
would breach the "input/output" object architecture. Otmar, what are
your concerns?

[Sumanth] Well, we do need number portability :). So I left this as-is.

#21
>4.  Requirements
>
>   REQ13:  Support for lookup keys having identical business keys (the
>           public identity string, the digits that comprise an RN, the
>           start and end point of a TN range's range) that concurrently
>           exist across multiple destination groups and where each
>           destination group may be managed by different SSPs.
>
>           Editor's note: We need to simplify the above requirement.

btw, one thing that is missing is the handling of overlapping
information:

e.g.

SSP-A provisions:  123-1000 to 123-1999 to DG "foobar"
SSP-B provisions:  123-1100 to 123-1149 to DG "funk"

what would a query for 123-1120 yield? Both entries? Just the one from
the closer match?


===
[S] I don't know if we speak about the resolution here. My personal take
is that both of them should be returned (assuming the recipient is
allowed to see either).
===


==> Alex: We still need to work on the "Editor's note" above. We can't
last call the document with it.. I have now read a few times through the
REQ, and i honestly don't think i've fully understood it.

Regarding the overlapping issue - i don't think we should specify it. I
think it might very well depend on the policy of the local registry. For
example, a "least cost" type registry might very well have overlapping
information. I'm for defining this as "local policy".

#22

>5.  Security Considerations
>
>   Session establishment data allows for the routing of SIP sesions
>   within, and between, SIP Service Providers.  Access to this data can
>   compromise the routing of sessions and expose a SIP Service Provider
>   to attacks such as service hijacking and denial of service.  The
data
>   can be compromised by vulnerable functional components and
interfaces
>   identified within the use cases.

This is a bit thin.

Consider:

* data-leaks
* stale data in the registry
* protection against a malicious SSP
* re-routing of calls due to injection of wrong data

==> Alex: I've added "A provisioning protocol or interface that
implements the described use cases MUST therefore provide
confidentiality, and MUST ensure integrity of the provisioning data
flow. Authentication and authorization are REQUIRED features of the
protocol and interfaces." - Do you think this is enough?

#23
>
>7.  Acknowledgments
>
>   (AT&T Corp), Ray Bellis (Nominet), the co-chairs (Richard Shockey,
>   Nuestar; and Alexander Mayrhofer, enum.at GmbH), and the editors of

Neustar.

===
[S] Thanks! 
===

==> Alex: I have removed the affiliations, since it's uncommon, and some
people work for different companies already...


Peter's comments
================

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

Alex: Yes, i agree this could benefit from more abstraction - and 
it has been discussed at the interim meeting already. I have rewritten
the use case.

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

Alex: I have rewritten this, so that it's clearer that the use case
describes the "combined" approach.

<<<
o RN is not expanded in the draft (neither in RFC 5486.
<<<

Alex: I have added a definition.

<<<
o Capitalization of "destination group" is not consistent.
<<<

Alex: I agree. We need to do a nits review once we have solved the
remaining issues outlined above.

<<<
o The text below figure 3 misses a description of the relation between
  "SED record" and "PI".
<<<

Alex: I have added a respective description. What we still need to think
about is whether an SED record can be contained in one Route Group as
well as in one Public Identifier (personally, i think it shouldn't).

[Sumanth] The way the diagram depicts it, a SED Record can be
*associated* with a public identifier, and *contained* in a Route Group.
Would this cause issues?

Alex: I think the basic requirement is that the relation is described. I
don't mind whether it's an "association", or it is "contained".

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

Alex: corrected.

<<<
o The term "lookup key", used in 3.6, is never defined.
  also: capitalization
<<<

Alex: I have changed this to "Public Identifiers", since those are the
objects which are used as lookup keys. Design Team: Anything besides
"Public Identifiers"?
<<<
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.
<<<

Alex: I have changed all occurences to "Route Group". It's the same
thing.

<<<
o IANA considerations: the list of non-actions should contain both
  registration and the creation of a registry (the absence thereof, of
  course).
<<<

Alex: changed.

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

Alex: There is now text that clarifies that a protocol or interface 
that implements the describe use cases must be considered in the 
respective specification.

<<<
o It is a bit unusual for an IETF document, albeit not completely
without
  precedent, to list the affiliations in the Acknowledgements section.
<<<

Alex: I have removed the affiliations

<<<
o References: RFC 5486 (SPEERMINT terminology) should be a normative
reference,
  since it is needed to understand this document.
<<<

Alex: RFC 5486 is now a normative reference.