Re: [MBONED] Eric Rescorla comments on draft-ietf-mboned-interdomain-peering-bcp-11

[Toerless Eckert <[e-mail]>]

[Did not find any original email from eric reflecting his ballot comments,
 this one email does not have right reply header, sorry.]

[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://raw.githubusercontent.com/toerless/peering-bcp/master/draft-ietf-mboned-interdomain-peering-bcp-12.txt&url2=https://raw.githubusercontent.com/toerless/peering-bcp/master/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

=====================================================================================
Eric Rescorla:

> I support Kathleen's and Alissa's discusses
> 
> I'm concerned about whether the practices described adequately capture the notion of user consent to receive the data. Specifically, we're talking about sending large streams of data to people. Do the protocols in question adequately ensure that the addresses in question wish to receive the data. Specifically, the issue I am concerned with is whether I can cause you to get a large video stream. I'm filing this as a Comment rather than a Discuss because it doesn't seem like an issue for this BCP but rather for the protocols it documents.

In SSM multicast, a receiver will not receive any unwanted traffic
from any source, but only traffic from those sources that it wants to receive
traffic from. Receiver issues a so-called (S,G) membership indicating it wants
from source S the traffic for group G (think of G as the equivalent of a TCP port).

Of course, all the goodness of SSM multicast is easily invalidated by the
application on the receiver device. You know, browsers that start receiving
streaming videos into some windows on the bottom of your desktop you've long
 forgotten because some content owner tries to pushes more Ads to you...

(sorry, couldn't resist ;-)

> Please define S,G at first use.

  <t>A service provider controls one or more application sources in
        AD-1 which will send multicast IP packets for one or more
        (S,G)s (multicast traffic flows,
        see <xref target="section-4.2.1"/> if you are unfamiliar with IP multicast).