[Mimi] Re: Call for adoption: draft-interop-mimi-discovery-requirements-01

[Femi Olumofin <[e-mail]>]

Hi Richard,

Thank you for your comments.
Please see my response below.

Thanks,

Femi
---
>
>Hi all,
>
>I have reviewed this document.  I think it's a reasonable starting point,
>though I have some reservations about its structure and content.  Comments
>below.
>
> --Richard

>Traditionally, the Terminology section goes after the Introduction.  It's a
>little abrupt  to land right there after the abstract.

We placed the terminology section before the introduction to improve
readability. It seems awkward to use terms that are not yet defined,
forcing readers to jump ahead to figure out what they mean. Is the
placement a matter of personal preference or a requirement?

>"A Cross-Service Identifier (CSI) is a globally unique identifier..." - The
>"globally unique" seems aspirational here, and should probably be deleted.

It isn't aspirational but required. Would it be mere aspiration for phone
numbers and email addresses to be globally unique, for example? We take
global uniqueness as a requirement.

>It seems like you could definitely have cases where the same CSI is bound
>to completely unrelated SSIs, for example:
>1. Alice is assigned a given E.164 number
>2. Alice registers the number with Service A
>3. Alice surrenders the number and it is reassigned to Bob
>4. Bob registers the number with Service B

Yes, the same CSI can be bound to multiple SSIs. However, we want to avoid
the scenario you described, given that all mappings of the same CSI to
multiple SSIs should be for a single user, Alice. BTW, we covered this
during the IETF 120 session (check the deck).

>This document is very agnostic about what the CSIs are, but practically
>speaking, we're only talking about email addresses and phone numbers.
>Would there be benefit to specializing to those two?  Even if we also have
>a section about what would have to be done to accommodate a new identifier
>type.

The draft includes phone numbers and email addresses as examples of
identifiers in several sections, including the abstract, terminology,
introduction, authentication mappings requirements, and discovery protocol
requirements. Section 8.1 also discusses suitable properties for
identifiers in general (your new identifier mention).  I'm having trouble
understanding the specific issues you're raising about this.

>There are a few instances where more plurals are needed, for example,
>"learn the messaging service provider that the user is using" -- the user
>could be registered to multiple MSPs with the same CSI.

This is a reference to the Introduction section, which appears before the
problem statement is introduced. We intentionally simplified it there, with
the "plurality" details explained in the Problem Statement section.

>While I appreciate the desire to capture the WG discussions about
>architectural models, these seem out of place in a requirements document,
>except possibly for building intuition about possible models.  I would
>probably move Section 4 to an appendix or delete it.

This is meant to help users build an intuition for the possible models.
Moving the content to the appendix seems to defeat that goal, but I'm open
to doing what works best.

>It would be helpful to have a more fleshed-out model of the system, in a
>more abstract way than Section 4 provides.  Roughly:

This feedback appears contradictory to your earlier comment that discussion
about architectural models should be deleted or moved to the appendix.
Here, you are asking for "a more fleshed-out model of the system". What
exactly is the feedback?

>* MSPs make DPs aware of authenticated SSI->CSI mappings

The statement is incorrect. It is the DPs that authenticate mappings, which
are then looked up by MSPs.

>"* Clients/MSPs request SSI->CSI mappings from a DP (possibly different
from
>the DP in the previous step)

I'm not sure exactly what you meant here because the details you outlined
are already explained in the draft:
"Note that once a mapping is created, it can be distributed by any DP, and
it should include metadata for clients that receive it to verify its
authenticity."

And captured in Requirement #3 "Client, MSP, and DP must collaborate to
generate a verifiable representation of the CSI-to-MSP mapping. This can
then be shared with any DP and verifiable by clients".

>In prior discussions we had made a distinction between entities who are
>trusted to *authenticate* mappings and those who *distribute* the
>mappings.  This document seems to assign both of those roles to a DP.  It
>seems worthwhile to separate them, since it seems plausible that there
>could be a system where the two roles are played by different entities,
>much like CAs and web servers in HTTPS.

Separation of concerns is desirable and appropriate in the CA-web server
role separation. However, it seems unnecessary to have an artificial
separation here simply because the same DP could collaboratively
authenticate mappings and also distribute those mappings or mappings from
other DPs.

>The requirements in Section 5 are a mix of requirements on the discovery
>protocol, over which this WG has full control, and requirements on the
>actors in the system outside the protocol, about which we can only be
>advisory.  It would be good to separate these out, and ideally focus on the
>former.

We grouped the requirements into authenticating mappings, discovery
protocol, operational, and security categories. When you say "requirements
on the actors in the system", are you referring to those in the operational
category? We would appreciate specifics to help us identify requirements
that should be reclassified or removed.

>The privacy requirements in section 8.4 seem very underdeveloped compared
>to what has been discussed in the working group.  In part, I suspect,
>because of the lack of a model of who does what here makes it hard to talk
>about who can be denied which information.

Can you be specific about the additional privacy requirements that must be
added?
The stated requirements are the minimum bar.