Subject: [MBONED] Mirja Kühlewind's No Objection on draft-ietf-mboned-interdomain-peering-bcp-11: (with COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 09 Oct 2017 06:00:47 -0700

Mirja Kühlewind 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:
----------------------------------------------------------------------

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?

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.

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.

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 28 Oct 2017 02:05:07 +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

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

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

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

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 30 Oct 2017 12:59:42 +0100

Hi Toerless,

thanks for addressing my discuss in such detail. The new text is great. Maybe one little change:

OLD:
   Like IP unicast traffic, IP multicast traffic carried across non-
   controlled networks must comply to Congestion Control Principles...
NOW
   Like IP unicast traffic, IP multicast traffic carried across non-
   controlled networks MUST comply to Congestion Control Principles…

Also I would still like to see that the respective text in section 3.1 is slightly rephrased to match this:

OLD:
      b. 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.
Proposed NEW:
      b. 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
        the multicast traffic MUST also support rate-adaption.

Thanks!
Mirja

> Am 28.10.2017 um 02:05 schrieb Toerless Eckert <[email-masked]>:
>

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 30 Oct 2017 18:14:53 +0100

Thanks, Mirja

Definitely "must" in second point, sorry.

Wrt.: MUST My issue is that this BCP was not written with
RFC2119 capitalization in mind and not vetted for it. If i change
must=>MUST in just two places (and introduce reference to RFC2119,
it looks out of place for the rest of the document, but doing capitalization
throughout the document, would require a lot more work and repeated review i fear.

Would it be possible to avoid 2119 language by adding behind both
places references that mandate this ("this is not the law, but look up the law" )?

Eg:
  Like IP unicast traffic, IP multicast traffic carried across non-
  controlled networks must comply to Congestion Control Principles
  (the normative place mandating this compliance is RFCxxxx, section y.z).

If you think this would work and had some xxxx,y,z for me, that would be great.

Otherwise i will do the MUST and RFC2119 header and pray to the IAB and
IESG that this will not raise a lot of followup capitalization requests.

Cheers
    Toerless

On Mon, Oct 30, 2017 at 12:59:42PM +0100, Mirja Kuehlewind (IETF) wrote:
>    controlled networks MUST comply to Congestion Control Principles???
> 

-- 
---
[email-masked]

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 30 Oct 2017 22:51:01 +0100

Hi Toerless,

I didn’t realize that there is no normative language in the draft. In this case lower case must is fine. I guess you can point to rfc8085, however, there is also no MUST, just more guidance. 

Mirja

> Am 30.10.2017 um 18:14 schrieb Toerless Eckert <[email-masked]>:
> 
> Thanks, Mirja
>

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 31 Oct 2017 00:48:14 +0100

Thanks!

8085 actually does have a lot of normative language, can't quite remember whether
it has the actual magic sentence (not controlled network ->MUST CC). If not, thats too bad.

At the off-chance one of the three remaining IESG members with discuss will be happy 
before the window for posting opens in Singapore, i've just pushed out -14 with the should->must
fix.

http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-mboned-interdomain-peering-bcp-13.txt&url2=https://tools.ietf.org/id/draft-ietf-mboned-interdomain-peering-bcp-14.txt

Cheers
    Toerless

On Mon, Oct 30, 2017 at 10:51:01PM +0100, Mirja Kuehlewind (IETF) wrote:
> Hi Toerless,
> 
> I didn???t realize that there is no normative language in the draft. In this case lower case must is fine. I guess you can point to rfc8085, however, there is also no MUST, just more guidance. 
> 
> Mirja
> 
> 

-- 
---
[email-masked]