Re: [MBONED] Mirja K?hlewind's No Objection on draft-ietf-mboned-interdomain-peering-bcp-11: (with 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

=====================================================================================
Mirja Kuehlewind:


> Sorry for this last minute discuss but I would like to emphasize the points made in the tsv-art review on congestion/rate control (Thanks Yoshi!):

> Please provide stronger guidance (MUST) on the use of rate/congestion control in these two cases:
> 
>  In Section 3.1:
>     " If the peering point between AD-1 and AD-2 is a controlled
>    network environment, then bandwidth can be allocated
>    accordingly by the two domains to permit the transit of non-
>    rate adaptive multicast traffic. If this is not the case, then
>    it is recommended that the multicast traffic should support
>    rate-adaption."
> 
> In Section 4.1,
>      "When determining the appropriate bandwidth allocation, parties should consider use
>        of a multicast protocol suitable for live video streaming that
>        is consistent with Congestion Control Principles [BCP41]."

I tried to fix this text a bit more comprehensively:
- removed text from 3.1. The CC requirements apply to every subsection of 3 (3.x)
  and it duplicates partial text in 4.1, so a random mentioning in 3.1 was not
  helpfull.
- Moved CC text from 4.1 to dedicated section 4.1.1 and made it a lot more explanatory
  because in my past experience most readers do not really understand our cryptic
  rules alone ("CC principles across non-controlled network paths"). Also added
  reference to the fresh BCP145.

Please re-read new section and let me know what you think.

> Minor questions/comments:
> 
> 1) Section 3.4 also says:
> "Highly efficient use of bandwidth in AD-1."
> But aren't packets eventually duplicated in this case in AD-1? I guess it's more efficient than replicating them at the network border but might be still less efficient than native multicast in the whole network, no?

Changed to:
  <t>Efficient use of bandwidth in AD-1 (The closer AR is to uBR, the more efficient).</t>

> 2) section 4.3.3 says:
> "The two AD's may supply additional security logs..."
> This seems to be a general action not specific to multicast or the scenarios described in this doc.

Yes, i thought about this and came up with the following explanation:
   
   <t>Note that except for implied multicast specific elements,
   the options listed here are not unique or novel for IP multicast, but
   they are more important for services novel to the operators than for
   operationally well established services (such as unicast).  Therefore
   we detail them as follows:</t>

> 3) I don't think the conclusion section (8) is helpful or needed. If you want to keep it at all, this text could be moved into the introduction.

Removed - for the time being. I was told that having a wrap up in documents is
always a good way to reflect on the document, but i agree the existing text
is more distracting than helpful.