Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirements-05.txt
Mary Barnes <mary.ietf.barnes@gmail.com> Wed, 23 October 2013 23:14 UTC
Return-Path: <mary.ietf.barnes@gmail.com>
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 2845111E8244 for <clue@ietfa.amsl.com>; Wed, 23 Oct 2013 16:14:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.604
X-Spam-Level:
X-Spam-Status: No, score=-101.604 tagged_above=-999 required=5 tests=[AWL=-0.671, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LnZAD+g3tLp for <clue@ietfa.amsl.com>; Wed, 23 Oct 2013 16:14:33 -0700 (PDT)
Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7948211E8294 for <clue@ietf.org>; Wed, 23 Oct 2013 16:14:25 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id hn9so1690081wib.17 for <clue@ietf.org>; Wed, 23 Oct 2013 16:14:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KCRQR9v3csry55TJ/vTSrOMD2ZHoIfie0FZWf2cMMWo=; b=qMWeRbDfiPjcDitotppOJsa/3hDXfTIKBj9zN3c7ubXy+egNKNGs1LHPtN9DaWlvu1 GWAFu2dPGWNnxVps9QzSKrSLbsTzFVnzu90NIPeFaz6+Cj2OY17TGFXaEzR1o5oA0zfU SeILkT9XyIoNdZqMGBgLhPgPbti799ddqrbQoCB0H7l7ja331Z09Pio2A44C4hzU5pbx ogviUJW9WPecaRYR3rUSp6EDZbx0LSqmPUFTRC5U3FRFCL8fLCSB/rVFgNv97gn7kQZo GI7bha3E+qVKUzPYtVmThCW9KXoFYgg5d6rxU5FjD4Ba6omcb+dKsNZdUTTtkfQb/7nk I3Fw==
MIME-Version: 1.0
X-Received: by 10.180.198.79 with SMTP id ja15mr3532004wic.36.1382570064620; Wed, 23 Oct 2013 16:14:24 -0700 (PDT)
Received: by 10.216.36.4 with HTTP; Wed, 23 Oct 2013 16:14:24 -0700 (PDT)
In-Reply-To: <52684B82.4090104@alum.mit.edu>
References: <20130830223924.16258.71205.idtracker@ietfa.amsl.com> <5224EC1A.1020603@alum.mit.edu> <52360B40.9030702@alum.mit.edu> <5237D653.901@nteczone.com> <CAHBDyN6GEXYmOud9+TC47-FYsAVYiL6iEoFgPPFrpZfHdHsCZg@mail.gmail.com> <5238BB74.6090907@alum.mit.edu> <CAHBDyN6wDySZtz5kpQkVAkOrRoN6oBYiyz0EFH-7TnoxKgnx-A@mail.gmail.com> <5238D6CA.3080500@alum.mit.edu> <CAHBDyN7PbUv8hWAHASutiXQtEwsG4YUODT1B_=B193TuOtpytw@mail.gmail.com> <49E45C59CA48264997FEBFB29B6BC2D60333D68B@CRPMBOXPRD07.polycom.com> <52684B82.4090104@alum.mit.edu>
Date: Wed, 23 Oct 2013 18:14:24 -0500
Message-ID: <CAHBDyN4y8xx=ivB64r67bY-Va2bSzKiE9ajZH8m=4fFeK6TA9g@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: multipart/alternative; boundary="047d7b6242529432d404e970adb5"
Cc: CLUE <clue@ietf.org>
Subject: Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirements-05.txt
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: CLUE - ControLling mUltiple streams for TElepresence <clue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/clue>, <mailto:clue-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/clue>
List-Post: <mailto:clue@ietf.org>
List-Help: <mailto:clue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/clue>, <mailto:clue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Oct 2013 23:14:36 -0000
On Wed, Oct 23, 2013 at 5:19 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote: > I'm trying to clean up old dangling mail, and came across this one. > > > On 9/24/13 4:46 PM, Duckworth, Mark wrote: > >> I always thought “site” and “endpoint” are synonymous. I don’t know >> what the difference would be. I was not using “site” to refer only to >> multiscreen/multicamera rooms. >> > > In most cases I think what you say will end up being right. > But there are some troublesome cases that I have considered. (And > discussed in the past.) Most notably: > > There could be a "traditional" TP room - seats for several people in front > of some big screens, and some cameras pointing at them, ... > There is a single system (endpoint) controlling all that equipment. > This seems like a "site" to me. > > People in that room may have their own laptops or tablets. Those systems > can have a CLUE client. They could connect directly to the same conference > focus that the room endpoint connects to. They could use their private > system to share presentations, and maybe to display video captures that > aren't displayed in the room. (Or that are, in order to get a closer view.) > > These separate systems will be viewed by the MCU as separate endpoints. > But should we consider them to be in a separate *site*? > > It might be difficult to discover that they are part of the same site. And > maybe we don't need to. But it might be convenient to be able to detect > that the person talking in the room is talking about the presentation being > shared by the separate endpoint that he controls. > > Maybe this just highlights that we shouldn't use the term "site", and > should instead use "endpoint" or "scene" depending on which is important. > [MB] Exactly. And, I used the former "endpoint" in resolving the issue that Christian raised. I think we got a little wrapped around the axle on this one as I don't think it matters in the context we're working - i.e., I don't think it's a problem for the framework, which uses primarily endpoint. "site" is only used in the context of "site-switching" in the framework - i.e,. 7.2.2 of the framework. Note that "scene" is already being used in that context for "Scene switch policy" - i.e., "site switch" or "segment switch". However, I think the term "site" is quite clear in that context, so I think we may be able to leave all that as is. We spent a lot of time early on coming up with terms for these things, so I do think we need to be extremely careful about making changes at this juncture. [/MB] > > Thanks, > Paul > > Mark >> >> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf >> >> Of *Mary Barnes >> *Sent:* Tuesday, September 17, 2013 7:21 PM >> *To:* Paul Kyzivat >> *Cc:* CLUE >> *Subject:* Re: [clue] REMINDER!!! WGLC: >> >> draft-ietf-clue-telepresence-**requirements-05.txt >> >> On Tue, Sep 17, 2013 at 5:25 PM, Paul Kyzivat <pkyzivat@alum.mit.edu >> <mailto:pkyzivat@alum.mit.edu>**> wrote: >> >> Mary, >> >> >> >> On 9/17/13 5:04 PM, Mary Barnes wrote: >> >> Yes. There are other requirements using the term site. If you look >> at >> the definition of "endpoint", there is the following statement: >> Endpoints can be anything from >> multiscreen/multicamera rooms to handheld devices. >> >> So, I think we are using site to refer explicitly/only to >> multiscreen/multicamera rooms. >> >> Are we? I think even then we are really talking about endpoints, but >> with our design center biased towards multiscreen/multicamera rooms. >> >> >> E.g., when we are doing "site switching", a CLUE compatible cell >> phone is still going to be treated as a site, together with the >> telepresence "rooms" in the session. >> >> [MB] Actually, we don't define "site" in the CLUE framework either (and >> the word appears 89 times in the use cases). So, maybe we *should* >> define site and leave most of the requirements alone. I think the word >> conveys the concept well and I think we lose something if we change to >> endpoint in many cases, which we should do consistently if we propose to >> do so in the requirements document. [/MB] >> >> >> I'm not aware of *anything* that is specific to >> multiscreen/multicamera endpoints. >> >> Maybe the easiest thing to do is to just >> add a parenthetical comment in that sentence like the following: >> >> Endpoints can be anything from >> multiscreen/multicamera rooms (referred to as "sites") >> to handheld devices. >> >> Wouldn't that confuse the definition of site switching? >> >> Thanks, >> Paul >> >> Then, I do think it is appropriate to change the word "site" in >> REQMT-12 >> to "endpoint" as the intent of the requirement should also to >> endpoints >> other than multiscreen/multicamera rooms. I think the use of >> "site" in >> the other requirements is okay. >> >> Mary. >> >> >> On Tue, Sep 17, 2013 at 3:28 PM, Paul Kyzivat >> <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu> >> >> <mailto:pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>**>> >> >> wrote: >> >> Mary, >> >> IIUC, you are proposing to make a change from "site" to >> "endpoint" >> in Reqmnt-12, and otherwise leave things alone? >> >> Thanks, >> Paul >> >> >> On 9/17/13 2:06 PM, Mary Barnes wrote: >> >> Hi Christian, >> >> Thanks for taking the time to review this. >> Comments/responses >> below [MB]. >> >> Mary. >> >> >> On Mon, Sep 16, 2013 at 11:10 PM, Christian Groves >> <Christian.Groves@nteczone.com >> <mailto:Christian.Groves@**nteczone.com<Christian.Groves@nteczone.com> >> > >> <mailto:Christian.Groves@**nteczone.com<Christian.Groves@nteczone.com> >> <mailto:Christian.Groves@**nteczone.com<Christian.Groves@nteczone.com> >> >> >> >> <mailto:Christian.Groves@ >> <mailto:Christian.Groves@>__nt**eczone.com <http://nteczone.com>< >> http://nteczone.com> >> >> >> <mailto:Christian.Groves@**nteczone.com<Christian.Groves@nteczone.com> >> <mailto:Christian.Groves@**nteczone.com<Christian.Groves@nteczone.com> >> >>>> >> >> wrote: >> >> Hello, >> >> Here are my comments to the WGLC: >> >> 1) Reqmt-1D - With regards to reqmt-1d: The >> solution MUST >> support a >> means to identify >> the extent of individual >> video >> captures in >> three dimensions. >> >> Did we decide whether this was with respect to a >> "plane of >> interest" >> in 3 dimensions? and/or a volume (i.e. >> incorporating a >> depth aspect) >> in 3 dimensions? It probably would be good to >> clarify this >> in the >> requirements. >> >> [MB] I don't know that this particular detail matters >> in the >> requirements document. [/MB] >> >> >> 2) General: At different places there are >> references to >> particular >> use cases. However this doesn't appear to used >> consistently. e.g. >> Regmt-9 regarding interoperability between >> endpoints using >> different >> numbers of streams makes references to the >> heterogeneous >> use case. >> The heterogeneous use cases mentions different bit >> rates etc, >> however Reqmts-8, 7 etc don't mention the use case? >> It >> seems to me >> that if we include references to use cases that we >> should >> be consistent. >> >> [MB] Not all requirements can be mapped directly to use >> cases - >> e.g., >> 16, 17 & 18. In the cases, where they can, we probably >> should. The >> references are intended to informative. [/MB] >> >> >> 3) REQMT-12: Rather than say "..more than two >> <sites>" >> should we use >> "..more than two endpoints". We don't have a >> definition for >> "site". >> >> [MB] We don't have an explicit definition but it can >> certainly be >> derived from the context. We use "site" in several >> other places >> and just >> replacing that with endpoint in those cases won't work >> - e.g,. in >> Section 4: "If Alice and Bob are at different sites, >> Alice needs to >> tell Bob about the camera and sound equipment >> arrangement at her >> site so >> that Bob's receiver can create an accurate rendering of >> her site." >> That all said, I think we can replace the use of "site" >> in that >> requirement as that's consistent with all the other >> requirements. >> [/MB] >> >> >> 4) General: Do we need to have some text in the >> document that >> indicates that there may be other unspecified >> requirements >> that may >> be implemented? The framework has a number of >> attributes >> that aren't >> mentioned as part of the requirements e.g. scene >> description. Or >> alternatively do we capture this by adding a generic >> requirement >> regarding description of the content of >> captures/scenes? The >> requirements are very focussed on spatial/render >> aspects >> rather than >> information pertaining to the selection of captures. >> >> [MB] I do not believe so. These are the bare bones >> requirements >> - if we >> don't have functionality to support these then we >> haven't done >> our job. >> However, the solution can certainly define additional >> functionality, >> that doesn't necessarily map to a specific requirement. >> The >> requirements should not be specifying all the details >> of the >> attributes >> necessary to support the use cases - that's the >> objective of the >> framework. Now, if you think there is a general >> requirement that's >> missing, certainly you can propose such. Realistically, >> requirements >> documents are starting points to seed the solution >> work. Once the >> solution is started unless the WG thinks a requirement >> can't be met, >> it's not necessarily productive to try to make the >> requirements >> document >> absolutely complete. Indeed, a number of WGs actually >> never publish >> requirements documents, but rather just cache them in an >> appendix for >> historical purposes. [/MB] >> >> >> 5) General: There seems to be a requirement in >> CLUE of the >> ability >> to indicate how captures are related to resources. >> e.g. the STS >> mechanism indicates which captures may be used >> together (which >> indicates which ones can't be used together) and >> the CSE >> that groups >> capture resources. This seems to be an important >> aspect of >> CLUE but >> there doesn't appear to be a requirement driving it. >> >> [MB] As I mentioned previously, we don't need to have a >> requirement to >> justify every aspect of the solution. We don't want >> to get >> into having >> to define capture scene entries, etc. in the >> requirements. We >> don't >> need to backwards engineer the requirements to match the >> solution. [/MB] >> >> >> Regards, Christian >> >> >> On 16/09/2013 5:32 AM, Paul Kyzivat wrote: >> >> We started WGLC on the requirements two weeks >> ago. >> It has run for two weeks, and there have been >> *NO* >> comments!!! :-( >> >> I can't advance this document without better >> indication of >> support from the WG. So I'm extending this >> WGLC. I'll >> be away >> next weekend, so I will let this extension run >> another two >> weeks, ending Sunday Sept 29. >> >> We NEED NEED NEED your comments on this. >> Please review >> it again, >> and respond either positively or negatively, >> whether >> you think >> it is ready to progress. >> >> Thanks, >> Paul >> >> On 9/2/13 3:50 PM, Paul Kyzivat wrote: >> >> With this message I'm announcing the start >> of WGLC for >> >> >> draft-ietf-clue-telepresence-_**___requirements-05 >> >> >> >> >> This WGLC will last for roughly two weeks, >> ending at >> midnight GMT on >> Sunday September 15. >> >> It is important to have decisive results >> from a WGLC. >> (Silence doesn't do it.) >> So please, take a last careful look at these >> requirements >> and comment. >> If you like these as they are, please say >> so. >> >> Thanks, >> Paul (as co-chair) >> >> On 8/30/13 6:39 PM, >> internet-drafts@ietf.org <mailto:internet-drafts@ietf.**org<internet-drafts@ietf.org> >> > >> <mailto:internet-drafts@ietf.**org<internet-drafts@ietf.org> >> <mailto:internet-drafts@ietf.**org <internet-drafts@ietf.org>>> >> >> <mailto:internet-drafts@ietf. >> <mailto:internet-drafts@ietf.>**__org >> >> >> <mailto:internet-drafts@ietf.**org<internet-drafts@ietf.org> >> <mailto:internet-drafts@ietf.**org <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 Working Group of the IETF. >> >> Title : Requirements for >> Telepresence >> Multi-Streams >> Author(s) : Allyn Romanow >> Stephen >> Botzko >> Mary Barnes >> Filename : >> >> draft-ietf-clue-telepresence-_**___requirements-05.txt >> >> >> >> Pages : 13 >> Date : 2013-08-30 >> >> Abstract: >> This memo discusses the >> requirements for a >> specification that enables >> telepresence interoperability, by >> describing the >> relationship between >> multiple RTP streams. In >> addition, the >> problem >> statement and >> definitions are also covered >> herein. >> >> >> The IETF datatracker status page for >> this draft is: >> >> https://datatracker.ietf.org/_**___doc/draft-ietf-clue-____** >> telepresence-requirements<https://datatracker.ietf.org/____doc/draft-ietf-clue-____telepresence-requirements> >> >> <https://datatracker.ietf.org/**__doc/draft-ietf-clue-__** >> telepresence-requirements<https://datatracker.ietf.org/__doc/draft-ietf-clue-__telepresence-requirements> >> > >> >> >> >> >> >> <https://datatracker.ietf.org/**__doc/draft-ietf-clue-__** >> telepresence-requirements<https://datatracker.ietf.org/__doc/draft-ietf-clue-__telepresence-requirements> >> >> <https://datatracker.ietf.org/**doc/draft-ietf-clue-** >> telepresence-requirements<https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements> >> >> >> >> >> >> There's also a htmlized version >> available at: >> >> http://tools.ietf.org/html/___**_draft-ietf-clue-telepresence-** >> ____requirements-05<http://tools.ietf.org/html/____draft-ietf-clue-telepresence-____requirements-05> >> >> <http://tools.ietf.org/html/__**draft-ietf-clue-telepresence-_** >> _requirements-05<http://tools.ietf.org/html/__draft-ietf-clue-telepresence-__requirements-05> >> > >> >> >> >> >> >> <http://tools.ietf.org/html/__**draft-ietf-clue-telepresence-_** >> _requirements-05<http://tools.ietf.org/html/__draft-ietf-clue-telepresence-__requirements-05> >> >> <http://tools.ietf.org/html/**draft-ietf-clue-telepresence-** >> requirements-05<http://tools.ietf.org/html/draft-ietf-clue-telepresence-requirements-05> >> >> >> >> A diff from the previous version is >> available at: >> >> http://www.ietf.org/rfcdiff?__**__url2=draft-ietf-clue-____** >> telepresence-requirements-05<http://www.ietf.org/rfcdiff?____url2=draft-ietf-clue-____telepresence-requirements-05> >> >> <http://www.ietf.org/rfcdiff?_**_url2=draft-ietf-clue-__** >> telepresence-requirements-05<http://www.ietf.org/rfcdiff?__url2=draft-ietf-clue-__telepresence-requirements-05> >> > >> >> >> >> >> >> <http://www.ietf.org/rfcdiff?_**_url2=draft-ietf-clue-__** >> telepresence-requirements-05<http://www.ietf.org/rfcdiff?__url2=draft-ietf-clue-__telepresence-requirements-05> >> >> <http://www.ietf.org/rfcdiff?**url2=draft-ietf-clue-** >> telepresence-requirements-05<http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-telepresence-requirements-05> >> >> >> >> >> >> >> 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 <http://tools.ietf.org> <http://tools.ietf.org> >> <http://tools.ietf.org>. >> >> >> >> >> Internet-Drafts are also available by >> anonymous >> FTP at: >> >> ftp://ftp.ietf.org/internet-__**__drafts/<ftp://ftp.ietf.org/internet-____drafts/> >> <ftp://ftp.ietf.org/internet-_**_drafts/<ftp://ftp.ietf.org/internet-__drafts/> >> > >> <ftp://ftp.ietf.org/internet-_** >> _drafts/ <ftp://ftp.ietf.org/internet-__drafts/> >> <ftp://ftp.ietf.org/internet-**drafts/<ftp://ftp.ietf.org/internet-drafts/> >> >> >> >> >> ______________________________**_____________________ >> clue mailing list >> clue@ietf.org <mailto:clue@ietf.org> <mailto:clue@ietf.org >> <mailto:clue@ietf.org>> <mailto:clue@ietf.org <mailto: >> clue@ietf.org> >> <mailto:clue@ietf.org <mailto:clue@ietf.org>>> >> >> https://www.ietf.org/mailman/_**___listinfo/clue<https://www.ietf.org/mailman/____listinfo/clue> >> <https://www.ietf.org/mailman/**__listinfo/clue<https://www.ietf.org/mailman/__listinfo/clue> >> > >> >> <https://www.ietf.org/mailman/**__listinfo/clue<https://www.ietf.org/mailman/__listinfo/clue> >> <https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue> >> >> >> >> >> >> ______________________________**_____________________ >> clue mailing list >> clue@ietf.org <mailto:clue@ietf.org> <mailto:clue@ietf.org >> <mailto:clue@ietf.org>> <mailto:clue@ietf.org <mailto: >> clue@ietf.org> >> <mailto:clue@ietf.org <mailto:clue@ietf.org>>> >> >> https://www.ietf.org/mailman/_**___listinfo/clue<https://www.ietf.org/mailman/____listinfo/clue> >> <https://www.ietf.org/mailman/**__listinfo/clue<https://www.ietf.org/mailman/__listinfo/clue> >> > >> <https://www.ietf.org/mailman/** >> __listinfo/clue <https://www.ietf.org/mailman/__listinfo/clue> >> <https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue> >> >> >> >> >> >> ______________________________**_____________________ >> clue mailing list >> clue@ietf.org <mailto:clue@ietf.org> <mailto:clue@ietf.org >> <mailto:clue@ietf.org>> <mailto:clue@ietf.org <mailto: >> clue@ietf.org> >> <mailto:clue@ietf.org <mailto:clue@ietf.org>>> >> >> https://www.ietf.org/mailman/_**___listinfo/clue<https://www.ietf.org/mailman/____listinfo/clue> >> <https://www.ietf.org/mailman/**__listinfo/clue<https://www.ietf.org/mailman/__listinfo/clue> >> > >> <https://www.ietf.org/mailman/**__listinfo/clue<https://www.ietf.org/mailman/__listinfo/clue> >> <https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue> >> >> >> >> >> ______________________________** >> _____________________ >> clue mailing list >> clue@ietf.org <mailto:clue@ietf.org> <mailto:clue@ietf.org >> <mailto:clue@ietf.org>> <mailto:clue@ietf.org <mailto: >> clue@ietf.org> >> <mailto:clue@ietf.org <mailto:clue@ietf.org>>> >> >> https://www.ietf.org/mailman/_**___listinfo/clue<https://www.ietf.org/mailman/____listinfo/clue> >> <https://www.ietf.org/mailman/**__listinfo/clue<https://www.ietf.org/mailman/__listinfo/clue> >> > >> >> >> <https://www.ietf.org/mailman/**__listinfo/clue<https://www.ietf.org/mailman/__listinfo/clue> >> <https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue> >> >> >> >> >> >> >> ______________________________**___________________ >> clue mailing list >> clue@ietf.org <mailto:clue@ietf.org> <mailto:clue@ietf.org >> <mailto:clue@ietf.org>> >> https://www.ietf.org/mailman/_**_listinfo/clue<https://www.ietf.org/mailman/__listinfo/clue> >> <https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue> >> > >> >> >> ______________________________**___________________ >> clue mailing list >> clue@ietf.org <mailto:clue@ietf.org> <mailto:clue@ietf.org >> <mailto:clue@ietf.org>> >> https://www.ietf.org/mailman/_**_listinfo/clue<https://www.ietf.org/mailman/__listinfo/clue> >> <https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue> >> > >> >> >
- [clue] I-D Action: draft-ietf-clue-telepresence-r… internet-drafts
- [clue] Fwd: I-D Action: draft-ietf-clue-teleprese… Mary Barnes
- [clue] WGLC: draft-ietf-clue-telepresence-require… Paul Kyzivat
- [clue] REMINDER!!! WGLC: draft-ietf-clue-telepres… Paul Kyzivat
- Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-tele… Christian Groves
- Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-tele… Mary Barnes
- Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-tele… Paul Kyzivat
- Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-tele… Mary Barnes
- Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-tele… Paul Kyzivat
- Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-tele… Mary Barnes
- Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-tele… Christian Groves
- Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-tele… Michael Hammer
- Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-tele… Duckworth, Mark
- Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-tele… Duckworth, Mark
- Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-tele… Paul Kyzivat
- Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-tele… Mary Barnes