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

[Greg Shepherd <[e-mail]>]

*,

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 <[e-mail]> 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" <[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]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mboned
>
>