Subject: Re: [MBONED] New Version Notification for draft-tsou-multrans-addr-acquisition-00.txt for the 2nd item "Multicast Source Discovery" of the interim meeting

From: Dave Thaler <[email-masked]>
Date: Thu, 1 Mar 2012 01:09:35 +0000

My comments on this document are now in the marked up copy at

http://research.microsoft.com/~dthaler/draft-tsou-multrans-addr-acquisition-00.pdf

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Tina TSOU
> Sent: Sunday, December 11, 2011 6:28 PM
> To: [email-masked]; MBONED WG
> Subject: [MBONED] New Version Notification for draft-tsou-multrans-addr-
> acquisition-00.txt for the 2nd item "Multicast Source Discovery" of the interim
> meeting
> 
> Dear all,
> Here is a new draft to work from for the 2nd item "Multicast Source Discovery"
> of the interim meeting.
> http://datatracker.ietf.org/doc/draft-tsou-multrans-addr-acquisition/
> 
> Title:
> Address Acquisition for Multicast Content When Source and Receiver Support
> Differing IP Versions
> Creation date:	 2011-12-11
> Number of pages: 9
> 
> Abstract:
>    In a typical IP television (IPTV) system, the receiver acquires
>    information about available program content, the subscriber selects a
>    program to watch, and the receiver signals to the network to begin
>    receiving the program in the form of multicast content.  The program
>    content information is typically XML-encoded, can be transmitted in
>    multiple segments, possibly over multiple channels, but includes
>    media stream descriptions for the individual program descriptions
>    that may also be XML-encoded or may use the Session Description
>    Protocol (SDP, RFC 4566).  The media stream descriptions provide
>    multicast group and unicast source addresses that are used in the
>    subsequent signalling to the network.
> 
>    During the transition from IPv4 to IPv6, scenarios can occur where
>    the IP version supported by the receiver differs from that supported
>    by the source.  This memo examines and evaluates alternative
>    strategies for allowing the receiver to acquire addresses in such
>    scenarios in the version it supports.
> 
> >> 2. Multicast address discovery by the receiver (2 hours)
> >>
> >> How does the receiver learn the multicast addresses corresponding to
> >> specific programs, in the IP version that the receiver understands?
> >
> > We might want to call this Multicast Source Discovery. The following are a
> few interesting questions:
> >
> > - How are multicast sources identified?
> > - How dynamic is the Source Discovery Mechanism? Does it simple discover
> and announce every multicast stream in the network or is registration
> required?
> > - How do we ensure that the scope of the Source discovery mechanism is the
> same as the scope of the multicast network?
> > - Can the Source Discovery mechanism be crafted from existing protocols?
> >
> > Again, it would be great if we had a draft to work from.
> 
> Specially, would like to thank Dave Thaler, for raising the problem, and inspiring
> the idea and giving technical advice; and valuable technical suggestions from
> Ron Bonica, Marshall Eubanks and Greg Shepherd.
> 
> 
> Best Regards,
> Tina
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned

---

From: Tina TSOU <[email-masked]>
Date: Thu, 01 Mar 2012 01:17:14 +0000

Dave,
Thank you for your comments. We will review them. Some of them may not apply to the latest version which is at
http://datatracker.ietf.org/doc/draft-tsou-mboned-multrans-addr-acquisition/

Tina

> From: Dave Thaler [mailto:[email-masked]]
> Sent: Wednesday, February 29, 2012 5:10 PM
> To: Tina TSOU; [email-masked]; MBONED WG
> Subject: RE: [MBONED] New Version Notification for draft-tsou-multrans-
> addr-acquisition-00.txt for the 2nd item "Multicast Source Discovery" of
> the interim meeting
>

---

From: Dave Thaler <[email-masked]>
Date: Thu, 1 Mar 2012 01:18:41 +0000

They should, since that's the version I actually grabbed to review.

-Dave

> From: Tina TSOU [mailto:[email-masked]]
> Sent: Wednesday, February 29, 2012 5:17 PM
> To: Dave Thaler; [email-masked]; MBONED WG
> Subject: RE: [MBONED] New Version Notification for draft-tsou-multrans-addr-
> Thank you for your comments. We will review them. Some of them may not
> apply to the latest version which is at http://datatracker.ietf.org/doc/draft-
> tsou-mboned-multrans-addr-acquisition/
> 
> Tina
> 
> 
> > Subject: RE: [MBONED] New Version Notification for
> > draft-tsou-multrans- addr-acquisition-00.txt for the 2nd item
> > "Multicast Source Discovery" of the interim meeting
> >
> > > From: [email-masked] [mailto:[email-masked]] On
> > > Behalf Of Tina TSOU
> > > Subject: [MBONED] New Version Notification for
> > > draft-tsou-multrans-addr- acquisition-00.txt for the 2nd item
> > > "Multicast Source Discovery" of the
> > interim
> > > meeting
> > >
> > > Dear all,
> > > >> How does the receiver learn the multicast addresses corresponding
> > > >> to specific programs, in the IP version that the receiver understands?
> > > >
> > > > We might want to call this Multicast Source Discovery. The
> > > > following
> > are a
> > > and announce every multicast stream in the network or is
> > > registration required?
> > > > - How do we ensure that the scope of the Source discovery
> > > > mechanism is
> > the
> > > Specially, would like to thank Dave Thaler, for raising the problem,
> > > and
> > inspiring
> > > the idea and giving technical advice; and valuable technical
> > > suggestions
> > from

---

From: Tina TSOU <[email-masked]>
Date: Thu, 01 Mar 2012 01:22:53 +0000

There is a subtle difference in the draft name; the newer one is draft-tsou-mboned....

Tina

> Sent: Wednesday, February 29, 2012 5:19 PM
> addr-

---

From: Dave Thaler <[email-masked]>
Date: Thu, 1 Mar 2012 01:33:22 +0000

Ah, I see.

One additional comment on the text changed in the -mboned- version
(I just reviewed the diffs, and only adding a comment here that wasn't
already in my other review).

Section 1: what's "zapping delay"??  avoid using undefined terms.

-Dave

> Sent: Wednesday, February 29, 2012 5:23 PM
> > > draft-tsou-multrans-
> > > acquisition-00.txt for the 2nd item "Multicast Source Discovery" of
> > > the
> > interim
> > > meeting
> > >
> > > Dave,
> > > Thank you for your comments. We will review them. Some of them may
> > > not apply to the latest version which is at
> > > > > From: [email-masked] [mailto:[email-masked]]
> > > > > On Behalf Of Tina TSOU
> > > > > Here is a new draft to work from for the 2nd item "Multicast
> > > > > Source
> > > > Discovery"
> > > > > of the interim meeting.
> > > > > http://datatracker.ietf.org/doc/draft-tsou-multrans-addr-acquisi
> > > > > tion
> > > > > /
> > > > >
> > > > > Title:
> > > > > Address Acquisition for Multicast Content When Source and
> > > > > Receiver
> > > > Support
> > > > > Differing IP Versions
> > > > >    content information is typically XML-encoded, can be
> > > > > transmitted
> > in
> > > > > >> How does the receiver learn the multicast addresses
> > > > > >> corresponding to specific programs, in the IP version that
> > > > > >> the receiver
> > understands?
> > > > > >
> > > > > > - How dynamic is the Source Discovery Mechanism? Does it
> > > > > > simple
> > > > discover
> > > > > Specially, would like to thank Dave Thaler, for raising the
> > > > > problem, and
> > > > inspiring