Re: [MBONED] WGLC on draft-ietf-mboned-session-announcement-req

[Leonard Giuliano <[e-mail]>]

On Mon, 19 Apr 2010, Hitoshi Asaeda wrote:

-) > My comments on the obsolescence of SAP could be generally applied to all 
-) > network-based content discovery schemes, wheter it's SAP, SAPv2 or some 
-) > new protocol.  No one would plausibly propose a network-based content 
-) > discovery of unicast, so why do it for mcast?
-) 
-) This draft does not propose or recommend network-based content
-) discovery. Whether network-based or other approach, there are special
-) requirements for content information announcement or discovery in IP
-) multicast.
-) 
-) Multicast is highly useful for real-time applications, such as live
-) streaming. To live with real-time applications, getting the content
-) information is the first step for users. However, if we obtain
-) "obsolete" content information (e.g. information about content ended),
-) it is meaningless. How can we obtain the "active" or "available"
-) content information in a time-sensitive manner? Or how we can discard
-) "obsolete" content information when we obtain the session information?

If you replace the word "Multicast" with "Unicast", this paragraph is 
equally true:

"Unicast is highly useful for real-time applications, such as live
streaming. To live with real-time applications, getting the content
information is the first step for users. However, if we obtain
"obsolete" content information (e.g. information about content ended),
it is meaningless. How can we obtain the "active" or "available"
content information in a time-sensitive manner? Or how we can discard
"obsolete" content information when we obtain the session information?"

-)
-)

[clip]

-) 
-) There is a problem to announce unicast real-time contents to the 
-) Internet users, too. The requirements for session announcement would 
-) fit the demend of real-time streaming. This means the problem exists 
-) also in unicast. How can I announce my streaming content to you now? 
-) How can you discover my streaming content now? What is the best way to 
-) convey or discover real-time content information in general? SAP, 
-) email, web, rss, or any other implementation does not fit the demand. 
-) (Our draft details the point, so I omit to explain what is the demand 
-) here.) The session announcement or discovery scheme doesn't depend on 
-) its transmission, whether unicast or multicast. The point is that the 
-) problems in session announcement give higher impact to multicast 
-) communication, and it is necessary to take it into account for its 
-) deployment. And also, the corresponding solution will solve both 
-) unicast and multicast.
-) 

I certainly agree with this paragraph (except the part about "higher 
impact to multicast"), and suggest if this is something needed for mcast, 
there is also something needed for unicast.  Perhaps a generic solution 
that addresses both unicast and mcast for this category of "real-time, 
dynamic content" might be appropriate.  If so, I am not sure this WG is 
the right place for such work.  Perhaps MMUSIC or one of the other RAI WGs 
might be the right place?

-) On the other hand, there is one important role in the announcement or
-) discovery for multicast contents. The keyword is "scope". This is
-) explained in the draft, and briefly in the latter part of this mail.
-) 

Not sure I agree that the desire for mcast scoping is any different than 
unicast access control.  But assuming there are some unique considerations 
for mcast, I think it would appropriate for MBONED to provide input on 
mcast considerations for a broader solution that encompasses both unicast 
and mcast.  Again, I think this generic solution would be more appropriate 
in one of the RAI WGs.