Subject: [MBONED] Adam Roach's No Objection on draft-ietf-mboned-interdomain-peering-bcp-11: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Wed, 11 Oct 2017 19:13:48 -0700

Adam Roach has entered the following ballot position for
draft-ietf-mboned-interdomain-peering-bcp-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mboned-interdomain-peering-bcp/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

___

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.

___

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.

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 28 Oct 2017 02:06:47 +0200

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

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

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

---

From: Adam Roach <[email-masked]>
Date: Fri, 27 Oct 2017 23:08:48 -0500

> track RFC where i do understand this). Any pointer ?

The general IESG guidance on normative references is here:

https://www.ietf.org/iesg/statement/normative-informative.html

Relevant to the original text, the following excerpts apply: "Normative 
references specify documents that must be read to understand or 
implement the technology in the new RFC, or whose technology must be 
present for the technology in the new RFC to work" and "Even references 
that are relevant only for optional features must be classified as 
normative if they meet the above conditions for normative references."

Your proposed shift to make [MDH-04] an example rather than an 
expectation makes it clear that it is only informative. Thanks.

/a