Subject: [Gen-art] Gen-ART review of draft-ietf-mboned-interdomain-peering-bcp-10

From: Christer Holmberg <[email-masked]>
Date: Sat, 2 Sep 2017 12:16:18 +0000

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

Document:                       draft-ietf-mboned-interdomain-peering-bcp-10.txt

Reviewer:                         Christer Holmberg

Review Date:                   2 September 2017

IETF LC End Date:           23 August 2017

IETF Telechat Date:        N/A

Summary: The document is well written. However, there are a couple of issues that I'd like the authors to address.

Major Issues: None

Minor Issues:

Q1: The Introduction talks about the growing usage of multicast, and the it begins the list what the document does. But, what is the background and need for the document? Is there a problem? Are there interoperability issues? At the end of the section it is said that ways to improve are identified, but it is unclear exactly what needs to be improved. I think it would be good to say a few words in the Introduction about the issues and problems.

Editorial Issues:

Q2: The title of section 4 is "Supporting Functionality". That seems a little strange in my eyes. Supporting functionality of what?

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 14 Sep 2017 20:58:52 +0200

On Sat, Sep 02, 2017 at 12:16:18PM +0000, Christer Holmberg wrote:
> 
> 
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq<https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.tools.ietf.org_area_gen_trac_wiki_GenArtfaq&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=4Z9x1ZAReZp_mJahI6h9bQ&m=iIo_51LYIireg4AnsuBoZIWVunRNL9x6ZXHqz5Q2CGc&s=peDTnfOaiDiT8_m4J-VWJr70Nt0m41lLVGq3yYls12k&e=>>
> 
> Minor Issues:
> 

I am a bit at a loss. This is a BCP, eg: it is meant to document current best practices.
It is not meant to suggest "improvements" for protocols or the like. The abstract and
intro do IMHO pretty well stsate the intent and purpose of the doc. 

Maybe its just surprising to you that there has so far been no document to describe how
to deploy IP multicast interdomain, especially with the inclusion of of options such
as GRE and AMT - and simplifying it by only using SSM ??

Or else: Do you have any text to propose ?

> Editorial Issues:
> 
> 
> 
> Q2: The title of section 4 is ?Supporting Functionality?. That seems a little strange in my eyes. Supporting functionality of what?
> 
All the subsections are called "<function-foobar> Guidlines", so how about wee call the whole section "Functional Guidelines" ?

Cheers
    Toerless

---
[email-masked]

---

From: "TARAPORE, PERCY S" <[email-masked]>
Date: Fri, 29 Sep 2017 13:00:00 +0000

Hi Christer,

We discussed your first comment and we agree with Toerless's response. We believe that the intro does express the intent and purpose of this BCP adequately. Based on your second comment, we have changed the title of Section 4 to "Functional Guidelines". The new version has been uploaded.

Thanks for taking the time and effort to read this BCP.

Best wishes,

Percy

-----Original Message-----
From: Toerless Eckert [mailto:[email-masked]] 
Sent: Thursday, September 14, 2017 2:59 PM
To: Christer Holmberg <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: Gen-ART review of draft-ietf-mboned-interdomain-peering-bcp-10

On Sat, Sep 02, 2017 at 12:16:18PM +0000, Christer Holmberg wrote:
> 
> 
> I am the assigned Gen-ART reviewer for this draft. For background on 
> Gen-ART, please see the FAQ at 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.tools.ietf.o
> rg_area_gen_trac_wiki_GenArtfaq&d=DwIBAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=4Z
> 9x1ZAReZp_mJahI6h9bQ&m=Yk2i9Ji8MOfUjKFN0Jp-3wS1nKYQtvqPqcyy5j0Rc2o&s=D
> GgoHGkoQq2XyywjloPLLrHgVKLzBLrEJ8qSkNxKa3I&e= 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.tools.ietf.o
> rg_area_gen_trac_wiki_GenArtfaq&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=4Z
> 9x1ZAReZp_mJahI6h9bQ&m=iIo_51LYIireg4AnsuBoZIWVunRNL9x6ZXHqz5Q2CGc&s=p
> eDTnfOaiDiT8_m4J-VWJr70Nt0m41lLVGq3yYls12k&e=>>
> 
> Minor Issues:
> 

I am a bit at a loss. This is a BCP, eg: it is meant to document current best practices.
It is not meant to suggest "improvements" for protocols or the like. The abstract and intro do IMHO pretty well stsate the intent and purpose of the doc. 

Maybe its just surprising to you that there has so far been no document to describe how to deploy IP multicast interdomain, especially with the inclusion of of options such as GRE and AMT - and simplifying it by only using SSM ??

Cheers
    Toerless

---
[email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 29 Sep 2017 13:25:03 +0000

Hi,

>We discussed your first comment and we agree with Toerless's response. We
>believe that the intro does express the intent and purpose of this BCP
>adequately. Based on your second comment, we have changed the title of
>Section 4 to "Functional Guidelines". The new version has been uploaded.

Ok. Thanks!

Regards,

Christer

>Cc: [email-masked];
>[email-masked]
>Subject: Re: Gen-ART review of
>draft-ietf-mboned-interdomain-peering-bcp-10
>
>> Q1: The Introduction talks about the growing usage of multicast, and
>>the it begins the list what the document does. But, what is the
>>background and need for the document? Is there a problem? Are there
>>interoperability issues? At the end of the section it is said that ways
>>to improve are identified, but it is unclear exactly what needs to be
>>improved. I think it would be good to say a few words in the
>>Introduction about the issues and problems.
>
>It is not meant to suggest "improvements" for protocols or the like. The
>abstract and intro do IMHO pretty well stsate the intent and purpose of
>the doc. 
>
>Maybe its just surprising to you that there has so far been no document
>to describe how to deploy IP multicast interdomain, especially with the
>inclusion of of options such as GRE and AMT - and simplifying it by only
>using SSM ??
>
>> Q2: The title of section 4 is ?Supporting Functionality?. That seems a
>>little strange in my eyes. Supporting functionality of what?
>> 
>All the subsections are called "<function-foobar> Guidlines", so how
>about wee call the whole section "Functional Guidelines" ?
>
>Cheers
>    Toerless
>
>---
>[email-masked]