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

["Mirja Kuehlewind (IETF)" <[e-mail]>]

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