Re: [MBONED] Alissa Cooper'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

========================================================================================
Alissa Cooper:

> Section 4.3.3 recommends that ADs generate and exchange extensive logging information, but the document says nothing about securing these logs or limiting the exchange of private or confidential information between the peers. This seems like it needs to be addressed in the BCP.

Sure. Pls. re-read the first four paragraphs of the Log Management section, i tried to make
it clearer. Also the new section on privacy.

> (1) Why does this document contain the copyright disclaimer for pre-RFC5378 work?

It has been there since -00, and i can not think of any reason why it should be there,
so i removed it.

Will also send email to working group mailing list to re-check.

> (2) Section 4.4 says:
> 
> "In the event of performance degradation (SLA violation), AD-1
>         may have to compensate the multicast application source per SLA
>         agreement. As appropriate, AD-1 may seek compensation from AD-2
>         if the cause of the degradation is in AD-2's network."
> 
> and
> 
> "Faults in service could lead to SLA violation for which the
>         multicast application source provider may have to be
>         compensated by AD-1. Subsequently, AD-1 may have to be
>         compensated by AD-2 based on the contract."
>     
> These bullets seem out of scope for this BCP. I would recommend deleting them.

Removed. 

I welcome a chat in Singapore why everybody seems to think the word "money"
must not be mentioned, not even in an operational document. 

> (3) Section 6 says:
> 
> "DRM and Application Accounting, Authorization and Authentication
>    should be the responsibility of the multicast application source
>    provider and/or AD-1. AD-1 needs to work out the appropriate
>    agreements with the source provider.
> 
>    Network has no DRM responsibilities, but might have authentication
>    and authorization obligations. These though are consistent with
>    normal operations of a CDN to insure end user reliability, security
>    and network security."
> 
> I find these two paragraphs somewhat contradictory and vague. The first paragraph makes it sound like DRM could be the responsibility of AD-1. The second paragraph makes it sound like AD-1 (assuming it counts as "network") would never be responsible for DRM. Then later on the text says:
> 
> "Authentication and authorization of EU to receive multicast content
>    is done at the application layer between the client application and
>    the source. This may involve some kind of token authentication and
>    is done at the application layer independently of the two AD's."
> 
> Is this differentiating authentication and authorization of the application source from that of the end user? It's not clear. I would suggest revising this whole section to be clear about which security functions are the responsibility of which parties.

Pls. re-read the security section, i have tried to rewrite it with
a clearer description of these aspect. As someone like me who is
deep int the subject matter it is always easy to overlook explaining
what we may think are well understood fundamentals, so please keep
complaining until its understandable!