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

[Matthias Waehlisch <[e-mail]>]

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


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

On Wed, 28 Mar 2012, John Buford wrote:

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