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

["Holland, Jake" <[e-mail]>]

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" <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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)