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

From: Matthias Waehlisch <[email-masked]>
Date: Mon, 16 Jul 2012 22:27:22 +0200

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:[email-masked] .. 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: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked]
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

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 17 Jul 2012 09:01:10 +0000

Hi,

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

> _______________________________________________
> SAM mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/sam

---

From: Matthias Waehlisch <[email-masked]>
Date: Tue, 17 Jul 2012 11:39:07 +0200

Hi Lars,

> document ready for IRSG review?
  arg, partially: As there is a thorough implementation of the API, I 
would like to change the status of the draft from "informational" to 
"experimental". This change I missed in version 05 :( but would like to 
make.

Thanks
  matthias

---

From: "John Buford" <[email-masked]>
Date: Wed, 18 Jul 2012 03:48:08 -0400

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.

John

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

Hi,

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

> .  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST .  
> Takustr. 9, D-14195 Berlin, Germany .. mailto:[email-masked] .. 
> http://www.inf.fu-berlin.de/~waehl
> has been successfully submitted by Matthias Waehlisch and posted to 
> the IETF repository.
> 
> 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
> Diff:
http://tools.ietf.org/rfcdiff?url2=draft-irtf-samrg-common-api-05

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 18 Jul 2012 09:43:28 +0000

Hi,

> in the baseline draft presented at Paris (http://www.samrg.org/paris-83/)

Section 14 of the baseline protocol lists 13 message codes, whereas Section 14.8 defines the four experimental message codes you list above. How are you mapping the 13 to the 4? Also, the values in the baseline protocol are different from the ones in p2psip-base-22.

> that RG items had to be approved by chairs, I don't think I know how do to

Try again and send me the error message, please.

Lars

---

From: [email-masked]
Date: Wed, 18 Jul 2012 07:24:24 -0600

Here is the table in the March draft, section 15:

       +-------------------------+------------------+------------------+
       | Message                 |RELOAD Code Point | ALM Message Code |
       +-------------------------+------------------+------------------+
       | CreateALMTRee           | 35               | 00               |
       +-------------------------+------------------+------------------+
       | CreateALMTreeResponse   | 36               | 01               |
       +-------------------------+------------------+------------------+
       | Join                    | 36               | 02               |
       +-------------------------+------------------+------------------+
       | JoinAccept              | 36               | 03               |
       +-------------------------+------------------+------------------+
       | JoinReject              | 36               | 04               |
       +-------------------------+------------------+------------------+
       | JoinConfirm             | 36               | 05               |
       +-------------------------+------------------+------------------+
       | JoinDecline             | 36               | 06               |
       +-------------------------+------------------+------------------+
       | Leave                   | 36               | 07               |
       +-------------------------+------------------+------------------+
       | LeaveResponse           | 36               | 08               |
       +-------------------------+------------------+------------------+
       | Reform                  | 36               | 09               |
       +-------------------------+------------------+------------------+
       | ReformResponse          | 36               | x0A              |
       +-------------------------+------------------+------------------+
       | Heartbeat               | 36               | x0B              |
       +-------------------------+------------------+------------------+
       | Push                    | 36               | x0C              |
       +-------------------------+------------------+------------------+
       | PushResponse            | 36               | x0D              |
       +-------------------------+------------------+------------------+

That is, we are using RELOAD exp_a_req and exp_a_ans for all cases.
So the RELOAD message code will be either 35 or 36.
Inside the RELOAD message body will be one of the ALM message codes.

I will resubmit the draft and let you know the specific message.

John

> Section 14 of the baseline protocol lists 13 message codes, whereas
> Section 14.8 defines the four experimental message codes you list above.
> How are you mapping the 13 to the 4? Also, the values in the baseline
> protocol are different from the ones in p2psip-base-22.
>

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 18 Jul 2012 14:44:51 +0000

Hi,

> Here is the table in the March draft, section 15:
...
> That is, we are using RELOAD exp_a_req and exp_a_ans for all cases.

OK, good. (Since the draft isn't available, it was kinda hard for me to see this table :-)

> I will resubmit the draft and let you know the specific message.

Great, thanks. We do need to wrap this up.

Lars

---

From: "John Buford" <[email-masked]>
Date: Mon, 30 Jul 2012 14:33:59 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Matthias Waehlisch
Sent: Monday, July 16, 2012 4:27 PM
To: [email-masked]
Subject: [SAM] New Version Notification for
draft-irtf-samrg-common-api-05.txt (fwd)

Hi folks,

  Feedback is welcome!

Cheers
  matthias

---------- Forwarded message ----------
Date: Mon, 16 Jul 2012 13:23:09 -0700
From: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: New Version Notification for draft-irtf-samrg-common-api-05.txt

Abstract:

The IETF Secretariat

---

From: Matthias Waehlisch <[email-masked]>
Date: Mon, 30 Jul 2012 23:46:31 -0700 (Pacific Sommerzeit)

Hi John,

On Mon, 30 Jul 2012, John Buford wrote:

> Can you indicate in the document whether "sips:" URI scheme is 
> supported or not.
> 
  I'm not really in favor of this due to two reasons. (1) The API spec 
mentions just some example schemes. There is no claim for completeness. 
(2) SIPS is explicitly a point-to-point protocol. Thus, if we add SIPS 
we have to add a side note how this fits into multicast.

> Please indicate in the ID whether Receive must be blocking or 
> non-blocking or can be either.
>
  OK, it can either.

Thanks
  matthias