Subject: Re: [MBONED] draft-ietf-mboned-interdomain-peering-bcp Last Call Comment Resolution

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 6 Sep 2016 17:22:37 +0900

Hi Percy and Bob,

Thank you very much for your work.

Almost every change is fine for me.

Please see inline.

> 1.     Hitoshi Comment 1: On Page 3, we have changed the RFC references as requested.

Thanks. That’s fine.

> 2.     Hitoshi Comment 2: On page 4, the reference to “draft-acq” is removed and the phrase “receiver’s router” is changed to “receiver’s upstream router”. However these changes impact previously agreed upon text from Mikael Abrahamsson and Tim Chown. Mikael and Tim, can you please confirm whether these changes are OK with you? If not, could you all work out acceptable text that we can include? Thanks.

I’m Ok for this change.

> 3.     Hitoshi Comment 3: This comment deals with the term “manifest file” which is mentioned in several places in the draft. We have decided to delete this term altogether. We have made several changes indicating that the main point here is the delivery of the appropriate information in the form of metadata that provides the End User with the “S, G” information at a minimum. See our changes on Pages 5, 16, 18, 19 & 20. Please let us know if these changes adequately resolve this comment.

Thanks for your update.
In fact, there are still no descriptions or answers for my previous questions in your revised document; what is the syntax of the metadata, how to make "appropriate" routers (or EUs) obtain the correct metadata, and how to discover which equipment is the appropriate router or EU?

Clarifying these things would be important, but now I understand it is not the role of this document.
So, how about making a small change for the following sentence described in Introduction, e.g.;

The delivery method by which the source transmits this information is determined via arrangements between the source and the two Administrative Domains.
->
The delivery method by which the source transmits this information is determined via arrangements between the source and the two Administrative Domains, whereas defining the delivery method and the format of the metadata is out of scope of this document.

What do you think?

Regards,
--
Hitoshi Asaeda

---

From: "TARAPORE, PERCY S" <[email-masked]>
Date: Tue, 6 Sep 2016 18:34:34 +0000

Thanks Hitoshi,

Your proposed change for your Comment 3 is fine with us. We are still waiting for the others to chime in with their reactions to our proposed changes. Can you all please let us know if the proposed changes - along with Hitoshi's proposal - is good for you?

Thanks

Percy

-----Original Message-----
From: MBONED [mailto:[email-masked]] On Behalf Of Hitoshi Asaeda
Sent: Tuesday, September 06, 2016 4:23 AM
To: TARAPORE, PERCY S <[email-masked]>
Cc: [email-masked]; NORTZ, DOUG <[email-masked]>
Subject: Re: [MBONED] draft-ietf-mboned-interdomain-peering-bcp Last Call Comment Resolution
Importance: High

Hi Percy and Bob,

Please see inline.

Thanks. That’s fine.

I’m Ok for this change.

Thanks for your update.

What do you think?

Regards,
--
Hitoshi Asaeda

_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned

---

From: "TARAPORE, PERCY S" <[email-masked]>
Date: Thu, 22 Sep 2016 15:26:54 +0000

Jake, Tim, Mikael, Lenny,

We are still waiting for your reactions to the changes we have proposed to this draft. Hitoshi has replied suggesting some minor changes - see attached email.

Can you please let us know your reactions so we can finalize all changes and upload the next revision of this BCP?

Thank you

Percy & Bob

From: TARAPORE, PERCY S
Sent: Thursday, August 25, 2016 5:00 PM
To: Hitoshi Asaeda <[email-masked]>; Holland, Jake <[email-masked]>; Tim Chown <[email-masked]>; Mikael Abrahamsson <[email-masked]>; [email-masked]' ([email-masked]) <[email-masked]>; 'Leonard Giuliano' ([email-masked]) <[email-masked]>
Cc: [email-masked]; SAYKO, ROBERT J <[email-masked]>; NORTZ, DOUG <[email-masked]>
Subject: draft-ietf-mboned-interdomain-peering-bcp Last Call Comment Resolution
Importance: High

Hi All,

We received comments from Hitoshi & Jake about this BCP during this Last Call - see attached emails. We have made many changes based on these comments. - see attached draft. Some of these changes impact previously agreed upon text and hence we want concurrence from all parties before we finalize the changes and upload the next revision. All changes in the draft are accompanied by Comments on the side indicating the source of the suggested change.

So here is a brief summary of our proposed changes.

2.     Hitoshi Comment 2: On page 4, the reference to "draft-acq" is removed and the phrase "receiver's router" is changed to "receiver's upstream router". However these changes impact previously agreed upon text from Mikael Abrahamsson and Tim Chown. Mikael and Tim, can you please confirm whether these changes are OK with you? If not, could you all work out acceptable text that we can include? Thanks.

3.     Hitoshi Comment 3: This comment deals with the term "manifest file" which is mentioned in several places in the draft. We have decided to delete this term altogether. We have made several changes indicating that the main point here is the delivery of the appropriate information in the form of metadata that provides the End User with the "S, G" information at a minimum. See our changes on Pages 5, 16, 18, 19 & 20. Please let us know if these changes adequately resolve this comment.

4.     Jake Comment 1: On Page 4, Jake requested an additional reference inclusion for RFC4607 that answers the question "Why Not ASM". However per previous Last Call comment resolution, we have removed all mention of ASM in the preceding paragraph. To add a reference here that now answers the question "Why Not ASM" is therefore a little ambiguous? Hence we are hesitant to do this. However if you can provide appropriate text that deals with this either at the impacted sentence on Page 4 or elsewhere, we would be happy to discuss further.

5.     Jake Comment 2: This is about the manifest file. See the resolution per Hitoshi Comment 3.

6.     Jake Comment 3: On Pages 26 and 27 we have added text to state that the authentication is done at the application layer independent of AD-2.

7.     Jake Comment 4: Per interaction with Lenny, Jake has withdrawn this concern. However we have added the sentence proposed by Jake - see page 15.

Please let us know if these changes adequately address your concerns.

Thanks in advance

Percy & Bob

Subject: RE: [MBONED] draft-ietf-mboned-interdomain-peering-bcp Last Call Comment Resolution
From: "TARAPORE, PERCY S" <[email-masked]>
To: Hitoshi Asaeda <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "NORTZ, DOUG" <[email-masked]>
Date: Tue, 6 Sep 2016 18:34:33 +0000

Thanks Hitoshi,

Thanks

Percy

-----Original Message-----
From: MBONED [mailto:[email-masked]] On Behalf Of Hitoshi Asaeda
Sent: Tuesday, September 06, 2016 4:23 AM
To: TARAPORE, PERCY S <[email-masked]>
Cc: [email-masked]; NORTZ, DOUG <[email-masked]>
Subject: Re: [MBONED] draft-ietf-mboned-interdomain-peering-bcp Last Call Comment Resolution
Importance: High

Hi Percy and Bob,

Please see inline.

Thanks. That’s fine.

I’m Ok for this change.

Thanks for your update.

What do you think?

Regards,
--
Hitoshi Asaeda

---

From: Leonard Giuliano <[email-masked]>
Date: Thu, 22 Sep 2016 13:49:31 -0700

I have no objections to the changes you have described below.

Thanks,
Lenny 

On Thu, 22 Sep 2016, TARAPORE, PERCY S wrote:

| Jake, Tim, Mikael, Lenny,
| 
| We are still waiting for your reactions to the changes we have proposed to this draft. Hitoshi has replied suggesting some minor changes - see attached email.
| 
| Can you please let us know your reactions so we can finalize all changes and upload the next revision of this BCP?
| 
| Thank you
| 
| Percy & Bob
| 
| From: TARAPORE, PERCY S
| Sent: Thursday, August 25, 2016 5:00 PM
| To: Hitoshi Asaeda <[email-masked]>; Holland, Jake <[email-masked]>; Tim Chown <[email-masked]>; Mikael Abrahamsson <[email-masked]>; [email-masked]' ([email-masked]) <[email-masked]>; 'Leonard Giuliano' ([email-masked]) <[email-masked]>
| Cc: [email-masked]; SAYKO, ROBERT J <[email-masked]>; NORTZ, DOUG <[email-masked]>
| Subject: draft-ietf-mboned-interdomain-peering-bcp Last Call Comment Resolution
| Importance: High
| 
| Hi All,
| 
| We received comments from Hitoshi & Jake about this BCP during this Last Call - see attached emails. We have made many changes based on these comments. - see attached draft. Some of these changes impact previously agreed upon text and hence we want concurrence from all parties before we finalize the changes and upload the next revision. All changes in the draft are accompanied by Comments on the side indicating the source of the suggested change.
| 
| So here is a brief summary of our proposed changes.
| 
| 
| 1.     Hitoshi Comment 1: On Page 3, we have changed the RFC references as requested.
| 
| 2.     Hitoshi Comment 2: On page 4, the reference to "draft-acq" is removed and the phrase "receiver's router" is changed to "receiver's upstream router". However these changes impact previously agreed upon text from Mikael Abrahamsson and Tim Chown. Mikael and Tim, can you please confirm whether these changes are OK with you? If not, could you all work out acceptable text that we can include? Thanks.
| 
| 3.     Hitoshi Comment 3: This comment deals with the term "manifest file" which is mentioned in several places in the draft. We have decided to delete this term altogether. We have made several changes indicating that the main point here is the delivery of the appropriate information in the form of metadata that provides the End User with the "S, G" information at a minimum. See our changes on Pages 5, 16, 18, 19 & 20. Please let us know if these changes adequately resolve this comment.
| 
| 4.     Jake Comment 1: On Page 4, Jake requested an additional reference inclusion for RFC4607 that answers the question "Why Not ASM". However per previous Last Call comment resolution, we have removed all mention of ASM in the preceding paragraph. To add a reference here that now answers the question "Why Not ASM" is therefore a little ambiguous? Hence we are hesitant to do this. However if you can provide appropriate text that deals with this either at the impacted sentence on Page 4 or elsewhere, we would be happy to discuss further.
| 
| 5.     Jake Comment 2: This is about the manifest file. See the resolution per Hitoshi Comment 3.
| 
| 6.     Jake Comment 3: On Pages 26 and 27 we have added text to state that the authentication is done at the application layer independent of AD-2.
| 
| 7.     Jake Comment 4: Per interaction with Lenny, Jake has withdrawn this concern. However we have added the sentence proposed by Jake - see page 15.
| 
| Please let us know if these changes adequately address your concerns.
| 
| Thanks in advance
| 
| Percy & Bob
|

---

From: "TARAPORE, PERCY S" <[email-masked]>
Date: Thu, 22 Sep 2016 20:56:19 +0000

Thanks Lenny,

Jake, Tim, Mikael can you please let us know your responses.

Thanks

Percy & Bob

Sent from my iPhone

> On Sep 22, 2016, at 10:49 PM, Leonard Giuliano <[email-masked]> wrote:
> 
>

---

From: "Holland, Jake" <[email-masked]>
Date: Thu, 22 Sep 2016 21:08:28 +0000

Sorry for the delay.

4.     Jake Comment 1: On Page 4, Jake requested an additional reference inclusion for RFC4607 that answers the question “Why Not ASM”. However per previous Last Call comment resolution, we have removed all mention of ASM in the preceding paragraph. To add a reference here that now answers the question “Why Not ASM” is therefore a little ambiguous? Hence we are hesitant to do this. However if you can provide appropriate text that deals with this either at the impacted sentence on Page 4 or elsewhere, we would be happy to discuss further.

IIRC, my suggestion was to provide a reference to RFC 4609 (not 4607), and I think it was in the introduction section in page 2-3.

I think it’s already perhaps covered by another change you’ve made, namely this addition:

      o As described in Section 2<https://tools.ietf.org/html/draft-ietf-mboned-interdomain-peering-bcp-04#section-2>, the source IP address of the

         multicast stream in the originating AD (AD-1) is known. Under

         this condition, PIM-SSM use is beneficial for the reasons

         stated in [draft-acq<https://tools.ietf.org/html/draft-acq>], e.g., it allows the receiver's router

         to directly send a JOIN message to the source without the need

         of invoking an intermediate Rendezvous Point (RP). Hence, in

         the case of inter-domain peering, it is recommended to use

         only SSM protocols.

However, (and this is an optional suggestion) I will invite you to insert before the final sentence in this paragraph something like:

... of invoking an intermediate Rendezvous Point (RP).
Use of SSM also presents an improved threat mitigation profile against attack, as described in [RFC4609].
Hence, in ...

(plus of course adding RFC4609 as a non-normative reference at the end, if it’s included).

That said, I have no remaining objections to the draft, even if you choose not to add this language or something similar. :)

Thanks and regards,
Jake

From: "TARAPORE, PERCY S" <[email-masked]>
Date: Thursday, September 22, 2016 at 8:26 AM
To: 'Hitoshi Asaeda' <[email-masked]>, Jacob Holland <[email-masked]>, 'Tim Chown' <[email-masked]>, 'Mikael Abrahamsson' <[email-masked]>, "[email-masked]' ([email-masked])" <[email-masked]>, "'Leonard Giuliano' ([email-masked])" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "SAYKO, ROBERT J" <[email-masked]>, "NORTZ, DOUG" <[email-masked]>
Subject: RE: draft-ietf-mboned-interdomain-peering-bcp Last Call Comment Resolution

We are still waiting for your reactions to the changes we have proposed to this draft. Hitoshi has replied suggesting some minor changes – see attached email.

Thank you

Percy & Bob

From: TARAPORE, PERCY S

Hi All,

We received comments from Hitoshi & Jake about this BCP during this Last Call – see attached emails. We have made many changes based on these comments. – see attached draft. Some of these changes impact previously agreed upon text and hence we want concurrence from all parties before we finalize the changes and upload the next revision. All changes in the draft are accompanied by Comments on the side indicating the source of the suggested change.

4.       Jake Comment 1: On Page 4, Jake requested an additional reference inclusion for RFC4607 that answers the question “Why Not ASM”. However per previous Last Call comment resolution, we have removed all mention of ASM in the preceding paragraph. To add a reference here that now answers the question “Why Not ASM” is therefore a little ambiguous? Hence we are hesitant to do this. However if you can provide appropriate text that deals with this either at the impacted sentence on Page 4 or elsewhere, we would be happy to discuss further.

7.       Jake Comment 4: Per interaction with Lenny, Jake has withdrawn this concern. However we have added the sentence proposed by Jake – see page 15.

Thanks in advance

Percy & Bob

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 23 Sep 2016 05:39:24 +0200 (CEST)

I have no problem with adding "upstream" to the agreed text.

-- 
Mikael Abrahamsson    email: [email-masked]