Re: [SAM] RG last call for draft-irtf-samrg-common-api-04

[John Buford <[e-mail]>]

Hi Matthias,

I believe "sip" and "sips" are two different schemes, the latter using secure connection.

So it might be good to indicate whether sips can also be used.

Personally I would like to see Xcast supported in this spec, but would endorse the ID for RGLC either way.

John

Sent from my iPad

On Mar 28, 2012, at 11:57 AM, Matthias Waehlisch <[e-mail]> wrote:

> Hi John,
> 
>  sorry for the late reply!
> 
> On Mon, 27 Feb 2012, John Buford wrote:
> 
>> p. 11 "Names can uniquely determine a group in a global communication
>> context".
>> - regarding "can", should this be "must" or "should"?
>> - please add language that specifies whether group names are intended 
>> to be unique (by namespace domain, by all domains, across all active 
>> sessions, across all past present or future sessions, other)?
>> 
>  OK. We will also clarify this in the Terminology section. The Group 
> Name is intended to be unique by all domains.
> 
>> - is the application responsible for selecting group names and 
>> determining uniqueness?
>> 
>  Group Names can be chosen by the end user. Determining which 
> component ensure uniqueness is out of scope of the document, I would 
> say.
> 
>> p. 11 "Details of service discovery are out of scope of this document" 
>> - is it intended that this be 1) implementation specific detail, 2) 
>> addressed in another specification, 3) use an existing service 
>> discovery mechanism (if so, such as)?
>> 
>  It's maybe more a question to the research group. A separate document 
> is not necessarily required.
> 
>> p. 12, 15
>> 
>>   is "sips" a possible scheme?
>> 
>  "sip", yes.
> 
>> p. 10 "It group communication services ..."  ?
>> 
>  OK, "It _provides_ group communication services ..."
> 
>> p. 19 (4.4.2) 
>> - is Receive meant to be non-blocking or blocking?
>> 
>  It's implemented as blocking.
> 
>> - Can the application receive an event when data is available to 
>> receive?
>> 
>  That's implementation specific. The current events focus on local 
> state changes.
> 
>> - How do you see an application implementing multi-resolution 
>> multicast with this?
>> 
>  It's more the question how to apply the API for multi-resolution 
> multicast? You could use the mapping of names to addresses. Considering 
> a domain with lightweight devices that want data in lower quality, for 
> example, the corresponding gateway could map the name to another address 
> compared to a gateway serving devices with higher capabilities.
> 
>> - how is mobility across multicast domains supported, that is, if a 
>> roaming client moves from an IPv4 multicast network to an overlay 
>> multicast network, is 1) the transition handled by the middleware,
>>  2) the transition detectable by the application through the API, 
>>  3) requires the application to detect the transition and make the 
>> appropriate calls to the API to reconfigure the membership and socket?
>> 
>  The application operates on the Group Name. The Group Name does not 
> change with mobility. From this perspective, the transition should be 
> handled by the middleware.
> 
>> - how is XCAST (or, generally multi-destination multicast routing) 
>> supported? For example, the discussion 3.5 Name to Address Mapping 
>> would seem to be effected if we want to be able to associate a group 
>> name with a list of unicast addresses.
>> 
>  XCAST would be a separate interface (i.e., distribution technology).
> 
>  As far as I understand XCAST, the destination list is unordered. If 
> this is the case, it's easy to extend the naming scheme such that the 
> instantiation of the group represents a set.
> 
>> - msg assembly/disassembly handled by the middleware for messages too 
>> large to send in one multicast packet?
>> 
>  The middleware layer should guarantee some maximal message size to the 
> application developer. We will clarify this in the next version in a 
> separate MTU section.
> 
> 
> 
> Cheers
>  matthias
> 
> -- 
> Matthias Waehlisch
> .  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
> .  Takustr. 9, D-14195 Berlin, Germany
> .. mailto:[e-mail] .. http://www.inf.fu-berlin.de/~waehl
> :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net