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

[Toerless Eckert <[e-mail]>]

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

-- 
---
[e-mail]