Re: [SAM] New Version Notification for draft-irtf-samrg-common-api-05.txt

Hi Matthias,

>From earlier comments on -04 version:

Can you indicate in the document whether "sips:" URI scheme is supported or
not.

This typo is now on p. 11 of the -05 draft
>> p. 10 "It group communication services ..."  ?
>> 
>  OK, "It _provides_ group communication services ..."

Please indicate in the ID whether Receive must be blocking or non-blocking
or can be either.
>> p. 19 (4.4.2)
>> - is Receive meant to be non-blocking or blocking?
>> 
>  It's implemented as blocking.

For IRSG review, please note (per RFC 5743, sec 2.1):

   o  There must be a statement in the abstract identifying it as the
      product of the RG.

   o  There must be a paragraph near the beginning (for example, in the
      introduction) describing the level of support for publication.
      Example text might read: "this document represents the consensus
      of the FOOBAR RG" or "the views in this document were considered
      controversial by the FOOBAR RG but the RG reached a consensus that
      the document should still be published".

   o  The breadth of review the document has received must also be
      noted.  For example, was this document read by all the active
      research group members, only three people, or folks who are not
      "in" the RG but are expert in the area?

   o  It must also be very clear throughout the document that it is not
      an IETF product and is not a standard.

Thanks,
John

-----Original Message-----
From: sam-bounces@irtf.org [mailto:sam-bounces@irtf.org] On Behalf Of
Matthias Waehlisch
Sent: Monday, July 16, 2012 4:27 PM
To: sam@irtf.org
Subject: [SAM] New Version Notification for
draft-irtf-samrg-common-api-05.txt (fwd)

Hi folks,

  there is a new version of the Common Mcast API available:

  * http://tools.ietf.org/html/draft-irtf-samrg-common-api-05

  Changes consider the comments of the research group last call, in 
detail:

   1.  Added section "A Note on Explicit Multicast (XCAST)"

   2.  Added section "MTU Handling"

   3.  Added socket option getAtomicMSgSize

   4.  Added service call getMaxMsgSize

  Feedback is welcome!

Cheers
  matthias

-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net

---------- Forwarded message ----------
Date: Mon, 16 Jul 2012 13:23:09 -0700
From: internet-drafts@ietf.org
To: mw@link-lab.net
Cc: schmidt@informatik.haw-hamburg.de, stig@cisco.com
Subject: New Version Notification for draft-irtf-samrg-common-api-05.txt

A new version of I-D, draft-irtf-samrg-common-api-05.txt
has been successfully submitted by Matthias Waehlisch and posted to the
IETF repository.

Filename:	 draft-irtf-samrg-common-api
Revision:	 05
Title:		 A Common API for Transparent Hybrid Multicast
Creation date:	 2012-07-16
WG ID:		 Individual Submission
Number of pages: 39
URL:
http://www.ietf.org/internet-drafts/draft-irtf-samrg-common-api-05.txt
Status:          http://datatracker.ietf.org/doc/draft-irtf-samrg-common-api
Htmlized:        http://tools.ietf.org/html/draft-irtf-samrg-common-api-05
Diff:
http://tools.ietf.org/rfcdiff?url2=draft-irtf-samrg-common-api-05

Abstract:
   Group communication services exist in a large variety of flavors, and
   technical implementations at different protocol layers.  Multicast
   data distribution is most efficiently performed on the lowest
   available layer, but a heterogeneous deployment status of multicast
   technologies throughout the Internet requires an adaptive service
   binding at runtime.  Today, it is difficult to write an application
   that runs everywhere and at the same time makes use of the most
   efficient multicast service available in the network.  Facing
   robustness requirements, developers are frequently forced to use a
   stable, upper layer protocol provided by the application itself.
   This document describes a common multicast API that is suitable for
   transparent communication in underlay and overlay, and grants access
   to the different multicast flavors.  It proposes an abstract naming
   by multicast URIs and discusses mapping mechanisms between different
   namespaces and distribution technologies.  Additionally, it describes
   the application of this API for building gateways that interconnect
   current multicast domains throughout the Internet.

The IETF Secretariat
_______________________________________________
SAM mailing list
SAM@irtf.org
http://www.irtf.org/mailman/listinfo/sam