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

"John Buford" <buford@samrg.org> Mon, 27 February 2012 19:02 UTC

Return-Path: <buford@samrg.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 DB11C21F87E1 for <sam@ietfa.amsl.com>; Mon, 27 Feb 2012 11:02:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.282
X-Spam-Level:
X-Spam-Status: No, score=-97.282 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 1MAg8wvVtCC2 for <sam@ietfa.amsl.com>; Mon, 27 Feb 2012 11:02:48 -0800 (PST)
Received: from oproxy4-pub.bluehost.com (oproxy4.bluehost.com [IPv6:2605:dc00:100:2::a4]) by ietfa.amsl.com (Postfix) with SMTP id 29D3421F87DD for <sam@irtf.org>; Mon, 27 Feb 2012 11:02:47 -0800 (PST)
Received: (qmail 8831 invoked by uid 0); 27 Feb 2012 19:02:46 -0000
Received: from unknown (HELO host181.hostmonster.com) (74.220.207.181) by cpoproxy1.bluehost.com with SMTP; 27 Feb 2012 19:02:46 -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=EA39DZYtOR7noo2gf+ETmH4MQxhfu51OltN3InOkxCg=; b=SByimBw3QhntnWe6/tgk9UXIN7r83YQ1J7SlKVvCLuE/M9AgM0SiX9MCBGvYqTM1SwEcCo5Rg8TmHY32gLqiTVO5Yx65XiM4m8QIObL+1RnfQBvzifX20NKeN5yDZYsg;
Received: from pool-98-110-40-196.cmdnnj.fios.verizon.net ([98.110.40.196] helo=AGILON) by host181.hostmonster.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.76) (envelope-from <buford@samrg.org>) id 1S25qQ-0000FY-1v; Mon, 27 Feb 2012 12:02:46 -0700
From: "John Buford" <buford@samrg.org>
To: <sam@irtf.org>
References: <C6BFDD26-69C7-4ABF-8871-13FFA5C342A0@samrg.org>
In-Reply-To: <C6BFDD26-69C7-4ABF-8871-13FFA5C342A0@samrg.org>
Date: Mon, 27 Feb 2012 14:02:58 -0500
Message-ID: <00eb01ccf582$6ee3acb0$4cab0610$@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: Aczk76X8qwoIy3w9RvqOSoy4AZH3rAQgyFaQ
Content-Language: en-us
X-Identified-User: {2055:host181.hostmonster.com:samrgorg:samrg.org} {sentby:smtp auth 98.110.40.196 authed with buford@samrg.org}
Subject: Re: [SAM] RG last call for draft-irtf-samrg-common-api-04
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: Mon, 27 Feb 2012 19:02:49 -0000

Following comments with my RG chair hat off.

Document is well written, design is good.  Great to see implementation work
accompanying the ID.
AFAIK, available multicast APIs are technology specific.  Perhaps this point
should be made in the document.

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)?
- is the application responsible for selecting group names and determining
uniqueness?

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

p. 12, 15

   is "sips" a possible scheme?

p. 10 "It group communication services ..."  ?

p. 19 (4.4.2) 
- is Receive meant to be non-blocking or blocking?
- Can the application receive an event when data is available to receive?


- How do you see an application implementing multi-resolution multicast with
this?

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

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

- msg assembly/disassembly handled by the middleware for messages too large
to send in one multicast packet?



-----Original Message-----
From: John Buford [mailto:buford@samrg.org] 
Sent: Monday, February 06, 2012 11:52 AM
To: sam@irtf.org
Cc: buford@samrg.org
Subject: RG last call for draft-irtf-samrg-common-api-04


This is to initiate a last call for the Common API document.

The document and related implementation work have been presented at multiple
RG meetings.

Comments from the RG are requested to progress this document along the RFC
path.

Please review the document and provide your comments by Feb. 24.

ID URL: http://datatracker.ietf.org/doc/draft-irtf-samrg-common-API

Thanks,

John