Subject: Re: [MBONED] WGLC: draft-ietf-mboned-interdomain-peering-bcp-06

From: Greg Shepherd <[email-masked]>
Date: Mon, 2 Jan 2017 21:26:07 -0800

*,

Jake's comments are significant to warrant another rev, sorry.

Jake, can you work closely (and quickly) with the authors to address your
comments?

Thanks,
Greg

On Sun, Dec 11, 2016 at 6:23 PM, Holland, Jake <[email-masked]> wrote:

> Support with comments.
>
>
>
> Comments:
>
> Please forgive me for not catching it last time; most of the doc seemed
> good, but after reading it again, I noticed that section 2 still bothered
> me:
>
>
>
> I found the list in section 2 confusing, and I’m not sure whether it’s
> describing a different scenario than what I consider typical or whether
> it’s just wrong in its description. The 4th and 5th bullet points in
> particular are puzzling. (And the 6th still mentions a manifest file, which
> I thought was supposed to be removed?)
>
>
>
> I almost left it alone on the grounds that it’s just an example and it’s
> OK if it doesn’t match my scenario exactly, but then I noticed the opening
> sentence of the section (“A multicast-based application delivery scenario
> is as follows:”) was unclear as to whether it meant “One possible example
> of a multicast-based application delivery scenario follows” or whether it
> meant “Multicast-based application delivery scenarios this document applies
> to generally are as follows:”. The possibility of the latter interpretation
> makes it an issue worth raising, I thought.
>
>
>
> The 4th bullet point (“An End User associated with...”) seems to indicate
> that the End User is requesting the application, rather than an application
> client requesting the application data stream.
>
>
>
> The 5th bullet point (“The request is communicated...”) seems to indicate
> that the application source has to handle a request and respond with
> metadata, when I think it’s ok if some other service provides the metadata.
> It later seems to imply that the metadata has to be communicated between
> the two ADs and directly provided by the application source, rather than
> just being obtained somehow by the end user’s application client, and that
> seems weirdly restrictive.
>
>
>
> For instance, the case I expect typically in practice: A service provider
> has configured the application source to transmit an (S,G), and also has
> put that (S,G) in metadata in a separate but complementary web service, and
> the application client fetches the metadata from the web service somehow
> (possibly over some other network besides AD-2, and possibly with no
> involvement from AD-1). And other examples shouldn’t be excluded either,
> e.g. I don’t see why the (S,G) couldn’t be communicated by telephone to the
> End User, who manually sets configuration in his application client.
>
>
>
> I don’t think these things need explaining at this point in the doc, but I
> do think ideally neither case should be excluded in the explanation here
> and they seem to be to me, so I’d like to see it be less specific about how
> the (S,G) is learned, or more clear that it’s just an example.
>
>
>
> I think there are many possible answers, but I will suggest these as a
> possible replacement for the last 4 bullet points (3 thru 6) in the list in
> Section 2 that would in my opinion address this issue:
>
> “
>
> - A service provider controls one or more application sources in AD-1
> which will send multicast IP packets for one or more (S,G)s. It is assumed
> that the service being provided is suitable for delivery via multicast
> (e.g. live video streaming of popular events, software downloads to many
> devices, etc.), and that the packet streams will be part of a suitable
> multicast transport protocol.
>
> - An End User (EU) controls a device connected to AD-2, which runs an
> application client compatible with the service provider’s application
> source.
>
> - The application client joins appropriate (S,G)s in order to receive the
> data necessary to provide the service to the end user. The mechanisms by
> which the application client learns the appropriate (S,G)s are an
> implementation detail of the application, and are out of scope for this
> document.
>
> “
>
>
>
> (Failing that, I also want to mention the more minor point that the 3rd
> bullet’s “known” sentence doesn’t specify known to whom or in what context,
> and the point seems better off without the confusion, either by dropping
> the sentence or clarifying it.)
>
>
>
>
>
> Nits:
>
> “live steaming” -> “live streaming” (‘r’ missing)
>
> “EU” needs expansion on first use
>
> Section 3: “There are five possible Use Cases for consideration”: I’m not
> sure if these 5 are the only possibilities. Suggest: “There are five Use
> Cases considered in this document”?
>
>
>
>
>
> Regards,
>
> Jake
>
>
>
> On 12/5/16, 12:24 PM, "Greg Shepherd" <[email-masked]> wrote:
>
>
>
> WG,
>
>
>
> The two week timer has expired, but nobody responded. And it just doesn't
> seem right to progress a doc without input from the WG. So, can the active
> members please the latest rev and reply to this thread with or without
> support.
>
>
>
> Thanks,
>
> Greg
>
>
>
> On Fri, Nov 18, 2016 at 7:08 AM, Greg Shepherd <[email-masked]> wrote:
>
> WG,
>
>
>
> The draft has be rev'd with the latest input from the group. It's time
> again for Working Group Last call. Please read and respond to the list in
> support or with comments.
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-mboned-
> interdomain-peering-bcp/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dmboned-2Dinterdomain-2Dpeering-2Dbcp_&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=Q_sy-fqGUwSNrXsZU6uFb60gJ7vGMfj9QrozvDUKIpI&s=U_iDIDiXJZKMyhQFed9rS5kZBZOmBj6m4rDCcoxo0rQ&e=>
>
>
>
> Let this message serve as the start of our two week timer, to close on Dec
> 2nd.
>
>
>
> Cheers,
>
> Greg (Chairs)
>
>
>
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned
>
>

---

From: Stig Venaas <[email-masked]>
Date: Thu, 5 Jan 2017 11:40:54 -0800

I agree with Jake's comments.

I read this more carefully now and I have a few comments as well.
The document is quite good. I just have some minor comments/nits.

The term "delivery of applications" is used a lot in the beginning of
the document. E.g.,

   Several types of applications (e.g., live video streaming, software
   downloads) are well suited for delivery via multicast means. The use
   of multicast for delivering such applications offers significant
   savings for utilization of resources in any given administrative
   domain. End user demand for such applications is growing. Often,
   this requires transporting such applications across administrative
   domains via inter-domain peering points.

and

     o Describe the technical process and establish guidelines for
        setting up multicast-based delivery of applications across inter-
        domain peering points via a set of use cases.

Wouldn't it be better to use the term  "application content" or
"application data"? It sounds a little odd to me to say "application
delivery".

I see in 4.2.3 it says:
  o Using the information from the metadata, and possibly information
     provisioned directly in the EU client, a DNS query is initiated in
     order to connect the EU client/AMT Gateway to an AMT Relay.

Do we already have a solution that allows for choosing a different
relay for different sources? I would be interested in more details. I
guess it may be out of scope here. But is there already a way of
describing this with metadata for any applications or EU clients? As a
BCP it should ideally refer to things that already are in use.

At the end of 4.2.3 it says:
   Note: Further routing discussion on optimal method to find "best AMT
   Relay/GW combination" and information exchange between AD's to be
   provided.

Was it supposed to be provided in this document? If not, then maybe
change/remove this sentence?

7. IANA Considerations

It should not be empty. At a minimum say that there are no considerations.

10. Acknowledgments

Should this really be empty? Remove it in that case.

That's all,

Stig

On Mon, Jan 2, 2017 at 9:26 PM, Greg Shepherd <[email-masked]> wrote:
>> describing a different scenario than what I consider typical or whether it’s
>> just wrong in its description. The 4th and 5th bullet points in particular
>> are puzzling. (And the 6th still mentions a manifest file, which I thought
>> was supposed to be removed?)
>>
>>
>>
>> sentence of the section (“A multicast-based application delivery scenario is
>> as follows:”) was unclear as to whether it meant “One possible example of a
>> multicast-based application delivery scenario follows” or whether it meant
>> “Multicast-based application delivery scenarios this document applies to
>> generally are as follows:”. The possibility of the latter interpretation
>> It later seems to imply that the metadata has to be communicated between the
>> two ADs and directly provided by the application source, rather than just
>> being obtained somehow by the end user’s application client, and that seems
>> weirdly restrictive.
>>
>>
>>
>> has configured the application source to transmit an (S,G), and also has put
>> that (S,G) in metadata in a separate but complementary web service, and the
>> application client fetches the metadata from the web service somehow
>> do think ideally neither case should be excluded in the explanation here and
>> they seem to be to me, so I’d like to see it be less specific about how the
>> (S,G) is learned, or more clear that it’s just an example.
>>
>>
>>
>> that the service being provided is suitable for delivery via multicast (e.g.
>> live video streaming of popular events, software downloads to many devices,
>> etc.), and that the packet streams will be part of a suitable multicast
>> transport protocol.
>>
>> and the point seems better off without the confusion, either by dropping the
>> sentence or clarifying it.)
>>
>>
>>
>>
>>
>> Nits:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-mboned-interdomain-peering-bcp/
>>
>>
>>

---

From: "Holland, Jake" <[email-masked]>
Date: Fri, 6 Jan 2017 02:38:50 +0000

On 1/5/17, 11:40 AM, "Stig Venaas" <[email-masked]> wrote:
    I see in 4.2.3 it says:
      o Using the information from the metadata, and possibly information
         provisioned directly in the EU client, a DNS query is initiated in
         order to connect the EU client/AMT Gateway to an AMT Relay.

The Octoshape media client does something that fits this description. The (S,G) and the relay address can be provisioned in the client based on metadata it receives at runtime. The DNS is optional, but in this context it’s an example, and I think this describes a real-life scenario that’s deployed today.

To be on the safe side, having mentioned the Octoshape client, I should probably make an IPR disclosure:
There are some patents related to the Octoshape technology that I believe are now owned by Akamai and/or its subsidiaries. Though I do not believe this nuance of configurable AMT relay discovery is covered in any of the claims, the Octoshape system itself does use some patent-encumbered technology, and if you are inspired to examine its behavior in light of this discussion or for some other reason, please be aware that you should consider the patents appropriately.

Cheers,
Jake

---

From: "TARAPORE, PERCY S" <[email-masked]>
Date: Mon, 30 Jan 2017 21:00:17 +0000

Jake & Stig,

Attached please find a revised marked up Draft BCP that addresses all your comments as follows:

Jake we accepted all your suggested revisions and have incorporated them into the text.

Stig, we attempted to address all your comments. Please review the changes associated with the revision proposed on page 18 (bottom of the page). These changes allow us to keep the text for the bullet on page 19 which was the motivation for Stig’s Comment 2. Please let us know if this is acceptable.

Please respond back to me by mid-week so I can formally upload the revised Draft and request start of the next – and hopefully last – Last Call.

Thank you for all your help.

Percy & Bob

-----Original Message-----
From: MBONED [mailto:[email-masked]] On Behalf Of Holland, Jake
Sent: Thursday, January 05, 2017 9:39 PM
To: Stig Venaas <[email-masked]>; Greg Shepherd <[email-masked]>
Cc: [email-masked]
Subject: Re: [MBONED] WGLC: draft-ietf-mboned-interdomain-peering-bcp-06

On 1/5/17, 11:40 AM, "Stig Venaas" <[email-masked]<mailto:[email-masked]>> wrote:

    I see in 4.2.3 it says:

Cheers,

Jake

MBONED mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Holland, Jake" <[email-masked]>
Date: Mon, 30 Jan 2017 23:41:45 +0000

This one looks fine to me. Thanks for all your work on this, Percy.

On 1/30/17, 1:00 PM, "TARAPORE, PERCY S" <[email-masked]<mailto:[email-masked]>> wrote:

Jake & Stig,

Percy & Bob

-----Original Message-----
From: MBONED [mailto:[email-masked]] On Behalf Of Holland, Jake
Sent: Thursday, January 05, 2017 9:39 PM
To: Stig Venaas <[email-masked]>; Greg Shepherd <[email-masked]>
Cc: [email-masked]
Subject: Re: [MBONED] WGLC: draft-ietf-mboned-interdomain-peering-bcp-06

    I see in 4.2.3 it says:

Cheers,

Jake

MBONED mailing list

https://www.ietf.org/mailman/listinfo/mboned<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mboned&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=bLqYFqDPyoUwkn0mhDUH_igeg-XnrQZJkWvGV_GPlGI&s=mjo85frCoyYa2M8cq3PiyBQFpUY8DMbTXI3ZAcPeNVA&e=>

---

From: "TARAPORE, PERCY S" <[email-masked]>
Date: Tue, 31 Jan 2017 20:25:09 +0000

Thanks Jake,

Stig do you have any further comments? Is the proposed revision good for you? I would like to request the Last Call process by the end of this week.

Thanks

Percy

From: Holland, Jake [mailto:[email-masked]]
Sent: Monday, January 30, 2017 6:42 PM
To: TARAPORE, PERCY S <[email-masked]>; Stig Venaas <[email-masked]>; Greg Shepherd <[email-masked]>
Cc: [email-masked]; SAYKO, ROBERT J <[email-masked]>
Subject: Re: [MBONED] WGLC: draft-ietf-mboned-interdomain-peering-bcp-06

Jake & Stig,

Percy & Bob

-----Original Message-----
From: MBONED [mailto:[email-masked]] On Behalf Of Holland, Jake
Sent: Thursday, January 05, 2017 9:39 PM
To: Stig Venaas <[email-masked]<mailto:[email-masked]>>; Greg Shepherd <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [MBONED] WGLC: draft-ietf-mboned-interdomain-peering-bcp-06

    I see in 4.2.3 it says:

Cheers,

Jake

MBONED mailing list

---

From: Stig Venaas <[email-masked]>
Date: Tue, 31 Jan 2017 13:48:16 -0800

Hi

This looks good to me,

Stig

On Tue, Jan 31, 2017 at 12:25 PM, TARAPORE, PERCY S <[email-masked]> wrote:
> Thanks Jake,
>
>
>
> Stig do you have any further comments? Is the proposed revision good for
> you? I would like to request the Last Call process by the end of this week.
>
>
>
> Thanks
>
>
>
> Percy
>
>
>
> On 1/30/17, 1:00 PM, "TARAPORE, PERCY S" <[email-masked]> wrote:
>
>
>
> Jake & Stig,
>
>
>
> Stig, we attempted to address all your comments. Please review the changes
> associated with the revision proposed on page 18 (bottom of the page). These
> changes allow us to keep the text for the bullet on page 19 which was the
> motivation for Stig’s Comment 2. Please let us know if this is acceptable.
>
>
>
> Please respond back to me by mid-week so I can formally upload the revised
> Draft and request start of the next – and hopefully last – Last Call.
>
>
>
> The Octoshape media client does something that fits this description. The
> (S,G) and the relay address can be provisioned in the client based on
> metadata it receives at runtime. The DNS is optional, but in this context
> it’s an example, and I think this describes a real-life scenario that’s
> deployed today.
>
>
>
>
>
> There are some patents related to the Octoshape technology that I believe
> are now owned by Akamai and/or its subsidiaries. Though I do not believe
> this nuance of configurable AMT relay discovery is covered in any of the
> claims, the Octoshape system itself does use some patent-encumbered
> technology, and if you are inspired to examine its behavior in light of this
> discussion or for some other reason, please be aware that you should
> consider the patents appropriately.
>
>
>
> Cheers,
>
> Jake
>
>
>
>
>

---

From: "TARAPORE, PERCY S" <[email-masked]>
Date: Tue, 31 Jan 2017 21:50:02 +0000

Thanks Stig,

Assuming I get no more feedback, I will upload this as a new Draft tomorrow and request Last Call.

Percy

-----Original Message-----
From: Stig Venaas [mailto:[email-masked]] 
Sent: Tuesday, January 31, 2017 4:48 PM
To: TARAPORE, PERCY S <[email-masked]>
Cc: Holland, Jake <[email-masked]>; Greg Shepherd <[email-masked]>; [email-masked]; SAYKO, ROBERT J <[email-masked]>
Subject: Re: [MBONED] WGLC: draft-ietf-mboned-interdomain-peering-bcp-06

Hi

This looks good to me,

Stig

On Tue, Jan 31, 2017 at 12:25 PM, TARAPORE, PERCY S <[email-masked]> wrote:
> Thanks Jake,
>
>
>
> Stig do you have any further comments? Is the proposed revision good 
> for you? I would like to request the Last Call process by the end of this week.
>
>
>
> Thanks
>
>
>
> Percy
>
>
>
> Subject: Re: [MBONED] WGLC: 
> draft-ietf-mboned-interdomain-peering-bcp-06
>
>
>
> Stig, we attempted to address all your comments. Please review the 
> changes associated with the revision proposed on page 18 (bottom of 
> the page). These changes allow us to keep the text for the bullet on 
> page 19 which was the motivation for Stig’s Comment 2. Please let us know if this is acceptable.
>
>
>
> Please respond back to me by mid-week so I can formally upload the 
> revised Draft and request start of the next – and hopefully last – Last Call.
>
>
>
> Subject: Re: [MBONED] WGLC: 
> draft-ietf-mboned-interdomain-peering-bcp-06
>
>
>
> metadata it receives at runtime. The DNS is optional, but in this 
> context it’s an example, and I think this describes a real-life 
> scenario that’s deployed today.
>
>
>
>
>
> There are some patents related to the Octoshape technology that I 
> believe are now owned by Akamai and/or its subsidiaries. Though I do 
> not believe this nuance of configurable AMT relay discovery is covered 
> in any of the claims, the Octoshape system itself does use some 
> patent-encumbered technology, and if you are inspired to examine its 
> behavior in light of this discussion or for some other reason, please 
> be aware that you should consider the patents appropriately.
>
>
>
> Cheers,
>
> Jake
>
>
>
>
>

---

From: Greg Shepherd <[email-masked]>
Date: Tue, 31 Jan 2017 13:55:33 -0800

Great. Thanks everyone!

Percy, please rev the doc to reflect these changes and we'll restart WGLC.

Cheers,
Greg

On Tue, Jan 31, 2017 at 1:48 PM, Stig Venaas <[email-masked]> wrote:

> > To: TARAPORE, PERCY S <[email-masked]>; Stig Venaas <[email-masked]>;
> Greg
> > Shepherd <[email-masked]>
> > Attached please find a revised marked up Draft BCP that addresses all
> your
> > comments as follows:
> >
> >
> >
> changes
> revised

---

From: Greg Shepherd <[email-masked]>
Date: Tue, 31 Jan 2017 13:55:45 -0800

:)

On Tue, Jan 31, 2017 at 1:50 PM, TARAPORE, PERCY S <[email-masked]> wrote:

> Cc: Holland, Jake <[email-masked]>; Greg Shepherd <[email-masked]>;
> [email-masked]; SAYKO, ROBERT J <[email-masked]>
> > Greg Shepherd <[email-masked]>
> > your comments as follows:
> >
> >
> >