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

[Toerless Eckert <[e-mail]>]

[The following text up to the individual reply comments is identical for 
 the replies to all ballot comments. I originally wanted to coalesce the reply to
 all positions into one email but the auto-generated header from datatracker
 makes it sound as if per-submitter replied are required. So, here we go with some
 repeated text followed by more individualized text:]

Dear Reviewer,

This is in response of your reviews of
    https://www.ietf.org/id/draft-ietf-mboned-interdomain-peering-bcp-11.txt
as entered in the ballot:
    https://datatracker.ietf.org/doc/draft-ietf-mboned-interdomain-peering-bcp/ballot/

A version of this email containing replies to all IESG feedback for -11 is also in: 
    https://raw.githubusercontent.com/toerless/peering-bcp/master/11-iesg-review-reply.txt

Thank you so much for your thorough review. In response to the IESG
feedback, version -12 and -13 of the draft where posted which we hope 
will resolve the open issues.
make 2

Version -12 of the draft was just a conversion from docx generated txt to XML (previous generations
where not built from XML), this introduced formatting changes (line wraps etc.) that rfcdiff can not ignore
and that would have obfuscated actual content changes. 

Version -13 of the draft contains the text changes done in response to your
comments and discusses. The following RFC diff shows the content diffs
vs. -11 without any formatting introduced changes:

http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-mboned-interdomain-peering-bcp-12.txt&url2=https://tools.ietf.org/id/draft-ietf-mboned-interdomain-peering-bcp-13.txt

In summary:
   Beside the various smaller fixups from comments, the mayor rewritten/new blocks are:

   4.1.1 - bandwidth management (aka: congestion control section). 
           I didn't just want to put the magic CC sentence in but wanted to let
           readers understand what it means in the context of specifically
   6. Security considerations
      6.1.  DoS attacks (against state and bandwidth)	
      6.2.  Content security	
      6.3.  Peering encryption
      6.4.  Operational Aspects
            This is where the securing of log exchange is discussed.
   7. Privacy Considerations
      Got somewhat longer to explain because the specifics of multicast content and privacy
      are likely not that obious to non-multicast  experienced readers, and given how this
      is a BCP and i don't even think we did describe this anywhere else, it had to be
      explanatory.
   
   4.2.4.  Public Peering Routing Aspects
      text did mention non-private peerings, but i was afraid that readers would not
      understand the problematic implications, so i detailled them given how those
      peering L2 domains are still common for unicast.


Cheers
    Toerless for the Authors

==========================================================================================
Ben Campbell:

Thanks a lot for the thorough review!

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

Modified to say "Network location" (of affected EUs).

> Substantive Comments:
> 
> - I support Alissa's and Kathleen's DISCUSS positions.

Yes, see feedback to their 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.

I did not find other assumptions beyond the ones you list below. Pls let us know explicitly what others you think exist.

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

Pls. check the revised first bullet (and sub-bullet) points of the introduction. It now says that there is one AD-1 but one or more AD-2. It also limits scope to EU just receiving content, but not sourcing it. It gives a suggestion how to let end-users source content but declares the detail out of scope.

To answer your points beyond what i changed in the text:

Yes, the assumption that this is a complete end-to-end story from someone (AD-1) taking responsibility  for sourcing the content to many end-users consuming the service is relevant because it allows us to constrain the scope/size of this document. If you think we should also have text for any of the current "out of scope" areas, i would be a lot happier if we could do this in BCPbis.

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

Done. Please check picture and modified text referring to it.

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

Done. Put into picture: N# EU/G -> N x AMT Tunnel.

Also updated both AMT pictures to show the fact that the AMT nodes are not necessarily the same as the physcial exchange point nodes.

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

Not really..  I added to 4.3.2:

    <t>The reason to specifically mention the need for AD-1 to initiate
    interactions with AD-2 (and use some account for that), as opposed
    to the opposite direction is based on the recommended workflow
    initiated by customers (see <xref target="section-4.4"/>): Customer
    contacts content source (part of AD-1), when AD sees the need to propagate 
    the issue, it will interact with AD-2.</t>

I am somewhat hesitating to bring long & gory explanations why we choose
this approach, because there are so many different reasons one could cite
and it cold become quite long:

-> Its the logical workflow with unicast content service.
-> Its the workflow also in CDN, even specifically in CDNI
-> Its logical that you start diagnostics from the application side
   and only once you figure out that the issue is NOT application, but
   network, you go down to network diagnostic. And you can start that
   usually only from the application sender side.
-> You want to make operations for all the AD-2 lightweight. The idea is NOT
   for all AD-2 to become broadcasters with a virtual headend. Instead
   they just need to be involved in the transport layer and beyond that
   only into the pieces they want to.

Let me know if you feel strongly that this reasoning needs to be written down.

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

I have rewritten the beginning of 4.3.3 into 4 paragraphs to hopefully make this clearer.

- I have also added a whole privacy consideration section (8.) that discusses
  privacy hopefully exhaustively enough.

Please re-check.

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

I have changed the first two paragraphs to hopefully set the context better:

    <t> Successful delivery of applications via multicast between pairs of
       interconnecting AD's can be improved through the ability to
       exchange appropriate logs for various workflows - troubleshooting,
       accounting/billing, traffic/content optimization, market research
       and so on. Except when the log includes information about the
       IP multicast behavior in AD-2, this is not specific to IP multicast
       solutions but equally desirable in Unicast-content delivery collaboration
       collaboration across AD-1/AD-2 (e.g.: for CDN services).</t>
    
    <t> The following type of logs are well understood examples known to help support operations
       in AD-1 when provided by AD-2. This could be done as part of AD-1/AD-2 contracts:</t>

Let us know please if you insist on examples. detailing operational workflows
can add quite a bit of text to the document.
 
> The statements about compensation should be out of scope for an IETF document.

Done. See my comment to the same point raised by Alissa if you like.

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

Ok, that paragraph didn't quite make sense to me either. I think my
co-authors where thinking about one specific implementation option, but
it really does not matter how its done. I for once did this in the past
just via radius controlled limited authentication profiles for TACACS accounts
into routers... yada yada -> removed looking-glass style mentioning, but
refined text to hightlt mtrace/traceroute more and discuss alternative
of providing this diag via EU.

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

Please re-read the security section. I did do a mayor overhaul to
hopefully better identify the security issues different from unicast
and to describe the attack vectors. Both for the encryption at the
peering point and other points.

> -- : "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.

No. It is only implication of the fact that this
document only considers network layer peering, but end-to-end
transport/app layer (to make it as close as possible to existing
unicast models where the same is done). See rewritten text of security section, should
make it much clearer now, i hope.
> 
> 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)

I XML'ified the document which removed a lot of surpls indentation,
but introduced more vertial white space hopefully this helps. Looks nicer to me now ;-))

In or defense, the WG did ask for structured bullet
listed format of the document to create more consistency and easier
vetting of individual statements made. 

I hope you can live through this because i am fearful of
doing more verbal changes (mayority of readers/commenters didn't complain about formatting).

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

That is about the most fundamental IP multicast term and is typically
used intentionally as a first line of defense against reader not
familiar enoigh with IP multicast to understand the text. 

But since you asked so nicely, the first instance now reads:

(S,G)s (multicast traffic flows, 
        see <xref target="section-4.2.1"/> if you are unfamiliar with IP multicast).

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

   <t>Ability to support partial and/or incremental IP multicast deployments in AD-
    1 and/or AD-2: Only the path(s) between AS/BR (AD-1) and BR/EU (AD-2) need to  
    be multicast enabled. The uBRs (and paths between BR and uBR) may not support IP multicast 
    or enabling it could be seen as operationally risky on that important nodes whereas dedicated
    BR nodes for IP multicast are more acceptable. BR can be located such that 
    only parts of the domain may need to support native IP multicast (e.g.: only the
    core in AD-1 but not access).</t>

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

Done.

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

Ack.

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

*sigh*. No, it's necessary, and we haven't really worked out all the good mechanisms to simpify this.

Check fixed text, explains it now better.

> -4.1: Please expand SLA on first use.

Ack

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

Fixed to:

<t hangText="AMT Gateway (GW):"> The Gateway will reside on an End-Point - this
        could be any type of IP host such as a Personal Computer (PC), mobile phone, 
        Set Top Box (STB) or refrigerator. 

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

Ok. We couldn't find a co-author willing to do a fundamental overhaul
of the text to better "activate"? the draft. Not being a native english
speaker myself, i always welcome help to improve on my english, but
i would prefer very explicit suggestions/proposed text, otherwise i may
just be replacing one bad english sentence with another one.

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

Ok, went through the whole document and tried to come up with creative alternatives to "/".

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

Check rewritten paragraph, pls.

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

Done.