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

[Stig Venaas <[e-mail]>]

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 <[e-mail]> wrote:
> *,
>
> 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/
>>
>>
>>
>> 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
>>
>
>
> _______________________________________________
> MBONED mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mboned
>