[SAM] New Version Notification for draft-irtf-samrg-common-api-04.txt (fwd)

Matthias Waehlisch <waehlisch@ieee.org> Fri, 27 January 2012 20:58 UTC

Return-Path: <waehlisch@ieee.org>
X-Original-To: sam@ietfa.amsl.com
Delivered-To: sam@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633C621F8723 for <sam@ietfa.amsl.com>; Fri, 27 Jan 2012 12:58:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.287
X-Spam-Level:
X-Spam-Status: No, score=-104.287 tagged_above=-999 required=5 tests=[AWL=1.163, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDM-jY1UCV9m for <sam@ietfa.amsl.com>; Fri, 27 Jan 2012 12:58:40 -0800 (PST)
Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5EF21F8717 for <sam@irtf.org>; Fri, 27 Jan 2012 12:58:40 -0800 (PST)
Envelope-to: sam@irtf.org
Received: from e178058053.adsl.alicedsl.de ([85.178.58.53] helo=mw-PC.fritz.box) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from <waehlisch@ieee.org>) id 1RqssY-0002dH-H6 for sam@irtf.org; Fri, 27 Jan 2012 21:58:38 +0100
Date: Fri, 27 Jan 2012 21:58:41 +0100
From: Matthias Waehlisch <waehlisch@ieee.org>
To: sam <sam@irtf.org>
Message-ID: <Pine.WNT.4.64.1201272155260.5908@mw-PC>
X-X-Sender: mw@mail2.rz.fhtw-berlin.de
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de)
X-HTW-DELIVERED-TO: sam@irtf.org
Subject: [SAM] New Version Notification for draft-irtf-samrg-common-api-04.txt (fwd)
X-BeenThere: sam@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" <sam.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/sam>, <mailto:sam-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/sam>
List-Post: <mailto:sam@irtf.org>
List-Help: <mailto:sam-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/sam>, <mailto:sam-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Jan 2012 20:58:41 -0000

Hi folks,

  according to comments and as discussed in the last meeting, we did the 
following changes:

   1.  Added section "Illustrative Example"
   2.  Added section "Implementation"
   3.  Minor clarifications


  We think the draft is ready for last call, now.


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: Fri, 27 Jan 2012 12:55:10 -0800
From: internet-drafts@ietf.org
To: mw@link-lab.net
Cc: schmidt@informatik.haw-hamburg.de, mw@link-lab.net, stig@cisco.com
Subject: New Version Notification for draft-irtf-samrg-common-api-04.txt

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

Filename:	 draft-irtf-samrg-common-api
Revision:	 04
Title:		 A Common API for Transparent Hybrid Multicast
Creation date:	 2012-01-27
WG ID:		 Individual Submission
Number of pages: 37

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