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

[Toerless Eckert <[e-mail]>]

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

-- 
---
[e-mail]