[MBONED] Ben Campbell's Discuss on draft-ietf-mboned-interdomain-peering-bcp-11: (with DISCUSS and COMMENT)

[Ben Campbell <[e-mail]>]

Ben Campbell has entered the following ballot position for
draft-ietf-mboned-interdomain-peering-bcp-11: 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 https://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:
https://datatracker.ietf.org/doc/draft-ietf-mboned-interdomain-peering-bcp/



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

(This is related to Alissa's DISCUSS about logging of privacy-sensitive data.
But since it's a little different, I'm entering my own DISCUSS.)

 In section 4.4 (operations) the bullet on problem notification states that AD2
 will inform AD1 of, among other things, the locations of users. Is that
 intended to be geolocation, or network location? If the former, that's
 extremely sensitive information, and needs privacy guidelines.


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

Substantive Comments:

- I support Alissa's and Kathleen's DISCUSS positions.

- There seem to be quite a few implied assumptions about business models. I
will call out some specifically, but I'm sure I didn't catch them all. These
assumptions should either be removed or made explicit.

- The lists of guidelines seem to mix guidelines with observations of fact.
This makes it difficult to tell which parts are "best practices" (that is,
recommendations) vs which parts simply state fact.

-2: Is the assumption that the source is a service provider and the consumer is
an end-user relevant? This seems to perpetuate the (often false) assumption
that end users only consume content, but never produce it. It would be better
to state this in the form of whatever assumptions are implied by the idea of
SPs and EUs.  For example, do you assume there is a one to many relationship
between SPs and EUs?

-3.2: Why does this section not rate a figure? I think it would be helpful to
show the GRE tunnel as distinct from the native multicast.

-3.5, paragraph after Figure 4: The large number of tunnels implies some
assumptions about the cardinality between SPs and EUs that should be stated
explicitly. (It would help to show this in the figures.)

- 4.3.2: The idea that that AD1 has a need to identify users in AD2 seems to be
based on some implied business model assumptions. Please state those
explicitly. (Or if I missed where they are stated, please point out the text.)

-4.3.3: This states that logging is necessary for delivery. Why is that? Again,
this seems to make some implicit business model assumptions. This section also
needs explicit privacy considerations.

-4.4: The choice of monitoring, etc, seems to be up to the network operators to
decide. Why does this document need to "expect" that? It might be helpful to
describe how monitoring specific information could be useful (perhaps for
troubleshooting), but the document does not go into that. The statements about
compensation should be out of scope for an IETF document.

-5: Can you define, or reference a definition for, "Looking-Glass style".

-6: Please include a discussion of threat models. When might one choose to
encrypt or not encrypt? What risks exist if you don't encrypt?

-- : "DRM and Application Accounting, Authorization and Authentication should
be the responsibility of the multicast application source" Why? This seems to
imply some business model assumptions.

Editorial Comments:

- General: I find the heavy use of nested bullet lists hard to read. Much of
the information in the lists would be better suited to paragraph form,
especially when list entries span several sentences.  Likewise, the
inconsistent use of full sentences vs fragments makes it hard to read. (Maybe
this is just me)

-2: Please explain (s,g) before using, or even better spell it out. You do, in
fact, explain it in 4.2.3, but it's used quite a bit before you get to there.

-3.2, third bullet: "Ability to support only partial IP multicast
deployments..." Does this mean "only able to support partial..." or "able to
support partial..."?

- 3.3, figure:
The figures that involve tunnels would be easier to understand if you visually
distinguished tunnels from non-tunneled links.

- 3.3, e: "AMT tunnels will then configure dynamically"
s/configure/"be configured"

-3.4, d: " It is recommended that proper procedures are implemented such
     that the AMT Gateway at the End User device is able to find the
     correct AMT Relay..."
Is that a recommendation or a requirement necessary to work at all? (Same
construction appears in at least 3.5).

-4.1: Please expand SLA on first use.

-4.2.3: AMT Gateway: "The Gateway will reside on an End-Point - this
        may be a Personal Computer (PC) or a Set Top Box (STB)."
Is that meant to be exhaustive? Surely there are endpoints that do not resemble
PCs or STBs.

-4.2.3, example procedures for gateway selection:
The heavy use of passive voice in this section obscures the actors. (This is
true to some degree throughout the document, but it seems more confusing here.)

-4.3.2, 2nd bullet: Please don't use "/" as shorthand for conjunctions. 
(Pattern repeats throughout the rest of the draft.)

-4.3.3, first paragraph: The first sentence is hard to parse.

-6: Please expand DRM and CDN on first mention.