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

From: Matthias Waehlisch <[email-masked]>
Date: Wed, 28 Mar 2012 17:57:47 +0200

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:[email-masked] .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net

---

From: John Buford <[email-masked]>
Date: Wed, 28 Mar 2012 19:03:13 -0400

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

---

From: Matthias Waehlisch <[email-masked]>
Date: Thu, 29 Mar 2012 09:14:29 +0200

Hi John,

  it's no problem to use "sips", as well. The scheme parameter can be 
extended.

  We will add some clarification statements regarding XCAST in the next 
version.

Thanks
  matthias