Re: [MBONED] Adam Roach'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

=====================================================================================
Adam Roach:

> I support Alissa's and Kathleen's DISCUSSes; and (as a separate concern), I support Ben's DISCUSS.
> 
> Most of the comments I noted in my review of this document have been made by other reviewers, and I will not reiterate most of them. I would, however, like to draw particular attention to Ben's comments regarding charging, billing, and settlement -- I believe these issues should either be fleshed out in significantly more detail, or removed (with a simple statement in the introduction that such issues are generally out of scope for the entire document).
> 

Those sentences where removed due to comments by other reviewers.

Your is is actually better guidance than the simple "should be out of scope" i saw
in other reviewers comments: i like the: not enough actionable information to pass bar for BCP.

We did have i think 10 years ago an attempt to standardize
multicast billing/accounting information exchange between SPs, alas those drafts never finished
because they where somewhat ill-build (on the wrong protocols). I think thats
why we as authors wanted to remind the community, but a reminder alone is not
sufficient for a BCP.

> Section 4.2.3 contains the following text:
> 
>     (Note
>      that in IPv6 there is a specific Anycast format and Anycast is
>      inherent in IPv6 routing, whereas in IPv4 Anycast is handled via
>      provisioning in the network. Details are out of scope for this
>      document.)
> 
> It would be helpful to the reader if the "out of scope" statement were accompanied by a pointer to BCP 126/RFC 4786.

Thanks. Added.

> Section 5 contains the following text:
> 
>    It is expected that multicast diagnostics will be collected
>    according to currently established practices [MDH-04].
> 
> I believe this statement makes [MDH-04] normative, as it is required to understand its contents to implement the recommendations in this BCP.

Interesting. This is my first BCP co-authoring, so its not clear to me
how references have to inherit state based on the way they are referred to in
a BCP (as opposed to being use in conjunction with a MUST/SHOULD in a standards
track RFC where i do understand this). Any pointer ?

I don't think that Dave Thaler is interested to make MDH finally an RFC after 17 years
of hiatus, although now that he's not IAB maybe he has more time ;-) And the
draft would definitely deserve it.

In any case, MDH-04 is informative reference and i weakened the sentence
referring to it to avoid IETF process mess followup:

<t>It is recommended that multicast diagnostics will be performed
   leveraging established operational practices such as documented in <xref target="MDH-04"/>. </t>