[SAM] sam-baseline-protocol-00

"John Buford" <buford@samrg.org> Wed, 18 July 2012 07:47 UTC

Return-Path: <buford@samrg.org>
X-Original-To: sam@ietfa.amsl.com
Delivered-To: sam@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E83A721F86DA for <sam@ietfa.amsl.com>; Wed, 18 Jul 2012 00:47:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.495
X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id D1RXtbHIaOpm for <sam@ietfa.amsl.com>; Wed, 18 Jul 2012 00:47:21 -0700 (PDT)
Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id E775021F86B1 for <sam@irtf.org>; Wed, 18 Jul 2012 00:47:20 -0700 (PDT)
Received: (qmail 31791 invoked by uid 0); 18 Jul 2012 07:48:10 -0000
Received: from unknown (HELO host181.hostmonster.com) ( by oproxy9.bluehost.com with SMTP; 18 Jul 2012 07:48:10 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=samrg.org; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=5azL9iDyUh4L0qkhTVoEyd/TUYkD9RLjsZ3pB+r0YdM=; b=ngICvjJyQ3RXd183+dh0MPoZ4Utdc38TUtPyaX5ZNRgTNPKHgELTMjqm7FAIQiqoEHi5G2LDvHIw8n6Qh2uvHjekxeERRtfeTvzVun3OYMaErjKuraxC4Z02LgSBVYHn;
Received: from [] (port=4784 helo=AGILON) by host181.hostmonster.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.76) (envelope-from <buford@samrg.org>) id 1SrOzR-0002y8-Pd; Wed, 18 Jul 2012 01:48:09 -0600
From: "John Buford" <buford@samrg.org>
To: "'Eggert, Lars'" <lars@netapp.com>
References: <Pine.WNT.4.64.1207162224420.9044@mw-PC> <BC314931-8A87-460A-BCA8-A136641A4608@netapp.com>
In-Reply-To: <BC314931-8A87-460A-BCA8-A136641A4608@netapp.com>
Date: Wed, 18 Jul 2012 03:48:08 -0400
Message-ID: <055b01cd64b9$ad1fc440$075f4cc0$@org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHNY5FiwgLsrVokwU6M09Jz2N0bhJcto6AAgAEBN2A=
Content-Language: en-us
X-Identified-User: {2055:host181.hostmonster.com:samrgorg:samrg.org} {sentby:smtp auth authed with buford@samrg.org}
Cc: sam@irtf.org
Subject: [SAM] sam-baseline-protocol-00
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: Wed, 18 Jul 2012 07:47:22 -0000

We're using the experimental message codes exp_{a,b}_{req,res} defined in
14.8 of p2psip-base-22
in the baseline draft presented at Paris (http://www.samrg.org/paris-83/)

However I think when I submitted this draft there was a message from the
submittal tool
that RG items had to be approved by chairs, I don't think I know how do to
do that.


-----Original Message-----
From: sam-bounces@irtf.org [mailto:sam-bounces@irtf.org] On Behalf Of
Eggert, Lars
Sent: Tuesday, July 17, 2012 5:01 AM
To: Matthias Waehlisch
Cc: <sam@irtf.org>
Subject: Re: [SAM] New Version Notification for
draft-irtf-samrg-common-api-05.txt (fwd)


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.


>  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:
> Status:
> Htmlized:        http://tools.ietf.org/html/draft-irtf-samrg-common-api-05
> Diff:
> 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