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

"Eggert, Lars" <lars@netapp.com> Tue, 17 July 2012 09:00 UTC

Return-Path: <lars@netapp.com>
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 A20A321F867A for <sam@ietfa.amsl.com>; Tue, 17 Jul 2012 02:00:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.047
X-Spam-Level:
X-Spam-Status: No, score=-10.047 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_RAND_LETTRS4=0.799]
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 JJHL-8yXrfIG for <sam@ietfa.amsl.com>; Tue, 17 Jul 2012 02:00:29 -0700 (PDT)
Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDAC21F8678 for <sam@irtf.org>; Tue, 17 Jul 2012 02:00:29 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.77,599,1336374000"; d="p7s'?scan'208"; a="666301220"
Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 17 Jul 2012 02:01:14 -0700
Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q6H91CBO027092; Tue, 17 Jul 2012 02:01:13 -0700 (PDT)
Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.13]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0298.004; Tue, 17 Jul 2012 02:01:12 -0700
From: "Eggert, Lars" <lars@netapp.com>
To: Matthias Waehlisch <waehlisch@ieee.org>
Thread-Topic: [SAM] New Version Notification for draft-irtf-samrg-common-api-05.txt (fwd)
Thread-Index: AQHNY5FiwgLsrVokwU6M09Jz2N0bhJcto6AA
Date: Tue, 17 Jul 2012 09:01:10 +0000
Message-ID: <BC314931-8A87-460A-BCA8-A136641A4608@netapp.com>
References: <Pine.WNT.4.64.1207162224420.9044@mw-PC>
In-Reply-To: <Pine.WNT.4.64.1207162224420.9044@mw-PC>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.106.53.51]
Content-Type: multipart/signed; boundary="Apple-Mail=_1EC7AF03-BE1B-404A-941A-F7AE0194DBB2"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Cc: "<sam@irtf.org>" <sam@irtf.org>
Subject: Re: [SAM] New Version Notification for draft-irtf-samrg-common-api-05.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: Tue, 17 Jul 2012 09:00:30 -0000

Hi,

On Jul 16, 2012, at 22:27, Matthias Waehlisch wrote:
>  there is a new version of the Common Mcast API available:
>  * http://tools.ietf.org/html/draft-irtf-samrg-common-api-05

are these all the outstanding changes? In other words, is this document ready for IRSG review?

I also note that draft-samrg-sam-baseline-protocol-00 (still) has IANA issues. RELOAD message codes can only be registered via an IETF Standards Action (see draft-ietf-p2psip-base-22). An IRTF-stream document thus cannot register these codes. In my view, this means that draft-samrg-sam-baseline-protocol needs to move over to the IETF.

Thanks,
Lars

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