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

[Matthias Waehlisch <[e-mail]>]

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