From nobody Tue Nov 1 08:32:12 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F56129A73 for ; Tue, 1 Nov 2016 08:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgtBRlNu5zfS for ; Tue, 1 Nov 2016 08:32:08 -0700 (PDT) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59BAF129565 for ; Tue, 1 Nov 2016 08:32:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=7oXd4rP7KKcF69gSZN68w31C0z/Uy225MeC1AJJKkBo=; b=r5J/7kW15e0qpt5YYtA8mKXyD/ rUCEqr0RPkjFOcmvY5GZcCglsKLR8KUdx8Hf8M5nLfW/ZyToEKfaS/KBIjdnVfOI5aAXXGmi/f2yP UCwh6guZa/j0uL3QBH0NHzifPXaplIMs/9oilt4FBQ1NnFPoyT4kLJY5YZAVp2TvtqGciKed2iMd1 5rHQE5GFvDeVSTlzuAz1RF3rm5OW7GVCr+K5cCAjEpLBl9ZrF6xDn0ARtWbhonA4fUo441P/Go2J+ ZhdNG+IwqB090ELhpokUpvo/txFMyEZRd5iPmNY7DgQpz4Cuq4tUCNdcxyIJjrK7bH5NFK4/z9c/H LpXo8nRA==; Received: from ip-90-186-159-254.web.vodafone.de ([90.186.159.254]:62338 helo=[192.168.8.102]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1c1b2e-001piB-Tm; Wed, 02 Nov 2016 02:32:01 +1100 To: "Duckworth, Mark" , Paul Kyzivat , "clue@ietf.org" References: <147733415926.15467.2006430670314279492.idtracker@ietfa.amsl.com> <618bed9d-5983-96a5-62b4-0c1577e04dcd@alum.mit.edu> <7d5da6f6-cc79-d9c4-48ab-2d39c289470a@alum.mit.edu> From: Christian Groves Message-ID: <3909463c-fa64-f7c9-1660-6ac467f5df5a@nteczone.com> Date: Wed, 2 Nov 2016 02:31:55 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [clue] WGLC for draft-ietf-clue-rtp-mapping-09.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 15:32:10 -0000 Hello Paul, +1 Regards, Christian On 29/10/2016 8:03 AM, Duckworth, Mark wrote: > Okay, for the record, the changes in the -09 version still look good to me. > Mark > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Friday, October 28, 2016 1:51 PM >> To: clue@ietf.org >> Cc: Colin Perkins ; Christian Groves >> ; Duckworth, Mark >> >> Subject: WGLC for draft-ietf-clue-rtp-mapping-09.txt >> >> This announced the start of another WGLC on the rtp-mapping document, >> this time draft-ietf-clue-rtp-mapping-09.txt. >> >> This will be a short one - one week. It will end Friday, November 4. >> >> I especially want to hear from the people who had issues with -08: Mark >> Duckworth, Christian Groves, and Colin Perkins. But not just them. >> Please, everyone who worked on CLUE please respond. This will impact the >> level of support for the document that I can report in the shepherd > writeup. >> See below for more on why I'm calling for wglc *again*. >> >> Thanks, >> Paul >> >> On 10/28/16 1:03 PM, Colin Perkins wrote: >>>> On 28 Oct 2016, at 17:58, Paul Kyzivat wrote: >>>> >>>> On 10/28/16 10:56 AM, Colin Perkins wrote: >>>>> And as I said before, you need to wait for confirmation from that who >> commented that the changes address their concerns. >>>> I checked the email discussion history. After -08 the non-author people >> who commented were me, Mark, and Christian. >>>> Since -09 Mark has confirmed that he is satisfied with it. I am also > satisfied. >> So if we hear from Christian then I think we will be good in this regard. > (I >> presume the authors are ok with this.) >>> I also sent extensive comments on -08 on 7 October, and have yet to have >> chance to review whether they were addressed in -09. >>> Why this rush to publish, without giving the working group chance to >> review? You should be issuing a new working group last call, since there > were >> substantive technical comments on the last version. >> >> My impression is that people are tired of this and want it over. And >> there seem to be only a small set of participants at this time. >> >> But, since you have asked, I'm hereby doing so. >> >> Thanks, >> Paul >> >> From nobody Tue Nov 1 10:46:28 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A110A1295F6 for ; Tue, 1 Nov 2016 10:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQYCDV2YdyoD for ; Tue, 1 Nov 2016 10:46:23 -0700 (PDT) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35D2C1279EB for ; Tue, 1 Nov 2016 10:46:23 -0700 (PDT) X-ASG-Debug-ID: 1478022376-05f275518ba0ef0001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id 4Ce571Bk1aGSfzZO (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Tue, 01 Nov 2016 18:46:16 +0100 (CET) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from simons-mbp-2.fritz.box ([151.70.132.75]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id uA1HkEvV006022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Nov 2016 18:46:15 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_4E888FFC-A679-45CC-A7AE-13EB0DEF45BD" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] I-D Action: draft-ietf-clue-protocol-09.txt In-Reply-To: Date: Tue, 1 Nov 2016 18:46:14 +0100 Message-Id: References: <147109006060.15052.2923637511144053272.idtracker@ietfa.amsl.com> To: Paul Kyzivat X-Mailer: Apple Mail (2.3124) X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1478022376 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi Received-SPF: softfail (unina.it: domain of transitioning spromano@unina.it does not designate 151.70.132.75 as permitted sender) X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO, BSF_SPF_SOFTFAIL, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.34192 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_SPF_SOFTFAIL Custom Rule SPF Softfail Archived-At: Cc: clue@ietf.org Subject: Re: [clue] I-D Action: draft-ietf-clue-protocol-09.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 17:46:26 -0000 --Apple-Mail=_4E888FFC-A679-45CC-A7AE-13EB0DEF45BD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello Paul, I prepared the revised version of the document, which includes (among = other minor modifications/fixes) the corrections you suggested. I will = officially upload it as soon as as the submission tool re-opens = (beginning of Seoul=92s meeting on the 14th). In the meanwhile, I would = encourage you all to take a look at version -10 and provide us with = further feedbacks/corrections to be included in the official submission. = You can access it here: = http://wpage.unina.it/spromano/CLUE/Protocol/draft-ietf-clue-protocol-10.t= xt = Thanks a lot and sorry about the delay in finalizing the document. Cheers, Simon _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it = <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ > On 19 Aug 2016, at 20:53, Paul Kyzivat wrote: >=20 > I'm just doing a final check as part of my shepherd writeup. >=20 > I have a couple of loose ends to clear up: >=20 > In section 5 there is a mention of response code 401. But because of = renumbering of response codes that should now be 402. >=20 > In section 9 (Schema) the version is set to 0.7. Is it intended that = it be published with that value? Or is the intent to set the version to = 1.0 for publication? If so, it needs to happen soon, and AUTH48 is = probably too late. >=20 > Thanks, > Paul >=20 > On 8/13/16 8:07 AM, internet-drafts@ietf.org wrote: >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the ControLling mUltiple streams for = tElepresence of the IETF. >>=20 >> Title : CLUE protocol >> Authors : Roberta Presta >> Simon Pietro Romano >> Filename : draft-ietf-clue-protocol-09.txt >> Pages : 56 >> Date : 2016-08-13 >>=20 >> Abstract: >> The CLUE protocol is an application protocol conceived for the >> description and negotiation of a telepresence session. The design = of >> the CLUE protocol takes into account the requirements and the >> framework defined within the IETF CLUE working group. A companion >> document delves into CLUE signaling details, as well as on the SIP/ >> SDP session establishment phase. CLUE messages flow upon the CLUE >> data channel, based on reliable and ordered SCTP over DTLS = transport. >> Message details, together with the behavior of CLUE Participants >> acting as Media Providers and/or Media Consumers, are herein >> discussed. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-clue-protocol-09 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-protocol-09 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >>=20 >=20 >=20 --Apple-Mail=_4E888FFC-A679-45CC-A7AE-13EB0DEF45BD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hello Paul,

I prepared the revised version of the document, which = includes (among other minor modifications/fixes) the corrections you = suggested. I will officially upload it as soon as as the submission tool = re-opens (beginning of Seoul=92s meeting on the 14th). In the meanwhile, = I would encourage you all to take a look at version -10 and provide us = with further feedbacks/corrections to be included in the official = submission. You can access it here:

http://wpage.unina.it/spromano/CLUE/Protocol/draft-ietf-clue-pr= otocol-10.txt

Thanks a lot and sorry about the delay in finalizing the = document.

Cheers,

Simon


          =             =   _\\|//_
      =                     =   = ( O-O )
      = ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
  =                 =    = Simon Pietro Romano
    =            Universita' di = Napoli Federico II
        =               Computer Engineering = Department 
           =   Phone: +39 081 7683823 -- Fax: +39 081 7683816
                =                     =        e-mail: spromano@unina.it

    <<Molti mi = dicono che lo scoraggiamento =E8 l'alibi degli 
=     idioti. Ci rifletto un istante; e mi = scoraggio>>. Magritte.
      =                 =                oooO
       ~~~~~~~~~~~~~~~~~~~~~~~( =   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=               =    \ (            (   = )
=               =                   =   \_)          ) /
                =                     =                     =               =  (_/



On 19 Aug 2016, at 20:53, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

I'm = just doing a final check as part of my shepherd writeup.
I have a couple of loose ends to clear up:

In section 5 there is a mention of response code 401. But = because of renumbering of response codes that should now be 402.

In section 9 (Schema) the version is set to = 0.7. Is it intended that it be published with that value? Or is the = intent to set the version to 1.0 for publication? If so, it needs to = happen soon, and AUTH48 is probably too late.

= Thanks,
Paul

On 8/13/16 8:07 AM, internet-drafts@ietf.org wrote:

A New Internet-Draft is = available from the on-line Internet-Drafts directories.
This= draft is a work item of the ControLling mUltiple streams for = tElepresence of the IETF.

=        Title =           : CLUE = protocol
=        Authors =         : Roberta Presta
=             &n= bsp;           &nbs= p;Simon Pietro Romano
Filename =        : = draft-ietf-clue-protocol-09.txt
Pages =           : 56
= Date =            : = 2016-08-13

Abstract:
=   The CLUE protocol is an application protocol conceived for = the
  description and negotiation of a = telepresence session.  The design of
  the = CLUE protocol takes into account the requirements and the
=   framework defined within the IETF CLUE working group. =  A companion
  document delves into CLUE = signaling details, as well as on the SIP/
  SDP = session establishment phase.  CLUE messages flow upon the CLUE
  data channel, based on reliable and ordered SCTP = over DTLS transport.
  Message details, = together with the behavior of CLUE Participants
=   acting as Media Providers and/or Media Consumers, are = herein
  discussed.


The IETF datatracker status page for this = draft is:
https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/<= br class=3D"">
There's also a htmlized version available = at:
https://tools.ietf.org/html/draft-ietf-clue-protocol-09

A diff from the previous version is available = at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-protocol-09=


Please note that it may = take a couple of minutes from the time of submission
until = the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by = anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue




= --Apple-Mail=_4E888FFC-A679-45CC-A7AE-13EB0DEF45BD-- From nobody Tue Nov 1 12:26:04 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE4912996A for ; Tue, 1 Nov 2016 12:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEl_7dvVqYBo for ; Tue, 1 Nov 2016 12:26:01 -0700 (PDT) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4625F12996F for ; Tue, 1 Nov 2016 12:26:01 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-02v.sys.comcast.net with SMTP id 1egPctFLb0MKR1eh6c9Hlz; Tue, 01 Nov 2016 19:26:00 +0000 Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-19v.sys.comcast.net with SMTP id 1eh5c9z4kcP8w1eh5c8Jhw; Tue, 01 Nov 2016 19:26:00 +0000 To: Simon Pietro Romano References: <147109006060.15052.2923637511144053272.idtracker@ietfa.amsl.com> From: Paul Kyzivat Message-ID: <3d97ce49-6ade-6da2-0757-e16bf05352c7@alum.mit.edu> Date: Tue, 1 Nov 2016 15:25:59 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfDtQWpbNBXQNF4K+KgpSdgG7yrQUUQdLJYY2/2fJKM4hgijBeYAA1LkAw1egghVEJ39pKYamsytHn217wIwSfovvxTHYgHk0FCCBJKMGuPlk2lJ++d5H 2iFpzGQcc/+OM9LKXuXERFAFQ51gRRSXb2bWxNk883wzmsdAb1ulzXDfKCgaudoP+rWWmXphsy5r9/FJtcguXzwVXztVxgBDplOmCjGd1Cu6Xb1BsI9UV4c+ Archived-At: Cc: clue@ietf.org Subject: Re: [clue] I-D Action: draft-ietf-clue-protocol-09.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 19:26:02 -0000 Simon and all CLUE participants: On 11/1/16 1:46 PM, Simon Pietro Romano wrote: > Hello Paul, > > I prepared the revised version of the document, which includes (among > other minor modifications/fixes) the corrections you suggested. I will > officially upload it as soon as as the submission tool re-opens > (beginning of Seouls meeting on the 14th). In the meanwhile, I would > encourage you all to take a look at version -10 and provide us with > further feedbacks/corrections to be included in the official submission. > You can access it here: > > http://wpage.unina.it/spromano/CLUE/Protocol/draft-ietf-clue-protocol-10.txt Thanks Simon. I will review it. Its unfortunate that the blackout applies even to WGs that aren't meeting. It slows down our ability to act on it. Others: please review and comment on this. It is our final document. We are close to wrapping up if we can get consensus. Thanks, Paul > Thanks a lot and sorry about the delay in finalizing the document. > > Cheers, > > Simon > > > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Engineering Department > Phone: +39 081 7683823 -- Fax: +39 081 7683816 > e-mail: spromano@unina.it > > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > > >> On 19 Aug 2016, at 20:53, Paul Kyzivat > > wrote: >> >> I'm just doing a final check as part of my shepherd writeup. >> >> I have a couple of loose ends to clear up: >> >> In section 5 there is a mention of response code 401. But because of >> renumbering of response codes that should now be 402. >> >> In section 9 (Schema) the version is set to 0.7. Is it intended that >> it be published with that value? Or is the intent to set the version >> to 1.0 for publication? If so, it needs to happen soon, and AUTH48 is >> probably too late. >> >> Thanks, >> Paul >> >> On 8/13/16 8:07 AM, internet-drafts@ietf.org >> wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the ControLling mUltiple streams for >>> tElepresence of the IETF. >>> >>> Title : CLUE protocol >>> Authors : Roberta Presta >>> Simon Pietro Romano >>> Filename : draft-ietf-clue-protocol-09.txt >>> Pages : 56 >>> Date : 2016-08-13 >>> >>> Abstract: >>> The CLUE protocol is an application protocol conceived for the >>> description and negotiation of a telepresence session. The design of >>> the CLUE protocol takes into account the requirements and the >>> framework defined within the IETF CLUE working group. A companion >>> document delves into CLUE signaling details, as well as on the SIP/ >>> SDP session establishment phase. CLUE messages flow upon the CLUE >>> data channel, based on reliable and ordered SCTP over DTLS transport. >>> Message details, together with the behavior of CLUE Participants >>> acting as Media Providers and/or Media Consumers, are herein >>> discussed. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/ >>> >>> There's also a htmlized version available at: >>> https://tools.ietf.org/html/draft-ietf-clue-protocol-09 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-protocol-09 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> > From nobody Tue Nov 1 13:04:13 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E192A1299B0 for ; Tue, 1 Nov 2016 13:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.698 X-Spam-Level: X-Spam-Status: No, score=-5.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yaNrt_VIFmO for ; Tue, 1 Nov 2016 13:04:10 -0700 (PDT) Received: from alum-mailsec-scanner-5.mit.edu (alum-mailsec-scanner-5.mit.edu [18.7.68.17]) by ietfa.amsl.com (Postfix) with ESMTP id A42361299B9 for ; Tue, 1 Nov 2016 13:04:10 -0700 (PDT) X-AuditID: 12074411-ff5ff700000008d0-32-5818f539efe9 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 20.5F.02256.935F8185; Tue, 1 Nov 2016 16:04:09 -0400 (EDT) Received: from [192.168.1.110] (c-73-186-127-100.hsd1.ma.comcast.net [73.186.127.100]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id uA1K48SS001128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 1 Nov 2016 16:04:09 -0400 To: clue@ietf.org References: <147109006060.15052.2923637511144053272.idtracker@ietfa.amsl.com> <3d97ce49-6ade-6da2-0757-e16bf05352c7@alum.mit.edu> From: Paul Kyzivat Message-ID: Date: Tue, 1 Nov 2016 16:04:08 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <3d97ce49-6ade-6da2-0757-e16bf05352c7@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsUixO6iqGv5VSLC4N4FbYv9py4zOzB6LFny kymAMYrLJiU1J7MstUjfLoEr483ZH+wFLToVzQ83sjcwzlLsYuTkkBAwkdjwaRpzFyMXh5DA ZUaJGWd+sUA4r5gkluxdxw5SJSygItFz7DlTFyMHh4iAoMTLK4IgYSGB14wSB5a5gdhsAloS cw79ZwGxeQXsJW58+ALWygLUOm/yLjYQW1QgTWL7ut3MEDWCEidnPgGr5xRwkNh+cRNYnFnA VuLO3N1QtrxE89bZzBMY+WYhaZmFpGwWkrIFjMyrGOUSc0pzdXMTM3OKU5N1i5MT8/JSi3RN 9XIzS/RSU0o3MUKCTHAH44yTcocYBTgYlXh4JyyRiBBiTSwrrsw9xCjJwaQkyrv8PVCILyk/ pTIjsTgjvqg0J7X4EKMEB7OSCK/AF6Acb0piZVVqUT5MSpqDRUmcl2+Jup+QQHpiSWp2ampB ahFMVoaDQ0mCtwmkUbAoNT21Ii0zpwQhzcTBCTKcB2h4Adjw4oLE3OLMdIj8KUZFKXFeR5CE AEgiozQPrheWBF4xigO9IgzRzgNMIHDdr4AGMwENNk8CG1ySiJCSamCUlDQWMV9oulJIduu7 5d4Zn6/JeZ73OF3BPOFk56wge8aoaV8ObF2m8aB1wdobxz1Zpq+eHjzn8smT8rHPrEO5z9Vc 8J61ZaXJ7xcV05hZLvDVWixpubij/7fcvJrchTcOfBVyS1VcrbcjV+nv8ZbJd5Z1rlpuIHdl ssq/6r2zXkjc3mcu0PNzgxJLcUaioRZzUXEiAJcpq2vdAgAA Archived-At: Subject: [clue] draft-ietf-clue-protocol-10 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 20:04:13 -0000 CLUEful, I just reviewed the history on this, and the last time we had a WGLC was on -04, more than a year ago. The differences between -10 and -04 are substantial. So we really need to have another WGLC on -10. I think for that to be proper we probably can't have it until -10 is published. However, people certainly can do their reviewing now on this pre-release version and be ready to respond when the WGLC is announced. I will plan to announce the WGLC as soon as -10 is posted, which I assume will be Nov 14. I won't count on everyone being able to review it that week (IETF week), so I'll plan on the WGLC ending on Nov 25. And then, barring any new issues, I will advance the document. Thanks, Paul On 11/1/16 3:25 PM, Paul Kyzivat wrote: > Simon and all CLUE participants: > > On 11/1/16 1:46 PM, Simon Pietro Romano wrote: >> Hello Paul, >> >> I prepared the revised version of the document, which includes (among >> other minor modifications/fixes) the corrections you suggested. I will >> officially upload it as soon as as the submission tool re-opens >> (beginning of Seouls meeting on the 14th). In the meanwhile, I would >> encourage you all to take a look at version -10 and provide us with >> further feedbacks/corrections to be included in the official submission. >> You can access it here: >> >> http://wpage.unina.it/spromano/CLUE/Protocol/draft-ietf-clue-protocol-10.txt >> > > Thanks Simon. I will review it. > > Its unfortunate that the blackout applies even to WGs that aren't > meeting. It slows down our ability to act on it. > > Others: please review and comment on this. It is our final document. We > are close to wrapping up if we can get consensus. > > Thanks, > Paul > >> Thanks a lot and sorry about the delay in finalizing the document. >> >> Cheers, >> >> Simon >> >> >> _\\|//_ >> ( O-O ) >> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >> Simon Pietro Romano >> Universita' di Napoli Federico II >> Computer Engineering Department >> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >> e-mail: spromano@unina.it >> >> >> <> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >> oooO >> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> \ ( ( ) >> \_) ) / >> >> (_/ >> >> >> >>> On 19 Aug 2016, at 20:53, Paul Kyzivat >> > wrote: >>> >>> I'm just doing a final check as part of my shepherd writeup. >>> >>> I have a couple of loose ends to clear up: >>> >>> In section 5 there is a mention of response code 401. But because of >>> renumbering of response codes that should now be 402. >>> >>> In section 9 (Schema) the version is set to 0.7. Is it intended that >>> it be published with that value? Or is the intent to set the version >>> to 1.0 for publication? If so, it needs to happen soon, and AUTH48 is >>> probably too late. >>> >>> Thanks, >>> Paul >>> >>> On 8/13/16 8:07 AM, internet-drafts@ietf.org >>> wrote: >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the ControLling mUltiple streams for >>>> tElepresence of the IETF. >>>> >>>> Title : CLUE protocol >>>> Authors : Roberta Presta >>>> Simon Pietro Romano >>>> Filename : draft-ietf-clue-protocol-09.txt >>>> Pages : 56 >>>> Date : 2016-08-13 >>>> >>>> Abstract: >>>> The CLUE protocol is an application protocol conceived for the >>>> description and negotiation of a telepresence session. The design of >>>> the CLUE protocol takes into account the requirements and the >>>> framework defined within the IETF CLUE working group. A companion >>>> document delves into CLUE signaling details, as well as on the SIP/ >>>> SDP session establishment phase. CLUE messages flow upon the CLUE >>>> data channel, based on reliable and ordered SCTP over DTLS transport. >>>> Message details, together with the behavior of CLUE Participants >>>> acting as Media Providers and/or Media Consumers, are herein >>>> discussed. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/ >>>> >>>> There's also a htmlized version available at: >>>> https://tools.ietf.org/html/draft-ietf-clue-protocol-09 >>>> >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-protocol-09 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> >>> >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Tue Nov 1 13:17:10 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77AE31299E4 for ; Tue, 1 Nov 2016 13:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=xzx4uikg; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=UmdhSB+T Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLFk3nMMKXDy for ; Tue, 1 Nov 2016 13:17:06 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1CD91299DF for ; Tue, 1 Nov 2016 13:17:06 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 31BD120384; Tue, 1 Nov 2016 16:17:06 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Tue, 01 Nov 2016 16:17:06 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=So0fpJ9fKh6eeFu XtsHEl8I/OHo=; b=xzx4uikgLu6ev5BXurX97iXLYUgiMvCf51RQmaN9b5TOLyu 0lXX9BZRSj6OKhd4WGgwMN9SWprycMg/BrfWUzWFqzUoWwbXrLv5pgYs6qIWRA9E e0CwsOR2oPyYkHcLhYzBFlT95ZHuGs3ry3IdvQgxCStEY3nf2FNqk8icAVM0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=So0fpJ9fKh6eeFuXtsHEl8I/OHo=; b=UmdhSB+Twmzn5ApiaRJh 4x3+gpVzr3a5wJJvfeSOeLT3dOe82GMy5gWGmIuob+Xt0q/oMtGBM982BAbhox52 4/L3dCxe+v7zN5d0Va4eA5f6cE4iBygh4ZNKFsDTCrRdyjHI+7WGMHvhO1L+uZrr W0ZhmLmC1eiXnIjnmESfrPw= X-ME-Sender: X-Sasl-enc: Ed4jTRbVzqO6Amx4Rz1dIMs6Eci24u03zUVjpbuus55Y 1478031424 Received: from sjc-alcoop-8814.cisco.com (unknown [128.107.241.186]) by mail.messagingengine.com (Postfix) with ESMTPA id 9AF14CCF31; Tue, 1 Nov 2016 16:17:02 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <3d97ce49-6ade-6da2-0757-e16bf05352c7@alum.mit.edu> Date: Tue, 1 Nov 2016 16:17:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <908E0660-DCE1-4EC5-9232-0504D9E53C57@cooperw.in> References: <147109006060.15052.2923637511144053272.idtracker@ietfa.amsl.com> <3d97ce49-6ade-6da2-0757-e16bf05352c7@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3124) Archived-At: Cc: clue@ietf.org Subject: Re: [clue] I-D Action: draft-ietf-clue-protocol-09.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 20:17:08 -0000 > On Nov 1, 2016, at 3:25 PM, Paul Kyzivat = wrote: >=20 > Simon and all CLUE participants: >=20 > On 11/1/16 1:46 PM, Simon Pietro Romano wrote: >> Hello Paul, >>=20 >> I prepared the revised version of the document, which includes (among >> other minor modifications/fixes) the corrections you suggested. I = will >> officially upload it as soon as as the submission tool re-opens >> (beginning of Seoul=92s meeting on the 14th). In the meanwhile, I = would >> encourage you all to take a look at version -10 and provide us with >> further feedbacks/corrections to be included in the official = submission. >> You can access it here: >>=20 >> = http://wpage.unina.it/spromano/CLUE/Protocol/draft-ietf-clue-protocol-10.t= xt >=20 > Thanks Simon. I will review it. >=20 > Its unfortunate that the blackout applies even to WGs that aren't = meeting. It slows down our ability to act on it. I can get this manually posted to the I-D repo if the WG so desires. Alissa >=20 > Others: please review and comment on this. It is our final document. = We are close to wrapping up if we can get consensus. >=20 > Thanks, > Paul >=20 >> Thanks a lot and sorry about the delay in finalizing the document. >>=20 >> Cheers, >>=20 >> Simon >>=20 >>=20 >> _\\|//_ >> ( O-O ) >> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >> Simon Pietro Romano >> Universita' di Napoli Federico II >> Computer Engineering Department >> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >> e-mail: spromano@unina.it >> >>=20 >> <> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >> oooO >> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> \ ( ( ) >> \_) ) / >> = (_/ >>=20 >>=20 >>=20 >>> On 19 Aug 2016, at 20:53, Paul Kyzivat >> > wrote: >>>=20 >>> I'm just doing a final check as part of my shepherd writeup. >>>=20 >>> I have a couple of loose ends to clear up: >>>=20 >>> In section 5 there is a mention of response code 401. But because of >>> renumbering of response codes that should now be 402. >>>=20 >>> In section 9 (Schema) the version is set to 0.7. Is it intended that >>> it be published with that value? Or is the intent to set the version >>> to 1.0 for publication? If so, it needs to happen soon, and AUTH48 = is >>> probably too late. >>>=20 >>> Thanks, >>> Paul >>>=20 >>> On 8/13/16 8:07 AM, internet-drafts@ietf.org >>> wrote: >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the ControLling mUltiple streams for >>>> tElepresence of the IETF. >>>>=20 >>>> Title : CLUE protocol >>>> Authors : Roberta Presta >>>> Simon Pietro Romano >>>> Filename : draft-ietf-clue-protocol-09.txt >>>> Pages : 56 >>>> Date : 2016-08-13 >>>>=20 >>>> Abstract: >>>> The CLUE protocol is an application protocol conceived for the >>>> description and negotiation of a telepresence session. The design = of >>>> the CLUE protocol takes into account the requirements and the >>>> framework defined within the IETF CLUE working group. A companion >>>> document delves into CLUE signaling details, as well as on the = SIP/ >>>> SDP session establishment phase. CLUE messages flow upon the CLUE >>>> data channel, based on reliable and ordered SCTP over DTLS = transport. >>>> Message details, together with the behavior of CLUE Participants >>>> acting as Media Providers and/or Media Consumers, are herein >>>> discussed. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/ >>>>=20 >>>> There's also a htmlized version available at: >>>> https://tools.ietf.org/html/draft-ietf-clue-protocol-09 >>>>=20 >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-protocol-09 >>>>=20 >>>>=20 >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at = tools.ietf.org. >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>>=20 >>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Tue Nov 1 15:06:33 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2E1129A22 for ; Tue, 1 Nov 2016 15:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVx0iznjyuvy for ; Tue, 1 Nov 2016 15:06:31 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 918921298C1 for ; Tue, 1 Nov 2016 15:06:30 -0700 (PDT) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-04v.sys.comcast.net with SMTP id 1hB4cskFN8Pea1hCPcNzEd; Tue, 01 Nov 2016 22:06:29 +0000 Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-02v.sys.comcast.net with SMTP id 1hCOcR74bMhnC1hCOcjHLu; Tue, 01 Nov 2016 22:06:29 +0000 To: Alissa Cooper References: <147109006060.15052.2923637511144053272.idtracker@ietfa.amsl.com> <3d97ce49-6ade-6da2-0757-e16bf05352c7@alum.mit.edu> <908E0660-DCE1-4EC5-9232-0504D9E53C57@cooperw.in> From: Paul Kyzivat Message-ID: <0af7ee02-097d-66c9-92b2-938dd2d2903c@alum.mit.edu> Date: Tue, 1 Nov 2016 18:06:28 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <908E0660-DCE1-4EC5-9232-0504D9E53C57@cooperw.in> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfO8EhFIBkVvkbwpAPjKpb4iwrXlzpGlYbHjS8hO+DUP52xB+sakRH7EjfNbf2iwvzkwZdPzSNf71qvteAidp8WAJYypbtyXy38vd89xCML4T7E/iXilZ D9zgCYYarezHuQf+SbpKsHESmROFO3ttvqjOTYMRlFCNLJJ0N5qLdUdL/7IXQiJWhz1HClze6Fwum20+zdj2PSPBoLmxzUpJtJirB1hHuitPz+5Pc8jRwVV7 Archived-At: Cc: clue@ietf.org Subject: Re: [clue] I-D Action: draft-ietf-clue-protocol-09.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 22:06:32 -0000 Alissa, On 11/1/16 4:17 PM, Alissa Cooper wrote: > I can get this manually posted to the I-D repo if the WG so desires. That would be very helpful. Then I could run a WGLC on it before the upcoming meeting. Thanks, Paul From nobody Wed Nov 2 13:10:05 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0741298A8 for ; Wed, 2 Nov 2016 13:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RINHsYCfsWB1 for ; Wed, 2 Nov 2016 13:10:01 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F9CA12989E for ; Wed, 2 Nov 2016 13:10:01 -0700 (PDT) Received: from [81.187.2.149] (port=32816 helo=[192.168.0.91]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1c21rC-0006n0-Jh; Wed, 02 Nov 2016 20:09:59 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: Date: Wed, 2 Nov 2016 20:09:54 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147733415926.15467.2006430670314279492.idtracker@ietfa.amsl.com> <618bed9d-5983-96a5-62b4-0c1577e04dcd@alum.mit.edu> <7d5da6f6-cc79-d9c4-48ab-2d39c289470a@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: CLUE Subject: Re: [clue] WGLC for draft-ietf-clue-rtp-mapping-09.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 20:10:03 -0000 Paul, I=92m sorry, but I still don=92t think this draft is ready for = publication. I have the following comments: - Section 2: The draft says that the RFC 2119 keywords =93indicate = requirement levels for compliant RTP implementations=94. This is = incorrect. They might indicate requirements for =93compliant CLUE = implementations=94, or perhaps for =93RTP processing in compliant CLUE = implementations=94, but they cannot apply to RTP implementations in = general. - Section 3, 4th and 5th paragraphs: The attempts to briefly summarise = the detailed descriptions from RFC 7667 confuse more than they help. = Since there is nothing CLUE specific here, these paragraphs can be = removed. The first paragraph of Section 3 says that these topologies can = be used with CLUE, which is all that=92s needed.=20 - Section 4, 2nd paragraph, says =93can send each media source in a = separate RTP session identified by the content attribute=94, but the = content attribute does not identify the RTP session, it identifies the = role of that RTP session in the CLUE context. It should perhaps say = something like =93=85in a separate RTP session, with a content attribute = [RFC4796] identifying the CLUE Capture Encoding represented by that RTP = session=94? - Section 4, 2nd paragraph: =93Demultipexing at the media receiver is = straightforward if the multiplexing point is at the UDP transport level, = where each RTP stream uses a separate RTP session=94 =97 it=92s not = clear what is being demultiplexed, since RTP streams don=92t use RTP = sessions. Is the intent to say something like =93Demultiplexing is = straightforward because each media capture is sent as a single RTP = stream, with each RTP stream being sent in a separate RTP session, on a = distinct UDP 5-tuple=94? - Section 4, 2nd paragraph: =93the mapping does not change even if the = RTP session is switched using same or different SSRC=94 =96 what does = this mean? An RTP session doesn=92t have an SSRC; it contains RTP = streams that are identified by SSRC. Accordingly, it doesn=92t make = sense to talk about RTP sessions being switched by SSRC. - Section 4, 3rd paragraph: =93CLUE endpoints that support sending of = several RTP streams in a single or multiple RTP sessions MUST support = [I-D.ietf-mmusic-sdp-bundle-negotiation]=94 =96 I don=92t understand why = BUNDLE would be used with multiple RTP sessions?=20 - Section 4, 3rd paragraph: This is hard to follow in general, and I = suggest trying to reword it. Maybe: =93Each Capture Encoding MUST be = sent as a separate RTP stream. CLUE endpoints MUST support sending each = such RTP stream in a separate RTP session signalled by an SDP m=3D line. = They MAY also support sending all the RTP streams in a single RTP = session, using the mechanism described in = [I-D.ietf-mmusic-sdp-bundle-negotiation] to relate RTP streams to SDP m=3D= lines.=94 - Section 5, 1st paragraph: I suggest changing =93mapping from the MCC = RTP stream to the constituent MC=94 to =93mapping from the SSRC of the = RTP stream conveying a particular MCC to=85=94 to make the layering = clear. - Section 5, 2nd paragraph: Similarly, I suggest changing =93associates = the SSRC of the MCC stream with the captureID=94 to =93associates the = SSRC of the RTP stream conveying a particular MCC with=85=94. - Section 5, 3rd and 5th paragraphs: The CaptureID is not sent in the = RTP Header, it=92s sent in an RTP Header Extension. Similarly, the = CaptureID is not sent in an =93RTCP SDES message=94, it=92s sent in an = =93RTCP CaptureID SDES item=94.=20 - Section 5, 4th paragraph: =93giving source information for these CSRC = values=94 is not quite correct. It would be clearer written =93giving = source information for the SSRC values sent as contributing sources = (CSRCs)=94. - Section 5, 5th paragraph: =93interprets this as meaning any previous = captureID value in this RTP header no longer applies=94 would be more = correct if written =93interprets this as meaning that any previous = CaptureID value associated with this SSRC no longer applies=94.=20 - Section 5.1, last paragraph: =93SDES message=94 -> =93SDES item=94. = Also, SDES items are not =93sent in a compound RTCP packet=94, they=92re = =93sent in an SDES packet within a compound RTCP packet=94.=20 - Section 5.1, last paragraph: Need to explain what happens if = Reduced-size RTCP has been negotiated, possibly by adding =93, in which = case it can be sent as an SDES packet in a non-compound RTCP packet=94 = to the end of the paragraph. - Section 5.2, 2nd paragraph: RFC 7941 requires the URN to be = =93urn:ietf:params:rtp-hdrext:sdes:CaptureID=94 not = =93urn:ietf:params:rtp-hdrext:sdes:CaptureID=94.=20 - Section 5.2: The packet diagrams don=92t match those in RFC 7941. I = suggest that the copy here be removed. Colin > On 28 Oct 2016, at 18:50, Paul Kyzivat wrote: >=20 > This announced the start of another WGLC on the rtp-mapping document, = this time draft-ietf-clue-rtp-mapping-09.txt. >=20 > This will be a short one - one week. It will end Friday, November 4. >=20 > I especially want to hear from the people who had issues with -08: = Mark Duckworth, Christian Groves, and Colin Perkins. But not just them. = Please, everyone who worked on CLUE please respond. This will impact the = level of support for the document that I can report in the shepherd = writeup. >=20 > See below for more on why I'm calling for wglc *again*. >=20 > Thanks, > Paul >=20 > On 10/28/16 1:03 PM, Colin Perkins wrote: >>=20 >>> On 28 Oct 2016, at 17:58, Paul Kyzivat = wrote: >>>=20 >>> On 10/28/16 10:56 AM, Colin Perkins wrote: >>>> And as I said before, you need to wait for confirmation from that = who commented that the changes address their concerns. >>>=20 >>> I checked the email discussion history. After -08 the non-author = people who commented were me, Mark, and Christian. >>>=20 >>> Since -09 Mark has confirmed that he is satisfied with it. I am also = satisfied. So if we hear from Christian then I think we will be good in = this regard. (I presume the authors are ok with this.) >>=20 >> I also sent extensive comments on -08 on 7 October, and have yet to = have chance to review whether they were addressed in -09. >>=20 >> Why this rush to publish, without giving the working group chance to = review? You should be issuing a new working group last call, since there = were substantive technical comments on the last version. >=20 > My impression is that people are tired of this and want it over. And = there seem to be only a small set of participants at this time. >=20 > But, since you have asked, I'm hereby doing so. >=20 > Thanks, > Paul --=20 Colin Perkins https://csperkins.org/ From nobody Wed Nov 2 13:13:02 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57552129951 for ; Wed, 2 Nov 2016 13:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvUlGeBCPEGf for ; Wed, 2 Nov 2016 13:12:47 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEDD01298D9 for ; Wed, 2 Nov 2016 13:12:39 -0700 (PDT) Received: from [81.187.2.149] (port=47657 helo=[192.168.0.91]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1c21tk-0007HV-5S; Wed, 02 Nov 2016 20:12:37 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: Date: Wed, 2 Nov 2016 20:12:34 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147733415926.15467.2006430670314279492.idtracker@ietfa.amsl.com> <618bed9d-5983-96a5-62b4-0c1577e04dcd@alum.mit.edu> <7d5da6f6-cc79-d9c4-48ab-2d39c289470a@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: CLUE Subject: Re: [clue] WGLC for draft-ietf-clue-rtp-mapping-09.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 20:12:51 -0000 > On 2 Nov 2016, at 20:09, Colin Perkins wrote: >=20 > Paul, >=20 > I=92m sorry, but I still don=92t think this draft is ready for = publication. I have the following comments: >=20 > - Section 2: The draft says that the RFC 2119 keywords =93indicate = requirement levels for compliant RTP implementations=94. This is = incorrect. They might indicate requirements for =93compliant CLUE = implementations=94, or perhaps for =93RTP processing in compliant CLUE = implementations=94, but they cannot apply to RTP implementations in = general. >=20 > - Section 3, 4th and 5th paragraphs: The attempts to briefly summarise = the detailed descriptions from RFC 7667 confuse more than they help. = Since there is nothing CLUE specific here, these paragraphs can be = removed. The first paragraph of Section 3 says that these topologies can = be used with CLUE, which is all that=92s needed.=20 >=20 > - Section 4, 2nd paragraph, says =93can send each media source in a = separate RTP session identified by the content attribute=94, but the = content attribute does not identify the RTP session, it identifies the = role of that RTP session in the CLUE context. It should perhaps say = something like =93=85in a separate RTP session, with a content attribute = [RFC4796] identifying the CLUE Capture Encoding represented by that RTP = session=94? >=20 > - Section 4, 2nd paragraph: =93Demultipexing at the media receiver is = straightforward if the multiplexing point is at the UDP transport level, = where each RTP stream uses a separate RTP session=94 =97 it=92s not = clear what is being demultiplexed, since RTP streams don=92t use RTP = sessions. Is the intent to say something like =93Demultiplexing is = straightforward because each media capture is sent as a single RTP = stream, with each RTP stream being sent in a separate RTP session, on a = distinct UDP 5-tuple=94? >=20 > - Section 4, 2nd paragraph: =93the mapping does not change even if the = RTP session is switched using same or different SSRC=94 =96 what does = this mean? An RTP session doesn=92t have an SSRC; it contains RTP = streams that are identified by SSRC. Accordingly, it doesn=92t make = sense to talk about RTP sessions being switched by SSRC. >=20 > - Section 4, 3rd paragraph: =93CLUE endpoints that support sending of = several RTP streams in a single or multiple RTP sessions MUST support = [I-D.ietf-mmusic-sdp-bundle-negotiation]=94 =96 I don=92t understand why = BUNDLE would be used with multiple RTP sessions?=20 >=20 > - Section 4, 3rd paragraph: This is hard to follow in general, and I = suggest trying to reword it. Maybe: =93Each Capture Encoding MUST be = sent as a separate RTP stream. CLUE endpoints MUST support sending each = such RTP stream in a separate RTP session signalled by an SDP m=3D line. = They MAY also support sending all the RTP streams in a single RTP = session, using the mechanism described in = [I-D.ietf-mmusic-sdp-bundle-negotiation] to relate RTP streams to SDP m=3D= lines.=94 >=20 > - Section 5, 1st paragraph: I suggest changing =93mapping from the MCC = RTP stream to the constituent MC=94 to =93mapping from the SSRC of the = RTP stream conveying a particular MCC to=85=94 to make the layering = clear. >=20 > - Section 5, 2nd paragraph: Similarly, I suggest changing =93associates = the SSRC of the MCC stream with the captureID=94 to =93associates the = SSRC of the RTP stream conveying a particular MCC with=85=94. >=20 > - Section 5, 3rd and 5th paragraphs: The CaptureID is not sent in the = RTP Header, it=92s sent in an RTP Header Extension. Similarly, the = CaptureID is not sent in an =93RTCP SDES message=94, it=92s sent in an = =93RTCP CaptureID SDES item=94.=20 >=20 > - Section 5, 4th paragraph: =93giving source information for these = CSRC values=94 is not quite correct. It would be clearer written =93giving= source information for the SSRC values sent as contributing sources = (CSRCs)=94. >=20 > - Section 5, 5th paragraph: =93interprets this as meaning any previous = captureID value in this RTP header no longer applies=94 would be more = correct if written =93interprets this as meaning that any previous = CaptureID value associated with this SSRC no longer applies=94.=20 >=20 > - Section 5.1, last paragraph: =93SDES message=94 -> =93SDES item=94. = Also, SDES items are not =93sent in a compound RTCP packet=94, they=92re = =93sent in an SDES packet within a compound RTCP packet=94.=20 >=20 > - Section 5.1, last paragraph: Need to explain what happens if = Reduced-size RTCP has been negotiated, possibly by adding =93, in which = case it can be sent as an SDES packet in a non-compound RTCP packet=94 = to the end of the paragraph. >=20 > - Section 5.2, 2nd paragraph: RFC 7941 requires the URN to be = =93urn:ietf:params:rtp-hdrext:sdes:CaptureID=94 not = =93urn:ietf:params:rtp-hdrext:sdes:CaptureID=94.=20 This should, of course, read =91not = =93urn:ietf:params:rtp-hdrext:CaptureID=94=92. > - Section 5.2: The packet diagrams don=92t match those in RFC 7941. I = suggest that the copy here be removed. >=20 > Colin >=20 >=20 >=20 >=20 >> On 28 Oct 2016, at 18:50, Paul Kyzivat wrote: >>=20 >> This announced the start of another WGLC on the rtp-mapping document, = this time draft-ietf-clue-rtp-mapping-09.txt. >>=20 >> This will be a short one - one week. It will end Friday, November 4. >>=20 >> I especially want to hear from the people who had issues with -08: = Mark Duckworth, Christian Groves, and Colin Perkins. But not just them. = Please, everyone who worked on CLUE please respond. This will impact the = level of support for the document that I can report in the shepherd = writeup. >>=20 >> See below for more on why I'm calling for wglc *again*. >>=20 >> Thanks, >> Paul >>=20 >> On 10/28/16 1:03 PM, Colin Perkins wrote: >>>=20 >>>> On 28 Oct 2016, at 17:58, Paul Kyzivat = wrote: >>>>=20 >>>> On 10/28/16 10:56 AM, Colin Perkins wrote: >>>>> And as I said before, you need to wait for confirmation from that = who commented that the changes address their concerns. >>>>=20 >>>> I checked the email discussion history. After -08 the non-author = people who commented were me, Mark, and Christian. >>>>=20 >>>> Since -09 Mark has confirmed that he is satisfied with it. I am = also satisfied. So if we hear from Christian then I think we will be = good in this regard. (I presume the authors are ok with this.) >>>=20 >>> I also sent extensive comments on -08 on 7 October, and have yet to = have chance to review whether they were addressed in -09. >>>=20 >>> Why this rush to publish, without giving the working group chance to = review? You should be issuing a new working group last call, since there = were substantive technical comments on the last version. >>=20 >> My impression is that people are tired of this and want it over. And = there seem to be only a small set of participants at this time. >>=20 >> But, since you have asked, I'm hereby doing so. >>=20 >> Thanks, >> Paul >=20 > --=20 > Colin Perkins > https://csperkins.org/ >=20 >=20 >=20 >=20 --=20 Colin Perkins https://csperkins.org/ From nobody Wed Nov 2 14:49:23 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A22F1299A8 for ; Wed, 2 Nov 2016 14:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXeRtW0WTR2c for ; Wed, 2 Nov 2016 14:49:19 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2CF7129444 for ; Wed, 2 Nov 2016 14:49:18 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id p190so296212948wmp.1 for ; Wed, 02 Nov 2016 14:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=Yrh1QmeiUvK2MVyEzq2/klfzzHBVGip3MmMfudZsUw8=; b=Ji2NpXfW29jWlRKA2CwG2HdUOCJWcBGzp3Tl3tOjrdPJCWeGzNErbZsSUSeeOl4P40 RlCU94rxCIqXEe6A653IriargFwizuer2mlBOnqDei1U/Rvmf7vawFUf1GceOK21NMl1 wyM/UYj5/AswdH6461nFo8rfXb/wnT858qhFRDwMmSlfjCu78jqqhR9JgJaaIvrDKYTH 8bATDqv+6+S2hOI9fGvu4pDsKksA6fxOeF4nuDHgYZRN39wwhu3zEZm3/arTz8B7YOAz 1fzshskNCMCzBbXHy9crH/dtkYH0dfnYTN/MiH24bocESbhebhhAMq5+VKtuJYP/5LhH ywUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=Yrh1QmeiUvK2MVyEzq2/klfzzHBVGip3MmMfudZsUw8=; b=TFplANOlvevQTNDlyyUUFLejRG5NLD9ebAEdLQjoZnZ6r2zWxIgfVKkNG5OBfbFumT SXMTPgCkoHnX8POxtwtMO1ahKXjv62hLZ0L39U/KR6WgFi260FpFrMCuQXdo4+nrzKle LPBBGdUqrLwJ4Zwvjt38I38bH7X7vf7agEzT8t4Oj9vrNSR9EzHREOJt9cmD5+w36ik1 lLeDTpJio9Y8qubFztT6xO+zwp3bWYthXlKeZOkwAhY4tmwjmXlDcOKJlNopJ9Ehb9JX c3JKCWriUCbWcQI7itREoso3SMEsvLqH9N36iavnS8wVbqUS96IY18+NiUJIxQifnYYt WmHQ== X-Gm-Message-State: ABUngvdfGhVeP4PaUfNKAPjZF3fax19uUHwDXUA5/LqCG+ncy6SDpwYOTGeysNDNMBnSmQ== X-Received: by 10.28.14.65 with SMTP id 62mr5089277wmo.3.1478123357151; Wed, 02 Nov 2016 14:49:17 -0700 (PDT) Received: from RoniPC (bzq-79-178-162-211.red.bezeqint.net. [79.178.162.211]) by smtp.gmail.com with ESMTPSA id o62sm38514896wmg.12.2016.11.02.14.49.15 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 02 Nov 2016 14:49:16 -0700 (PDT) From: "Roni Even" To: "'Colin Perkins'" , "'Paul Kyzivat'" References: <147733415926.15467.2006430670314279492.idtracker@ietfa.amsl.com> <618bed9d-5983-96a5-62b4-0c1577e04dcd@alum.mit.edu> <7d5da6f6-cc79-d9c4-48ab-2d39c289470a@alum.mit.edu> In-Reply-To: Date: Wed, 2 Nov 2016 23:47:13 +0200 Message-ID: <01ac01d23552$acd89070$0689b150$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHxQj6WRwwH+p5W6HT5Si1pTU2UWAKsdCe6AXzHRAUB4cNn5QIhsDMWAcbo/PwCxa6cPAGGL0iFAp9ekQMBcpZ5UAMjX/Ywn9xzGyA= Content-Language: he Archived-At: Cc: 'CLUE' Subject: Re: [clue] WGLC for draft-ietf-clue-rtp-mapping-09.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 21:49:21 -0000 Colin, Thanks for the review Inline Roni > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Colin Perkins > Sent: Wednesday, November 02, 2016 10:13 PM > To: Paul Kyzivat > Cc: CLUE > Subject: Re: [clue] WGLC for draft-ietf-clue-rtp-mapping-09.txt > > > > On 2 Nov 2016, at 20:09, Colin Perkins wrote: > > > > Paul, > > > > I'm sorry, but I still don't think this draft is ready for publication. I have the > following comments: > > > > - Section 2: The draft says that the RFC 2119 keywords "indicate > requirement levels for compliant RTP implementations". This is incorrect. > They might indicate requirements for "compliant CLUE implementations", or > perhaps for "RTP processing in compliant CLUE implementations", but they > cannot apply to RTP implementations in general. [Roni Even] OK > > > > - Section 3, 4th and 5th paragraphs: The attempts to briefly summarise the > detailed descriptions from RFC 7667 confuse more than they help. Since > there is nothing CLUE specific here, these paragraphs can be removed. The > first paragraph of Section 3 says that these topologies can be used with > CLUE, which is all that's needed. [Roni Even] I can delete these paragraphs, I assume that you suggest they are not needed since they do not have any CLUE specific content. > > > > - Section 4, 2nd paragraph, says "can send each media source in a separate > RTP session identified by the content attribute", but the content attribute > does not identify the RTP session, it identifies the role of that RTP session in > the CLUE context. It should perhaps say something like ".in a separate RTP > session, with a content attribute [RFC4796] identifying the CLUE Capture > Encoding represented by that RTP session"? [Roni Even] OK > > > > - Section 4, 2nd paragraph: "Demultipexing at the media receiver is > straightforward if the multiplexing point is at the UDP transport level, where > each RTP stream uses a separate RTP session" - it's not clear what is being > demultiplexed, since RTP streams don't use RTP sessions. Is the intent to say > something like "Demultiplexing is straightforward because each media > capture is sent as a single RTP stream, with each RTP stream being sent in a > separate RTP session, on a distinct UDP 5-tuple"? [Roni Even] OK > > > > - Section 4, 2nd paragraph: "the mapping does not change even if the RTP > session is switched using same or different SSRC" - what does this mean? An > RTP session doesn't have an SSRC; it contains RTP streams that are identified > by SSRC. Accordingly, it doesn't make sense to talk about RTP sessions being > switched by SSRC. [Roni Even] OK will change the language > > > > - Section 4, 3rd paragraph: "CLUE endpoints that support sending of > several RTP streams in a single or multiple RTP sessions MUST support [I- > D.ietf-mmusic-sdp-bundle-negotiation]" - I don't understand why BUNDLE > would be used with multiple RTP sessions? [Roni Even] there can be for example two RTP sessions each of them is using bundle to multiplex multiple RTP streams > > > > - Section 4, 3rd paragraph: This is hard to follow in general, and I suggest > trying to reword it. Maybe: "Each Capture Encoding MUST be sent as a > separate RTP stream. CLUE endpoints MUST support sending each such RTP > stream in a separate RTP session signalled by an SDP m= line. They MAY also > support sending all the RTP streams in a single RTP session, using the > mechanism described in [I-D.ietf-mmusic-sdp-bundle-negotiation] to relate > RTP streams to SDP m= lines." [Roni Even] OK but also see my previous response about a single RTP session > > > > - Section 5, 1st paragraph: I suggest changing "mapping from the MCC RTP > stream to the constituent MC" to "mapping from the SSRC of the RTP stream > conveying a particular MCC to." to make the layering clear. [Roni Even] OK > > > > - Section 5, 2nd paragraph: Similarly, I suggest changing "associates the > SSRC of the MCC stream with the captureID" to "associates the SSRC of the > RTP stream conveying a particular MCC with.". [Roni Even] OK > > > > - Section 5, 3rd and 5th paragraphs: The CaptureID is not sent in the RTP > Header, it's sent in an RTP Header Extension. Similarly, the CaptureID is not > sent in an "RTCP SDES message", it's sent in an "RTCP CaptureID SDES item". [Roni Even] OK > > > > - Section 5, 4th paragraph: "giving source information for these CSRC > values" is not quite correct. It would be clearer written "giving source > information for the SSRC values sent as contributing sources (CSRCs)". [Roni Even] OK > > > > - Section 5, 5th paragraph: "interprets this as meaning any previous > captureID value in this RTP header no longer applies" would be more correct > if written "interprets this as meaning that any previous CaptureID value > associated with this SSRC no longer applies". [Roni Even] OK > > > > - Section 5.1, last paragraph: "SDES message" -> "SDES item". Also, SDES > items are not "sent in a compound RTCP packet", they're "sent in an SDES > packet within a compound RTCP packet". [Roni Even] OK > > > > - Section 5.1, last paragraph: Need to explain what happens if Reduced-size > RTCP has been negotiated, possibly by adding ", in which case it can be sent > as an SDES packet in a non-compound RTCP packet" to the end of the > paragraph. [Roni Even] OK > > > > - Section 5.2, 2nd paragraph: RFC 7941 requires the URN to be > "urn:ietf:params:rtp-hdrext:sdes:CaptureID" not "urn:ietf:params:rtp- > hdrext:sdes:CaptureID". [Roni Even]OK > > This should, of course, read 'not "urn:ietf:params:rtp-hdrext:CaptureID"'. > > > - Section 5.2: The packet diagrams don't match those in RFC 7941. I > suggest that the copy here be removed. [Roni Even] OK can remove the diagrams since anyhow it is missing text which is in RFC5285 and RFC7941 > > > > Colin > > > > > > > > > >> On 28 Oct 2016, at 18:50, Paul Kyzivat wrote: > >> > >> This announced the start of another WGLC on the rtp-mapping document, > this time draft-ietf-clue-rtp-mapping-09.txt. > >> > >> This will be a short one - one week. It will end Friday, November 4. > >> > >> I especially want to hear from the people who had issues with -08: Mark > Duckworth, Christian Groves, and Colin Perkins. But not just them. Please, > everyone who worked on CLUE please respond. This will impact the level of > support for the document that I can report in the shepherd writeup. > >> > >> See below for more on why I'm calling for wglc *again*. > >> > >> Thanks, > >> Paul > >> > >> On 10/28/16 1:03 PM, Colin Perkins wrote: > >>> > >>>> On 28 Oct 2016, at 17:58, Paul Kyzivat > wrote: > >>>> > >>>> On 10/28/16 10:56 AM, Colin Perkins wrote: > >>>>> And as I said before, you need to wait for confirmation from that who > commented that the changes address their concerns. > >>>> > >>>> I checked the email discussion history. After -08 the non-author people > who commented were me, Mark, and Christian. > >>>> > >>>> Since -09 Mark has confirmed that he is satisfied with it. I am also > satisfied. So if we hear from Christian then I think we will be good in this > regard. (I presume the authors are ok with this.) > >>> > >>> I also sent extensive comments on -08 on 7 October, and have yet to > have chance to review whether they were addressed in -09. > >>> > >>> Why this rush to publish, without giving the working group chance to > review? You should be issuing a new working group last call, since there were > substantive technical comments on the last version. > >> > >> My impression is that people are tired of this and want it over. And there > seem to be only a small set of participants at this time. > >> > >> But, since you have asked, I'm hereby doing so. > >> > >> Thanks, > >> Paul > > > > -- > > Colin Perkins > > https://csperkins.org/ > > > > > > > > > > > > -- > Colin Perkins > https://csperkins.org/ > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Wed Nov 2 15:27:25 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE73E1296E8 for ; Wed, 2 Nov 2016 15:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5S4ZTzP3SG3 for ; Wed, 2 Nov 2016 15:27:22 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D95B8129518 for ; Wed, 2 Nov 2016 15:27:21 -0700 (PDT) Received: from [81.187.2.149] (port=37741 helo=[192.168.0.91]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1c2402-0006S6-Bw; Wed, 02 Nov 2016 22:27:15 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: <01ac01d23552$acd89070$0689b150$@gmail.com> Date: Wed, 2 Nov 2016 22:27:11 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <995635FC-770E-4F72-8ABC-3522FCB72F72@csperkins.org> References: <147733415926.15467.2006430670314279492.idtracker@ietfa.amsl.com> <618bed9d-5983-96a5-62b4-0c1577e04dcd@alum.mit.edu> <7d5da6f6-cc79-d9c4-48ab-2d39c289470a@alum.mit.edu> <01ac01d23552$acd89070$0689b150$@gmail.com> To: Roni Even X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: CLUE Subject: Re: [clue] WGLC for draft-ietf-clue-rtp-mapping-09.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 22:27:24 -0000 Hi Roni, [inline] > On 2 Nov 2016, at 21:47, Roni Even wrote: >=20 > Colin, > Thanks for the review > Inline > Roni >=20 >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Colin Perkins >> Sent: Wednesday, November 02, 2016 10:13 PM >> To: Paul Kyzivat >> Cc: CLUE >> Subject: Re: [clue] WGLC for draft-ietf-clue-rtp-mapping-09.txt >>=20 >>=20 >>> On 2 Nov 2016, at 20:09, Colin Perkins wrote: >>>=20 >>> Paul, >>>=20 >>> I=E2=80=99m sorry, but I still don't think this draft is ready for = publication. I have the following comments: >>>=20 >>> - Section 2: The draft says that the RFC 2119 keywords =E2=80=9Cindica= te requirement levels for compliant RTP implementations". This is = incorrect. They might indicate requirements for =E2=80=9Ccompliant CLUE = implementations=E2=80=9D, or perhaps for "RTP processing in compliant = CLUE implementations", but they cannot apply to RTP implementations in = general. > [Roni Even] OK >>>=20 >>> - Section 3, 4th and 5th paragraphs: The attempts to briefly = summarise the detailed descriptions from RFC 7667 confuse more than they = help. Since there is nothing CLUE specific here, these paragraphs can be = removed. The first paragraph of Section 3 says that these topologies can = be used with CLUE, which is all that=E2=80=99s needed. > [Roni Even] I can delete these paragraphs, I assume that you suggest = they > are not needed since they do not have any CLUE specific content.=20 Yes. >>> - Section 4, 2nd paragraph, says =E2=80=9Ccan send each media source = in a separate RTP session identified by the content attribute=E2=80=9D, = but the content attribute does not identify the RTP session, it = identifies the role of that RTP session in the CLUE context. It should = perhaps say something like =E2=80=9C.in a separate RTP session, with a = content attribute [RFC4796] identifying the CLUE Capture Encoding = represented by that RTP session=E2=80=9D? > [Roni Even] OK >>>=20 >>> - Section 4, 2nd paragraph: =E2=80=9CDemultipexing at the media = receiver is straightforward if the multiplexing point is at the UDP = transport level, where each RTP stream uses a separate RTP session=E2=80=9D= - it=E2=80=99s not clear what is being demultiplexed, since RTP streams = don=E2=80=99t use RTP sessions. Is the intent to say something like = =E2=80=9CDemultiplexing is straightforward because each media capture is = sent as a single RTP stream, with each RTP stream being sent in a = separate RTP session, on a distinct UDP 5-tuple=E2=80=9D? > [Roni Even] OK >>>=20 >>> - Section 4, 2nd paragraph: =E2=80=9Cthe mapping does not change = even if the RTP session is switched using same or different SSRC=E2=80=9D = - what does this mean? An RTP session doesn=E2=80=99t have an SSRC; it = contains RTP streams that are identified by SSRC. Accordingly, it = doesn=E2=80=99t make sense to talk about RTP sessions being switched by = SSRC. > [Roni Even] OK will change the language >>>=20 >>> - Section 4, 3rd paragraph: =E2=80=9CCLUE endpoints that support = sending of several RTP streams in a single or multiple RTP sessions MUST = support [I-D.ietf-mmusic-sdp-bundle-negotiation]=E2=80=9D - I don't = understand why BUNDLE would be used with multiple RTP sessions? > [Roni Even] there can be for example two RTP sessions each of them is = using > bundle to multiplex multiple RTP streams Okay, but that=E2=80=99s not clear from the text. >>> - Section 4, 3rd paragraph: This is hard to follow in general, and I = suggest trying to reword it. Maybe: =E2=80=9CEach Capture Encoding MUST = be sent as a separate RTP stream. CLUE endpoints MUST support sending = each such RTP stream in a separate RTP session signalled by an SDP m=3D = line. They MAY also support sending all the RTP streams in a single RTP = session, using the mechanism described in = [I-D.ietf-mmusic-sdp-bundle-negotiation] to relate RTP streams to SDP m=3D= lines.=E2=80=9D > [Roni Even] OK but also see my previous response about a single RTP = session Could maybe change =E2=80=9CMAY also support sending all the RTP streams = in a single RTP session=E2=80=9D to =E2=80=9C=E2=80=A6sending some or = all of the RTP streams=E2=80=A6=E2=80=9D? >>> - Section 5, 1st paragraph: I suggest changing =E2=80=9Cmapping from = the MCC RTP stream to the constituent MC=E2=80=9D to "mapping from the = SSRC of the RTP stream conveying a particular MCC to." to make the = layering clear. > [Roni Even] OK >>>=20 >>> - Section 5, 2nd paragraph: Similarly, I suggest changing = =E2=80=9Cassociates the SSRC of the MCC stream with the captureID=E2=80=9D= to =E2=80=9Cassociates the SSRC of the RTP stream conveying a = particular MCC with.". > [Roni Even] OK >>>=20 >>> - Section 5, 3rd and 5th paragraphs: The CaptureID is not sent in = the RTP Header, it=E2=80=99s sent in an RTP Header Extension. Similarly, = the CaptureID is not sent in an =E2=80=9CRTCP SDES message=E2=80=9D, = it's sent in an "RTCP CaptureID SDES item". > [Roni Even] OK >>>=20 >>> - Section 5, 4th paragraph: =E2=80=9Cgiving source information for = these CSRC values" is not quite correct. It would be clearer written = =E2=80=9Cgiving source information for the SSRC values sent as = contributing sources (CSRCs)". > [Roni Even] OK >>>=20 >>> - Section 5, 5th paragraph: =E2=80=9Cinterprets this as meaning any = previous captureID value in this RTP header no longer applies=E2=80=9D = would be more correct if written =E2=80=9Cinterprets this as meaning = that any previous CaptureID value associated with this SSRC no longer = applies=E2=80=9D. > [Roni Even] OK >>>=20 >>> - Section 5.1, last paragraph: "SDES message" -> "SDES item". Also, = SDES items are not =E2=80=9Csent in a compound RTCP packet=E2=80=9D, = they're "sent in an SDES packet within a compound RTCP packet". > [Roni Even] OK >>>=20 >>> - Section 5.1, last paragraph: Need to explain what happens if = Reduced-size RTCP has been negotiated, possibly by adding =E2=80=9C, in = which case it can be sent as an SDES packet in a non-compound RTCP = packet=E2=80=9D to the end of the paragraph. > [Roni Even] OK >>>=20 >>> - Section 5.2, 2nd paragraph: RFC 7941 requires the URN to be = =E2=80=9Curn:ietf:params:rtp-hdrext:sdes:CaptureID=E2=80=9D not = "urn:ietf:params:rtp- hdrext:CaptureID". > [Roni Even]OK >>=20 >> This should, of course, read 'not = "urn:ietf:params:rtp-hdrext:CaptureID"'. >>=20 >>> - Section 5.2: The packet diagrams don=E2=80=99t match those in RFC = 7941. I suggest that the copy here be removed. > [Roni Even] OK can remove the diagrams since anyhow it is missing text = which > is in RFC5285 and RFC7941 Thanks, Colin --=20 Colin Perkins https://csperkins.org/ From nobody Wed Nov 2 15:59:12 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0936412946A for ; Wed, 2 Nov 2016 15:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJUSWDJaQvm4 for ; Wed, 2 Nov 2016 15:59:09 -0700 (PDT) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D01FA1293FD for ; Wed, 2 Nov 2016 15:59:09 -0700 (PDT) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-12v.sys.comcast.net with SMTP id 24UncRUBmxBKT24UvcVEMe; Wed, 02 Nov 2016 22:59:09 +0000 Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-07v.sys.comcast.net with SMTP id 24UtcJ6gWV3TX24UucqeCv; Wed, 02 Nov 2016 22:59:08 +0000 To: Colin Perkins References: <147733415926.15467.2006430670314279492.idtracker@ietfa.amsl.com> <618bed9d-5983-96a5-62b4-0c1577e04dcd@alum.mit.edu> <7d5da6f6-cc79-d9c4-48ab-2d39c289470a@alum.mit.edu> From: Paul Kyzivat Message-ID: <54399f8f-628d-340c-dcdd-bea31b85bb23@alum.mit.edu> Date: Wed, 2 Nov 2016 18:59:07 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfH/fyu4WTp6LAzbbuSC9InZOaewpAnmEgjcuA8yGLbUJ1kBGih76bPNteMxUuQUUiNb4ysOs2japHWiuoxGAiTOl3jzZfWWyiTU7XmVPmV8USCHFjW4m L8/qfhZUE1JQmKgL/lR/Pg1i7InViKODLlsqRsbvxviImt5U5YIlN80qYhUYe2sHgZsGxSjZqp6IPFUs3/B4WuCW9navYO1HF54= Archived-At: Cc: CLUE Subject: Re: [clue] WGLC for draft-ietf-clue-rtp-mapping-09.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 22:59:11 -0000 On 11/2/16 4:09 PM, Colin Perkins wrote: > Paul, > > Im sorry, but I still dont think this draft is ready for publication. I have the following comments: OK, this is WGLC, and these are WGLC comments. Lets hear what the authors have to say on them. Thanks, Paul > - Section 2: The draft says that the RFC 2119 keywords indicate requirement levels for compliant RTP implementations. This is incorrect. They might indicate requirements for compliant CLUE implementations, or perhaps for RTP processing in compliant CLUE implementations, but they cannot apply to RTP implementations in general. > > - Section 3, 4th and 5th paragraphs: The attempts to briefly summarise the detailed descriptions from RFC 7667 confuse more than they help. Since there is nothing CLUE specific here, these paragraphs can be removed. The first paragraph of Section 3 says that these topologies can be used with CLUE, which is all thats needed. > > - Section 4, 2nd paragraph, says can send each media source in a separate RTP session identified by the content attribute, but the content attribute does not identify the RTP session, it identifies the role of that RTP session in the CLUE context. It should perhaps say something like in a separate RTP session, with a content attribute [RFC4796] identifying the CLUE Capture Encoding represented by that RTP session? > > - Section 4, 2nd paragraph: Demultipexing at the media receiver is straightforward if the multiplexing point is at the UDP transport level, where each RTP stream uses a separate RTP session its not clear what is being demultiplexed, since RTP streams dont use RTP sessions. Is the intent to say something like Demultiplexing is straightforward because each media capture is sent as a single RTP stream, with each RTP stream being sent in a separate RTP session, on a distinct UDP 5-tuple? > > - Section 4, 2nd paragraph: the mapping does not change even if the RTP session is switched using same or different SSRC what does this mean? An RTP session doesnt have an SSRC; it contains RTP streams that are identified by SSRC. Accordingly, it doesnt make sense to talk about RTP sessions being switched by SSRC. > > - Section 4, 3rd paragraph: CLUE endpoints that support sending of several RTP streams in a single or multiple RTP sessions MUST support [I-D.ietf-mmusic-sdp-bundle-negotiation] I dont understand why BUNDLE would be used with multiple RTP sessions? > > - Section 4, 3rd paragraph: This is hard to follow in general, and I suggest trying to reword it. Maybe: Each Capture Encoding MUST be sent as a separate RTP stream. CLUE endpoints MUST support sending each such RTP stream in a separate RTP session signalled by an SDP m= line. They MAY also support sending all the RTP streams in a single RTP session, using the mechanism described in [I-D.ietf-mmusic-sdp-bundle-negotiation] to relate RTP streams to SDP m= lines. > > - Section 5, 1st paragraph: I suggest changing mapping from the MCC RTP stream to the constituent MC to mapping from the SSRC of the RTP stream conveying a particular MCC to to make the layering clear. > > - Section 5, 2nd paragraph: Similarly, I suggest changing associates the SSRC of the MCC stream with the captureID to associates the SSRC of the RTP stream conveying a particular MCC with. > > - Section 5, 3rd and 5th paragraphs: The CaptureID is not sent in the RTP Header, its sent in an RTP Header Extension. Similarly, the CaptureID is not sent in an RTCP SDES message, its sent in an RTCP CaptureID SDES item. > > - Section 5, 4th paragraph: giving source information for these CSRC values is not quite correct. It would be clearer written giving source information for the SSRC values sent as contributing sources (CSRCs). > > - Section 5, 5th paragraph: interprets this as meaning any previous captureID value in this RTP header no longer applies would be more correct if written interprets this as meaning that any previous CaptureID value associated with this SSRC no longer applies. > > - Section 5.1, last paragraph: SDES message -> SDES item. Also, SDES items are not sent in a compound RTCP packet, theyre sent in an SDES packet within a compound RTCP packet. > > - Section 5.1, last paragraph: Need to explain what happens if Reduced-size RTCP has been negotiated, possibly by adding , in which case it can be sent as an SDES packet in a non-compound RTCP packet to the end of the paragraph. > > - Section 5.2, 2nd paragraph: RFC 7941 requires the URN to be urn:ietf:params:rtp-hdrext:sdes:CaptureID not urn:ietf:params:rtp-hdrext:sdes:CaptureID. > > - Section 5.2: The packet diagrams dont match those in RFC 7941. I suggest that the copy here be removed. > > Colin > > > > >> On 28 Oct 2016, at 18:50, Paul Kyzivat wrote: >> >> This announced the start of another WGLC on the rtp-mapping document, this time draft-ietf-clue-rtp-mapping-09.txt. >> >> This will be a short one - one week. It will end Friday, November 4. >> >> I especially want to hear from the people who had issues with -08: Mark Duckworth, Christian Groves, and Colin Perkins. But not just them. Please, everyone who worked on CLUE please respond. This will impact the level of support for the document that I can report in the shepherd writeup. >> >> See below for more on why I'm calling for wglc *again*. >> >> Thanks, >> Paul >> >> On 10/28/16 1:03 PM, Colin Perkins wrote: >>> >>>> On 28 Oct 2016, at 17:58, Paul Kyzivat wrote: >>>> >>>> On 10/28/16 10:56 AM, Colin Perkins wrote: >>>>> And as I said before, you need to wait for confirmation from that who commented that the changes address their concerns. >>>> >>>> I checked the email discussion history. After -08 the non-author people who commented were me, Mark, and Christian. >>>> >>>> Since -09 Mark has confirmed that he is satisfied with it. I am also satisfied. So if we hear from Christian then I think we will be good in this regard. (I presume the authors are ok with this.) >>> >>> I also sent extensive comments on -08 on 7 October, and have yet to have chance to review whether they were addressed in -09. >>> >>> Why this rush to publish, without giving the working group chance to review? You should be issuing a new working group last call, since there were substantive technical comments on the last version. >> >> My impression is that people are tired of this and want it over. And there seem to be only a small set of participants at this time. >> >> But, since you have asked, I'm hereby doing so. >> >> Thanks, >> Paul > From nobody Thu Nov 3 08:26:20 2016 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 583151294EA; Thu, 3 Nov 2016 08:26:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147818677535.22862.6977797013680928860.idtracker@ietfa.amsl.com> Date: Thu, 03 Nov 2016 08:26:15 -0700 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-protocol-10.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 15:26:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence of the IETF. Title : CLUE protocol Authors : Roberta Presta Simon Pietro Romano Filename : draft-ietf-clue-protocol-10.txt Pages : 56 Date : 2016-11-03 Abstract: The CLUE protocol is an application protocol conceived for the description and negotiation of a telepresence session. The design of the CLUE protocol takes into account the requirements and the framework defined within the IETF CLUE working group. A companion document delves into CLUE signaling details, as well as on the SIP/ SDP session establishment phase. CLUE messages flow upon the CLUE data channel, based on reliable and ordered SCTP over DTLS transport. Message details, together with the behavior of CLUE Participants acting as Media Providers and/or Media Consumers, are herein discussed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-clue-protocol-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-protocol-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Nov 4 09:26:26 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729731295B1 for ; Fri, 4 Nov 2016 09:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.698 X-Spam-Level: X-Spam-Status: No, score=-5.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfUYF4lbwt5O for ; Fri, 4 Nov 2016 09:26:24 -0700 (PDT) Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id 499EB1295B0 for ; Fri, 4 Nov 2016 09:26:24 -0700 (PDT) X-AuditID: 12074413-9a9ff70000000a14-cb-581cb6aea22f Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 72.AF.02580.EA6BC185; Fri, 4 Nov 2016 12:26:23 -0400 (EDT) Received: from [192.168.1.110] (c-73-186-127-100.hsd1.ma.comcast.net [73.186.127.100]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id uA4GQLiJ006478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 4 Nov 2016 12:26:22 -0400 To: CLUE From: Paul Kyzivat Message-ID: Date: Fri, 4 Nov 2016 12:26:21 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsUixO6iqLt+m0yEwe6D4hb7T11mdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRvcMhYJtnBVNX5IaGA+xdzFyckgImEj8ndXF3MXIxSEkcJlR 4vXHV0wQzismiY2v37OBVIkISEicOnWXEcRmE9CSmHPoP0sXIweHsICuxNELiiBhXgF7idfb rzOB2CwCKhLTD89hBbFFBdIktq/bzQxRIyhxcuYTFhCbWcBMYt7mh8wQtrzE9rdzmCcw8sxC UjYLSdksJGULGJlXMcol5pTm6uYmZuYUpybrFicn5uWlFuma6+VmluilppRuYoQEjPAOxl0n 5Q4xCnAwKvHwJkyRiRBiTSwrrsw9xCjJwaQkyvtsA1CILyk/pTIjsTgjvqg0J7X4EKMEB7OS CK/mFqAcb0piZVVqUT5MSpqDRUmcV22Jup+QQHpiSWp2ampBahFMVoaDQ0mClxEYGUKCRanp qRVpmTklCGkmDk6Q4TxAwxdtBRleXJCYW5yZDpE/xagoJc4bCZIQAElklObB9cIi+hWjONAr wrwJIFU8wGQA1/0KaDAT0GC3ELDBJYkIKakGxnxdiQvXnv1bKiq8LvhzjNzJd3FReffPp8Zr /GI0NNKt25sl+Ljv+Mzn3W80M6Zx782a/GxClYHC5vbDdzbdvvfX4IyxWYO646WMe0G7dpc8 1eYo6eVNMLr6c8H+SS+v6FevNTrM7CcUHTDh0mWuIivu6z8bZZkEn4vn58wLTzz/cP0i34gZ XkosxRmJhlrMRcWJAEGPCQvDAgAA Archived-At: Subject: [clue] WGLC for draft-ietf-clue-protocol-10 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 16:26:25 -0000 This message announces the start of a WGLC for draft-ietf-clue-protocol-10. The last time we had a WGLC on this document was -04. Since then there have been substantial changes: https://tools.ietf.org/rfcdiff?url2=draft-ietf-clue-protocol-10.txt;url1=draft-ietf-clue-protocol-04.txt I have the sense that I have been the only one reviewing and commenting on this document along the way. It is important that we have thorough review by others in the wg. So please give careful attention to this document and comment back. Note that this is the last piece of CLUE. Once this one is done we can declare victory and close down the wg. Unfortunately this review is starting at a busy time: the Seoul IETF meeting is coming in a week, and so some people will be busy with that. And the week after that is Thanksgiving in the US, so some people won't be off some of that week. As a result, I'm giving a longer duration for this review, so that everyone will have an opportunity to fit the work into their schedule somewhere. Starting Date: Friday, November 4, 2016 Ending Date: Wednesday, Novemeber 30, 2016 Please do this so we can wrap things up. Thanks, Paul From nobody Fri Nov 4 11:38:29 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C91E129626 for ; Fri, 4 Nov 2016 11:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxfodn4ARJff for ; Fri, 4 Nov 2016 11:38:26 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 256421295EE for ; Fri, 4 Nov 2016 11:38:26 -0700 (PDT) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-08v.sys.comcast.net with SMTP id 2jNEcLgjc84vj2jNhc1eSz; Fri, 04 Nov 2016 18:38:25 +0000 Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-07v.sys.comcast.net with SMTP id 2jNgcQkesV3TX2jNgcudsw; Fri, 04 Nov 2016 18:38:25 +0000 To: Colin Perkins , Roni Even References: <147733415926.15467.2006430670314279492.idtracker@ietfa.amsl.com> <618bed9d-5983-96a5-62b4-0c1577e04dcd@alum.mit.edu> <7d5da6f6-cc79-d9c4-48ab-2d39c289470a@alum.mit.edu> <01ac01d23552$acd89070$0689b150$@gmail.com> <995635FC-770E-4F72-8ABC-3522FCB72F72@csperkins.org> From: Paul Kyzivat Message-ID: <26174e84-b070-9c48-9121-6ddae79f523a@alum.mit.edu> Date: Fri, 4 Nov 2016 14:38:24 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <995635FC-770E-4F72-8ABC-3522FCB72F72@csperkins.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfG/qUrdjjEC3z++qpQ3/TeeshyYO1E6INBBeuXQCLg0X9dMgSjm7cU9NitPQ+mg+IaUTcPnxmEgKSg++MAXLbqTxSs1cTDqbMDIrrhLLamUvBwRSooto 8vockRQTlXcUm2/DjuAWDRfAvKJ/1bu4TalMx+f5QyD2lPiRifySGzfJotrVSlqFL6C5wZHxqmdOGe1UFDfaoCJcQo/veeuy0pMRlAuRqnkYRLLG2PHziV9p Archived-At: Cc: CLUE Subject: Re: [clue] WGLC for draft-ietf-clue-rtp-mapping-09.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 18:38:28 -0000 Today is the end of the WGLC on this document. If you haven't commented yet and want to, speak now or forget it. The only comments requiring attention have come in have been from Colin. It looks like these can be addressed easily. Does anyone think we need yet another WGLC after these have been addressed? Thanks, Paul On 11/2/16 6:27 PM, Colin Perkins wrote: > Hi Roni, > > [inline] > >> On 2 Nov 2016, at 21:47, Roni Even wrote: >> >> Colin, >> Thanks for the review >> Inline >> Roni >> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Colin Perkins >>> Sent: Wednesday, November 02, 2016 10:13 PM >>> To: Paul Kyzivat >>> Cc: CLUE >>> Subject: Re: [clue] WGLC for draft-ietf-clue-rtp-mapping-09.txt >>> >>> >>>> On 2 Nov 2016, at 20:09, Colin Perkins wrote: >>>> >>>> Paul, >>>> >>>> I’m sorry, but I still don't think this draft is ready for publication. I have the following comments: >>>> >>>> - Section 2: The draft says that the RFC 2119 keywords “indicate requirement levels for compliant RTP implementations". This is incorrect. They might indicate requirements for “compliant CLUE implementations”, or perhaps for "RTP processing in compliant CLUE implementations", but they cannot apply to RTP implementations in general. >> [Roni Even] OK >>>> >>>> - Section 3, 4th and 5th paragraphs: The attempts to briefly summarise the detailed descriptions from RFC 7667 confuse more than they help. Since there is nothing CLUE specific here, these paragraphs can be removed. The first paragraph of Section 3 says that these topologies can be used with CLUE, which is all that’s needed. >> [Roni Even] I can delete these paragraphs, I assume that you suggest they >> are not needed since they do not have any CLUE specific content. > > Yes. > >>>> - Section 4, 2nd paragraph, says “can send each media source in a separate RTP session identified by the content attribute”, but the content attribute does not identify the RTP session, it identifies the role of that RTP session in the CLUE context. It should perhaps say something like “.in a separate RTP session, with a content attribute [RFC4796] identifying the CLUE Capture Encoding represented by that RTP session”? >> [Roni Even] OK >>>> >>>> - Section 4, 2nd paragraph: “Demultipexing at the media receiver is straightforward if the multiplexing point is at the UDP transport level, where each RTP stream uses a separate RTP session” - it’s not clear what is being demultiplexed, since RTP streams don’t use RTP sessions. Is the intent to say something like “Demultiplexing is straightforward because each media capture is sent as a single RTP stream, with each RTP stream being sent in a separate RTP session, on a distinct UDP 5-tuple”? >> [Roni Even] OK >>>> >>>> - Section 4, 2nd paragraph: “the mapping does not change even if the RTP session is switched using same or different SSRC” - what does this mean? An RTP session doesn’t have an SSRC; it contains RTP streams that are identified by SSRC. Accordingly, it doesn’t make sense to talk about RTP sessions being switched by SSRC. >> [Roni Even] OK will change the language >>>> >>>> - Section 4, 3rd paragraph: “CLUE endpoints that support sending of several RTP streams in a single or multiple RTP sessions MUST support [I-D.ietf-mmusic-sdp-bundle-negotiation]” - I don't understand why BUNDLE would be used with multiple RTP sessions? >> [Roni Even] there can be for example two RTP sessions each of them is using >> bundle to multiplex multiple RTP streams > > Okay, but that’s not clear from the text. > >>>> - Section 4, 3rd paragraph: This is hard to follow in general, and I suggest trying to reword it. Maybe: “Each Capture Encoding MUST be sent as a separate RTP stream. CLUE endpoints MUST support sending each such RTP stream in a separate RTP session signalled by an SDP m= line. They MAY also support sending all the RTP streams in a single RTP session, using the mechanism described in [I-D.ietf-mmusic-sdp-bundle-negotiation] to relate RTP streams to SDP m= lines.” >> [Roni Even] OK but also see my previous response about a single RTP session > > Could maybe change “MAY also support sending all the RTP streams in a single RTP session” to “…sending some or all of the RTP streams…”? > >>>> - Section 5, 1st paragraph: I suggest changing “mapping from the MCC RTP stream to the constituent MC” to "mapping from the SSRC of the RTP stream conveying a particular MCC to." to make the layering clear. >> [Roni Even] OK >>>> >>>> - Section 5, 2nd paragraph: Similarly, I suggest changing “associates the SSRC of the MCC stream with the captureID” to “associates the SSRC of the RTP stream conveying a particular MCC with.". >> [Roni Even] OK >>>> >>>> - Section 5, 3rd and 5th paragraphs: The CaptureID is not sent in the RTP Header, it’s sent in an RTP Header Extension. Similarly, the CaptureID is not sent in an “RTCP SDES message”, it's sent in an "RTCP CaptureID SDES item". >> [Roni Even] OK >>>> >>>> - Section 5, 4th paragraph: “giving source information for these CSRC values" is not quite correct. It would be clearer written “giving source information for the SSRC values sent as contributing sources (CSRCs)". >> [Roni Even] OK >>>> >>>> - Section 5, 5th paragraph: “interprets this as meaning any previous captureID value in this RTP header no longer applies” would be more correct if written “interprets this as meaning that any previous CaptureID value associated with this SSRC no longer applies”. >> [Roni Even] OK >>>> >>>> - Section 5.1, last paragraph: "SDES message" -> "SDES item". Also, SDES items are not “sent in a compound RTCP packet”, they're "sent in an SDES packet within a compound RTCP packet". >> [Roni Even] OK >>>> >>>> - Section 5.1, last paragraph: Need to explain what happens if Reduced-size RTCP has been negotiated, possibly by adding “, in which case it can be sent as an SDES packet in a non-compound RTCP packet” to the end of the paragraph. >> [Roni Even] OK >>>> >>>> - Section 5.2, 2nd paragraph: RFC 7941 requires the URN to be “urn:ietf:params:rtp-hdrext:sdes:CaptureID” not "urn:ietf:params:rtp- hdrext:CaptureID". >> [Roni Even]OK >>> >>> This should, of course, read 'not "urn:ietf:params:rtp-hdrext:CaptureID"'. >>> >>>> - Section 5.2: The packet diagrams don’t match those in RFC 7941. I suggest that the copy here be removed. >> [Roni Even] OK can remove the diagrams since anyhow it is missing text which >> is in RFC5285 and RFC7941 > > Thanks, > Colin > > > From nobody Fri Nov 4 12:07:54 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339791295F5 for ; Fri, 4 Nov 2016 12:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=plcm365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9vd6wN7wDSI for ; Fri, 4 Nov 2016 12:07:50 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5733212964A for ; Fri, 4 Nov 2016 12:07:47 -0700 (PDT) Received: from [216.82.251.38] by server-9.bemta-12.messagelabs.com id A3/C5-06696-28CDC185; Fri, 04 Nov 2016 19:07:46 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSbUxTVxzGe+5Le2HtvBSwf5uqs/GDNpYMNk2 nMYNECW4RidPMEMO81bv2bn0h97ZLzVgGJIpgjegmKx0RhS6bOhMDGSDLnDgdo3YWNwaMCUVB XRlTZogvLC7r7UHUb7+T33PO8z8nhyG1MaWe4X0eXnRxDqMylfLfyz1hrrxm2PbyoR615fvwr 6Tly/hPyPLVmfO05XEVmUsVPL47RRTUxWLKgrPBYVVBKPSIKKKKacFldft20Pb+2BGyNLrZd7 nxw3I0WFiDGAbYDdDRra9BqYyW/RHBnp8jyhqUwlBsFQmBPWVY1BLQN9pG4UUXgsjkaUpOKdl XYfLRCCFzBuuBeLsfyUyyeujtHyZlTmdfhy9+a5rN5ELL0G0Kcz4cHYhTuG0p1E3HVDJr2O0Q eNiqwmWHaAjdmEyGUlgLdAfOJgsQOx8ehL8mcJkOhsYbkwxsBly/elmJORPiY//ROL8dLnaGE b7yauhrY3BkI3TU3SHlLmBDNDRFeyks8uGHveWz/D5cafidxmyCfReDBN4QQdDcUEtiYYCDzW MUFg9pqI9MJCfSsjthoLyVxk+hh+G+aoTZAH9e+46uRcuDz1wimNhPsn4Enwx20cHkc6RBT/0 4hUNm6Dx3nsS8GNr/bpjlNRCY6VJiXgKf7r+uwrwS/rr0DzqGmJNomcSLH/CiOSc7yyoKNrvH yQkOc3Z2TpaTlyTOxjs4q5S10+1sQYnP9rFCgTpQ1WdvXEALGMKYqbl1xrBN+6LVvWu3nZPs7 4heBy9dQAaGMYJG+CPh0kTexvveFRyJH/tEA6M2ZmgcstZIpZxTEmxYhZGZGZ+aGiW0lMvt4v U6zW45xMohu9c1d8STf/8LWqhP1yCFQqFVl/KiU/A87yeQjkHGdI1bPkUtuDxzTROJIYjEEPl bkkN4uKdKX46OBBaZ1LqhUXdJ6wtFh/NK3tox8vZAdfpge1qjeOV42/R6LtqZueLYex/5S1dv Wj7z5tpXSk6Zchri1uqxrW1+iFytaPQv3pi6onhVWUWvbcHAazPGVffKDryk/nzDqWhu4byRo umQkOf799z9/iXfVB7W2r711t90VseXdm9a51V5C42UZOeyTaQocf8DJ5TF9PIDAAA= X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-6.tower-163.messagelabs.com!1478286452!95250332!14 X-Originating-IP: [140.242.64.169] X-StarScan-Received: X-StarScan-Version: 9.0.13; banners=-,-,- X-VirusChecked: Checked Received: (qmail 51885 invoked from network); 4 Nov 2016 19:07:46 -0000 Received: from mailrelay.polycom.com (HELO SACWPEXEDGE02V.polycom.com) (140.242.64.169) by server-6.tower-163.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 4 Nov 2016 19:07:46 -0000 X-CrossPremisesHeadersFilteredBySendConnector: SACWPEXEDGE02V.polycom.com Received: from NAM03-CO1-obe.outbound.protection.outlook.com (216.32.181.18) by mailrelay.polycom.com (10.244.6.169) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 4 Nov 2016 12:07:33 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=plcm365.onmicrosoft.com; s=selector1-polycom-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SNVwc8Wc7eXSfvOppQsXj+ijNXVRsgrBMwluPh/Zr7w=; b=hWM2kblevEqTV+PKfIfcc418/RQTAtogdZL3lcacXAm8bCLKP1Wef0P7+oo+gruZn3ATvhemPQ9GloQY1dJAE2D2jSD29nyzC3zUTQXi+kh2w+UbDEVSabjF5TyArRG6j5P9V1wQHVLP9h/kRYih/vA5JhW6EUqj/cMD3dDagZc= Received: from BN6PR10MB1395.namprd10.prod.outlook.com (10.173.30.17) by BN6PR10MB1395.namprd10.prod.outlook.com (10.173.30.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.12; Fri, 4 Nov 2016 19:07:31 +0000 Received: from BN6PR10MB1395.namprd10.prod.outlook.com ([10.173.30.17]) by BN6PR10MB1395.namprd10.prod.outlook.com ([10.173.30.17]) with mapi id 15.01.0693.009; Fri, 4 Nov 2016 19:07:31 +0000 From: "Duckworth, Mark" To: Roni Even , 'Colin Perkins' , 'Paul Kyzivat' Thread-Topic: [clue] WGLC for draft-ietf-clue-rtp-mapping-09.txt Thread-Index: AQHSMUPjm0Iso1Zjmkq22QCna3OFmKDGJ54AgAAAvwCAABpygIAC90aQ Date: Fri, 4 Nov 2016 19:07:30 +0000 Message-ID: References: <147733415926.15467.2006430670314279492.idtracker@ietfa.amsl.com> <618bed9d-5983-96a5-62b4-0c1577e04dcd@alum.mit.edu> <7d5da6f6-cc79-d9c4-48ab-2d39c289470a@alum.mit.edu> <01ac01d23552$acd89070$0689b150$@gmail.com> In-Reply-To: <01ac01d23552$acd89070$0689b150$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [2601:18c:8800:1250:a5c3:5587:e28f:465b] x-ms-office365-filtering-correlation-id: 997a2c03-1d55-4d0e-1665-08d404e5d3ab x-microsoft-exchange-diagnostics: 1; BN6PR10MB1395; 7:uxSoSVweOI0AT1ErgjWp/HpPKufSrzM/zEo6tRJvs16sWAcOstk4+1GwoVhqaJF4EYcsuEQmYDoAjsrNx3C/m6hHAkipD+eTjDeSU4eCsVBMs8qTVXba2EBxoOm/ZBWmeMxtyAcPp/JG48K2wsW+MK/rgFrLECD302A2ILoqMUxUIw9RR/dId7PsqtmrX23jQ++EMofVJROYu8UVUcQ5QMax8Zer3pvE/+hghKX5sFs+X663CH+i4C9IXuiaC9flP0DPGC6PrufNRyf4KAd7L5aeNK0REPptkyIcy2OJcD0wFjA7JSs3nKtyUp2y6dYQIMV9YMlBReVevkUPPTUcrvrP+YHU0j/3SalCYZcUHcs=; 20:QpMnj4kOiAVnfLz0m5kcJiJWjApesDg3YhF5oiYM4rwJu5BkjlJIWlZhb8HNijlXd7myRLwbaO6vmib19UBCpnA8ne8O2OBFruvAwAqduPEyzIM7YNRrLIWhhWVeMvELuuu7g3Gqdsrv1Qz9KLGxqW6USSCN0xB+9BS8Aoi8VTDlw1y6FHzLKPVzuQWjcWfgW0zzKKRb4TP3mgIMl77Lgr3mMUYzcClypgprVevWxyERJJ+Jgv9LpBV6Dd7L6uX8 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR10MB1395; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415321)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BN6PR10MB1395; BCL:0; PCL:0; RULEID:; SRVR:BN6PR10MB1395; x-forefront-prvs: 01165471DB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(199003)(13464003)(51914003)(189002)(3660700001)(102836003)(68736007)(76576001)(7736002)(33656002)(74316002)(99286002)(54356999)(6116002)(586003)(86362001)(81156014)(2906002)(81166006)(105586002)(305945005)(99936001)(7846002)(4326007)(3280700002)(10400500002)(8936002)(106116001)(106356001)(9686002)(2171001)(11100500001)(5002640100001)(2950100002)(76176999)(97736004)(19580405001)(19580395003)(5001770100001)(87936001)(122556002)(50986999)(92566002)(2900100001)(5660300001)(230783001)(77096005)(7696004)(189998001)(101416001)(93886004)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR10MB1395; H:BN6PR10MB1395.namprd10.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: polycom.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02AE_01D236AD.28173F60" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2016 19:07:30.9487 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d0880d3f-e6d1-4a41-9e81-b8fbcddf7b6c X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR10MB1395 X-OriginatorOrg: polycom.com X-OrganizationHeadersPreserved: SACWPEXEDGE02V.polycom.com Archived-At: Cc: 'CLUE' Subject: Re: [clue] WGLC for draft-ietf-clue-rtp-mapping-09.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 19:07:52 -0000 ------=_NextPart_000_02AE_01D236AD.28173F60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I also agree with Colin's suggestions for clarifying section 5. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even > Sent: Wednesday, November 02, 2016 5:47 PM > To: 'Colin Perkins' ; 'Paul Kyzivat' > > Cc: 'CLUE' > Subject: Re: [clue] WGLC for draft-ietf-clue-rtp-mapping-09.txt > > Colin, > Thanks for the review > Inline > Roni > > > -----Original Message----- > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Colin Perkins > > Sent: Wednesday, November 02, 2016 10:13 PM > > To: Paul Kyzivat > > Cc: CLUE > > Subject: Re: [clue] WGLC for draft-ietf-clue-rtp-mapping-09.txt > > ... snip... > > > - Section 5, 1st paragraph: I suggest changing "mapping from the MCC RTP > > stream to the constituent MC" to "mapping from the SSRC of the RTP > stream > > conveying a particular MCC to." to make the layering clear. > [Roni Even] OK > > > > > > - Section 5, 2nd paragraph: Similarly, I suggest changing "associates > the > > SSRC of the MCC stream with the captureID" to "associates the SSRC of the > > RTP stream conveying a particular MCC with.". > [Roni Even] OK > > > > > > - Section 5, 3rd and 5th paragraphs: The CaptureID is not sent in the > RTP > > Header, it's sent in an RTP Header Extension. Similarly, the CaptureID is > not > > sent in an "RTCP SDES message", it's sent in an "RTCP CaptureID SDES > item". > [Roni Even] OK > > > > > > - Section 5, 4th paragraph: "giving source information for these CSRC > > values" is not quite correct. It would be clearer written "giving source > > information for the SSRC values sent as contributing sources (CSRCs)". > [Roni Even] OK > > > > > > - Section 5, 5th paragraph: "interprets this as meaning any previous > > captureID value in this RTP header no longer applies" would be more > correct > > if written "interprets this as meaning that any previous CaptureID value > > associated with this SSRC no longer applies". > [Roni Even] OK ------=_NextPart_000_02AE_01D236AD.28173F60 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUEjCCBQ0w ggL1oAMCAQICEBrVY02YeFKcQ+zVfznU/o4wDQYJKoZIhvcNAQEFBQAwGTEXMBUGA1UEAxMOUG9s eWNvbS1Sb290Q0EwHhcNMTMxMTA0MTg1NzA2WhcNMjMxMTA0MTkwNjU4WjAZMRcwFQYDVQQDEw5Q b2x5Y29tLVJvb3RDQTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAMzj+6krY3OF7mtq +O2/yC5heUML7DFZn2cp0Mkp/vos7TDrysGdPDdEIK+zYvZQZs6TrGzPh0XXnEpMcHE7V4nD5zN3 VX0+Zg46w0wCHdkgq/GV3EKlyg0AsX8LgooGlUMeuUNpe+sT0WBl3mXB97TUw7mnRLY1m/IAlyFv 4XO8LfQ1L03vfLBRAVft7xc9Okm6DbHrPxFx9VKpgIkSIUvIx/BK0zXBa/0arWW3tfimfY9t5KdJ Wqb68E8Nb0bD8S0Ve0O76TCR4dVE/HmVj6YrauGcUGfvB4yT+bOOCGlsOw3NoHW2G9PZJF9B9PvV cWzv9Jw3AlzGU2sQMbVD1ZiiRgkG47bvqvi/tg38vWEDMj1lzSpMp/FhC8YrSaGb4YwjM52w9MXM DNypbOFZ/0WjrykwuGB1P9Ga38nRlaMkMJ3lE7P1pQMgxElO5uE+1TI5kTJ9mIGgQtQb57w4vkkJ kHNKjmqzOo3IFkhEIUS3ARPkYG4HWzP7xtmcYBoEx4QwpbxYQKKcxN9h/zuv9LYc79WvnF+i+aj0 1YJKoldsPnIXhG3HullYVQb+v19q8cqm0OGUEq7e2wY72H6JiT6YFc5kZitpZ65L5d1OGVLyFO6b iC79ARA9eBE5L3g9zF/du+U1k9L6LWW3VaHr3ZDCECU8ZX5QeBrqv2aTb0VNAgMBAAGjUTBPMAsG A1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSMD03mpjCj/UgRICWESaXA53z3 0TAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG9w0BAQUFAAOCAgEAs02vFW5Je6895ZBWadxy5vxR z2imWk97qU2sMFSMnmf9QeqPwdawGO33zWr1sSQr8d67AHQc+3ihZuoAaeQAAC6Lww9r17Q3vVqg 7Qge86101Xw1fjXqTFUnWTxBK0S7re7pMqWlqaFgFQOHBMLnrM9z+NQIyDh7st9JjA+bRfFwErQ9 5CziXu+o/4q7eDBP1WaI0yKkEcOQ2LyPuCCE4hcshcJABiSYPax8nW71foHb+bv92IYvYXu2Wpa6 VgnxYqdi2k0Yk8CDiYalVsc+7QH0euQ1YIcovPbpZ02AirLqiiy6XB9i8OKfuapKSftsdfjLKqwI L7lKqz/4uAheETQsORVEh4IT0P8RRaIgHBOBVz/DOW+/IiiYagOJIYqbwGIFImQ7uOLNCoP5qY4y PLUZhmHFnnr7xtz4gv455KP9cwtPYcAarc/IB7WkTmEhFYa19k4jXlZ19AZIO/SPhvV7qz50zqB+ pCReRB5fXnf3qhRSw2WpRD4xr/q8OrWTfQRdXaooTJ14tRziqjEWLz4nPQKbE45aAjgwO0Rp6k5J tWGPhCxmuru/iqVES98VbjuAoo2qYZk7eNrqcnMuSxgqU0bgyie/R/FfMcbsw6rAh7T+qfBSxVIQ tpiqPwtZR5kdi6af3vf4w9q1PvEGrNipAjKEN2HW73558qGfPMowggZ5MIIEYaADAgECAhNuAAAA AgUmZh85ZflDAAAAAAACMA0GCSqGSIb3DQEBBQUAMBkxFzAVBgNVBAMTDlBvbHljb20tUm9vdENB MB4XDTEzMTEwNDE5MTM1MFoXDTIzMTEwNDE5MDY1OFowSDETMBEGCgmSJomT8ixkARkWA2NvbTEX MBUGCgmSJomT8ixkARkWB3BvbHljb20xGDAWBgNVBAMTD1BvbHljb20tU1VCQ0EwMTCCAiIwDQYJ KoZIhvcNAQEBBQADggIPADCCAgoCggIBAOZhKwn7h/qKsHx8zQQPT356Og5GOOJ26SKfzS6dIZaD NjFIhS/5QRd3HZ9I1qFD8faDfpIHL+NzC0xqYJUZsEKntD+cCj99nx33t9D6GCmsEEngeLV0FO/u DlDcCXVJNJWS65E05vKyWFPlIRegDs+E73mNh3dHZ53mgrsCFd8PnX5Zm6zm+dAinDTUreXzSuzT si5yuZ10jHdEoin3bQyYQfAe4nR7BiqcQzYnD+JgU+NrZZ555xMdwVtRhjIFuFHwCN1BgWL8+cmI PTmW3bS/irYkbUn/IYFXGJIdgeZTzsp22+OPChBkCBiy86d9RaM6qvOV/ZLmq0bj4souN1cNBg0g ZnYIgTypQY/5Ew99FJJDor4TH1R5YNtqgwxBiSZSc0WSKy8WBrcUpBM+FP1gETY2sqZh2ApFkhU1 7BBLXcEwu6dnSO9Y5u0zJfOTKPesVaeGTfvzTEcm6A8xKO6V+ai/zhu3egbv4SmlPGiMENMPsWRy cG0c73xz/w9RwpWpImjIcE3+XA9rPhIdNj2KN4sbMJvvN5/ZLJHRScE5F3pltq2sFLyPSqhukYVY NRVXmdJ14FCArDqlrREeWLA2tP4ir0WeFeX6KgU+QrmWvdw1hJZ9/lPkiqDvuBWvDVyON0u/Dvi3 p6RJmWJlC5F8ajRegnM+BAYfokRZkvOHAgMBAAGjggGJMIIBhTAQBgkrBgEEAYI3FQEEAwIBADAd BgNVHQ4EFgQUcIfA57S89xZAbs9iT83FhcVNeekwGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEw CwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAUjA9N5qYwo/1IESAlhEml wOd899EwbwYDVR0fBGgwZjBkoGKgYIYuaHR0cDovL2NkcDEucG9seWNvbS5jb20vcGtpL1BvbHlj b20tUm9vdENBLmNybIYuaHR0cDovL2NkcDIucG9seWNvbS5jb20vcGtpL1BvbHljb20tUm9vdENB LmNybDCBhgYIKwYBBQUHAQEEejB4MDoGCCsGAQUFBzAChi5odHRwOi8vY2RwMS5wb2x5Y29tLmNv bS9wa2kvUG9seWNvbS1Sb290Q0EuY3J0MDoGCCsGAQUFBzAChi5odHRwOi8vY2RwMi5wb2x5Y29t LmNvbS9wa2kvUG9seWNvbS1Sb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4ICAQDAITSF89YEDKMA zqteWVdg8IqzdMHSHIJGybNrbe1UJj6trSldu42wcgjYLgJrTIDEUEX2Qp1xywpv+zpVAE1bVoek 6ot846XEIiOTofJYnwACZNnCLJ3ijG2iuBCSJjPc6FzwCF/2DMR0erdh8PNhEnl3xDRNyqVOy+DC mlLssSjPgej1UxM4yaDZZUCBrkv1dB3a4qkTbMPFBj5CkC5gPnyKTRW7iUFMKr0pXvByGPHCtRbu ShXAcoSdVH2f8cLUfJ8raVMWu1ynjOMcvlagDaZAcbzLSc8hzhxJNC6Wel9U1uFyEaYGodJTMxzv e5zRU5wZod5kPaEThCKq12Fr9Sz/dYYp4Rup/SymTS4A46qMIrOi6i3icxa3SYAhsCeALdcrgCH4 +cCtKiEE1UpqIfJq8P/+FE6cnfHyGaXD+wn4BTA5BrUBg900HNVNf1Y6BDMqaXDeAPKbiSb5FDot PjAW0v7GLoshHMr+951EdhaFNSUyOV8CoSx9b9BjlYpjJV+QtiaqJLn9UlNOa987Fg9dIY4vrfqH q9kCVr+sVpQsZ6DC17bE7etrHPevRny/EcLmuJY1RD56gPAyePHFs1GEhmKVW9ZlLWtNs79G6wSf ZRnr3vRAtr7v0zWyjfvn52HWM4kbXedjCa/q9boJMVqK+8DJawhrrn38Liw7oDCCCIAwggZooAMC AQICE2sAANv9iRUGFNx/sYkAAAAA2/0wDQYJKoZIhvcNAQELBQAwSDETMBEGCgmSJomT8ixkARkW A2NvbTEXMBUGCgmSJomT8ixkARkWB3BvbHljb20xGDAWBgNVBAMTD1BvbHljb20tU1VCQ0EwMTAe Fw0xNjAyMTYxNzI1NTlaFw0xNzAyMTUxNzI1NTlaMIGnMRMwEQYKCZImiZPyLGQBGRYDY29tMRcw FQYKCZImiZPyLGQBGRYHcG9seWNvbTEPMA0GA1UECxMGUGVvcGxlMRIwEAYDVQQLEwlFbXBsb3ll ZXMxDTALBgNVBAsTBE5BTEExGDAWBgNVBAMTD0R1Y2t3b3J0aCwgTWFyazEpMCcGCSqGSIb3DQEJ ARYaTWFyay5EdWNrd29ydGhAcG9seWNvbS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDUKfyJTxXkwEsUnHz/9m3k1jNMh31VSjpcboNOXMLE7ERqwC+KdVON0NLHp5ctN4kWewuu YDOuS+Qhp/Pm/+T2acQ0cqw+oY3nvKl7erYfC5Ul0EATlD3aUTGz34L2iKttOm9YID2GylBH9670 PHQ7n3YqC5sh1C7l2S4CznZz5c4ATRw1VtAzWskinzwYWKeiJV2ybr4JU9EM5QAGqM84jFXV2kN2 3CGKmAWlo6GIXstg82hfTkfubmgW9BQ+iyHEfwP1DIvdLh4tsyrgHoz+qomNaXmG+jUiP5CktXDF KueQLciDeg9HyxGh7AgtTvdMtI3KZUFCDyKDN4k0ux/5AgMBAAGjggQBMIID/TA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiGpOVThtjlcoO1gRiEnaYag+m7OimFw9RYg9ngHQIBZAIBBzApBgNV HSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwCwYDVR0PBAQDAgWgMDUGCSsG AQQBgjcVCgQoMCYwCgYIKwYBBQUHAwIwCgYIKwYBBQUHAwQwDAYKKwYBBAGCNwoDBDBEBgkqhkiG 9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZI hvcNAwcwHQYDVR0OBBYEFBENjiHBionI5U/bTdJlzr9d3XeNMB8GA1UdIwQYMBaAFHCHwOe0vPcW QG7PYk/NxYXFTXnpMIIBOgYDVR0fBIIBMTCCAS0wggEpoIIBJaCCASGGgbxsZGFwOi8vL0NOPVBv bHljb20tU1VCQ0EwMSxDTj12d2NvbG9zdWJjYTAxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBT ZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXBvbHljb20sREM9Y29tP2Nl cnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Q b2ludIYvaHR0cDovL2NkcDEucG9seWNvbS5jb20vcGtpL1BvbHljb20tU1VCQ0EwMS5jcmyGL2h0 dHA6Ly9jZHAyLnBvbHljb20uY29tL3BraS9Qb2x5Y29tLVNVQkNBMDEuY3JsMIIBPQYIKwYBBQUH AQEEggEvMIIBKzCBrgYIKwYBBQUHMAKGgaFsZGFwOi8vL0NOPVBvbHljb20tU1VCQ0EwMSxDTj1B SUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlv bixEQz1wb2x5Y29tLERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTA7BggrBgEFBQcwAoYvaHR0cDovL2NkcDEucG9seWNvbS5jb20vcGtp L1BvbHljb20tU1VCQ0EwMS5jcnQwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jZHAyLnBvbHljb20uY29t L3BraS9Qb2x5Y29tLVNVQkNBMDEuY3J0MEgGA1UdEQRBMD+gIQYKKwYBBAGCNxQCA6ATDBFtYXJr ZEBwb2x5Y29tLmNvbYEaTWFyay5EdWNrd29ydGhAcG9seWNvbS5jb20wDQYJKoZIhvcNAQELBQAD ggIBAHSlqpzE3JJ6cwdt2ve4eLY7IBfvrGjyFRQRfUgHg7SpxJVjB1jIZY7xXeGcBozQDSO6nQF6 KN3s+Mhy1GgH0tRMZBqefwZaT0taRdMHH/bXxDE4Qf8BRMXNIPZPb+2CV4ldFakuT1VZwmg1Gdtc ZU41o/zXYUBkzjPRX4DaEBWDsxI8Z3OX0lz3Kps3CocagYE+sjTaPIEFF3Gztyw5I8fS/nMnrSq3 G91bqqWE0teuGfBdt6tKqavJ0qHobkOQRV2bQi6OPzLZg8a1IaSZMviUDgzj/VASvw7phEUScEVf VqAvoru/7TWREyoc/lSvsd+PTpMeOjLUDre/FAbRGpN9Sx8FuBgvvb3wYdIMg/R8tIaQ8tqaAG/3 dSa9IeRfWOrcAOuc8TUieSDsTqugStWtKVsO8dCcZtdaPpL0deSjjEF+Ep9ZfqufhibQyFGNTjRK VwgxCQc+owwJx69vo2oDlzwWYhASQmwXVW9eiSWnvvMhvAny5dftCFaV47mSyQimkQ3k/rsX2Cg9 qbeuI0dSSD5c5pgE6z3jkF8ISL/1WitwCtG5Yqqp7Q8G2a35smlSVRzc1WTAiy6jZHSPZsbnRu5Y 9BnsB/TOcmKt9kAn6VUAC4j+Rq7MokZJzmj0sKNMH4qz3bo6ZMImkGS3xCLyvsK4iilg1Me67dlz bbJ1MYIDXzCCA1sCAQEwXzBIMRMwEQYKCZImiZPyLGQBGRYDY29tMRcwFQYKCZImiZPyLGQBGRYH cG9seWNvbTEYMBYGA1UEAxMPUG9seWNvbS1TVUJDQTAxAhNrAADb/YkVBhTcf7GJAAAAANv9MAkG BSsOAwIaBQCgggHVMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2 MTEwNDE5MDcyN1owIwYJKoZIhvcNAQkEMRYEFNQpq1W6VdHlOwmKmj6PpDo5jR35MG4GCSsGAQQB gjcQBDFhMF8wSDETMBEGCgmSJomT8ixkARkWA2NvbTEXMBUGCgmSJomT8ixkARkWB3BvbHljb20x GDAWBgNVBAMTD1BvbHljb20tU1VCQ0EwMQITawAA2/2JFQYU3H+xiQAAAADb/TBwBgsqhkiG9w0B CRACCzFhoF8wSDETMBEGCgmSJomT8ixkARkWA2NvbTEXMBUGCgmSJomT8ixkARkWB3BvbHljb20x GDAWBgNVBAMTD1BvbHljb20tU1VCQ0EwMQITawAA2/2JFQYU3H+xiQAAAADb/TCBkwYJKoZIhvcN AQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCGjALBglghkgBZQMEAgMw CwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQCTp5JCUKqQjgU8aZsd 48gGAsADPl1VXXyqvlx8JbH0iY90aO+smAID5M/mEgCrcpyv+HdL8mJwoXM0HgyCTS20reXGdov2 +OK11n6fTBmM2PX1jMK4XoJQs/sPBSO2dmK5hFiM2JxX70/BKOiBMFhfEeAJ6Zs0BwYuHHN2WdHY uVuCoF6OAg2YarepbxaMBzNjsgD1K7ApBOIKKVfTzMgKjGbTVM+Y4fxYRM/El4sufwg1H/vXreUQ GSRJEC90yy0tjWEudP6a9uKW024CKokUX+FqHVP7uyHg9YYTNtTMxtq6/r6uUEy+AkFF9RauZeLX tMDF1rmlHSauNDIL1hvJAAAAAAAA ------=_NextPart_000_02AE_01D236AD.28173F60-- From nobody Mon Nov 7 03:53:43 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93918129528 for ; Mon, 7 Nov 2016 03:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62aYEVpbz6KS for ; Mon, 7 Nov 2016 03:53:39 -0800 (PST) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DB031294DD for ; Mon, 7 Nov 2016 03:53:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=in1oCc9VbO4ZpyiauLL+4tjEMK9kpEqWzgJU/akioqA=; b=DlV6df/zBSxvX36WSw/asN1gmz XuMwrNkFsD7RpA1UdU0kwq9ZL8N5lqjLdAF5LAtKUO66U3DeusKV3W71JgPfdTtCP0ocpkDfKWWoR QZ08qUPJNMhecSlMBb9widOpoblctZQ8O/jUXbhbqycBBlo1ldBbKq4Vh012SgvkvcWEckQbsvL1+ +yog3cNC0M/n34U9rG7YDw38DiKmD7JzmLqmhDDMURihG2YjdqxZMpYcW2AOxGHuN8XEe63SYKIFf l4L97c1ZYkyjNeRLqG07XS/y78jUDXog7iUj8QgNxnjSxiUYs8VKlLbuSLBsMKstvCCmk1Ms3OxIZ yI05WC1w==; Received: from ip-90-186-178-159.web.vodafone.de ([90.186.178.159]:57038 helo=[192.168.8.101]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1c3iUZ-003rWj-Eq for clue@ietf.org; Mon, 07 Nov 2016 22:53:36 +1100 To: clue@ietf.org References: From: Christian Groves Message-ID: <075716a0-ab1d-f943-50d0-a65fd339f165@nteczone.com> Date: Mon, 7 Nov 2016 22:53:28 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [clue] WGLC for draft-ietf-clue-protocol-10 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 11:53:41 -0000 Hello Paul, Here are my comments: Cl.1 bullet 1: Change "envisioned" to "defined". The information isn't some future thing. Cl.1 para 2: Change "upon" to "over". There's other instances in the draft also. Cl.1 para 3: The section says "Participant state machines" whereas the referred to section 6 is called "Protocol state machines". Cl.2 Endpoint: "...and exactly one [RFC4353 ] Participant (which, in turn, includes exactly one SIP User Agent)." Can we make the SIP aspect more as an example? E.g. A WebRTC endpoint doesn't include a SIP user agent. How about something like "...and exactly one participant (e.g. a [RFC4353] paricipant)." Cl.4 para 1: change "...we are not able..." -> "...it is not possible..." Cl.4 para 1: change "Such information is designed...." -> "Such information is contained..." Cl.4 para 2: "Three main communication layers" would it be better to say "phases" instead of "layers"? Cl.4 bullet 2: "The version and options negotiation can be performed once and only at this stage." clarification "... can be performed once during the CLUE session and ...." Cl.4 para 3: "is is", delete one. Cl.4 para 4:"After that negotiation..." -> "After the negotiation..." Cl.4 para last: "Such messages will be..." -> "Such messages are..." Cl.5: "The basic structure determines the mandatory information that is carried within each CLUE message. Such an information is made by:" can this be simplified to say "The mandatory information contained in each CLUE message is:"? Cl.5 last bullet: "Allowed values are of this kind: "1.3", "2.4", etc." change to "E.g. "1.3", "2.4" etc." Otherwise it sounds like the values are normative. General: The document talks about extensions and options. Are they different? if not should we use one term. Cl.5.2: "RESPONSE contains mandatorily..." -> "RESPONSE contains a mandatory..." Cl.5.2: Is there a reason why we indicated that both the response code AND string are mandatory? It seems like an unnecessary duplication. Its not clear that text other than what has be defined may be sent. Cl.5.2: The XML doesn't match the XML in section 9. E.g. responseCode is of type "xs:short" in section 9 its type "type="responseCodeType". Cl.5.2 last paragraph: Can the paragraph be simplified to say "Upon reception of the OPTIONS RESPONSE the version to be used is provided in the tag of the message."? Cl.5.2 last paragraph: "the CLUE dialogue will be those" -> "the CLUE dialogue are those" Cl.5.3 para 1: "The MP sends to the MC an ADV as soon " -> "The MP sends an ADV to the MC as soon..." Cl.5.3 para 1: "its media CLUE telepresence capabilities change" -> "its CLUE telepresence media capabilities change" Cl.5.3 para 1: Rather than use "invalidates" would "replaces" be better? Cl.5.3 para 2: "Picture" -> "Syntax" or "Schema". Its worth harmonising how each message section describes this. Cl.5.4: The XML doesn't match the XML in section 9. E.g. responseCode is of type "xs:short" in section 9 its type "type="responseCodeType". Cl.5.6: The XML doesn't match the XML in section 9. E.g. responseCode is of type "xs:short" in section 9 its type "type="responseCodeType". Cl.5.6/General: Do we need some text indicating that there's no partial execution of commands. E.g. If a MP is able to understand all the selected capture encodings bar one. The whole command fails and nothing is instantiated. Cl.5.7: It says future protocol version can introduce error codes? How about options? It seems like an option could introduce a specific error code. Cl.5.7: Error code 302 is duplicated. The 2nd one should be 303. Cl.6 para 5: "Otherwise ("channel error")..." Cl.6 para 1: "the MP is preparing" -> "the MP prepares" Cl.6.1&6.2: Do we need to indicate that the timeout and retry relates to the transport (e.g. SCTP) rather than application level timers/counters? I'm a bit confused about the descriptions in the draft as we have a reliable transport. Cl.6.2 para 1: "Otherwise the MC is stuck in..." -> "Otherwise the MC stays in..." Cl.6.2 para 3: "If the ADV elaboration..." -> "If the ADV processing..." Cl.6.2 para 3: "If the ADV elaboration is unsuccessful (bad syntax, missing XML elements, etc.), and the number of times this has happened is under the retry treshold," I don't understand why the retry threshold comes in here? Wouldn't the MC simply send a NACK is there's an error. It wouldn't wait for multiple instances of the erroneous message. Cl.6.2 para 3: "the MC sends a NACK message (i.e., an ACK with an error response code) to the MP describing the problem via a proper reason phrase." Isn't the reason code enough? Cl.6.2 para 4: "the MC is preparing" -> "the MC prepares". Cl.6.2 para 5: "the MC is waiting" -> "the MC waits". Cl.7 para 3: "The version of the XML schema contained in the standard document deriving from this draft will be 1.0." -> "This document defines XML schema version 1.0". Cl.8 bullet 1: "...we may want to add more fields" -> "... more fields may be added" Cl.8 I think it would be very helpful to include an example syntax showing the definition of a new capture attribute that could be used by future people as a template. Its still not clear if there's any distinction between "option" and "extension". Cl.9: Should this be "17" instead of "12" to match the version number? Does this get updated to the relevant RFC number? Cl.10.1: "The associated Media Provider's telepresence capabilities are described in [I-D.ietf-clue-data-model-schema], Section "Sample XML file"." I'm a bit confused because the example in 10.1 doesn't match the one specified in cl.27/draft-ietf-clue-data-model-schema-17. Many of the attribute values are different. Some of the syntax has different names. e.g. capturePoint->captureOrigin. Cl.10.1/10.2: protocol="CLUE" v="0.4" should this be "1.0" given this is going for WGLC? Cl.12. Do we need to establish IANA registry for clue options/extensions to manage the option names? Regards, Christian On 5/11/2016 3:26 AM, Paul Kyzivat wrote: > This message announces the start of a WGLC for > draft-ietf-clue-protocol-10. > > The last time we had a WGLC on this document was -04. Since then there > have been substantial changes: > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-clue-protocol-10.txt;url1=draft-ietf-clue-protocol-04.txt > > > I have the sense that I have been the only one reviewing and > commenting on this document along the way. It is important that we > have thorough review by others in the wg. So please give careful > attention to this document and comment back. Note that this is the > last piece of CLUE. Once this one is done we can declare victory and > close down the wg. > > Unfortunately this review is starting at a busy time: the Seoul IETF > meeting is coming in a week, and so some people will be busy with > that. And the week after that is Thanksgiving in the US, so some > people won't be off some of that week. As a result, I'm giving a > longer duration for this review, so that everyone will have an > opportunity to fit the work into their schedule somewhere. > > Starting Date: Friday, November 4, 2016 > Ending Date: Wednesday, Novemeber 30, 2016 > > Please do this so we can wrap things up. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Mon Nov 7 09:13:19 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52481299E1 for ; Mon, 7 Nov 2016 09:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.698 X-Spam-Level: X-Spam-Status: No, score=-5.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IE_g9UBol762 for ; Mon, 7 Nov 2016 09:13:15 -0800 (PST) Received: from alum-mailsec-scanner-5.mit.edu (alum-mailsec-scanner-5.mit.edu [18.7.68.17]) by ietfa.amsl.com (Postfix) with ESMTP id BD184129863 for ; Mon, 7 Nov 2016 09:13:15 -0800 (PST) X-AuditID: 12074411-ff5ff700000008d0-33-5820b62a0739 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 55.09.02256.A26B0285; Mon, 7 Nov 2016 12:13:14 -0500 (EST) Received: from [192.168.1.110] (c-73-186-127-100.hsd1.ma.comcast.net [73.186.127.100]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id uA7HDD1r010085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 7 Nov 2016 12:13:14 -0500 From: Paul Kyzivat To: clue@ietf.org References: <075716a0-ab1d-f943-50d0-a65fd339f165@nteczone.com> Message-ID: Date: Mon, 7 Nov 2016 12:13:13 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <075716a0-ab1d-f943-50d0-a65fd339f165@nteczone.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKIsWRmVeSWpSXmKPExsUixO6iqKu1TSHC4PIqC4v9py4zOzB6LFny kymAMYrLJiU1J7MstUjfLoEro3PdLMaCFueK75/6WRoY75l2MXJySAiYSOz4tp8VxBYSuMwo 8WE9UJwLyH7FJDGz/zgLSIJNQEtizqH/YLawgIXEhSMbgBo4OEQEBCVeXhGE6C2VmNq2HWwO r4C9xO/X79lAbBYBFYnDS98ygdiiAmkS29ftZoaoEZQ4OfMJ2EhOAQeJ7886GEFsZgFbiTtz IWqYBeQltr+dwzyBkW8WkpZZSMpmISlbwMi8ilEuMac0Vzc3MTOnODVZtzg5MS8vtUjXVC83 s0QvNaV0EyMkxAR3MM44KXeIUYCDUYmH90W/QoQQa2JZcWXuIUZJDiYlUd6UTUAhvqT8lMqM xOKM+KLSnNTiQ4wSHMxKIrxxW4FyvCmJlVWpRfkwKWkOFiVxXr4l6n5CAumJJanZqakFqUUw WRkODiUJXhOQRsGi1PTUirTMnBKENBMHJ8hwHqDhq7eADC8uSMwtzkyHyJ9i1OV4s+vlAyYh lrz8vFQpcd6tIEUCIEUZpXlwc2Cp4RWjONBbwrzmIOt4gGkFbtIroCVMQEuqYsCWlCQipKQa GFesO7z409GYLsaj+vfO/rtuYqXwv+d89k+BnZPumf/xPJbzQOdT5OYF3zKurlrCnp2+Y13x 3vAv/17OUF+feSOEX/t9c9NckQmel21sF3QcTnZZtp9F8Wo/O5P5LnGxqL1rfrq47lF6tG7P RPmExo2CgQ0v5mRMdio/K5nEUnMy63jH9Fsqlr+VWIozEg21mIuKEwH4CuKn6AIAAA== Archived-At: Subject: Re: [clue] WGLC for draft-ietf-clue-protocol-10 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 17:13:18 -0000 Christian, Thanks for the detailed comments. This doc really needs that level of scrutiny by a variety of people. I'll leave it to Simon to respond in detail. But some of your comments suggest to me that you were reviewing -09 rather than -10. Please double check and update your comments if needed. Thanks, Paul On 11/7/16 6:53 AM, Christian Groves wrote: > Hello Paul, > > Here are my comments: > > Cl.1 bullet 1: Change "envisioned" to "defined". The information isn't > some future thing. > > Cl.1 para 2: Change "upon" to "over". There's other instances in the > draft also. > > Cl.1 para 3: The section says "Participant state machines" whereas the > referred to section 6 is called "Protocol state machines". > > Cl.2 Endpoint: "...and exactly one [RFC4353 > ] Participant (which, in turn, > includes exactly one SIP User Agent)." Can we make the SIP aspect more > as an example? E.g. A WebRTC endpoint doesn't include a SIP user agent. > How about something like "...and exactly one participant (e.g. a > [RFC4353] paricipant)." > > Cl.4 para 1: change "...we are not able..." -> "...it is not possible..." > > Cl.4 para 1: change "Such information is designed...." -> "Such > information is contained..." > > Cl.4 para 2: "Three main communication layers" would it be better to say > "phases" instead of "layers"? > > Cl.4 bullet 2: "The version and options negotiation can be performed > once and only at this stage." clarification "... can be performed once > during the CLUE session and ...." > > Cl.4 para 3: "is is", delete one. > > Cl.4 para 4:"After that negotiation..." -> "After the negotiation..." > > Cl.4 para last: "Such messages will be..." -> "Such messages are..." > > Cl.5: "The basic structure determines the mandatory information that is > carried within each CLUE message. Such an information is made by:" > can this be simplified to say "The mandatory information contained in > each CLUE message is:"? > > Cl.5 last bullet: "Allowed values are of this kind: "1.3", "2.4", etc." > change to "E.g. "1.3", "2.4" etc." Otherwise it sounds like the values > are normative. > > General: The document talks about extensions and options. Are they > different? if not should we use one term. > > Cl.5.2: "RESPONSE contains mandatorily..." -> "RESPONSE contains a > mandatory..." > > Cl.5.2: Is there a reason why we indicated that both the response code > AND string are mandatory? It seems like an unnecessary duplication. Its > not clear that text other than what has be defined may be sent. > > Cl.5.2: The XML doesn't match the XML in section 9. E.g. responseCode is > of type "xs:short" in section 9 its type "type="responseCodeType". > > Cl.5.2 last paragraph: Can the paragraph be simplified to say "Upon > reception of the OPTIONS RESPONSE the version to be used is provided in > the tag of the message."? > > Cl.5.2 last paragraph: "the CLUE dialogue will be those" -> "the CLUE > dialogue are those" > > Cl.5.3 para 1: "The MP sends to the MC an ADV as soon " -> "The MP sends > an ADV to the MC as soon..." > > Cl.5.3 para 1: "its media CLUE telepresence capabilities change" -> "its > CLUE telepresence media capabilities change" > > Cl.5.3 para 1: Rather than use "invalidates" would "replaces" be better? > > Cl.5.3 para 2: "Picture" -> "Syntax" or "Schema". Its worth harmonising > how each message section describes this. > > Cl.5.4: The XML doesn't match the XML in section 9. E.g. responseCode is > of type "xs:short" in section 9 its type "type="responseCodeType". > > Cl.5.6: The XML doesn't match the XML in section 9. E.g. responseCode is > of type "xs:short" in section 9 its type "type="responseCodeType". > > Cl.5.6/General: Do we need some text indicating that there's no partial > execution of commands. E.g. If a MP is able to understand all the > selected capture encodings bar one. The whole command fails and nothing > is instantiated. > > Cl.5.7: It says future protocol version can introduce error codes? How > about options? It seems like an option could introduce a specific error > code. > > Cl.5.7: Error code 302 is duplicated. The 2nd one should be 303. > > Cl.6 para 5: "Otherwise ("channel error")..." > > Cl.6 para 1: "the MP is preparing" -> "the MP prepares" > > Cl.6.1&6.2: Do we need to indicate that the timeout and retry relates to > the transport (e.g. SCTP) rather than application level timers/counters? > I'm a bit confused about the descriptions in the draft as we have a > reliable transport. > > Cl.6.2 para 1: "Otherwise the MC is stuck in..." -> "Otherwise the MC > stays in..." > > Cl.6.2 para 3: "If the ADV elaboration..." -> "If the ADV processing..." > > Cl.6.2 para 3: "If the ADV elaboration is unsuccessful (bad syntax, > missing XML elements, etc.), and the number of times this has happened > is under the retry treshold," I don't understand why the retry threshold > comes in here? Wouldn't the MC simply send a NACK is there's an error. > It wouldn't wait for multiple instances of the erroneous message. > > Cl.6.2 para 3: "the MC sends a NACK message (i.e., an ACK with an > error response code) to the MP describing the problem via a proper > reason phrase." Isn't the reason code enough? > > Cl.6.2 para 4: "the MC is preparing" -> "the MC prepares". > > Cl.6.2 para 5: "the MC is waiting" -> "the MC waits". > > Cl.7 para 3: "The version of the XML schema contained in the standard > document deriving from this draft will be 1.0." -> "This document > defines XML schema version 1.0". > > Cl.8 bullet 1: "...we may want to add more fields" -> "... more fields > may be added" > > Cl.8 I think it would be very helpful to include an example syntax > showing the definition of a new capture attribute that could be used by > future people as a template. Its still not clear if there's any > distinction between "option" and "extension". > > Cl.9: schemaLocation="data-model-schema-12.xsd"/> Should this be "17" instead > of "12" to match the version number? Does this get updated to the > relevant RFC number? > > Cl.10.1: "The associated Media Provider's telepresence capabilities are > described in [I-D.ietf-clue-data-model-schema], Section "Sample XML > file"." I'm a bit confused because the example in 10.1 doesn't match > the one specified in cl.27/draft-ietf-clue-data-model-schema-17. Many of > the attribute values are different. Some of the syntax has different > names. e.g. capturePoint->captureOrigin. > > Cl.10.1/10.2: protocol="CLUE" v="0.4" should this be "1.0" given this is > going for WGLC? > > Cl.12. Do we need to establish IANA registry for clue options/extensions > to manage the option names? > > Regards, Christian > > > > > > > > > On 5/11/2016 3:26 AM, Paul Kyzivat wrote: >> This message announces the start of a WGLC for >> draft-ietf-clue-protocol-10. >> >> The last time we had a WGLC on this document was -04. Since then there >> have been substantial changes: >> >> https://tools.ietf.org/rfcdiff?url2=draft-ietf-clue-protocol-10.txt;url1=draft-ietf-clue-protocol-04.txt >> >> >> I have the sense that I have been the only one reviewing and >> commenting on this document along the way. It is important that we >> have thorough review by others in the wg. So please give careful >> attention to this document and comment back. Note that this is the >> last piece of CLUE. Once this one is done we can declare victory and >> close down the wg. >> >> Unfortunately this review is starting at a busy time: the Seoul IETF >> meeting is coming in a week, and so some people will be busy with >> that. And the week after that is Thanksgiving in the US, so some >> people won't be off some of that week. As a result, I'm giving a >> longer duration for this review, so that everyone will have an >> opportunity to fit the work into their schedule somewhere. >> >> Starting Date: Friday, November 4, 2016 >> Ending Date: Wednesday, Novemeber 30, 2016 >> >> Please do this so we can wrap things up. >> >> Thanks, >> Paul >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Mon Nov 7 10:03:12 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F351294E7 for ; Mon, 7 Nov 2016 10:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBqB0W6YUqU4 for ; Mon, 7 Nov 2016 10:03:08 -0800 (PST) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8B4112945E for ; Mon, 7 Nov 2016 10:03:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=vX/5JlBA4SdODnzN/Jd5exOA7XawbqAXmBnNAz6JiE0=; b=EK/w4eeEqtcBWrTLm9m7YOtOGV VExopl+SsWWwfvBxW85J4T/XJuqVLCrx4Zhy/7HG1xdJmR09+NF8PIWsPhkgStpyl1EQzokWa5qEH lriaApRWOA6K4jkKWMHdTLWFUi1Bk6VqfeziNHHV03LaYxc0qHCYiyhQZUQuA2n5FlfI5wHiNkHo3 hvW+cFo/BbbkzbtI9KxP1TsxnNWAKTW4AZ3zO5+9HVqI4c5dmcpHJkxeiiyM0y8k1NfhQH09VZiwt t0lTDYmcY2DP5/tm3ER9fo/lanwt9gDlL4Z++xGdm3fGPz+8l/cXU9QX6P45aPVFe4g3AEEKhHg+a v7UQh1cg==; Received: from ip-90-186-178-159.web.vodafone.de ([90.186.178.159]:49845 helo=[192.168.8.101]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1c3oG9-004MQd-28 for clue@ietf.org; Tue, 08 Nov 2016 05:03:06 +1100 To: clue@ietf.org References: <075716a0-ab1d-f943-50d0-a65fd339f165@nteczone.com> From: Christian Groves Message-ID: Date: Tue, 8 Nov 2016 05:02:38 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [clue] WGLC for draft-ietf-clue-protocol-10 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 18:03:11 -0000 Hello Paul, Pretty sure I reviewed v10. What makes you think its v9? Regards, Christian On 8/11/2016 4:13 AM, Paul Kyzivat wrote: > Christian, > > Thanks for the detailed comments. This doc really needs that level of > scrutiny by a variety of people. I'll leave it to Simon to respond in > detail. But some of your comments suggest to me that you were > reviewing -09 rather than -10. Please double check and update your > comments if needed. > > Thanks, > Paul > > On 11/7/16 6:53 AM, Christian Groves wrote: >> Hello Paul, >> >> Here are my comments: >> >> Cl.1 bullet 1: Change "envisioned" to "defined". The information isn't >> some future thing. >> >> Cl.1 para 2: Change "upon" to "over". There's other instances in the >> draft also. >> >> Cl.1 para 3: The section says "Participant state machines" whereas the >> referred to section 6 is called "Protocol state machines". >> >> Cl.2 Endpoint: "...and exactly one [RFC4353 >> ] Participant (which, in turn, >> includes exactly one SIP User Agent)." Can we make the SIP aspect more >> as an example? E.g. A WebRTC endpoint doesn't include a SIP user agent. >> How about something like "...and exactly one participant (e.g. a >> [RFC4353] paricipant)." >> >> Cl.4 para 1: change "...we are not able..." -> "...it is not >> possible..." >> >> Cl.4 para 1: change "Such information is designed...." -> "Such >> information is contained..." >> >> Cl.4 para 2: "Three main communication layers" would it be better to say >> "phases" instead of "layers"? >> >> Cl.4 bullet 2: "The version and options negotiation can be performed >> once and only at this stage." clarification "... can be performed once >> during the CLUE session and ...." >> >> Cl.4 para 3: "is is", delete one. >> >> Cl.4 para 4:"After that negotiation..." -> "After the negotiation..." >> >> Cl.4 para last: "Such messages will be..." -> "Such messages are..." >> >> Cl.5: "The basic structure determines the mandatory information that is >> carried within each CLUE message. Such an information is made by:" >> can this be simplified to say "The mandatory information contained in >> each CLUE message is:"? >> >> Cl.5 last bullet: "Allowed values are of this kind: "1.3", "2.4", etc." >> change to "E.g. "1.3", "2.4" etc." Otherwise it sounds like the values >> are normative. >> >> General: The document talks about extensions and options. Are they >> different? if not should we use one term. >> >> Cl.5.2: "RESPONSE contains mandatorily..." -> "RESPONSE contains a >> mandatory..." >> >> Cl.5.2: Is there a reason why we indicated that both the response code >> AND string are mandatory? It seems like an unnecessary duplication. Its >> not clear that text other than what has be defined may be sent. >> >> Cl.5.2: The XML doesn't match the XML in section 9. E.g. responseCode is >> of type "xs:short" in section 9 its type "type="responseCodeType". >> >> Cl.5.2 last paragraph: Can the paragraph be simplified to say "Upon >> reception of the OPTIONS RESPONSE the version to be used is provided in >> the tag of the message."? >> >> Cl.5.2 last paragraph: "the CLUE dialogue will be those" -> "the CLUE >> dialogue are those" >> >> Cl.5.3 para 1: "The MP sends to the MC an ADV as soon " -> "The MP sends >> an ADV to the MC as soon..." >> >> Cl.5.3 para 1: "its media CLUE telepresence capabilities change" -> "its >> CLUE telepresence media capabilities change" >> >> Cl.5.3 para 1: Rather than use "invalidates" would "replaces" be better? >> >> Cl.5.3 para 2: "Picture" -> "Syntax" or "Schema". Its worth harmonising >> how each message section describes this. >> >> Cl.5.4: The XML doesn't match the XML in section 9. E.g. responseCode is >> of type "xs:short" in section 9 its type "type="responseCodeType". >> >> Cl.5.6: The XML doesn't match the XML in section 9. E.g. responseCode is >> of type "xs:short" in section 9 its type "type="responseCodeType". >> >> Cl.5.6/General: Do we need some text indicating that there's no partial >> execution of commands. E.g. If a MP is able to understand all the >> selected capture encodings bar one. The whole command fails and nothing >> is instantiated. >> >> Cl.5.7: It says future protocol version can introduce error codes? How >> about options? It seems like an option could introduce a specific error >> code. >> >> Cl.5.7: Error code 302 is duplicated. The 2nd one should be 303. >> >> Cl.6 para 5: "Otherwise ("channel error")..." >> >> Cl.6 para 1: "the MP is preparing" -> "the MP prepares" >> >> Cl.6.1&6.2: Do we need to indicate that the timeout and retry relates to >> the transport (e.g. SCTP) rather than application level timers/counters? >> I'm a bit confused about the descriptions in the draft as we have a >> reliable transport. >> >> Cl.6.2 para 1: "Otherwise the MC is stuck in..." -> "Otherwise the MC >> stays in..." >> >> Cl.6.2 para 3: "If the ADV elaboration..." -> "If the ADV processing..." >> >> Cl.6.2 para 3: "If the ADV elaboration is unsuccessful (bad syntax, >> missing XML elements, etc.), and the number of times this has happened >> is under the retry treshold," I don't understand why the retry threshold >> comes in here? Wouldn't the MC simply send a NACK is there's an error. >> It wouldn't wait for multiple instances of the erroneous message. >> >> Cl.6.2 para 3: "the MC sends a NACK message (i.e., an ACK with an >> error response code) to the MP describing the problem via a proper >> reason phrase." Isn't the reason code enough? >> >> Cl.6.2 para 4: "the MC is preparing" -> "the MC prepares". >> >> Cl.6.2 para 5: "the MC is waiting" -> "the MC waits". >> >> Cl.7 para 3: "The version of the XML schema contained in the standard >> document deriving from this draft will be 1.0." -> "This document >> defines XML schema version 1.0". >> >> Cl.8 bullet 1: "...we may want to add more fields" -> "... more fields >> may be added" >> >> Cl.8 I think it would be very helpful to include an example syntax >> showing the definition of a new capture attribute that could be used by >> future people as a template. Its still not clear if there's any >> distinction between "option" and "extension". >> >> Cl.9: > schemaLocation="data-model-schema-12.xsd"/> Should this be "17" instead >> of "12" to match the version number? Does this get updated to the >> relevant RFC number? >> >> Cl.10.1: "The associated Media Provider's telepresence capabilities are >> described in [I-D.ietf-clue-data-model-schema], Section "Sample XML >> file"." I'm a bit confused because the example in 10.1 doesn't match >> the one specified in cl.27/draft-ietf-clue-data-model-schema-17. Many of >> the attribute values are different. Some of the syntax has different >> names. e.g. capturePoint->captureOrigin. >> >> Cl.10.1/10.2: protocol="CLUE" v="0.4" should this be "1.0" given this is >> going for WGLC? >> >> Cl.12. Do we need to establish IANA registry for clue options/extensions >> to manage the option names? >> >> Regards, Christian >> >> >> >> >> >> >> >> >> On 5/11/2016 3:26 AM, Paul Kyzivat wrote: >>> This message announces the start of a WGLC for >>> draft-ietf-clue-protocol-10. >>> >>> The last time we had a WGLC on this document was -04. Since then there >>> have been substantial changes: >>> >>> https://tools.ietf.org/rfcdiff?url2=draft-ietf-clue-protocol-10.txt;url1=draft-ietf-clue-protocol-04.txt >>> >>> >>> >>> I have the sense that I have been the only one reviewing and >>> commenting on this document along the way. It is important that we >>> have thorough review by others in the wg. So please give careful >>> attention to this document and comment back. Note that this is the >>> last piece of CLUE. Once this one is done we can declare victory and >>> close down the wg. >>> >>> Unfortunately this review is starting at a busy time: the Seoul IETF >>> meeting is coming in a week, and so some people will be busy with >>> that. And the week after that is Thanksgiving in the US, so some >>> people won't be off some of that week. As a result, I'm giving a >>> longer duration for this review, so that everyone will have an >>> opportunity to fit the work into their schedule somewhere. >>> >>> Starting Date: Friday, November 4, 2016 >>> Ending Date: Wednesday, Novemeber 30, 2016 >>> >>> Please do this so we can wrap things up. >>> >>> Thanks, >>> Paul >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Wed Nov 9 14:38:32 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 107F5129543 for ; Wed, 9 Nov 2016 14:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.698 X-Spam-Level: X-Spam-Status: No, score=-5.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghyUhg5N-IWi for ; Wed, 9 Nov 2016 14:38:28 -0800 (PST) Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEB4127ABE for ; Wed, 9 Nov 2016 14:38:28 -0800 (PST) X-AuditID: 12074413-991ff70000000a14-ac-5823a563100a Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 36.93.02580.365A3285; Wed, 9 Nov 2016 17:38:27 -0500 (EST) Received: from [192.168.1.110] (c-73-186-127-100.hsd1.ma.comcast.net [73.186.127.100]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id uA9McQe5006890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 9 Nov 2016 17:38:27 -0500 From: Paul Kyzivat To: clue@ietf.org References: <075716a0-ab1d-f943-50d0-a65fd339f165@nteczone.com> Message-ID: <5422de4a-7a93-dc4d-9e02-bf7d63d9a73e@alum.mit.edu> Date: Wed, 9 Nov 2016 17:38:26 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOIsWRmVeSWpSXmKPExsUixO6iqJu8VDnC4P9bRYv9py4zOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4/Ch3YwF/7wr1v9aztTAeNi2i5GTQ0LARGJxw3a2LkYuDiGB y4wSa6behXJeMUnM3/iTGaSKTUBLYs6h/ywgtrCAhcSFIxtYuxg5OEQEBCVeXhGEqH/IKHF/ ewsjSA2vgL3Es96jTCA2i4CKxIlZl8F6RQXSJLav280MUSMocXLmE7A4p4CDxOctJ8HqmQVs Je7MhahhFpCX2P52DvMERr5ZSFpmISmbhaRsASPzKka5xJzSXN3cxMyc4tRk3eLkxLy81CJd c73czBK91JTSTYyQMBPewbjrpNwhRgEORiUe3gfayhFCrIllxZW5hxglOZiURHnreoFCfEn5 KZUZicUZ8UWlOanFhxglOJiVRHj7lwDleFMSK6tSi/JhUtIcLErivGpL1P2EBNITS1KzU1ML UotgsjIcHEoSvOEgjYJFqempFWmZOSUIaSYOTpDhPEDDk8GGFxck5hZnpkPkTzHqcrzZ9fIB kxBLXn5eqpQ4r+lioCIBkKKM0jy4ObD08IpRHOgtYd7rIKN4gKkFbtIroCVMQEuqYhRAlpQk IqSkGhj9P0dH3/kh0WP+2uV1xfYDb1OjZGb0BBjIrKsw3DKj+3ZfmbLPxsNN7LU+axTUZd0i v0QxSdRdctXIYizOWuZ2t88k5fusi6+v+766/EAuzvXuxe9fF3gYi4oIfFKtdtdY+eyw/hPP DVIPZe5lzljw42Jf/XzuGL09nXadGlKr/xodnfqne5sSS3FGoqEWc1FxIgBQ7Pci6gIAAA== Archived-At: Subject: Re: [clue] WGLC for draft-ietf-clue-protocol-10 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 22:38:31 -0000 On 11/7/16 1:02 PM, Christian Groves wrote: > Hello Paul, > > Pretty sure I reviewed v10. What makes you think its v9? Sorry, I take it back. I was working from memory at the time, and misinterpreted a couple of things you called out that was thinking had been fixed in the move from -09 to -10. Sorry, Paul > Regards, Christian > > > On 8/11/2016 4:13 AM, Paul Kyzivat wrote: >> Christian, >> >> Thanks for the detailed comments. This doc really needs that level of >> scrutiny by a variety of people. I'll leave it to Simon to respond in >> detail. But some of your comments suggest to me that you were >> reviewing -09 rather than -10. Please double check and update your >> comments if needed. >> >> Thanks, >> Paul >> >> On 11/7/16 6:53 AM, Christian Groves wrote: >>> Hello Paul, >>> >>> Here are my comments: >>> >>> Cl.1 bullet 1: Change "envisioned" to "defined". The information isn't >>> some future thing. >>> >>> Cl.1 para 2: Change "upon" to "over". There's other instances in the >>> draft also. >>> >>> Cl.1 para 3: The section says "Participant state machines" whereas the >>> referred to section 6 is called "Protocol state machines". >>> >>> Cl.2 Endpoint: "...and exactly one [RFC4353 >>> ] Participant (which, in turn, >>> includes exactly one SIP User Agent)." Can we make the SIP aspect more >>> as an example? E.g. A WebRTC endpoint doesn't include a SIP user agent. >>> How about something like "...and exactly one participant (e.g. a >>> [RFC4353] paricipant)." >>> >>> Cl.4 para 1: change "...we are not able..." -> "...it is not >>> possible..." >>> >>> Cl.4 para 1: change "Such information is designed...." -> "Such >>> information is contained..." >>> >>> Cl.4 para 2: "Three main communication layers" would it be better to say >>> "phases" instead of "layers"? >>> >>> Cl.4 bullet 2: "The version and options negotiation can be performed >>> once and only at this stage." clarification "... can be performed once >>> during the CLUE session and ...." >>> >>> Cl.4 para 3: "is is", delete one. >>> >>> Cl.4 para 4:"After that negotiation..." -> "After the negotiation..." >>> >>> Cl.4 para last: "Such messages will be..." -> "Such messages are..." >>> >>> Cl.5: "The basic structure determines the mandatory information that is >>> carried within each CLUE message. Such an information is made by:" >>> can this be simplified to say "The mandatory information contained in >>> each CLUE message is:"? >>> >>> Cl.5 last bullet: "Allowed values are of this kind: "1.3", "2.4", etc." >>> change to "E.g. "1.3", "2.4" etc." Otherwise it sounds like the values >>> are normative. >>> >>> General: The document talks about extensions and options. Are they >>> different? if not should we use one term. >>> >>> Cl.5.2: "RESPONSE contains mandatorily..." -> "RESPONSE contains a >>> mandatory..." >>> >>> Cl.5.2: Is there a reason why we indicated that both the response code >>> AND string are mandatory? It seems like an unnecessary duplication. Its >>> not clear that text other than what has be defined may be sent. >>> >>> Cl.5.2: The XML doesn't match the XML in section 9. E.g. responseCode is >>> of type "xs:short" in section 9 its type "type="responseCodeType". >>> >>> Cl.5.2 last paragraph: Can the paragraph be simplified to say "Upon >>> reception of the OPTIONS RESPONSE the version to be used is provided in >>> the tag of the message."? >>> >>> Cl.5.2 last paragraph: "the CLUE dialogue will be those" -> "the CLUE >>> dialogue are those" >>> >>> Cl.5.3 para 1: "The MP sends to the MC an ADV as soon " -> "The MP sends >>> an ADV to the MC as soon..." >>> >>> Cl.5.3 para 1: "its media CLUE telepresence capabilities change" -> "its >>> CLUE telepresence media capabilities change" >>> >>> Cl.5.3 para 1: Rather than use "invalidates" would "replaces" be better? >>> >>> Cl.5.3 para 2: "Picture" -> "Syntax" or "Schema". Its worth harmonising >>> how each message section describes this. >>> >>> Cl.5.4: The XML doesn't match the XML in section 9. E.g. responseCode is >>> of type "xs:short" in section 9 its type "type="responseCodeType". >>> >>> Cl.5.6: The XML doesn't match the XML in section 9. E.g. responseCode is >>> of type "xs:short" in section 9 its type "type="responseCodeType". >>> >>> Cl.5.6/General: Do we need some text indicating that there's no partial >>> execution of commands. E.g. If a MP is able to understand all the >>> selected capture encodings bar one. The whole command fails and nothing >>> is instantiated. >>> >>> Cl.5.7: It says future protocol version can introduce error codes? How >>> about options? It seems like an option could introduce a specific error >>> code. >>> >>> Cl.5.7: Error code 302 is duplicated. The 2nd one should be 303. >>> >>> Cl.6 para 5: "Otherwise ("channel error")..." >>> >>> Cl.6 para 1: "the MP is preparing" -> "the MP prepares" >>> >>> Cl.6.1&6.2: Do we need to indicate that the timeout and retry relates to >>> the transport (e.g. SCTP) rather than application level timers/counters? >>> I'm a bit confused about the descriptions in the draft as we have a >>> reliable transport. >>> >>> Cl.6.2 para 1: "Otherwise the MC is stuck in..." -> "Otherwise the MC >>> stays in..." >>> >>> Cl.6.2 para 3: "If the ADV elaboration..." -> "If the ADV processing..." >>> >>> Cl.6.2 para 3: "If the ADV elaboration is unsuccessful (bad syntax, >>> missing XML elements, etc.), and the number of times this has happened >>> is under the retry treshold," I don't understand why the retry threshold >>> comes in here? Wouldn't the MC simply send a NACK is there's an error. >>> It wouldn't wait for multiple instances of the erroneous message. >>> >>> Cl.6.2 para 3: "the MC sends a NACK message (i.e., an ACK with an >>> error response code) to the MP describing the problem via a proper >>> reason phrase." Isn't the reason code enough? >>> >>> Cl.6.2 para 4: "the MC is preparing" -> "the MC prepares". >>> >>> Cl.6.2 para 5: "the MC is waiting" -> "the MC waits". >>> >>> Cl.7 para 3: "The version of the XML schema contained in the standard >>> document deriving from this draft will be 1.0." -> "This document >>> defines XML schema version 1.0". >>> >>> Cl.8 bullet 1: "...we may want to add more fields" -> "... more fields >>> may be added" >>> >>> Cl.8 I think it would be very helpful to include an example syntax >>> showing the definition of a new capture attribute that could be used by >>> future people as a template. Its still not clear if there's any >>> distinction between "option" and "extension". >>> >>> Cl.9: >> schemaLocation="data-model-schema-12.xsd"/> Should this be "17" instead >>> of "12" to match the version number? Does this get updated to the >>> relevant RFC number? >>> >>> Cl.10.1: "The associated Media Provider's telepresence capabilities are >>> described in [I-D.ietf-clue-data-model-schema], Section "Sample XML >>> file"." I'm a bit confused because the example in 10.1 doesn't match >>> the one specified in cl.27/draft-ietf-clue-data-model-schema-17. Many of >>> the attribute values are different. Some of the syntax has different >>> names. e.g. capturePoint->captureOrigin. >>> >>> Cl.10.1/10.2: protocol="CLUE" v="0.4" should this be "1.0" given this is >>> going for WGLC? >>> >>> Cl.12. Do we need to establish IANA registry for clue options/extensions >>> to manage the option names? >>> >>> Regards, Christian >>> >>> >>> >>> >>> >>> >>> >>> >>> On 5/11/2016 3:26 AM, Paul Kyzivat wrote: >>>> This message announces the start of a WGLC for >>>> draft-ietf-clue-protocol-10. >>>> >>>> The last time we had a WGLC on this document was -04. Since then there >>>> have been substantial changes: >>>> >>>> https://tools.ietf.org/rfcdiff?url2=draft-ietf-clue-protocol-10.txt;url1=draft-ietf-clue-protocol-04.txt >>>> >>>> >>>> >>>> I have the sense that I have been the only one reviewing and >>>> commenting on this document along the way. It is important that we >>>> have thorough review by others in the wg. So please give careful >>>> attention to this document and comment back. Note that this is the >>>> last piece of CLUE. Once this one is done we can declare victory and >>>> close down the wg. >>>> >>>> Unfortunately this review is starting at a busy time: the Seoul IETF >>>> meeting is coming in a week, and so some people will be busy with >>>> that. And the week after that is Thanksgiving in the US, so some >>>> people won't be off some of that week. As a result, I'm giving a >>>> longer duration for this review, so that everyone will have an >>>> opportunity to fit the work into their schedule somewhere. >>>> >>>> Starting Date: Friday, November 4, 2016 >>>> Ending Date: Wednesday, Novemeber 30, 2016 >>>> >>>> Please do this so we can wrap things up. >>>> >>>> Thanks, >>>> Paul >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Fri Nov 11 15:11:09 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6CD7129841 for ; Fri, 11 Nov 2016 15:11:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=plcm365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TmbXgS5Zw1t for ; Fri, 11 Nov 2016 15:11:05 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A1991296ED for ; Fri, 11 Nov 2016 15:11:05 -0800 (PST) Received: from [216.82.242.46] by server-11.bemta-8.messagelabs.com id 81/A3-05157-80056285; Fri, 11 Nov 2016 23:11:04 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSfUgTcRjH97vb1jW9POfSx2FEK6UXNxMypBT 8rxfwpaBQi/LMy622m+ymLoqyzFrLYlriFCMDiV4kSamWUppZw1nRK1bYi6iVVmRhmS9kO+80 ++9zz/d5vr/vczwEruyRqwnGZmUsLG3UyBXS4h8JF7VESkTq8mea2GbvMzwBra2pGcFSULrMw GaabRkyffWlXTl2J7LZD0UVoI+FyIEIAqh14PaoHUhBKCkPgstNd6X8h5Q6isOZD+MyB5rtU0 owaC9cL3S1Iuh1tuG8IKdWwJeRtxjvpKLCofhlIl8OoiLht+cw4llFRcPVHo/IOhgvGZpkqa/ ddbpfyo+S1FaoezT5FKKCYdhbi/GMUyHwuvfsJAOlgu4nHXKB50J/zx+xfyu0NXqRUF8Fxfcr JvMDVSODhl+DUkFIhKreAWyKP11xika74US/XRxOg7I6Fy4MP0DQOXFNbAoDp6NdFIpk0NHQj At/ZQd0FjTIhI3V8Ob5MSRwGHzquiUTVihGUORW8ExSgdBe0SsmSobmk52znCiicsamlTNGKm eMCPV06HJ+xwXWQuPtFpHnw42vVSJHwpF3HSIvg/PnPou8Glyjd+QCL4DTx7tnCRwDn+99R9X I7xJazDGWPMaijY7RZVoM2XqriTYYtdHLY3UmhuPobMZIZ3K6HWZTPfId3AGJBLlRy8c1rSiU wDRzySV94anKOZnmrD16mtNvt+QaGa4VhRGEBsi6pIhUZaCFyWZsOw1G39VOyUD4a1Tkl0SfT HI5tIkzZAuSF2mJtsHB95hSyppZRh1CunkPim/S57LTFlO3/xTNUweRSCKRKP1zGIvJYP1fH0 AhBNIEkQ95F38Da51+acAXAvOFcG1bxIew0v8kdQGac/MbMmsefu2KHcrorK2KK3WVX/8ZjK3 VZhXZRyvyhjLwzX5X32ck5W8ZdrHJBtalirwxsXLDBb+07oaApS1jLwK2RLjK8yv3Bz1tmv2K 3bgzrolw23fdLo1SXIs7mB6vSqufv/5x/BizKTTRT7e37HH9Ke9CR1ZUEnV9JOfFvj6NlNPT0 UtxC0f/Bej6lyX2AwAA X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-11.tower-96.messagelabs.com!1478905863!43345870!1 X-Originating-IP: [140.242.64.169] X-StarScan-Received: X-StarScan-Version: 9.0.13; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16833 invoked from network); 11 Nov 2016 23:11:03 -0000 Received: from mailrelay.polycom.com (HELO SACWPEXEDGE02V.polycom.com) (140.242.64.169) by server-11.tower-96.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 11 Nov 2016 23:11:03 -0000 X-CrossPremisesHeadersFilteredBySendConnector: SACWPEXEDGE02V.polycom.com Received: from NAM03-DM3-obe.outbound.protection.outlook.com (207.46.163.15) by mailrelay.polycom.com (10.244.6.169) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 11 Nov 2016 15:11:04 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=plcm365.onmicrosoft.com; s=selector1-polycom-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pbxvOJ5xPT60NwN3VfUil51IkzJWDs5X2iSx041OD80=; b=PkCxy3s0+cRLGGqDvHrzredLsMA+KwvvB4kHnscE3XqCE5AguycV+IjR58CBK/RKDX3UaAzZ+I+zwrSaTr6cVuzPP71G5SPQzCRvzecVNCI8mCJUsO07lDOiushwfXu44vQMmPru/E6OnR0AxlyOVFqIL5MpYe3za/EiYMqpO14= Received: from BN6PR10MB1395.namprd10.prod.outlook.com (10.173.30.17) by BN6PR10MB1396.namprd10.prod.outlook.com (10.173.30.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Fri, 11 Nov 2016 23:11:01 +0000 Received: from BN6PR10MB1395.namprd10.prod.outlook.com ([10.173.30.17]) by BN6PR10MB1395.namprd10.prod.outlook.com ([10.173.30.17]) with mapi id 15.01.0693.009; Fri, 11 Nov 2016 23:11:01 +0000 From: "Duckworth, Mark" To: "'clue@ietf.org'" Thread-Topic: Mark's WGLC comments on protocol-10 Thread-Index: AdI8cIRoDTmygyj+TwOaZxz7lqqQQA== Date: Fri, 11 Nov 2016 23:11:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [2601:18c:8800:1250:8c81:260d:f2cc:b87a] x-microsoft-exchange-diagnostics: 1; BN6PR10MB1396; 7:vOadULHJQeBMOzRGHZSVmth7ejAJWNe66Z7lirovFUDEXLn+AJovTAp8/r9/f2IagJfR1+ixwW2/7Jusu2o9UA1JWbGYrTP9q9LvUppbwDpWKRRD6xtxoWpEVNGBgifSa3WVedtYHYng5R2vPqNWIgN2tTjThhqTJmGlEj/7ni5gIg04LGpGXTD43aBALuSbJG7dQcYJiEZwr7g/bbXuePFDO+ktTc3uHn2Xy4P99A//FMRjpgtlFAPrL6nruwzGolqkAvY2oWl37x44o7ARX2N6WCpFDFv+ipkqy/oi9oMlUOheOADRNRwrqzeKRpMcRlyDqCYniJwJA2K0TzgSvyJI54LgEHNn8BXLyawy5Fs=; 20:CaZKjuS+SkSSU3dWiLhzKJTOIJzS6sELnS2wis1w4Fz3jyTgo/4h/DWUmnzhlXiOh9g96acr4KF9HouiCo38YMyUACEWCWvnyOf43TKxagbwmjHoXn6f2ex2Kc8th8iobA/eDNMiQN3WV6vNArKSRC58W9ANblpI1zzpvMjFKRPmLN5q5kSmcWolYEXuDyrAo3iGva05wN9RB8LJ1P7G8iG4D8nZ93ErWLL8YOlToN7tGZaqpAGeSY7Ml4WkdtK6 x-ms-office365-filtering-correlation-id: 1974c194-28db-4f1f-6db8-08d40a8800bc x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR10MB1396; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(131327999870524)(788757137089)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BN6PR10MB1396; BCL:0; PCL:0; RULEID:; SRVR:BN6PR10MB1396; x-forefront-prvs: 012349AD1C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(189002)(57704003)(199003)(7736002)(86362001)(7846002)(110136003)(2906002)(92566002)(3660700001)(105586002)(450100001)(2900100001)(122556002)(8936002)(99286002)(5660300001)(106356001)(81166006)(7696004)(81156014)(3280700002)(77096005)(102836003)(790700001)(6116002)(74316002)(586003)(76576001)(107886002)(6916009)(87936001)(101416001)(54356999)(189998001)(33656002)(8676002)(68736007)(97736004)(99936001)(50986999)(9686002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR10MB1396; H:BN6PR10MB1395.namprd10.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: polycom.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0FF2_01D23C46.F20E81E0" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2016 23:11:00.6778 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d0880d3f-e6d1-4a41-9e81-b8fbcddf7b6c X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR10MB1396 X-OriginatorOrg: polycom.com X-OrganizationHeadersPreserved: SACWPEXEDGE02V.polycom.com Archived-At: Subject: [clue] Mark's WGLC comments on protocol-10 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 23:11:08 -0000 ------=_NextPart_000_0FF2_01D23C46.F20E81E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0FF3_01D23C46.F20E81E0" ------=_NextPart_001_0FF3_01D23C46.F20E81E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The document is in good shape. I have some minor and editorial comments. 4. "three main communication layers" - I agree with Christian these are phases, not layers. 5. clueId - it still isn't clear to me what is the use of this element. It seems wasteful to include this element in every message. Simon previously said "In my view, it is just a name for the CP". But what is it used for? Can we delete clueId if it has no purpose? Or if it has a purpose and is meant to be static, can we make it part of the options message exchange rather than every message? And explain what the purpose is? "Each CP MUST be able to manage up to three (independent) streams of sequence numbers" - sounds to me like it is really six streams of sequence numbers. Because each of the three "streams" described actually has separate independent sequence numbers for each direction. - initiation phase send - initiation phase receive - MP send - MP receive - MC send - MC receive It also is misleading because it is not required to be both an MC and an MP, so possibly only one of those applies. So it could be either four streams of sequence numbers, or six streams. 5.2 "copied in the the" remove a "the" 5.3 "an MP may send new ADV messages to replace the previously advertised options" - this could be misunderstood as relating to the options messages in the initiation phase. How about "an MP may send new ADV messages to replace the previous advertisement" Christian wrote: "Cl.6.1&6.2: Do we need to indicate that the timeout and retry relates to the transport (e.g. SCTP) rather than application level timers/counters? I'm a bit confused about the descriptions in the draft as we have a reliable transport" I thought the timeout and retry stuff was application level, not to account for transport errors but rather to account for application behavior such as an application not responding for whatever reason. So I think it does need to be clarified if Christian and I interpreted it differently. Christian wrote: "Cl.6.2 para 3: "If the ADV elaboration is unsuccessful (bad syntax, missing XML elements, etc.), and the number of times this has happened is under the retry treshold," I don't understand why the retry threshold comes in here? Wouldn't the MC simply send a NACK is there's an error. It wouldn't wait for multiple instances of the erroneous message." My understanding is it gives the MP an opportunity to send a different advertisement after it receives a nack. It doesn't have to send another copy of the same advertisement. 10.1 simple ADV - I suggest updating this to be consistent with the sample XML file in the data model. We already fixed some problems with that sample XML. I see problems, probably the same ones we already fixed, here in the simple ADV example. For example captureID AC0 is a video capture but the description says "main audio from the room". And on page 36 sceneView SE3 and SE4 are the same, so that is a mistake. I think we've done a good review of the XML in the data model, so let's just use that as much as possible to avoid new mistakes in this document. 10.2 - same comment, I suggest using the already reviewed XML from the data model, and show it here in the protocol message envelope. Mark ------=_NextPart_001_0FF3_01D23C46.F20E81E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The document is in good shape. I have some minor and = editorial comments.

 

4. = "three main communication layers" - I agree with Christian = these are phases, not layers.

 

5. clueId - = it still isn't clear to me what is the use of this element. It seems = wasteful to include this element in every message.

Simon previously said "In my view, it is just a = name for the CP". But what is it used for? Can we delete clueId if = it has no purpose?

Or if it has a = purpose and is meant to be static, can we make it part of the options = message exchange rather than every message? And explain what the purpose = is?

 

"Each CP MUST be able to manage up to three = (independent) streams of

sequence = numbers" - sounds to me like it is really six streams of sequence = numbers. Because each of the three "streams" described = actually has separate independent sequence numbers for each = direction.

- initiation phase = send

- initiation phase = receive

- MP send

- MP receive

- MC = send

- MC receive

It also is misleading because it is not required to be = both an MC and an MP, so possibly only one of those applies. So it could = be either four streams of sequence numbers, or six = streams.

 

5.2 "copied in the the" remove a = "the"

 

5.3 "an = MP may send new ADV messages to replace the previously advertised = options" - this could be misunderstood as relating to the options = messages in the initiation phase. How about "an MP may send new ADV = messages to replace the previous advertisement"

 

Christian = wrote: "Cl.6.1&6.2: Do we need to indicate that the timeout and = retry relates to the transport (e.g. SCTP) rather than application level = timers/counters? I'm a bit confused about the descriptions in the draft = as we have a reliable transport"

I thought the timeout and retry stuff was application = level, not to account for transport errors but rather to account for = application behavior such as an application not responding for whatever = reason. So I think it does need to be clarified if Christian and I = interpreted it differently.

 

Christian = wrote: "Cl.6.2 para 3: "If the ADV elaboration is unsuccessful = (bad syntax, missing XML elements, etc.), and the number of times this = has happened is under the retry treshold," I don't understand why = the retry threshold comes in here? Wouldn't the MC simply send a NACK is = there's an error. It wouldn't wait for multiple instances of the = erroneous message."

My = understanding is it gives the MP an opportunity to send a different = advertisement after it receives a nack. It doesn't have to send another = copy of the same advertisement.

 

10.1 simple = ADV - I suggest updating this to be consistent with the sample XML file = in the data model. We already fixed some problems with that sample XML. = I see problems, probably the same ones we already fixed, here in the = simple ADV example. For example captureID AC0 is a video capture but the = description says "main audio from the room". And on page 36 = sceneView SE3 and SE4 are the same, so that is a mistake. I think we've = done a good review of the XML in the data model, so let's just use that = as much as possible to avoid new mistakes in this = document.

 

10.2 - same comment, I suggest using the already = reviewed XML from the data model, and show it here in the protocol = message envelope.

 

Mark

------=_NextPart_001_0FF3_01D23C46.F20E81E0-- ------=_NextPart_000_0FF2_01D23C46.F20E81E0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUEjCCBQ0w ggL1oAMCAQICEBrVY02YeFKcQ+zVfznU/o4wDQYJKoZIhvcNAQEFBQAwGTEXMBUGA1UEAxMOUG9s eWNvbS1Sb290Q0EwHhcNMTMxMTA0MTg1NzA2WhcNMjMxMTA0MTkwNjU4WjAZMRcwFQYDVQQDEw5Q b2x5Y29tLVJvb3RDQTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAMzj+6krY3OF7mtq +O2/yC5heUML7DFZn2cp0Mkp/vos7TDrysGdPDdEIK+zYvZQZs6TrGzPh0XXnEpMcHE7V4nD5zN3 VX0+Zg46w0wCHdkgq/GV3EKlyg0AsX8LgooGlUMeuUNpe+sT0WBl3mXB97TUw7mnRLY1m/IAlyFv 4XO8LfQ1L03vfLBRAVft7xc9Okm6DbHrPxFx9VKpgIkSIUvIx/BK0zXBa/0arWW3tfimfY9t5KdJ Wqb68E8Nb0bD8S0Ve0O76TCR4dVE/HmVj6YrauGcUGfvB4yT+bOOCGlsOw3NoHW2G9PZJF9B9PvV cWzv9Jw3AlzGU2sQMbVD1ZiiRgkG47bvqvi/tg38vWEDMj1lzSpMp/FhC8YrSaGb4YwjM52w9MXM DNypbOFZ/0WjrykwuGB1P9Ga38nRlaMkMJ3lE7P1pQMgxElO5uE+1TI5kTJ9mIGgQtQb57w4vkkJ kHNKjmqzOo3IFkhEIUS3ARPkYG4HWzP7xtmcYBoEx4QwpbxYQKKcxN9h/zuv9LYc79WvnF+i+aj0 1YJKoldsPnIXhG3HullYVQb+v19q8cqm0OGUEq7e2wY72H6JiT6YFc5kZitpZ65L5d1OGVLyFO6b iC79ARA9eBE5L3g9zF/du+U1k9L6LWW3VaHr3ZDCECU8ZX5QeBrqv2aTb0VNAgMBAAGjUTBPMAsG A1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSMD03mpjCj/UgRICWESaXA53z3 0TAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG9w0BAQUFAAOCAgEAs02vFW5Je6895ZBWadxy5vxR z2imWk97qU2sMFSMnmf9QeqPwdawGO33zWr1sSQr8d67AHQc+3ihZuoAaeQAAC6Lww9r17Q3vVqg 7Qge86101Xw1fjXqTFUnWTxBK0S7re7pMqWlqaFgFQOHBMLnrM9z+NQIyDh7st9JjA+bRfFwErQ9 5CziXu+o/4q7eDBP1WaI0yKkEcOQ2LyPuCCE4hcshcJABiSYPax8nW71foHb+bv92IYvYXu2Wpa6 VgnxYqdi2k0Yk8CDiYalVsc+7QH0euQ1YIcovPbpZ02AirLqiiy6XB9i8OKfuapKSftsdfjLKqwI L7lKqz/4uAheETQsORVEh4IT0P8RRaIgHBOBVz/DOW+/IiiYagOJIYqbwGIFImQ7uOLNCoP5qY4y PLUZhmHFnnr7xtz4gv455KP9cwtPYcAarc/IB7WkTmEhFYa19k4jXlZ19AZIO/SPhvV7qz50zqB+ pCReRB5fXnf3qhRSw2WpRD4xr/q8OrWTfQRdXaooTJ14tRziqjEWLz4nPQKbE45aAjgwO0Rp6k5J tWGPhCxmuru/iqVES98VbjuAoo2qYZk7eNrqcnMuSxgqU0bgyie/R/FfMcbsw6rAh7T+qfBSxVIQ tpiqPwtZR5kdi6af3vf4w9q1PvEGrNipAjKEN2HW73558qGfPMowggZ5MIIEYaADAgECAhNuAAAA AgUmZh85ZflDAAAAAAACMA0GCSqGSIb3DQEBBQUAMBkxFzAVBgNVBAMTDlBvbHljb20tUm9vdENB MB4XDTEzMTEwNDE5MTM1MFoXDTIzMTEwNDE5MDY1OFowSDETMBEGCgmSJomT8ixkARkWA2NvbTEX MBUGCgmSJomT8ixkARkWB3BvbHljb20xGDAWBgNVBAMTD1BvbHljb20tU1VCQ0EwMTCCAiIwDQYJ KoZIhvcNAQEBBQADggIPADCCAgoCggIBAOZhKwn7h/qKsHx8zQQPT356Og5GOOJ26SKfzS6dIZaD NjFIhS/5QRd3HZ9I1qFD8faDfpIHL+NzC0xqYJUZsEKntD+cCj99nx33t9D6GCmsEEngeLV0FO/u DlDcCXVJNJWS65E05vKyWFPlIRegDs+E73mNh3dHZ53mgrsCFd8PnX5Zm6zm+dAinDTUreXzSuzT si5yuZ10jHdEoin3bQyYQfAe4nR7BiqcQzYnD+JgU+NrZZ555xMdwVtRhjIFuFHwCN1BgWL8+cmI PTmW3bS/irYkbUn/IYFXGJIdgeZTzsp22+OPChBkCBiy86d9RaM6qvOV/ZLmq0bj4souN1cNBg0g ZnYIgTypQY/5Ew99FJJDor4TH1R5YNtqgwxBiSZSc0WSKy8WBrcUpBM+FP1gETY2sqZh2ApFkhU1 7BBLXcEwu6dnSO9Y5u0zJfOTKPesVaeGTfvzTEcm6A8xKO6V+ai/zhu3egbv4SmlPGiMENMPsWRy cG0c73xz/w9RwpWpImjIcE3+XA9rPhIdNj2KN4sbMJvvN5/ZLJHRScE5F3pltq2sFLyPSqhukYVY NRVXmdJ14FCArDqlrREeWLA2tP4ir0WeFeX6KgU+QrmWvdw1hJZ9/lPkiqDvuBWvDVyON0u/Dvi3 p6RJmWJlC5F8ajRegnM+BAYfokRZkvOHAgMBAAGjggGJMIIBhTAQBgkrBgEEAYI3FQEEAwIBADAd BgNVHQ4EFgQUcIfA57S89xZAbs9iT83FhcVNeekwGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEw CwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAUjA9N5qYwo/1IESAlhEml wOd899EwbwYDVR0fBGgwZjBkoGKgYIYuaHR0cDovL2NkcDEucG9seWNvbS5jb20vcGtpL1BvbHlj b20tUm9vdENBLmNybIYuaHR0cDovL2NkcDIucG9seWNvbS5jb20vcGtpL1BvbHljb20tUm9vdENB LmNybDCBhgYIKwYBBQUHAQEEejB4MDoGCCsGAQUFBzAChi5odHRwOi8vY2RwMS5wb2x5Y29tLmNv bS9wa2kvUG9seWNvbS1Sb290Q0EuY3J0MDoGCCsGAQUFBzAChi5odHRwOi8vY2RwMi5wb2x5Y29t LmNvbS9wa2kvUG9seWNvbS1Sb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4ICAQDAITSF89YEDKMA zqteWVdg8IqzdMHSHIJGybNrbe1UJj6trSldu42wcgjYLgJrTIDEUEX2Qp1xywpv+zpVAE1bVoek 6ot846XEIiOTofJYnwACZNnCLJ3ijG2iuBCSJjPc6FzwCF/2DMR0erdh8PNhEnl3xDRNyqVOy+DC mlLssSjPgej1UxM4yaDZZUCBrkv1dB3a4qkTbMPFBj5CkC5gPnyKTRW7iUFMKr0pXvByGPHCtRbu ShXAcoSdVH2f8cLUfJ8raVMWu1ynjOMcvlagDaZAcbzLSc8hzhxJNC6Wel9U1uFyEaYGodJTMxzv e5zRU5wZod5kPaEThCKq12Fr9Sz/dYYp4Rup/SymTS4A46qMIrOi6i3icxa3SYAhsCeALdcrgCH4 +cCtKiEE1UpqIfJq8P/+FE6cnfHyGaXD+wn4BTA5BrUBg900HNVNf1Y6BDMqaXDeAPKbiSb5FDot PjAW0v7GLoshHMr+951EdhaFNSUyOV8CoSx9b9BjlYpjJV+QtiaqJLn9UlNOa987Fg9dIY4vrfqH q9kCVr+sVpQsZ6DC17bE7etrHPevRny/EcLmuJY1RD56gPAyePHFs1GEhmKVW9ZlLWtNs79G6wSf ZRnr3vRAtr7v0zWyjfvn52HWM4kbXedjCa/q9boJMVqK+8DJawhrrn38Liw7oDCCCIAwggZooAMC AQICE2sAANv9iRUGFNx/sYkAAAAA2/0wDQYJKoZIhvcNAQELBQAwSDETMBEGCgmSJomT8ixkARkW A2NvbTEXMBUGCgmSJomT8ixkARkWB3BvbHljb20xGDAWBgNVBAMTD1BvbHljb20tU1VCQ0EwMTAe Fw0xNjAyMTYxNzI1NTlaFw0xNzAyMTUxNzI1NTlaMIGnMRMwEQYKCZImiZPyLGQBGRYDY29tMRcw FQYKCZImiZPyLGQBGRYHcG9seWNvbTEPMA0GA1UECxMGUGVvcGxlMRIwEAYDVQQLEwlFbXBsb3ll ZXMxDTALBgNVBAsTBE5BTEExGDAWBgNVBAMTD0R1Y2t3b3J0aCwgTWFyazEpMCcGCSqGSIb3DQEJ ARYaTWFyay5EdWNrd29ydGhAcG9seWNvbS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDUKfyJTxXkwEsUnHz/9m3k1jNMh31VSjpcboNOXMLE7ERqwC+KdVON0NLHp5ctN4kWewuu YDOuS+Qhp/Pm/+T2acQ0cqw+oY3nvKl7erYfC5Ul0EATlD3aUTGz34L2iKttOm9YID2GylBH9670 PHQ7n3YqC5sh1C7l2S4CznZz5c4ATRw1VtAzWskinzwYWKeiJV2ybr4JU9EM5QAGqM84jFXV2kN2 3CGKmAWlo6GIXstg82hfTkfubmgW9BQ+iyHEfwP1DIvdLh4tsyrgHoz+qomNaXmG+jUiP5CktXDF KueQLciDeg9HyxGh7AgtTvdMtI3KZUFCDyKDN4k0ux/5AgMBAAGjggQBMIID/TA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiGpOVThtjlcoO1gRiEnaYag+m7OimFw9RYg9ngHQIBZAIBBzApBgNV HSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwCwYDVR0PBAQDAgWgMDUGCSsG AQQBgjcVCgQoMCYwCgYIKwYBBQUHAwIwCgYIKwYBBQUHAwQwDAYKKwYBBAGCNwoDBDBEBgkqhkiG 9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZI hvcNAwcwHQYDVR0OBBYEFBENjiHBionI5U/bTdJlzr9d3XeNMB8GA1UdIwQYMBaAFHCHwOe0vPcW QG7PYk/NxYXFTXnpMIIBOgYDVR0fBIIBMTCCAS0wggEpoIIBJaCCASGGgbxsZGFwOi8vL0NOPVBv bHljb20tU1VCQ0EwMSxDTj12d2NvbG9zdWJjYTAxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBT ZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXBvbHljb20sREM9Y29tP2Nl cnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Q b2ludIYvaHR0cDovL2NkcDEucG9seWNvbS5jb20vcGtpL1BvbHljb20tU1VCQ0EwMS5jcmyGL2h0 dHA6Ly9jZHAyLnBvbHljb20uY29tL3BraS9Qb2x5Y29tLVNVQkNBMDEuY3JsMIIBPQYIKwYBBQUH AQEEggEvMIIBKzCBrgYIKwYBBQUHMAKGgaFsZGFwOi8vL0NOPVBvbHljb20tU1VCQ0EwMSxDTj1B SUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlv bixEQz1wb2x5Y29tLERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTA7BggrBgEFBQcwAoYvaHR0cDovL2NkcDEucG9seWNvbS5jb20vcGtp L1BvbHljb20tU1VCQ0EwMS5jcnQwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jZHAyLnBvbHljb20uY29t L3BraS9Qb2x5Y29tLVNVQkNBMDEuY3J0MEgGA1UdEQRBMD+gIQYKKwYBBAGCNxQCA6ATDBFtYXJr ZEBwb2x5Y29tLmNvbYEaTWFyay5EdWNrd29ydGhAcG9seWNvbS5jb20wDQYJKoZIhvcNAQELBQAD ggIBAHSlqpzE3JJ6cwdt2ve4eLY7IBfvrGjyFRQRfUgHg7SpxJVjB1jIZY7xXeGcBozQDSO6nQF6 KN3s+Mhy1GgH0tRMZBqefwZaT0taRdMHH/bXxDE4Qf8BRMXNIPZPb+2CV4ldFakuT1VZwmg1Gdtc ZU41o/zXYUBkzjPRX4DaEBWDsxI8Z3OX0lz3Kps3CocagYE+sjTaPIEFF3Gztyw5I8fS/nMnrSq3 G91bqqWE0teuGfBdt6tKqavJ0qHobkOQRV2bQi6OPzLZg8a1IaSZMviUDgzj/VASvw7phEUScEVf VqAvoru/7TWREyoc/lSvsd+PTpMeOjLUDre/FAbRGpN9Sx8FuBgvvb3wYdIMg/R8tIaQ8tqaAG/3 dSa9IeRfWOrcAOuc8TUieSDsTqugStWtKVsO8dCcZtdaPpL0deSjjEF+Ep9ZfqufhibQyFGNTjRK VwgxCQc+owwJx69vo2oDlzwWYhASQmwXVW9eiSWnvvMhvAny5dftCFaV47mSyQimkQ3k/rsX2Cg9 qbeuI0dSSD5c5pgE6z3jkF8ISL/1WitwCtG5Yqqp7Q8G2a35smlSVRzc1WTAiy6jZHSPZsbnRu5Y 9BnsB/TOcmKt9kAn6VUAC4j+Rq7MokZJzmj0sKNMH4qz3bo6ZMImkGS3xCLyvsK4iilg1Me67dlz bbJ1MYIDXzCCA1sCAQEwXzBIMRMwEQYKCZImiZPyLGQBGRYDY29tMRcwFQYKCZImiZPyLGQBGRYH cG9seWNvbTEYMBYGA1UEAxMPUG9seWNvbS1TVUJDQTAxAhNrAADb/YkVBhTcf7GJAAAAANv9MAkG BSsOAwIaBQCgggHVMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2 MTExMTIzMTA1NVowIwYJKoZIhvcNAQkEMRYEFPcW1Gmmt1GUfNeTtUzNIKzcMwBgMG4GCSsGAQQB gjcQBDFhMF8wSDETMBEGCgmSJomT8ixkARkWA2NvbTEXMBUGCgmSJomT8ixkARkWB3BvbHljb20x GDAWBgNVBAMTD1BvbHljb20tU1VCQ0EwMQITawAA2/2JFQYU3H+xiQAAAADb/TBwBgsqhkiG9w0B CRACCzFhoF8wSDETMBEGCgmSJomT8ixkARkWA2NvbTEXMBUGCgmSJomT8ixkARkWB3BvbHljb20x GDAWBgNVBAMTD1BvbHljb20tU1VCQ0EwMQITawAA2/2JFQYU3H+xiQAAAADb/TCBkwYJKoZIhvcN AQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCGjALBglghkgBZQMEAgMw CwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQAZ8eau43f1IX+TEOSM 1PTJ4/dsLRKrk1Qs/MPeTAfZ9pNF0N+a6eYhXd+Mq/oESg6YgC6L0OM5gs05n9ue5MmIRBe8iH1K 3WNGiCl9yBOM4UyrCKQ6lAXCQKaeJKjfQsuJV/pJJnu6PGHUhGzIRBrZ8drV9XJ4LmqnfW+eB58d i9Jd/aDU8ZnkfjzrVFLAIuwbGJOcMENV5FjVtukXPE5hBm3E2jZ7jRAJOAIXdtk9wiO6d4nw8XM+ xRvmfqSMfedFtHqm7mNNNZ+bCn/3ap3gjPukR6bj1y/n5TJFBF+QFvi6YJ75ZqDHD1JtDt3tvGSQ VARgwIpitZvULRDNw9uiAAAAAAAA ------=_NextPart_000_0FF2_01D23C46.F20E81E0-- From nobody Sun Nov 13 22:16:16 2016 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3285A1294DC; Sun, 13 Nov 2016 22:16:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147910417519.10329.16085090468217873493.idtracker@ietfa.amsl.com> Date: Sun, 13 Nov 2016 22:16:15 -0800 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-rtp-mapping-10.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 06:16:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence of the IETF. Title : Mapping RTP streams to CLUE Media Captures Authors : Roni Even Jonathan Lennox Filename : draft-ietf-clue-rtp-mapping-10.txt Pages : 12 Date : 2016-11-13 Abstract: This document describes how the Real Time transport Protocol (RTP) is used in the context of the CLUE protocol. It also describes the mechanisms and recommended practice for mapping RTP media streams defined in SDP to CLUE Media Captures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-rtp-mapping-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Nov 13 22:18:38 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882CF129690 for ; Sun, 13 Nov 2016 22:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2zkvPWxru1F for ; Sun, 13 Nov 2016 22:18:35 -0800 (PST) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F84B12969B for ; Sun, 13 Nov 2016 22:18:30 -0800 (PST) Received: by mail-pg0-x22b.google.com with SMTP id f188so50221843pgc.3 for ; Sun, 13 Nov 2016 22:18:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=dIyOaQ3Q+HTf3KPjNqeYFmlmD/aZWb9ZZJOh2YT0Vpw=; b=HZqxxGvloJriFGuSnG/MIW2+GV02DK8CFOusJji6M/+GknRd3rKY2Uught3+fcegh7 d2hhwUehawOy6QntYGz6zB+KEB6WzpEvvcKuoa+JMIidPNPVKHTdvGNt+Qfi3yILLJ8R wiPxkPkZGDofcK7Ncgt1GLlcHEmeHfUPXXASHC+hH/322nSs6jgKFY6lXjAwn+4ksMAy 9DbdoH0gZ78AtF9FtkO3++75RyzpzGivawrfiTz10qgEywgwtjCrWnU/ykFAdODWwyal Mh7CcCg03wPvwSWk1GWu4wXNSSP8dl7+oqJxsAB+/KA9yPNswHvYSKi8q9TH3qZoIyQ2 OnOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=dIyOaQ3Q+HTf3KPjNqeYFmlmD/aZWb9ZZJOh2YT0Vpw=; b=d8xVR7XrrdEx6eyIH+dA2GBxr7Sb6b2Wi0Q3ebyGSXnCHHr2B6D2ojRJDaqlLLDxcI 12IWQeiqq6JJx1R/0Zi3yRdWub92FOu8cWx6HuNfcwLauSWoEZ7qA5UDzmJrGtQ7KpXB 3tNCGxq0LtY1eFLI/HSPWfXhmMqoWvflxhMJNLwV7WT5DRkrf2mWN8pWRk/CHV0C+ZgD H41WxwQ/WCs5w0qD9qCwjOBwhmajqWEu0g2Y2AEEP1APMaz7hbvSpslYw7g8h7z1YOz7 Am0/mJw+/KbGCtg98gr/TaZt+zoH3kjNgJIWuIE3CNO8/U/ydSnGu5vuzHNNz64n9mY6 dUzw== X-Gm-Message-State: ABUngvdutMDTMSoBmnkEtgQpEHbguLG9sesttISBncEJjYiFIvyXZidYGE0UqrsHw7/Y3Q== X-Received: by 10.99.49.213 with SMTP id x204mr25879069pgx.92.1479104309551; Sun, 13 Nov 2016 22:18:29 -0800 (PST) Received: from RoniPC ([2001:67c:370:128:ecea:c9ea:2159:5ff4]) by smtp.gmail.com with ESMTPSA id si1sm1726287pab.8.2016.11.13.22.18.27 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 13 Nov 2016 22:18:28 -0800 (PST) From: "Roni Even" To: References: <147910417519.10329.16085090468217873493.idtracker@ietfa.amsl.com> In-Reply-To: <147910417519.10329.16085090468217873493.idtracker@ietfa.amsl.com> Date: Mon, 14 Nov 2016 08:16:14 +0200 Message-ID: <037901d23e3e$9b781b80$d2685280$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEOLaqRm2J5yFwmU8GzsBME8CP2GqJgIbpw Content-Language: he Archived-At: Subject: [clue] FW: I-D Action: draft-ietf-clue-rtp-mapping-10.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 06:18:37 -0000 Hi, This version addresses the comments made by Colin Roni -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Monday, November 14, 2016 8:16 AM To: i-d-announce@ietf.org Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-rtp-mapping-10.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence of the IETF. Title : Mapping RTP streams to CLUE Media Captures Authors : Roni Even Jonathan Lennox Filename : draft-ietf-clue-rtp-mapping-10.txt Pages : 12 Date : 2016-11-13 Abstract: This document describes how the Real Time transport Protocol (RTP) is used in the context of the CLUE protocol. It also describes the mechanisms and recommended practice for mapping RTP media streams defined in SDP to CLUE Media Captures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-rtp-mapping-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From nobody Mon Nov 14 17:48:40 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD9F129675; Mon, 14 Nov 2016 17:48:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7spCcQgtcIF; Mon, 14 Nov 2016 17:48:32 -0800 (PST) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6381D129651; Mon, 14 Nov 2016 17:48:31 -0800 (PST) Received: by mail-pg0-x22f.google.com with SMTP id 3so60522736pgd.0; Mon, 14 Nov 2016 17:48:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:thread-index :content-language; bh=2N6uerMeUYTlrpwQDz1EPMyfaav/e8Py4SfJYYvq248=; b=R8LW/qwaWqbbGdd5cCaxVtAx0/iJtypCOl9LlwbWFrCcUNHAWyrKsn9JGBOtR5LF0v roUZUR8WPg7qZhn+cpEGC+f209TZuP8EA/NRr+aRHghACRhdZ1r1q2EqW7mdb3kVgN8o wI/zTxZ+1HNDe3SJTTBWzALXr40vv0j0Nl0aV3WVsC1eMFsnx1emkEhGB2S1FJm84C3O Zuc/xrxNOC+HmWNBdWIdh4F2QL9Oc2m8UPCUfD9OC5cNSSKwgIgJVosK2QwgoBR9GX77 k2REgzmjdpjn8YawpDCLiNt0pMczt47ZdZUj+N2N7D+nJJkR5wl7ikHkfEzLxxAC9JyG 8B8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :thread-index:content-language; bh=2N6uerMeUYTlrpwQDz1EPMyfaav/e8Py4SfJYYvq248=; b=cGIkvgiNcQK3ZeUldZ9NWNlCF5wYdToBQxl3jP4Brq6gfZS4DNjxObCLW2VEIdNPHe Qw88ZkgorwLWLDjUaVNwYSbZ10V1MBERPL5wQ0Mw8ZUPl4xkdOuI6SSvNHqs9wCraV0L 3LGdmPR3hbFVEGQ0iXLBWrX8kZ4G75l2Xf497S/JxOKcw7Yts3OUjsbqhCE5r2rt7SqV cHu8SmFAOV37YpQoOxOrLVXgm7IausXtHEG6xFUZelGqgYvqfhJpSmOVgVHex6eEuhWw FZ4SGsqsd//zfyamIfh8avVBmKbZ2NopZNmnVRb7i9dJoh6KBkcqEPv9Wk4zgLpVA6B9 8G/A== X-Gm-Message-State: ABUngveUYll+g7h7DJrg6rCFEPBthMZVxC/+mSpvsQUO4SIHLMUrQIy8zZMCLOA+5sU0nA== X-Received: by 10.99.109.6 with SMTP id i6mr73136566pgc.139.1479174510675; Mon, 14 Nov 2016 17:48:30 -0800 (PST) Received: from RoniPC ([2001:67c:370:128:bc29:a069:9e9a:89ab]) by smtp.gmail.com with ESMTPSA id q12sm38036750pfj.18.2016.11.14.17.48.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 14 Nov 2016 17:48:29 -0800 (PST) From: "Roni Even" To: Date: Tue, 15 Nov 2016 03:46:12 +0200 Message-ID: <047701d23ee2$0e786d30$2b694790$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0478_01D23EF2.D201B260" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdI+4anUPRA73kO1R+6ZpXypiLKwcg== Content-Language: he Archived-At: Cc: clue@ietf.org Subject: [clue] status of draft-ietf-clue-signaling X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 01:48:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0478_01D23EF2.D201B260 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi guys, The current version has expired. Can you provide me with your view on the status of the document and when can we expect a new version This is the last document we need to finish for CLUE Thanks Roni Even CLUE co-chair ------=_NextPart_000_0478_01D23EF2.D201B260 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi = guys,

The current version has = expired. Can you provide me with your view on the status of the document = and when can we expect a new version

This is the last document we need to finish for = CLUE

Thanks

Roni Even

CLUE = co-chair

------=_NextPart_000_0478_01D23EF2.D201B260-- From nobody Mon Nov 14 21:21:51 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8811129A12; Mon, 14 Nov 2016 21:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=B4nWKlJP; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=mdhoADNL Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0r1lNAbOp0Ey; Mon, 14 Nov 2016 21:21:46 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC666129461; Mon, 14 Nov 2016 21:21:45 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 46B7A207DA; Tue, 15 Nov 2016 00:21:45 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Tue, 15 Nov 2016 00:21:45 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=Z9z4M/0UoL0RQEBKoE/DaNdYhU8=; b=B4nWKl JPHcjfXnnnYgiEXK/+4sa5Po7HnuVIjoQuqOGxNPXyhVncXUZebpNk4c0GWsBith URHsXx314v0mCwkaMLnNqKs8YTw3WFA1FE+2oUKXPGJe6u2zC2EODfTdLM9+ISd4 zRfEAbjomQwkFs+mWDvca+ApTt+5G1zN/wOa8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=smtpout; bh=Z9z4M/0UoL0RQE BKoE/DaNdYhU8=; b=mdhoADNLY4xK2y4TD2Sey1U712OhrkdYqCN8hUdrTXtQeD jnGOviSrRu2LSFFNh52HAEMsCd8u/aO4pNDOQ+qdPOul0P+YLA5vZDRqthB8G3iF Z8zza+RRUUp8U1lNhhC9q6mWB50py2siVJr5kReXG/6iK0qxJb+RD73ROlNi4= X-ME-Sender: X-Sasl-enc: LqqX026dQzoZszQjsTmIY7q/5IRk9oB2RxJRK84ZbcQA 1479187304 Received: from [10.24.8.140] (unknown [128.107.241.187]) by mail.messagingengine.com (Postfix) with ESMTPA id A45412405C; Tue, 15 Nov 2016 00:21:43 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_C46F1E97-2344-46D1-BCA7-CD6BA4C28D9B" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <047701d23ee2$0e786d30$2b694790$@gmail.com> Date: Tue, 15 Nov 2016 14:21:40 +0900 Message-Id: References: <047701d23ee2$0e786d30$2b694790$@gmail.com> To: Roni Even X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-clue-signaling@ietf.org, clue@ietf.org Subject: Re: [clue] status of draft-ietf-clue-signaling X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 05:21:49 -0000 --Apple-Mail=_C46F1E97-2344-46D1-BCA7-CD6BA4C28D9B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This document has already been through WGLC and updated based on = comments received. I thought it was ready for pub req. Alissa > On Nov 15, 2016, at 10:46 AM, Roni Even = wrote: >=20 > Hi guys, > The current version has expired. Can you provide me with your view on = the status of the document and when can we expect a new version > This is the last document we need to finish for CLUE > Thanks > Roni Even > CLUE co-chair > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue = --Apple-Mail=_C46F1E97-2344-46D1-BCA7-CD6BA4C28D9B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
This document has already been through WGLC = and updated based on comments received. I thought it was ready for pub = req.

Alissa

On Nov 15, 2016, at 10:46 AM, Roni Even = <ron.even.tlv@gmail.com> wrote:

Hi guys,
The = current version has expired. Can you provide me with your view on the = status of the document and when can we expect a new version
This is = the last document we need to finish for CLUE
Thanks
Roni = Even
CLUE = co-chair
_______________________________________________
clue mailing = list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

= --Apple-Mail=_C46F1E97-2344-46D1-BCA7-CD6BA4C28D9B-- From nobody Tue Nov 15 04:44:20 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECF6129460; Tue, 15 Nov 2016 04:44:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPObsstiO_Mh; Tue, 15 Nov 2016 04:44:18 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CD2F12942F; Tue, 15 Nov 2016 04:44:18 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id 189so36383115pfz.3; Tue, 15 Nov 2016 04:44:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=Q515MklFaylBx+MmFO86tE++10NQUWazjXpQXlONzkA=; b=EzFNqpclEUOIhjyDGUsIOKq6fkLuoom9W5Tr55ffR10upf468+7sxxOI9OpdDjS6vP eYE9Ip4j26yPCrdIwmUHwlA20mftxwIHT67VJBDqLDpjmfhhS6IDCTYVxiG12DUib3et QHQoLDudcER8oZe6MiypLICJFboal6K66wVGr2PDhgCamBy6EOjIGkQVsbkBwNeB+Z+e sFd64otYWdurzYjcFV5zuttCHifScS/1ZIQrhVeFWWIYrWavQ0INpkibwajJGjWnux9E M9QRWDMnoeSZU1KeVNgZ9r0JMktcjAfq+Q6z61tvtELhXjaVwPuDOCGVKBKxUmO4SX6W gDVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=Q515MklFaylBx+MmFO86tE++10NQUWazjXpQXlONzkA=; b=MlOiTPcPoy6HycIEUOXm4xkiRKZZpdefqs+nEbLySfwmzSMdHIZcCEjCDT+ZzxCxcs 9IIoz7ehnP3dt7InRIncVZ8yVa4Ywu1oVredF0tw7PsjO6zkCrjVPB+BJX7GM0sSaSEH UGCc+iUwIV2sBIpbPSWxGQt7/mptBES7HliipBQC8mxhD9Nd4GoJsscnndwRuYqHLftt 3StdT5yHppnFiKQfD1RRqBerF2W+X0sw2Ltp8V2sYfSaXAf6pFMmv3WUQqjXKYE5iCw6 6JjqJ0ZBUYZOWge9VrNZ6dvrI/b1pC4Mc1BPRYLyCIc4758uJI8LKUZRgia8U0u4oDqE EMog== X-Gm-Message-State: ABUngvcAiAQYO5vaJMh0LGfKQGXLgHSOyuEC9Tt2UF9ijnQ6+UctZaxKXuN+w/RFiN81fg== X-Received: by 10.98.73.1 with SMTP id w1mr46220266pfa.123.1479213857895; Tue, 15 Nov 2016 04:44:17 -0800 (PST) Received: from RoniPC ([2001:67c:370:144:9174:1a6e:1e1d:e9a5]) by smtp.gmail.com with ESMTPSA id q9sm42916315pfg.47.2016.11.15.04.44.15 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 15 Nov 2016 04:44:16 -0800 (PST) From: "Roni Even" To: "'Alissa Cooper'" References: <047701d23ee2$0e786d30$2b694790$@gmail.com> In-Reply-To: Date: Tue, 15 Nov 2016 14:44:11 +0200 Message-ID: <009701d23f3d$fa10ddd0$ee329970$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0098_01D23F4E.BD9A7120" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF9v44zJAjIriQHEFUgNtFzXmuQ1QGpDz5KoXWzwkA= Content-Language: he Archived-At: Cc: draft-ietf-clue-signaling@ietf.org, clue@ietf.org Subject: Re: [clue] status of draft-ietf-clue-signaling X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 12:44:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0098_01D23F4E.BD9A7120 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Alissa, Thanks, I was not the original shepherd and did not see it in the tracker. You are right, it finished WGLC and addressed comments; so for the authors (Rob?) please submit a version and we can send it to publication Roni From: Alissa Cooper [mailto:alissa@cooperw.in] Sent: Tuesday, November 15, 2016 7:22 AM To: Roni Even Cc: draft-ietf-clue-signaling@ietf.org; clue@ietf.org Subject: Re: [clue] status of draft-ietf-clue-signaling This document has already been through WGLC and updated based on comments received. I thought it was ready for pub req. Alissa On Nov 15, 2016, at 10:46 AM, Roni Even wrote: Hi guys, The current version has expired. Can you provide me with your view on the status of the document and when can we expect a new version This is the last document we need to finish for CLUE Thanks Roni Even CLUE co-chair _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue ------=_NextPart_000_0098_01D23F4E.BD9A7120 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alissa,

Thanks, I was not the original shepherd and did not see it in the = tracker. You are right, it finished WGLC and addressed comments; so for = the authors (Rob?) please submit a version and we can send it to = publication

Roni

 

From:= = Alissa Cooper [mailto:alissa@cooperw.in]
Sent: Tuesday, = November 15, 2016 7:22 AM
To: Roni Even
Cc: = draft-ietf-clue-signaling@ietf.org; clue@ietf.org
Subject: Re: = [clue] status of = draft-ietf-clue-signaling

 

This = document has already been through WGLC and updated based on comments = received. I thought it was ready for pub = req.

 

Alissa

 

On Nov 15, 2016, at 10:46 AM, Roni Even <ron.even.tlv@gmail.com> = wrote:

 

Hi = guys,

The = current version has expired. Can you provide me with your view on the = status of the document and when can we expect a new = version

This is = the last document we need to finish for = CLUE

Thanks=

Roni = Even

CLUE = co-chair

__________= _____________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

 

------=_NextPart_000_0098_01D23F4E.BD9A7120-- From nobody Tue Nov 15 08:00:23 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E404129488; Tue, 15 Nov 2016 08:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.017 X-Spam-Level: X-Spam-Status: No, score=-16.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uetF9houJJo0; Tue, 15 Nov 2016 08:00:18 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C1441295FC; Tue, 15 Nov 2016 08:00:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10386; q=dns/txt; s=iport; t=1479225618; x=1480435218; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7tbppZ1WorhBSpteMot0nqEf6eVQRus/mWsL9v9S+nQ=; b=WVfHYOHINdEx6uPDtpBPSyg+IHXIW+w0pFy4tTRiIwQQyMJy7sqOVYfJ WTCXPCTT5RMAYDl59fl3RfTOfr5POdTF6SdhTTA3GeKIo9OwpvZeg/vFp OiqbYeZX8UBTMGIh3ylVCrM5MyK6H39fL0x16H7KlvuhagUNXWXPm4bhs M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAQDvLytY/4ENJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnM2DgEBAQEBH1iBAAeNN5cLh2yHWoUcggcdAQqFewKCIT8UAQI?= =?us-ascii?q?BAQEBAQEBYiiEYQEBAQQBAQEqQQsQAgEIDgMEAQEoByEGCxQJCAEBBAENBQiIS?= =?us-ascii?q?gMXDrJph0UNg3wBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYsWgkiCNoUrBYElAYc?= =?us-ascii?q?ih1mJazMCAY0Zg0GBdoR2iT2HQIFehCmECQEeN4EgLYJ2HIFdcgGHDYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.31,495,1473120000"; d="scan'208,217";a="347991955" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Nov 2016 16:00:15 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id uAFG0FM4004349 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Nov 2016 16:00:15 GMT Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 15 Nov 2016 10:00:14 -0600 Received: from xch-rcd-016.cisco.com ([173.37.102.26]) by XCH-RCD-016.cisco.com ([173.37.102.26]) with mapi id 15.00.1210.000; Tue, 15 Nov 2016 10:00:14 -0600 From: "Rob Hansen (rohanse2)" To: Roni Even , "'Alissa Cooper'" Thread-Topic: [clue] status of draft-ietf-clue-signaling Thread-Index: AdI+4anUPRA73kO1R+6ZpXypiLKwcgAUMW8AAA90aYAABcDlIA== Date: Tue, 15 Nov 2016 16:00:14 +0000 Message-ID: <0c96b559015045139d2f3b3475662fa0@XCH-RCD-016.cisco.com> References: <047701d23ee2$0e786d30$2b694790$@gmail.com> <009701d23f3d$fa10ddd0$ee329970$@gmail.com> In-Reply-To: <009701d23f3d$fa10ddd0$ee329970$@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.230.72.159] Content-Type: multipart/alternative; boundary="_000_0c96b559015045139d2f3b3475662fa0XCHRCD016ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-clue-signaling@ietf.org" , "clue@ietf.org" Subject: Re: [clue] status of draft-ietf-clue-signaling X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 16:00:21 -0000 --_000_0c96b559015045139d2f3b3475662fa0XCHRCD016ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I can update it - would like to review it in light of the changes to the pr= otocol dodcument (as there are some dependencies there). Will get that done= ASAP. Rob From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: 15 November 2016 12:44 To: 'Alissa Cooper' Cc: draft-ietf-clue-signaling@ietf.org; clue@ietf.org Subject: RE: [clue] status of draft-ietf-clue-signaling Hi Alissa, Thanks, I was not the original shepherd and did not see it in the tracker. = You are right, it finished WGLC and addressed comments; so for the authors = (Rob?) please submit a version and we can send it to publication Roni From: Alissa Cooper [mailto:alissa@cooperw.in] Sent: Tuesday, November 15, 2016 7:22 AM To: Roni Even Cc: draft-ietf-clue-signaling@ietf.org; clue@ietf.org Subject: Re: [clue] status of draft-ietf-clue-signaling This document has already been through WGLC and updated based on comments r= eceived. I thought it was ready for pub req. Alissa On Nov 15, 2016, at 10:46 AM, Roni Even > wrote: Hi guys, The current version has expired. Can you provide me with your view on the s= tatus of the document and when can we expect a new version This is the last document we need to finish for CLUE Thanks Roni Even CLUE co-chair _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_0c96b559015045139d2f3b3475662fa0XCHRCD016ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I can upda= te it – would like to review it in light of the changes to the protoc= ol dodcument (as there are some dependencies there). Will get that done ASAP.

 = ;

Rob=

 = ;

From: = Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: 15 November 2016 12:44
To: 'Alissa Cooper' <alissa@cooperw.in>
Cc: draft-ietf-clue-signaling@ietf.org; clue@ietf.org
Subject: RE: [clue] status of draft-ietf-clue-signaling

 

Hi Alissa,<= /span>

Thanks, I was not the = original shepherd and did not see it in the tracker. You are right, it fini= shed WGLC and addressed comments; so for the authors (Rob?) please submit a version and we can send it to publication

Roni=

 

 

This document has already been = through WGLC and updated based on comments received. I thought it was ready= for pub req.

 

Alissa

 

On Nov 15, 2016, at 10:46 AM, R= oni Even <ron.even.tlv@gmail.c= om> wrote:

 

Hi guys,

The current version has expired. Can= you provide me with your view on the status of the document and when can w= e expect a new version

This is the last document we need to= finish for CLUE

Thanks

Roni Even

CLUE co-chair

___________________________________= ____________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

 

--_000_0c96b559015045139d2f3b3475662fa0XCHRCD016ciscocom_-- From nobody Mon Nov 21 09:20:18 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383DA129AFC for ; Mon, 21 Nov 2016 09:20:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vwuKknMb6Pe for ; Mon, 21 Nov 2016 09:20:16 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D15D5129B10 for ; Mon, 21 Nov 2016 09:20:01 -0800 (PST) Received: from [2001:630:40:70e0::107] (port=56697) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1c8sG7-0001zj-MK; Mon, 21 Nov 2016 17:20:00 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: <037901d23e3e$9b781b80$d2685280$@gmail.com> Date: Mon, 21 Nov 2016 17:19:57 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147910417519.10329.16085090468217873493.idtracker@ietfa.amsl.com> <037901d23e3e$9b781b80$d2685280$@gmail.com> To: Roni Even X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: clue@ietf.org Subject: Re: [clue] I-D Action: draft-ietf-clue-rtp-mapping-10.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 17:20:17 -0000 Thanks Roni, this looks good. Colin > On 14 Nov 2016, at 06:16, Roni Even wrote: >=20 > Hi, > This version addresses the comments made by Colin > Roni >=20 > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Monday, November 14, 2016 8:16 AM > To: i-d-announce@ietf.org > Cc: clue@ietf.org > Subject: [clue] I-D Action: draft-ietf-clue-rtp-mapping-10.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the ControLling mUltiple streams for > tElepresence of the IETF. >=20 > Title : Mapping RTP streams to CLUE Media Captures > Authors : Roni Even > Jonathan Lennox > Filename : draft-ietf-clue-rtp-mapping-10.txt > Pages : 12 > Date : 2016-11-13 >=20 > Abstract: > This document describes how the Real Time transport Protocol (RTP) = is > used in the context of the CLUE protocol. It also describes the > mechanisms and recommended practice for mapping RTP media streams > defined in SDP to CLUE Media Captures. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-10 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-rtp-mapping-10 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue --=20 Colin Perkins https://csperkins.org/ From nobody Tue Nov 22 11:30:09 2016 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0400129E80 for ; Tue, 22 Nov 2016 11:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=plcm365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGKh-OjTKj7v for ; Tue, 22 Nov 2016 11:30:06 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 180FD129B3F for ; Tue, 22 Nov 2016 11:30:06 -0800 (PST) Received: from [216.82.242.36] by server-11.bemta-8.messagelabs.com id AD/E3-05157-DBC94385; Tue, 22 Nov 2016 19:30:05 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSa0gUURTHuzOzs5Ps2rhqnhZTGi1JWtOyEIM yJbUikgqUkGqsaXdzd7WdrRSDtheSFopJmG2oZdo7Mnto2WM1MKUPahhl9s5Kk7TQ0DVrZ+/a 43763fM/93/OPRyGVHXSakbIsghmE2/gaA/q8LeYs5o7tsiU8Md7PaLutXSQUdWfm1HUz1wyh kw89uoVnVhX2i1PrKwcIZLI9TK9KS0ja5NMN9z+g8y8l5xlO3mCsCL7mjzEMMAuh8raoDzkwa jYZgTVrzto6UKxuSQ4vhbLsVJIQMOpcwS+2BH0/Bqk8tBkhmYj4cvIS0JiH3YW9F36TktMsvF gbRt3xb3ZWHC0tslwThxYx1rdPA9GumxIYoqdCUNtN1yeSjYVHn0cIHGxqwiGBqtcwmR2KfR1 j5ESI3Yq/Gi5SOBifvD8fZmLgfWBN22tNGZf+PxuXIbzU6GpvgXheDTcqLkgkwoAWymDsSujF BZWwekPdmKCzx7okWNOh/rLDrfpImg+/YzCj/cR8KlrwP3YH47bG0m3QENVb7nLScVuhqfWaz I8CzV0PzmEMPvDpxcNskI0u/SfX2A+jODdw6RS1zi84NHx9xSOa6D+7n0ScyDc7Le5eRGUjD6 gMc+A4vw3cswLoO/hICpHzHkUIgrmnYJZExGWZtZrdRYjrzdoIsKjwoyCKPJawcCniWGbM4w1 yLljk5znFjpwJM6OpjEE56tsPDMvReWZlrElW8eLuo3mHQZBtCN/huFAueREZIrKyyxohayte oNzUSdkYBScj3KuJCvFTN4o6rVYakEapmlg4DWhokwZJkHtpyyUklgpSbfD9MdiYt3b0XS1tx I5m1IpMgWzUW/5X+9FfgzivJV7JBeF3mT5U6nX2QThbGLa8HypCQv/V1JbUUXomvibJYEJe7n slWJIUE7F/Mi6IM/FtbZ1c4jcghp5T2x1p+/a1PTl1navin7fFG1y8PDKcUXB7RXE85eO7SWr HXMX5ngN9dd9CFA0Jqt3f6yIyT86ZVfA251E0fWDTdor59YeCi7avyH6ybdtxeEFRNzbsGVJF /RlXNdSsoNbkMBRoo6PCCXNIv8b1zrQ8ukDAAA= X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-16.tower-94.messagelabs.com!1479843003!118085479!1 X-Originating-IP: [140.242.64.168] X-StarScan-Received: X-StarScan-Version: 9.0.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 129054 invoked from network); 22 Nov 2016 19:30:03 -0000 Received: from mailrelay.polycom.com (HELO SACWPEXEDGE01V.polycom.com) (140.242.64.168) by server-16.tower-94.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 22 Nov 2016 19:30:03 -0000 X-CrossPremisesHeadersFilteredBySendConnector: SACWPEXEDGE01V.polycom.com Received: from NAM01-SN1-obe.outbound.protection.outlook.com (207.46.163.118) by mailrelay.polycom.com (10.244.6.168) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 22 Nov 2016 11:30:01 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=plcm365.onmicrosoft.com; s=selector1-polycom-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=C1R7F/FMjZlStUZOgOsNsfX7Lw4EsO/up6P9GoTzDZk=; b=un50WAAiRjvI+/OgJ6JpxUf+u53Bv2k6LMr/Af3smjFCwa6wslZEQPAnw0ZHSmZ3fRXqsesq8v56Ze/E9vGTvOMfF4P5ED5md/0Ff30alQnpOp3O/UtyCVX3YKJ9UYuQFxQhXh0y2jEWbgpyvNR2PkgX5gZZKd876Sw+v0olF2s= Received: from BN6PR10MB1395.namprd10.prod.outlook.com (10.173.30.17) by BN6PR10MB1394.namprd10.prod.outlook.com (10.173.30.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.8; Tue, 22 Nov 2016 19:30:01 +0000 Received: from BN6PR10MB1395.namprd10.prod.outlook.com ([10.173.30.17]) by BN6PR10MB1395.namprd10.prod.outlook.com ([10.173.30.17]) with mapi id 15.01.0734.014; Tue, 22 Nov 2016 19:30:01 +0000 From: "Duckworth, Mark" To: Roni Even Thread-Topic: [clue] I-D Action: draft-ietf-clue-rtp-mapping-10.txt Thread-Index: AQHSRBufjO+EY/7tTESrvgIHgkd6QqDlZUWQ Date: Tue, 22 Nov 2016 19:30:01 +0000 Message-ID: References: <147910417519.10329.16085090468217873493.idtracker@ietfa.amsl.com> <037901d23e3e$9b781b80$d2685280$@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [2601:18c:8800:1250:7c20:b7fe:898a:5c17] x-microsoft-exchange-diagnostics: 1; BN6PR10MB1394; 7:5V/THtg4/iaHv++X1cApCDM/kAyBxqdm6tiRVxZlCN0Wq5ui5uKh+pcZRE21wtaXKQCSsl4aZ4c/97zAIgiDE6S0uMKZ5EefTlm+p7tXV1JuCY8HLqoWdyBbqZUItMk/uQ4nwTLN6mVO+3APd1QIxxRlaKyE6dwrhCgvuiNdFy7CVZCXpBAk/t272+fzZqQZo6AILD0Cvjqqs5cqvaSdUc5btfNTc25+mmuMf0mp4Qcphi5+FNSZ8UG4TYuSsjZ9YgKxV4pg+fBEOGzCc1R2ilR/8rETZeMOqxaMpD0Axpu0pHSBV+omFNrE15syAsJz1rttVEUjkbt9AEAXwgO6TW6QlTyB1+TyWcz4tRLxpiY=; 20:5OrM1MrgKDAb/Wd1Ikm8zsptm3rFk3L6yfwA6Pt0hWQSeul5itcu7ERhaadCVKUBkr41ZIFnH2DEYQQbZ8SByUQGVmJCHv++v9/UF2hm/GDCdZZsR5870X1df1cZcQGDqSnw9m0QplEQJtoHfa1Oow5YPqSpL34MxcKYEWsJwDxoK2wFekhCr1d/zSNHg4ONhTaF6g8npb4CdTQJKjk6yceReM3kTGanXKJBPOKn6bKowVnAn/zKSjndIX1qAtaP x-ms-office365-filtering-correlation-id: 9b6be8d7-78c1-4e62-2429-08d4130df400 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR10MB1394; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6060326)(6040307)(6045199)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6061324)(6041248)(6042181)(6072148); SRVR:BN6PR10MB1394; BCL:0; PCL:0; RULEID:; SRVR:BN6PR10MB1394; x-forefront-prvs: 0134AD334F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(7916002)(24454002)(377424004)(189002)(199003)(13464003)(377454003)(7696004)(2950100002)(122556002)(8936002)(81156014)(6916009)(102836003)(6116002)(81166006)(5660300001)(110136003)(38730400001)(99286002)(2900100001)(106116001)(33656002)(92566002)(106356001)(86362001)(77096005)(105586002)(8676002)(74316002)(3660700001)(99936001)(6506003)(76576001)(230783001)(9686002)(101416001)(305945005)(7736002)(4326007)(50986999)(68736007)(7846002)(76176999)(54356999)(3280700002)(2906002)(229853002)(97736004)(4001150100001)(189998001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR10MB1394; H:BN6PR10MB1395.namprd10.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: polycom.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_048F_01D244CC.E783D700" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2016 19:30:01.3934 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d0880d3f-e6d1-4a41-9e81-b8fbcddf7b6c X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR10MB1394 X-OriginatorOrg: polycom.com X-OrganizationHeadersPreserved: SACWPEXEDGE01V.polycom.com Archived-At: Cc: "clue@ietf.org" Subject: Re: [clue] I-D Action: draft-ietf-clue-rtp-mapping-10.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 19:30:09 -0000 ------=_NextPart_000_048F_01D244CC.E783D700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit +1 > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Colin Perkins > Sent: Monday, November 21, 2016 12:20 PM > To: Roni Even > Cc: clue@ietf.org > Subject: Re: [clue] I-D Action: draft-ietf-clue-rtp-mapping-10.txt > > Thanks Roni, this looks good. > Colin > > > > > On 14 Nov 2016, at 06:16, Roni Even wrote: > > > > Hi, > > This version addresses the comments made by Colin > > Roni > > > > -----Original Message----- > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of > > internet-drafts@ietf.org > > Sent: Monday, November 14, 2016 8:16 AM > > To: i-d-announce@ietf.org > > Cc: clue@ietf.org > > Subject: [clue] I-D Action: draft-ietf-clue-rtp-mapping-10.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the ControLling mUltiple streams for > > tElepresence of the IETF. > > > > Title : Mapping RTP streams to CLUE Media Captures > > Authors : Roni Even > > Jonathan Lennox > > Filename : draft-ietf-clue-rtp-mapping-10.txt > > Pages : 12 > > Date : 2016-11-13 > > > > Abstract: > > This document describes how the Real Time transport Protocol (RTP) is > > used in the context of the CLUE protocol. It also describes the > > mechanisms and recommended practice for mapping RTP media streams > > defined in SDP to CLUE Media Captures. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-10 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-rtp-mapping-10 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > -- > Colin Perkins > https://csperkins.org/ > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue ------=_NextPart_000_048F_01D244CC.E783D700 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUEjCCBQ0w ggL1oAMCAQICEBrVY02YeFKcQ+zVfznU/o4wDQYJKoZIhvcNAQEFBQAwGTEXMBUGA1UEAxMOUG9s eWNvbS1Sb290Q0EwHhcNMTMxMTA0MTg1NzA2WhcNMjMxMTA0MTkwNjU4WjAZMRcwFQYDVQQDEw5Q b2x5Y29tLVJvb3RDQTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAMzj+6krY3OF7mtq +O2/yC5heUML7DFZn2cp0Mkp/vos7TDrysGdPDdEIK+zYvZQZs6TrGzPh0XXnEpMcHE7V4nD5zN3 VX0+Zg46w0wCHdkgq/GV3EKlyg0AsX8LgooGlUMeuUNpe+sT0WBl3mXB97TUw7mnRLY1m/IAlyFv 4XO8LfQ1L03vfLBRAVft7xc9Okm6DbHrPxFx9VKpgIkSIUvIx/BK0zXBa/0arWW3tfimfY9t5KdJ Wqb68E8Nb0bD8S0Ve0O76TCR4dVE/HmVj6YrauGcUGfvB4yT+bOOCGlsOw3NoHW2G9PZJF9B9PvV cWzv9Jw3AlzGU2sQMbVD1ZiiRgkG47bvqvi/tg38vWEDMj1lzSpMp/FhC8YrSaGb4YwjM52w9MXM DNypbOFZ/0WjrykwuGB1P9Ga38nRlaMkMJ3lE7P1pQMgxElO5uE+1TI5kTJ9mIGgQtQb57w4vkkJ kHNKjmqzOo3IFkhEIUS3ARPkYG4HWzP7xtmcYBoEx4QwpbxYQKKcxN9h/zuv9LYc79WvnF+i+aj0 1YJKoldsPnIXhG3HullYVQb+v19q8cqm0OGUEq7e2wY72H6JiT6YFc5kZitpZ65L5d1OGVLyFO6b iC79ARA9eBE5L3g9zF/du+U1k9L6LWW3VaHr3ZDCECU8ZX5QeBrqv2aTb0VNAgMBAAGjUTBPMAsG A1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSMD03mpjCj/UgRICWESaXA53z3 0TAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG9w0BAQUFAAOCAgEAs02vFW5Je6895ZBWadxy5vxR z2imWk97qU2sMFSMnmf9QeqPwdawGO33zWr1sSQr8d67AHQc+3ihZuoAaeQAAC6Lww9r17Q3vVqg 7Qge86101Xw1fjXqTFUnWTxBK0S7re7pMqWlqaFgFQOHBMLnrM9z+NQIyDh7st9JjA+bRfFwErQ9 5CziXu+o/4q7eDBP1WaI0yKkEcOQ2LyPuCCE4hcshcJABiSYPax8nW71foHb+bv92IYvYXu2Wpa6 VgnxYqdi2k0Yk8CDiYalVsc+7QH0euQ1YIcovPbpZ02AirLqiiy6XB9i8OKfuapKSftsdfjLKqwI L7lKqz/4uAheETQsORVEh4IT0P8RRaIgHBOBVz/DOW+/IiiYagOJIYqbwGIFImQ7uOLNCoP5qY4y PLUZhmHFnnr7xtz4gv455KP9cwtPYcAarc/IB7WkTmEhFYa19k4jXlZ19AZIO/SPhvV7qz50zqB+ pCReRB5fXnf3qhRSw2WpRD4xr/q8OrWTfQRdXaooTJ14tRziqjEWLz4nPQKbE45aAjgwO0Rp6k5J tWGPhCxmuru/iqVES98VbjuAoo2qYZk7eNrqcnMuSxgqU0bgyie/R/FfMcbsw6rAh7T+qfBSxVIQ tpiqPwtZR5kdi6af3vf4w9q1PvEGrNipAjKEN2HW73558qGfPMowggZ5MIIEYaADAgECAhNuAAAA AgUmZh85ZflDAAAAAAACMA0GCSqGSIb3DQEBBQUAMBkxFzAVBgNVBAMTDlBvbHljb20tUm9vdENB MB4XDTEzMTEwNDE5MTM1MFoXDTIzMTEwNDE5MDY1OFowSDETMBEGCgmSJomT8ixkARkWA2NvbTEX MBUGCgmSJomT8ixkARkWB3BvbHljb20xGDAWBgNVBAMTD1BvbHljb20tU1VCQ0EwMTCCAiIwDQYJ KoZIhvcNAQEBBQADggIPADCCAgoCggIBAOZhKwn7h/qKsHx8zQQPT356Og5GOOJ26SKfzS6dIZaD NjFIhS/5QRd3HZ9I1qFD8faDfpIHL+NzC0xqYJUZsEKntD+cCj99nx33t9D6GCmsEEngeLV0FO/u DlDcCXVJNJWS65E05vKyWFPlIRegDs+E73mNh3dHZ53mgrsCFd8PnX5Zm6zm+dAinDTUreXzSuzT si5yuZ10jHdEoin3bQyYQfAe4nR7BiqcQzYnD+JgU+NrZZ555xMdwVtRhjIFuFHwCN1BgWL8+cmI PTmW3bS/irYkbUn/IYFXGJIdgeZTzsp22+OPChBkCBiy86d9RaM6qvOV/ZLmq0bj4souN1cNBg0g ZnYIgTypQY/5Ew99FJJDor4TH1R5YNtqgwxBiSZSc0WSKy8WBrcUpBM+FP1gETY2sqZh2ApFkhU1 7BBLXcEwu6dnSO9Y5u0zJfOTKPesVaeGTfvzTEcm6A8xKO6V+ai/zhu3egbv4SmlPGiMENMPsWRy cG0c73xz/w9RwpWpImjIcE3+XA9rPhIdNj2KN4sbMJvvN5/ZLJHRScE5F3pltq2sFLyPSqhukYVY NRVXmdJ14FCArDqlrREeWLA2tP4ir0WeFeX6KgU+QrmWvdw1hJZ9/lPkiqDvuBWvDVyON0u/Dvi3 p6RJmWJlC5F8ajRegnM+BAYfokRZkvOHAgMBAAGjggGJMIIBhTAQBgkrBgEEAYI3FQEEAwIBADAd BgNVHQ4EFgQUcIfA57S89xZAbs9iT83FhcVNeekwGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEw CwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAUjA9N5qYwo/1IESAlhEml wOd899EwbwYDVR0fBGgwZjBkoGKgYIYuaHR0cDovL2NkcDEucG9seWNvbS5jb20vcGtpL1BvbHlj b20tUm9vdENBLmNybIYuaHR0cDovL2NkcDIucG9seWNvbS5jb20vcGtpL1BvbHljb20tUm9vdENB LmNybDCBhgYIKwYBBQUHAQEEejB4MDoGCCsGAQUFBzAChi5odHRwOi8vY2RwMS5wb2x5Y29tLmNv bS9wa2kvUG9seWNvbS1Sb290Q0EuY3J0MDoGCCsGAQUFBzAChi5odHRwOi8vY2RwMi5wb2x5Y29t LmNvbS9wa2kvUG9seWNvbS1Sb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4ICAQDAITSF89YEDKMA zqteWVdg8IqzdMHSHIJGybNrbe1UJj6trSldu42wcgjYLgJrTIDEUEX2Qp1xywpv+zpVAE1bVoek 6ot846XEIiOTofJYnwACZNnCLJ3ijG2iuBCSJjPc6FzwCF/2DMR0erdh8PNhEnl3xDRNyqVOy+DC mlLssSjPgej1UxM4yaDZZUCBrkv1dB3a4qkTbMPFBj5CkC5gPnyKTRW7iUFMKr0pXvByGPHCtRbu ShXAcoSdVH2f8cLUfJ8raVMWu1ynjOMcvlagDaZAcbzLSc8hzhxJNC6Wel9U1uFyEaYGodJTMxzv e5zRU5wZod5kPaEThCKq12Fr9Sz/dYYp4Rup/SymTS4A46qMIrOi6i3icxa3SYAhsCeALdcrgCH4 +cCtKiEE1UpqIfJq8P/+FE6cnfHyGaXD+wn4BTA5BrUBg900HNVNf1Y6BDMqaXDeAPKbiSb5FDot PjAW0v7GLoshHMr+951EdhaFNSUyOV8CoSx9b9BjlYpjJV+QtiaqJLn9UlNOa987Fg9dIY4vrfqH q9kCVr+sVpQsZ6DC17bE7etrHPevRny/EcLmuJY1RD56gPAyePHFs1GEhmKVW9ZlLWtNs79G6wSf ZRnr3vRAtr7v0zWyjfvn52HWM4kbXedjCa/q9boJMVqK+8DJawhrrn38Liw7oDCCCIAwggZooAMC AQICE2sAANv9iRUGFNx/sYkAAAAA2/0wDQYJKoZIhvcNAQELBQAwSDETMBEGCgmSJomT8ixkARkW A2NvbTEXMBUGCgmSJomT8ixkARkWB3BvbHljb20xGDAWBgNVBAMTD1BvbHljb20tU1VCQ0EwMTAe Fw0xNjAyMTYxNzI1NTlaFw0xNzAyMTUxNzI1NTlaMIGnMRMwEQYKCZImiZPyLGQBGRYDY29tMRcw FQYKCZImiZPyLGQBGRYHcG9seWNvbTEPMA0GA1UECxMGUGVvcGxlMRIwEAYDVQQLEwlFbXBsb3ll ZXMxDTALBgNVBAsTBE5BTEExGDAWBgNVBAMTD0R1Y2t3b3J0aCwgTWFyazEpMCcGCSqGSIb3DQEJ ARYaTWFyay5EdWNrd29ydGhAcG9seWNvbS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDUKfyJTxXkwEsUnHz/9m3k1jNMh31VSjpcboNOXMLE7ERqwC+KdVON0NLHp5ctN4kWewuu YDOuS+Qhp/Pm/+T2acQ0cqw+oY3nvKl7erYfC5Ul0EATlD3aUTGz34L2iKttOm9YID2GylBH9670 PHQ7n3YqC5sh1C7l2S4CznZz5c4ATRw1VtAzWskinzwYWKeiJV2ybr4JU9EM5QAGqM84jFXV2kN2 3CGKmAWlo6GIXstg82hfTkfubmgW9BQ+iyHEfwP1DIvdLh4tsyrgHoz+qomNaXmG+jUiP5CktXDF KueQLciDeg9HyxGh7AgtTvdMtI3KZUFCDyKDN4k0ux/5AgMBAAGjggQBMIID/TA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiGpOVThtjlcoO1gRiEnaYag+m7OimFw9RYg9ngHQIBZAIBBzApBgNV HSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwCwYDVR0PBAQDAgWgMDUGCSsG AQQBgjcVCgQoMCYwCgYIKwYBBQUHAwIwCgYIKwYBBQUHAwQwDAYKKwYBBAGCNwoDBDBEBgkqhkiG 9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZI hvcNAwcwHQYDVR0OBBYEFBENjiHBionI5U/bTdJlzr9d3XeNMB8GA1UdIwQYMBaAFHCHwOe0vPcW QG7PYk/NxYXFTXnpMIIBOgYDVR0fBIIBMTCCAS0wggEpoIIBJaCCASGGgbxsZGFwOi8vL0NOPVBv bHljb20tU1VCQ0EwMSxDTj12d2NvbG9zdWJjYTAxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBT ZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXBvbHljb20sREM9Y29tP2Nl cnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Q b2ludIYvaHR0cDovL2NkcDEucG9seWNvbS5jb20vcGtpL1BvbHljb20tU1VCQ0EwMS5jcmyGL2h0 dHA6Ly9jZHAyLnBvbHljb20uY29tL3BraS9Qb2x5Y29tLVNVQkNBMDEuY3JsMIIBPQYIKwYBBQUH AQEEggEvMIIBKzCBrgYIKwYBBQUHMAKGgaFsZGFwOi8vL0NOPVBvbHljb20tU1VCQ0EwMSxDTj1B SUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlv bixEQz1wb2x5Y29tLERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTA7BggrBgEFBQcwAoYvaHR0cDovL2NkcDEucG9seWNvbS5jb20vcGtp L1BvbHljb20tU1VCQ0EwMS5jcnQwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jZHAyLnBvbHljb20uY29t L3BraS9Qb2x5Y29tLVNVQkNBMDEuY3J0MEgGA1UdEQRBMD+gIQYKKwYBBAGCNxQCA6ATDBFtYXJr ZEBwb2x5Y29tLmNvbYEaTWFyay5EdWNrd29ydGhAcG9seWNvbS5jb20wDQYJKoZIhvcNAQELBQAD ggIBAHSlqpzE3JJ6cwdt2ve4eLY7IBfvrGjyFRQRfUgHg7SpxJVjB1jIZY7xXeGcBozQDSO6nQF6 KN3s+Mhy1GgH0tRMZBqefwZaT0taRdMHH/bXxDE4Qf8BRMXNIPZPb+2CV4ldFakuT1VZwmg1Gdtc ZU41o/zXYUBkzjPRX4DaEBWDsxI8Z3OX0lz3Kps3CocagYE+sjTaPIEFF3Gztyw5I8fS/nMnrSq3 G91bqqWE0teuGfBdt6tKqavJ0qHobkOQRV2bQi6OPzLZg8a1IaSZMviUDgzj/VASvw7phEUScEVf VqAvoru/7TWREyoc/lSvsd+PTpMeOjLUDre/FAbRGpN9Sx8FuBgvvb3wYdIMg/R8tIaQ8tqaAG/3 dSa9IeRfWOrcAOuc8TUieSDsTqugStWtKVsO8dCcZtdaPpL0deSjjEF+Ep9ZfqufhibQyFGNTjRK VwgxCQc+owwJx69vo2oDlzwWYhASQmwXVW9eiSWnvvMhvAny5dftCFaV47mSyQimkQ3k/rsX2Cg9 qbeuI0dSSD5c5pgE6z3jkF8ISL/1WitwCtG5Yqqp7Q8G2a35smlSVRzc1WTAiy6jZHSPZsbnRu5Y 9BnsB/TOcmKt9kAn6VUAC4j+Rq7MokZJzmj0sKNMH4qz3bo6ZMImkGS3xCLyvsK4iilg1Me67dlz bbJ1MYIDXzCCA1sCAQEwXzBIMRMwEQYKCZImiZPyLGQBGRYDY29tMRcwFQYKCZImiZPyLGQBGRYH cG9seWNvbTEYMBYGA1UEAxMPUG9seWNvbS1TVUJDQTAxAhNrAADb/YkVBhTcf7GJAAAAANv9MAkG BSsOAwIaBQCgggHVMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2 MTEyMjE5Mjk1OVowIwYJKoZIhvcNAQkEMRYEFL90QcSU197AfYaT9UCIwsaf6wIYMG4GCSsGAQQB gjcQBDFhMF8wSDETMBEGCgmSJomT8ixkARkWA2NvbTEXMBUGCgmSJomT8ixkARkWB3BvbHljb20x GDAWBgNVBAMTD1BvbHljb20tU1VCQ0EwMQITawAA2/2JFQYU3H+xiQAAAADb/TBwBgsqhkiG9w0B CRACCzFhoF8wSDETMBEGCgmSJomT8ixkARkWA2NvbTEXMBUGCgmSJomT8ixkARkWB3BvbHljb20x GDAWBgNVBAMTD1BvbHljb20tU1VCQ0EwMQITawAA2/2JFQYU3H+xiQAAAADb/TCBkwYJKoZIhvcN AQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCGjALBglghkgBZQMEAgMw CwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQBZxpeA/ADHJgXm5Inh BzIXfiSsYT23LnXcG0JpXvXm6HuKFpK0IfOb7hXeEURK91BIpusirr5p6ZjExwOzUw6rXhkY/L2N 51cuauqTE77xRHag75+rugDWLb6Vj2Kr20DmPNQjyiHVjwllIu3Rwql5Cj/4yRJqqtloh77ctVqG OhfBCA0oBtmuqupJWBl4YEmFuwFaZgXEeeDq/cn/GItM+n2nKlB+IuFgiyJfU2K4xe4xEmC5p852 APbVH01bZSC+3g96Nb4amiIYLzXdfNxVhYRrj+rsYn5urvokpFQn1fwcqhUdxn6Rqot67Qj2GgRJ +LomrZdmZTzNa0ygzN58AAAAAAAA ------=_NextPart_000_048F_01D244CC.E783D700--