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

["John Buford" <[e-mail]>]

Following comments with my RG chair hat off.

Document is well written, design is good.  Great to see implementation work
accompanying the ID.
AFAIK, available multicast APIs are technology specific.  Perhaps this point
should be made in the document.

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)?
- is the application responsible for selecting group names and determining
uniqueness?

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)?

p. 12, 15

   is "sips" a possible scheme?

p. 10 "It group communication services ..."  ?

p. 19 (4.4.2) 
- is Receive meant to be non-blocking or blocking?
- Can the application receive an event when data is available to receive?


- How do you see an application implementing multi-resolution multicast with
this?

- 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?

- 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.

- msg assembly/disassembly handled by the middleware for messages too large
to send in one multicast packet?



-----Original Message-----
From: John Buford [mailto:[e-mail]] 
Sent: Monday, February 06, 2012 11:52 AM
To: [e-mail]
Cc: [e-mail]
Subject: RG last call for draft-irtf-samrg-common-api-04


This is to initiate a last call for the Common API document.

The document and related implementation work have been presented at multiple
RG meetings.

Comments from the RG are requested to progress this document along the RFC
path.

Please review the document and provide your comments by Feb. 24.

ID URL: http://datatracker.ietf.org/doc/draft-irtf-samrg-common-API

Thanks,

John