From ieprep-bounces@ietf.org Mon Aug 01 05:51:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzWwu-0007Nz-I8; Mon, 01 Aug 2005 05:51:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzWwt-0007NR-8t for ieprep@megatron.ietf.org; Mon, 01 Aug 2005 05:51:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13544 for ; Mon, 1 Aug 2005 05:51:04 -0400 (EDT) Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DzXT2-0007UX-IW for ieprep@ietf.org; Mon, 01 Aug 2005 06:24:27 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-3.tower-121.messagelabs.com!1122889850!3855972!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.132] Received: (qmail 29437 invoked from network); 1 Aug 2005 09:50:50 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.133.132) by server-3.tower-121.messagelabs.com with SMTP; 1 Aug 2005 09:50:50 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 42E3BC2B001E495E; Mon, 1 Aug 2005 05:50:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Aug 2005 04:50:49 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA060CE6A7@KCCLUST06EVS1.ugd.att.com> Thread-Topic: Precedence/Priority Requirements for MLPP/Assured-Services & NSIS Work in Progress Thread-Index: AcWWcr6+vbx38vXLTBusww2wVdz+owACoh0Q From: "Ash, Gerald R \(Jerry\), ALABS" To: X-Spam-Score: 0.9 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "Fineberg, Victoria" , "Ash, Gerald R \(Jerry\), ALABS" , "Nguyen, An" , "DeSimone, Tony - APL" Subject: [Ieprep] Precedence/Priority Requirements for MLPP/Assured-Services & NSIS Work in Progress X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org All, Following up on Tony DeSimone's and An Nguyen's presentations this morning at the IEPREP meeting regarding priority/precedence requirements, it would be good for folks to be aware of the work of NSIS http://ietf.org/html.charters/nsis-charter.html on QoS signaling. In particular, please take a look at > QoS-NSLP > http://ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-07.txt > and QSPEC for QoS-NSLP > http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-05.txt >=20 > The latter document specifies several parameters for signaling > priority: holding priority, preemption priority, reservation priority > (latter including admission priority, RPH namespace, RPH priority). >=20 Requirements for 'MLPP/Assured-Services' (not sure what it's called now) may fit into the work already started in NSIS. > Thanks, > Jerry _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Mon Aug 01 10:42:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzbV8-0000Ze-Ii; Mon, 01 Aug 2005 10:42:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzbV6-0000Yv-1n for ieprep@megatron.ietf.org; Mon, 01 Aug 2005 10:42:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13424 for ; Mon, 1 Aug 2005 10:42:42 -0400 (EDT) Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzc1N-0003kP-HL for ieprep@ietf.org; Mon, 01 Aug 2005 11:16:06 -0400 Received: from [149.8.64.21] by mclmx2.mail.saic.com for ieprep@ietf.org; Mon, 1 Aug 2005 10:42:35 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2005080110423509443 for ; Mon, 01 Aug 2005 10:42:35 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Mon, 1 Aug 2005 10:42:35 -0400 Message-Id: From: "King, Kimberly S." To: "'ieprep@ietf.org'" Date: Mon, 1 Aug 2005 10:42:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [Ieprep] Precedence and Preemption for the GIG Transport Services X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org You may find the slides from today's meeting here http://www.apl.jhu.edu/Notes/DeSimone/IETF/IEPREP/Paris/P&P_ietf_ieprep_31ju l2005.pdf _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Fri Aug 26 12:05:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8giE-00017G-21; Fri, 26 Aug 2005 12:05:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8giC-00016f-4a for ieprep@megatron.ietf.org; Fri, 26 Aug 2005 12:05:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28999 for ; Fri, 26 Aug 2005 12:05:45 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8giw-0003U9-0x for ieprep@ietf.org; Fri, 26 Aug 2005 12:06:35 -0400 Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j7QG3Tu10391 for ; Fri, 26 Aug 2005 12:03:29 -0400 (EDT) Received: from KCHAN-2K3.nortel.com (kchan-2k3.us.nortel.com [47.16.54.138]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RCFP3XFW; Fri, 26 Aug 2005 12:05:24 -0400 Message-Id: <6.0.3.0.0.20050826115408.0487ac58@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Fri, 26 Aug 2005 12:05:23 -0400 To: ieprep@ietf.org From: "Kwok-Ho Chan" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ieprep] After IEPREP WG meeting in Paris X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org Hi: I noticed that Proceedings Submission Cut-Off date for the 63rd IETF at Paris is Friday Sept 02, 2005, which is one week away. I have not seen the IEPREP Working Group Meeting Notes/Minutes posted on the IEPREP WG Mailing List yet. Shouldn't the content of the meeting notes/minutes be reviewed by the WG on the WG mailing list prior to their submission to proceedings? What about the Re-Chartering discussions? Wasn't there supposed to be changes to the proposed new charter to be posted on the list so further discussion on this topic can continue on this list (for people who did not attend the meeting in Paris)? Thanks! -- Kwok -- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Fri Aug 26 12:46:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8hLH-0006EJ-2P; Fri, 26 Aug 2005 12:46:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8hLF-0006CW-UD for ieprep@megatron.ietf.org; Fri, 26 Aug 2005 12:46:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01276 for ; Fri, 26 Aug 2005 12:46:07 -0400 (EDT) Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8hM0-0004uV-9V for ieprep@ietf.org; Fri, 26 Aug 2005 12:46:57 -0400 Received: from [149.8.64.21] by mclmx2.mail.saic.com; Fri, 26 Aug 2005 12:45:49 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2005082612454902410 ; Fri, 26 Aug 2005 12:45:49 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Fri, 26 Aug 2005 12:45:49 -0400 Message-Id: From: "King, Kimberly S." To: Kwok-Ho Chan , ieprep@ietf.org Subject: RE: [Ieprep] After IEPREP WG meeting in Paris Date: Fri, 26 Aug 2005 12:45:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org Kwok, The ieprep minutes are here http://www3.ietf.org/proceedings/05aug/minutes/ieprep.html The re-chartering discussion will start soon... Kimberly _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Fri Aug 26 15:41:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8k5C-0006TT-5M; Fri, 26 Aug 2005 15:41:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8k5A-0006TO-Hf for ieprep@megatron.ietf.org; Fri, 26 Aug 2005 15:41:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10771 for ; Fri, 26 Aug 2005 15:41:42 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8k5w-0001uO-8C for ieprep@ietf.org; Fri, 26 Aug 2005 15:42:33 -0400 Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j7QJdQu06549; Fri, 26 Aug 2005 15:39:26 -0400 (EDT) Received: from KCHAN-2K3.nortel.com (kchan-2k3.us.nortel.com [47.16.54.138]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RCFP35LC; Fri, 26 Aug 2005 15:41:21 -0400 Message-Id: <6.0.3.0.0.20050826153849.046a3958@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Fri, 26 Aug 2005 15:41:20 -0400 To: "King, Kimberly S." From: "Kwok-Ho Chan" Subject: RE: [Ieprep] After IEPREP WG meeting in Paris In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ieprep@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org Kimberly: Thank you very much! Will be providing any comments on the minute's content to the list. -- Kwok -- At 12:45 PM 8/26/2005, King, Kimberly S. wrote: >Kwok, > >The ieprep minutes are here >http://www3.ietf.org/proceedings/05aug/minutes/ieprep.html > >The re-chartering discussion will start soon... > >Kimberly _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Tue Aug 30 15:25:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EABjr-0006Ag-Dz; Tue, 30 Aug 2005 15:25:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EABjp-0006AI-9Q for ieprep@megatron.ietf.org; Tue, 30 Aug 2005 15:25:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03107 for ; Tue, 30 Aug 2005 15:25:37 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EABlN-0002cQ-M0 for ieprep@ietf.org; Tue, 30 Aug 2005 15:27:18 -0400 Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j7UJPG618344; Tue, 30 Aug 2005 15:25:17 -0400 (EDT) Received: from KCHAN-2K3.nortel.com (kchan-2k3.us.nortel.com [47.16.54.138]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RCFPP9RS; Tue, 30 Aug 2005 15:25:01 -0400 Message-Id: <6.0.3.0.0.20050830140155.046f1a40@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Tue, 30 Aug 2005 15:25:00 -0400 To: "King, Kimberly S." , ieprep@ietf.org From: "Kwok-Ho Chan" Subject: RE: [Ieprep] After IEPREP WG meeting in Paris In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d437399464e10b52abe9a34ed7e712d0 Cc: X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org Kimberly: My Thanks to the note takers. And thank you very much for posting the meeting minutes to the IEPREP list. I have made clarifications/corrections to the provided 63rd IETF IEPREP WG Meeting Minutes. The clarifications/corrections can be summarized as follows: 1. The hum indicated support for re-chartering in its current spirit with wording to be agreed on the mailing list. 2. The Working Group needs to have clear requirements before assuming any solutions or framework that satisfy the requirements. 3. Correction on my name, removing Paul: part or replacing Paul with Kwok. 4. Correction on name: Joe Babiarz. I have included below the posted minutes with the clarifications/corrections detailed, to assist the minutes editor(s) task. Thank you again for the opportunity to review the meeting minutes before they are finalized in the 63rd IETF Proceedings. -- Kwok Ho Chan -- Posted minutes with clarifications/corrections: >IEPREP Working Group Meeting at IETF-63 > >The IEPREP Working Group was chaired by Kimberly King at the Paris IETF-63 >on Monday August 1, 2005. (Scott Bradner, the other Co-Chair, was unable >to attend the Paris IETF meeting but was listening to the audio stream.) > >Minutes by Greg Bain with editorial assistance by Ken Carlberg > >The Agenda was as follows: > >5 minutes: agenda bashing >25 minutes: Ieprep re-charter discussion >15 minutes: Antonio DeSimone: DoD Requirements >15 Minutes: An Nguyen: NCS Presentation > >There were no objections to the agenda. > >Kimberly introduced the new proposed charter of Ieprep for discussion >having explained that the proposed revised charter had been posted to the >ieprep list before the meeting. > >Kimberly outlined important points, including some work being done in >other existing Working Groups, specifically highlighting the following >from the proposed charter: > >"If there is an existing WG that can discuss the requirements for >extending their protocol or mechanism, IEPREP will generate only a >requirements document for that group to discuss. > >If there is not an existing WG that can discuss the requirements for >extending their protocol or mechanism, IEPREP will prepare requirements >and discuss the extension of that protocol/mechanism or >protocols/mechanisms within IEPREP." > > >James Polk: >The charter is good. James suggested that something be added to the >proposed charter. The addition could take into account other applications >that may not be under way by other groups. Priority e-mail is a prime >example of one of these. James said that many things are "inferred" in the >charter, i.e., not explicitly stated, but understood. > >Ken Carlberg: >Question to James Polk, What is the status of your documents in TSV >(Transport Services Working Group)? > >Area Director Jon Peterson: >It is obvious that there has not been much procedural progress in TSV, but >this will be addressed shortly. > >James Polk: >James recommended that we continue to move forward in TSVWG with those >documents that are already in TSVWG. > >Ken: >Question for Kimberly: >Has anything been received privately on comments positive or negative on >the new proposed charter? > >Kimberly: >Tony DeSimone sent comments and he will speak to this question. > >Tony DeSimone: >I did have a few comments on language because there is work going on in >other forums. >Nested VPNs is an example of such work. There are language issues where >differences in definitions apply. > >Paul Kwok Ho Chan: Kwok Ho Chan: > >Will the MLPP draft be done here? > >Jon Peterson: >It will proceed in TSVWG. > >Paul Kwok Ho Chan: Kwok Ho Chan: > >We are jumping to solutions instead of doing more requirements? The MLPP >draft is more than requirements. Will the group be thinking about >additional possible solutions? > >Kimberly: >We hope to not presuppose solutions. > >Paul Kwok Ho Chan: Kwok Ho Chan: >Does the charter state MLPP is the framework? > >Kimberly: >The MLPP framework is posed as an example. > >Paul Kwok Ho Chan: Kwok Ho Chan: >We need to work out requirements that can provide us the opportunity for >another solution. We need to work out the requirements first before assuming specific solutions. >Kimberly: >We can make the charter clearer with respect on how we propose to go >forward using some documents as an example. > >James Polk: >Words in the charter say "could serve as a framework." This wording >implies more than one framework, including a solution within the charter. > >Fred Baker: >To Paul, are you working on an alternative framework? To Kwok, are you working on an alternative framework? >Paul Kwok Ho Chan: Kwok Ho Chan: >Something needs to be worked out. Yes, we are willing to work on the framework document and contribute to this WG. >Fred Baker: >We need to understand how this works towards the solution. > >Paul Kwok Ho Chan: Kwok Ho Chan: >We are willing to work with this WG. We can work with the WG on this. >Joe Barbiaz: Joe Babiarz: >This is a WG that should be presenting an understanding of frameworks to >work toward solutions. This WG should have requirement and understanding of requirement before having framework to work toward solutions. >Jon Peterson: >We have to be careful in the charter when working toward solutions. For >example, in the case of e-mail, Ieprep may be stepping on the toes of the >applications Area. We should coordinate a reference with them. > >James Polk: >In the case of prioritised e-mail, if we cannot find a home for it, then >it should be done here. Perhaps we can put in the charter if there is not >a clear Area for certain applications, then it should be done here. > >Jon Peterson: >I recommend we make the charter clearer here (for this particular example). > >Kimberly: >To the group: Is anybody opposed to the charter in the spirit as it is >currently written? > >James Polk: >I want to know the scope of the different words that are being proposed? >James, to Paul, please present these words on the mailing list. James, to Kwok, please present these words on the mailing list. Kwok Ho Chan: Lets do this on the WG mailing list. >Jon Peterson: >To Kimberly, ask for consensus. > >Hum in support of charter with words in the spirit as the charter reads now. Hum in support of charter with words in the spirit as the charter reads now, with wording to be worked out on the mailing list. > >(The hum indicated support for the proposed charter. - There was not any >hum in opposition.). (The hum indicated support for the proposed charter in its current spirit, with wording to be worked out on the mailing list. - There was not any hum in opposition.). >Kimberly then asked Tony DeSimone to give his presentation, i.e., the next >Agenda item. > >Precedence and Pre-emption for the GIG transport Service > >Global Information Grid Network. (GIG) > >GIG is an organizing construct for a number of programs across the US >Department of Defence and the Intelligence Community. Various GIG WGs are >working on requirements across a variety of programs. > >One of these WGs is developing a strategy for precedence and pre-emption. >The Challenge for GIG is not just voice, but other applications for all >programs in the DOD and intelligence community. > >GIG is really looking at the requirements for precedence and pre-emption. >Requirements come from a number of documents. CJCSI 6215.02A is a draft >document where 6 precedence levels are called out. Different types of data >need to be transferred across the networks. Higher priority data needs to >be transferred before lower priority data. > >The history of this work goes back to analog networks. Taking circuit >world requirements and solutions and moving to new services is the focus. > >James Polk: >Question on bullet 3 (on additional features), are you implying nothing >needs to happen in the network and that you only need to inform the user >of the pre-emption? > >Tony DeSimone: >To James, you are asking something beyond the bullet, your statement that >nothing needs to happen in the network is not the intent of bullet 3. > >Stu Goldman: >Bullet 2: In the circuit world you either have the priority or you don >Does bullet 2, in regard to lower precedence, talk about degrading? > >Tony DeSimone: >We are talking about degrading. > >Kimberly: >These are just high-level requirements. Let's get through this >presentation, in view of our time limit for this WG meeting. > >Tony DeSimone: >The fundamental requirement: The network needs to support the commanders' >intent with respect to what resources are available. Pre-emption: We need >to look at this with respect to how it applies to data. The state of >network: with respect to precedence and pre-emption. Something that is >meaningful to the user needs to be offered. > >Transport services, what the network nodes are implementing is important. > >Precedence and pre-emption needs to be done to support users. > >There is a GIG capabilities document that covers generic switching. > >The Fundamental Requirements slide is an important slide: it lays out the >issues. > >Derived goals: >Turn high-level requirements into goals Some requirements are incomplete >and inconsistent, that is why derived goals have been done. There are >subtleties how you can do pre-emption and precedence in the packet world. > >Ken Carlberg: >You should consider when you turn this into a draft that you will need a >terminology section. > >Tony DeSimone: We need to harmonize the terminology and that is our intent. > >James Polk: >Is any of this to be turned into an Internet draft? > >Tony DeSimone: >Yes, at the next meeting. > >Steve Silverman: >Will the slides be sent to the IETF for IETF participants to view? >Many in the audience wanted the slides available to the WG before the >meeting. > >Tony DeSimone: >The slides will be made available. Some of the other documents mentioned >are subject to "access control". > >Paul: Kwok Ho Chan: Kwok Ho Chan: >How is the IETF to work on something (e.g. GIG) that is under access control? > >Tony DeSimone: >There are a large number of documents that are driving the GIG. Some of >these documents are classified. We are trying to extract relevant >unclassified requirements documents for IETF work. >In general some material cannot be made public. > >Paul: Kwok Ho Chan: Kwok Ho Chan: >There will be problems if we do not have access to all the requirements. > >Kimberly: >It is up to a specific country to make decisions on what to be made >available with respect to requirements. This is an open forum > >Paul Kwok Ho Chan: Kwok Ho Chan: >Some material is not open. > >Kimberly: >The mapping of what is not open into the requirements we define here will >be the responsibility of each individual company or country. The >requirements for our work will be openly available. > >Having completed this Agenda item, Kimberly called for An Nguyen to cover >the last Agenda item, the NCS presentation > >An Nguyen's short presentation covered the NCS perspective on the new >proposed charter for Ieprep. > >An recalled the origins of Ieprep several years ago in the original BOF on >Ieprep. The BOF addressed how to get priority service across packet >switched networks. > >An stated that NCS is happy with the requirements documents work already >done by Ieprep during the past few years. The NCS does not oppose DoD work >in Ieprep. From the NCS perspective of ETS and GETS, MLPP (of DoD) is >deployed in a private network. The NCS does not see any conflict. > >Now after 4 years, we have requirements that will enable us to work on >solutions for priority services. Accordingly, we can plan for future services. > >Note: Two current (other) documents are relevant to NCS interests. These >are: the QoS NSLP QSPEC document, and the resource management RMD - QOSM >document. > >The most important requirements from the list of 14 high level NCS >requirements that were stated several years ago by the NCS are: >interoperability, priority voice, and authentications. > >ETS (Emergency Telecommunication Service) type solutions will be >identified in other WGs, in the future, as they may occur. Future >applications of interest to the NCS include: priority data and video. > >Kimberly: >General priority system requirements are what we are trying to do. > >Having completed all Agenda items in the allocated time, Kimberly >adjourned the WG meeting. At 12:45 PM 8/26/2005, King, Kimberly S. wrote: >Kwok, > >The ieprep minutes are here >http://www3.ietf.org/proceedings/05aug/minutes/ieprep.html > >The re-chartering discussion will start soon... > >Kimberly _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Tue Aug 30 17:07:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EADJx-0004ec-Nt; Tue, 30 Aug 2005 17:07:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EADJu-0004eV-Gp for ieprep@megatron.ietf.org; Tue, 30 Aug 2005 17:07:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09769 for ; Tue, 30 Aug 2005 17:06:59 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EADLV-000661-9G for ieprep@ietf.org; Tue, 30 Aug 2005 17:08:43 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 30 Aug 2005 14:06:51 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7UL6DQs022114; Tue, 30 Aug 2005 14:06:46 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 30 Aug 2005 14:06:44 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.98.163]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 30 Aug 2005 14:06:43 -0700 Message-Id: <4.3.2.7.2.20050830155210.03318258@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Aug 2005 16:06:42 -0500 To: "Kwok-Ho Chan" From: "James M. Polk" Subject: RE: [Ieprep] After IEPREP WG meeting in Paris In-Reply-To: <6.0.3.0.0.20050830140155.046f1a40@zbl6c002.corpeast.baynet works.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 30 Aug 2005 21:06:43.0673 (UTC) FILETIME=[B9686490:01C5ADA6] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea36de7a5e28e9b4461c8d685f4e97f1 Cc: "King, Kimberly S." , Scott Bradner , ieprep@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org Kwok While I agree that requirements are always necessary before solutions - this doesn't mean we start from square one on this. There are requirements RFCs in this WG already and TSVWG has a working solution (going to WGLC as soon as Allison posts the message she said was posted during the TSVWG meeting) to at least base future work on in IEPREP - which is the language of the recharter. That effort *is not* claiming victory or a raised white flag saying this is "it" for IEPREP for government networks. That effort is a data-path-coupled control plane solution, of which I do not believe there are any others. There is room for additional documents in the new charter or future recharters, based on WG consensus. These can come from the Gap Analysis ID to be done fairly early in the recharter's timeline. I believe it would be premature to offer new documents into the IEPREP recharter that the WG has not seen before. MLPP-That-Works was reviewed by IEPREP and was given a green light to TSVWG to progress, since, at the time (and still now), IEPREP cannot work on solutions for government networks. At 03:25 PM 8/30/2005 -0400, Kwok-Ho Chan wrote: >Kimberly: >My Thanks to the note takers. >And thank you very much for posting the meeting minutes to the IEPREP list. > >I have made clarifications/corrections to the provided 63rd IETF IEPREP >WG Meeting Minutes. >The clarifications/corrections can be summarized as follows: >1. The hum indicated support for re-chartering in its current spirit with >wording > to be agreed on the mailing list. >2. The Working Group needs to have clear requirements before assuming any > solutions or framework that satisfy the requirements. >3. Correction on my name, removing Paul: part or replacing Paul with Kwok. >4. Correction on name: Joe Babiarz. > >I have included below the posted minutes with the clarifications/corrections >detailed, to assist the minutes editor(s) task. > >Thank you again for the opportunity to review the meeting minutes before >they are finalized in the 63rd IETF Proceedings. >-- Kwok Ho Chan -- > >Posted minutes with clarifications/corrections: > >>IEPREP Working Group Meeting at IETF-63 >> >>The IEPREP Working Group was chaired by Kimberly King at the Paris >>IETF-63 on Monday August 1, 2005. (Scott Bradner, the other Co-Chair, was >>unable to attend the Paris IETF meeting but was listening to the audio stream.) >> >>Minutes by Greg Bain with editorial assistance by Ken Carlberg >> >>The Agenda was as follows: >> >>5 minutes: agenda bashing >>25 minutes: Ieprep re-charter discussion >>15 minutes: Antonio DeSimone: DoD Requirements >>15 Minutes: An Nguyen: NCS Presentation >> >>There were no objections to the agenda. >> >>Kimberly introduced the new proposed charter of Ieprep for discussion >>having explained that the proposed revised charter had been posted to the >>ieprep list before the meeting. >> >>Kimberly outlined important points, including some work being done in >>other existing Working Groups, specifically highlighting the following >>from the proposed charter: >> >>"If there is an existing WG that can discuss the requirements for >>extending their protocol or mechanism, IEPREP will generate only a >>requirements document for that group to discuss. >> >>If there is not an existing WG that can discuss the requirements for >>extending their protocol or mechanism, IEPREP will prepare requirements >>and discuss the extension of that protocol/mechanism or >>protocols/mechanisms within IEPREP." >> >> >>James Polk: >>The charter is good. James suggested that something be added to the >>proposed charter. The addition could take into account other applications >>that may not be under way by other groups. Priority e-mail is a prime >>example of one of these. James said that many things are "inferred" in >>the charter, i.e., not explicitly stated, but understood. >> >>Ken Carlberg: >>Question to James Polk, What is the status of your documents in TSV >>(Transport Services Working Group)? >> >>Area Director Jon Peterson: >>It is obvious that there has not been much procedural progress in TSV, >>but this will be addressed shortly. >> >>James Polk: >>James recommended that we continue to move forward in TSVWG with those >>documents that are already in TSVWG. >> >>Ken: >>Question for Kimberly: >>Has anything been received privately on comments positive or negative on >>the new proposed charter? >> >>Kimberly: >>Tony DeSimone sent comments and he will speak to this question. >> >>Tony DeSimone: >>I did have a few comments on language because there is work going on in >>other forums. >>Nested VPNs is an example of such work. There are language issues where >>differences in definitions apply. >> >>Paul Kwok Ho Chan: > >Kwok Ho Chan: > >> >>Will the MLPP draft be done here? >> >>Jon Peterson: >>It will proceed in TSVWG. >> >>Paul Kwok Ho Chan: > >Kwok Ho Chan: > >> >>We are jumping to solutions instead of doing more requirements? The MLPP >>draft is more than requirements. Will the group be thinking about >>additional possible solutions? >> >>Kimberly: >>We hope to not presuppose solutions. >> >>Paul Kwok Ho Chan: > >Kwok Ho Chan: > >>Does the charter state MLPP is the framework? >> >>Kimberly: >>The MLPP framework is posed as an example. >> >>Paul Kwok Ho Chan: > >Kwok Ho Chan: > >>We need to work out requirements that can provide us the opportunity for >>another solution. > >We need to work out the requirements first before assuming specific solutions. > > >>Kimberly: >>We can make the charter clearer with respect on how we propose to go >>forward using some documents as an example. >> >>James Polk: >>Words in the charter say "could serve as a framework." This wording >>implies more than one framework, including a solution within the charter. >> >>Fred Baker: >>To Paul, are you working on an alternative framework? > >To Kwok, are you working on an alternative framework? > > >>Paul Kwok Ho Chan: > >Kwok Ho Chan: > >>Something needs to be worked out. > >Yes, we are willing to work on the framework document and contribute to >this WG. > > >>Fred Baker: >>We need to understand how this works towards the solution. >> >>Paul Kwok Ho Chan: > >Kwok Ho Chan: > >>We are willing to work with this WG. > >We can work with the WG on this. > > >>Joe Barbiaz: > >Joe Babiarz: > >>This is a WG that should be presenting an understanding of frameworks to >>work toward solutions. > >This WG should have requirement and understanding of requirement before >having framework >to work toward solutions. > > >>Jon Peterson: >>We have to be careful in the charter when working toward solutions. For >>example, in the case of e-mail, Ieprep may be stepping on the toes of the >>applications Area. We should coordinate a reference with them. >> >>James Polk: >>In the case of prioritised e-mail, if we cannot find a home for it, then >>it should be done here. Perhaps we can put in the charter if there is not >>a clear Area for certain applications, then it should be done here. >> >>Jon Peterson: >>I recommend we make the charter clearer here (for this particular example). >> >>Kimberly: >>To the group: Is anybody opposed to the charter in the spirit as it is >>currently written? >> >>James Polk: >>I want to know the scope of the different words that are being proposed? >>James, to Paul, please present these words on the mailing list. > >James, to Kwok, please present these words on the mailing list. > >Kwok Ho Chan: >Lets do this on the WG mailing list. > > >>Jon Peterson: >>To Kimberly, ask for consensus. >> >>Hum in support of charter with words in the spirit as the charter reads now. > >Hum in support of charter with words in the spirit as the charter reads >now, with wording >to be worked out on the mailing list. > >> >>(The hum indicated support for the proposed charter. - There was not any >>hum in opposition.). > >(The hum indicated support for the proposed charter in its current spirit, >with wording to >be worked out on the mailing list. - There was not any hum in opposition.). > > >>Kimberly then asked Tony DeSimone to give his presentation, i.e., the >>next Agenda item. >> >>Precedence and Pre-emption for the GIG transport Service >> >>Global Information Grid Network. (GIG) >> >>GIG is an organizing construct for a number of programs across the US >>Department of Defence and the Intelligence Community. Various GIG WGs are >>working on requirements across a variety of programs. >> >>One of these WGs is developing a strategy for precedence and pre-emption. >>The Challenge for GIG is not just voice, but other applications for all >>programs in the DOD and intelligence community. >> >>GIG is really looking at the requirements for precedence and pre-emption. >>Requirements come from a number of documents. CJCSI 6215.02A is a draft >>document where 6 precedence levels are called out. Different types of >>data need to be transferred across the networks. Higher priority data >>needs to be transferred before lower priority data. >> >>The history of this work goes back to analog networks. Taking circuit >>world requirements and solutions and moving to new services is the focus. >> >>James Polk: >>Question on bullet 3 (on additional features), are you implying nothing >>needs to happen in the network and that you only need to inform the user >>of the pre-emption? >> >>Tony DeSimone: >>To James, you are asking something beyond the bullet, your statement that >>nothing needs to happen in the network is not the intent of bullet 3. >> >>Stu Goldman: >>Bullet 2: In the circuit world you either have the priority or you don >>Does bullet 2, in regard to lower precedence, talk about degrading? >> >>Tony DeSimone: >>We are talking about degrading. >> >>Kimberly: >>These are just high-level requirements. Let's get through this >>presentation, in view of our time limit for this WG meeting. >> >>Tony DeSimone: >>The fundamental requirement: The network needs to support the commanders' >>intent with respect to what resources are available. Pre-emption: We need >>to look at this with respect to how it applies to data. The state of >>network: with respect to precedence and pre-emption. Something that is >>meaningful to the user needs to be offered. >> >>Transport services, what the network nodes are implementing is important. >> >>Precedence and pre-emption needs to be done to support users. >> >>There is a GIG capabilities document that covers generic switching. >> >>The Fundamental Requirements slide is an important slide: it lays out the >>issues. >> >>Derived goals: >>Turn high-level requirements into goals Some requirements are incomplete >>and inconsistent, that is why derived goals have been done. There are >>subtleties how you can do pre-emption and precedence in the packet world. >> >>Ken Carlberg: >>You should consider when you turn this into a draft that you will need a >>terminology section. >> >>Tony DeSimone: We need to harmonize the terminology and that is our intent. >> >>James Polk: >>Is any of this to be turned into an Internet draft? >> >>Tony DeSimone: >>Yes, at the next meeting. >> >>Steve Silverman: >>Will the slides be sent to the IETF for IETF participants to view? >>Many in the audience wanted the slides available to the WG before the >>meeting. >> >>Tony DeSimone: >>The slides will be made available. Some of the other documents mentioned >>are subject to "access control". >> >>Paul: Kwok Ho Chan: > >Kwok Ho Chan: > >>How is the IETF to work on something (e.g. GIG) that is under access control? >> >>Tony DeSimone: >>There are a large number of documents that are driving the GIG. Some of >>these documents are classified. We are trying to extract relevant >>unclassified requirements documents for IETF work. >>In general some material cannot be made public. >> >>Paul: Kwok Ho Chan: > >Kwok Ho Chan: > >>There will be problems if we do not have access to all the requirements. >> >>Kimberly: >>It is up to a specific country to make decisions on what to be made >>available with respect to requirements. This is an open forum >> >>Paul Kwok Ho Chan: > >Kwok Ho Chan: > >>Some material is not open. >> >>Kimberly: >>The mapping of what is not open into the requirements we define here will >>be the responsibility of each individual company or country. The >>requirements for our work will be openly available. >> >>Having completed this Agenda item, Kimberly called for An Nguyen to cover >>the last Agenda item, the NCS presentation >> >>An Nguyen's short presentation covered the NCS perspective on the new >>proposed charter for Ieprep. >> >>An recalled the origins of Ieprep several years ago in the original BOF >>on Ieprep. The BOF addressed how to get priority service across packet >>switched networks. >> >>An stated that NCS is happy with the requirements documents work already >>done by Ieprep during the past few years. The NCS does not oppose DoD >>work in Ieprep. From the NCS perspective of ETS and GETS, MLPP (of DoD) >>is deployed in a private network. The NCS does not see any conflict. >> >>Now after 4 years, we have requirements that will enable us to work on >>solutions for priority services. Accordingly, we can plan for future services. >> >>Note: Two current (other) documents are relevant to NCS interests. These >>are: the QoS NSLP QSPEC document, and the resource management RMD - QOSM >>document. >> >>The most important requirements from the list of 14 high level NCS >>requirements that were stated several years ago by the NCS are: >>interoperability, priority voice, and authentications. >> >>ETS (Emergency Telecommunication Service) type solutions will be >>identified in other WGs, in the future, as they may occur. Future >>applications of interest to the NCS include: priority data and video. >> >>Kimberly: >>General priority system requirements are what we are trying to do. >> >>Having completed all Agenda items in the allocated time, Kimberly >>adjourned the WG meeting. > > > > >At 12:45 PM 8/26/2005, King, Kimberly S. wrote: >>Kwok, >> >>The ieprep minutes are here >>http://www3.ietf.org/proceedings/05aug/minutes/ieprep.html >> >>The re-chartering discussion will start soon... >> >>Kimberly > > >_______________________________________________ >Ieprep mailing list >Ieprep@ietf.org >https://www1.ietf.org/mailman/listinfo/ieprep cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Tue Aug 30 17:31:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EADhN-0003O6-Gp; Tue, 30 Aug 2005 17:31:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EADhM-0003Ny-Aj for ieprep@megatron.ietf.org; Tue, 30 Aug 2005 17:31:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10689 for ; Tue, 30 Aug 2005 17:31:13 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EADiy-0006fo-7y for ieprep@ietf.org; Tue, 30 Aug 2005 17:32:57 -0400 Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j7ULSj112228; Tue, 30 Aug 2005 17:28:45 -0400 (EDT) Received: from KCHAN-2K3.nortel.com (kchan-2k3.us.nortel.com [47.16.54.138]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RCFPQAN7; Tue, 30 Aug 2005 17:30:41 -0400 Message-Id: <6.0.3.0.0.20050830172027.040d0098@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Tue, 30 Aug 2005 17:30:41 -0400 To: "James M. Polk" From: "Kwok-Ho Chan" Subject: RE: [Ieprep] After IEPREP WG meeting in Paris In-Reply-To: <4.3.2.7.2.20050830155210.03318258@email.cisco.com> References: <4.3.2.7.2.20050830155210.03318258@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 054490fec19f6a94c68e63428d06db69 Cc: "King, Kimberly S." , Scott Bradner , ieprep@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org James: The E-Mail I sent was just to clarify the minutes of the 63rd IETF IEPREP WG session in Paris. With the draft and event status at the time of the meeting. Please do not read anything more than just that. IMHO, we should start/continue discussing the IEPREP re-chartering on this (IEPREP) list. But IMHO, that should be a different E-Mail thread. And discussion of the MLPP draft as its own E-Mail thread here or on TSVWG list as suggested. Thanks! -- Kwok -- At 05:06 PM 8/30/2005, James M. Polk wrote: >Kwok > >While I agree that requirements are always necessary before solutions - >this doesn't mean we start from square one on this. There are requirements >RFCs in this WG already and TSVWG has a working solution (going to WGLC as >soon as Allison posts the message she said was posted during the TSVWG >meeting) to at least base future work on in IEPREP - which is the language >of the recharter. That effort *is not* claiming victory or a raised white >flag saying this is "it" for IEPREP for government networks. That effort >is a data-path-coupled control plane solution, of which I do not believe >there are any others. > >There is room for additional documents in the new charter or future >recharters, based on WG consensus. These can come from the Gap Analysis >ID to be done fairly early in the recharter's timeline. I believe it >would be premature to offer new documents into the IEPREP recharter that >the WG has not seen before. MLPP-That-Works was reviewed by IEPREP and was >given a green light to TSVWG to progress, since, at the time (and still >now), IEPREP cannot work on solutions for government networks. > >At 03:25 PM 8/30/2005 -0400, Kwok-Ho Chan wrote: >>Kimberly: >>My Thanks to the note takers. >>And thank you very much for posting the meeting minutes to the IEPREP list. >> >>I have made clarifications/corrections to the provided 63rd IETF IEPREP >>WG Meeting Minutes. >>The clarifications/corrections can be summarized as follows: >>1. The hum indicated support for re-chartering in its current spirit with >>wording >> to be agreed on the mailing list. >>2. The Working Group needs to have clear requirements before assuming any >> solutions or framework that satisfy the requirements. >>3. Correction on my name, removing Paul: part or replacing Paul with Kwok. >>4. Correction on name: Joe Babiarz. >> >>I have included below the posted minutes with the clarifications/corrections >>detailed, to assist the minutes editor(s) task. >> >>Thank you again for the opportunity to review the meeting minutes before >>they are finalized in the 63rd IETF Proceedings. >>-- Kwok Ho Chan -- >> >>Posted minutes with clarifications/corrections: >> >>>IEPREP Working Group Meeting at IETF-63 >>> >>>The IEPREP Working Group was chaired by Kimberly King at the Paris >>>IETF-63 on Monday August 1, 2005. (Scott Bradner, the other Co-Chair, >>>was unable to attend the Paris IETF meeting but was listening to the >>>audio stream.) >>> >>>Minutes by Greg Bain with editorial assistance by Ken Carlberg >>> >>>The Agenda was as follows: >>> >>>5 minutes: agenda bashing >>>25 minutes: Ieprep re-charter discussion >>>15 minutes: Antonio DeSimone: DoD Requirements >>>15 Minutes: An Nguyen: NCS Presentation >>> >>>There were no objections to the agenda. >>> >>>Kimberly introduced the new proposed charter of Ieprep for discussion >>>having explained that the proposed revised charter had been posted to >>>the ieprep list before the meeting. >>> >>>Kimberly outlined important points, including some work being done in >>>other existing Working Groups, specifically highlighting the following >>>from the proposed charter: >>> >>>"If there is an existing WG that can discuss the requirements for >>>extending their protocol or mechanism, IEPREP will generate only a >>>requirements document for that group to discuss. >>> >>>If there is not an existing WG that can discuss the requirements for >>>extending their protocol or mechanism, IEPREP will prepare requirements >>>and discuss the extension of that protocol/mechanism or >>>protocols/mechanisms within IEPREP." >>> >>> >>>James Polk: >>>The charter is good. James suggested that something be added to the >>>proposed charter. The addition could take into account other >>>applications that may not be under way by other groups. Priority e-mail >>>is a prime example of one of these. James said that many things are >>>"inferred" in the charter, i.e., not explicitly stated, but understood. >>> >>>Ken Carlberg: >>>Question to James Polk, What is the status of your documents in TSV >>>(Transport Services Working Group)? >>> >>>Area Director Jon Peterson: >>>It is obvious that there has not been much procedural progress in TSV, >>>but this will be addressed shortly. >>> >>>James Polk: >>>James recommended that we continue to move forward in TSVWG with those >>>documents that are already in TSVWG. >>> >>>Ken: >>>Question for Kimberly: >>>Has anything been received privately on comments positive or negative on >>>the new proposed charter? >>> >>>Kimberly: >>>Tony DeSimone sent comments and he will speak to this question. >>> >>>Tony DeSimone: >>>I did have a few comments on language because there is work going on in >>>other forums. >>>Nested VPNs is an example of such work. There are language issues where >>>differences in definitions apply. >>> >>>Paul Kwok Ho Chan: >> >>Kwok Ho Chan: >> >>> >>>Will the MLPP draft be done here? >>> >>>Jon Peterson: >>>It will proceed in TSVWG. >>> >>>Paul Kwok Ho Chan: >> >>Kwok Ho Chan: >> >>> >>>We are jumping to solutions instead of doing more requirements? The MLPP >>>draft is more than requirements. Will the group be thinking about >>>additional possible solutions? >>> >>>Kimberly: >>>We hope to not presuppose solutions. >>> >>>Paul Kwok Ho Chan: >> >>Kwok Ho Chan: >> >>>Does the charter state MLPP is the framework? >>> >>>Kimberly: >>>The MLPP framework is posed as an example. >>> >>>Paul Kwok Ho Chan: >> >>Kwok Ho Chan: >> >>>We need to work out requirements that can provide us the opportunity for >>>another solution. >> >>We need to work out the requirements first before assuming specific >>solutions. >> >> >>>Kimberly: >>>We can make the charter clearer with respect on how we propose to go >>>forward using some documents as an example. >>> >>>James Polk: >>>Words in the charter say "could serve as a framework." This wording >>>implies more than one framework, including a solution within the charter. >>> >>>Fred Baker: >>>To Paul, are you working on an alternative framework? >> >>To Kwok, are you working on an alternative framework? >> >> >>>Paul Kwok Ho Chan: >> >>Kwok Ho Chan: >> >>>Something needs to be worked out. >> >>Yes, we are willing to work on the framework document and contribute to >>this WG. >> >> >>>Fred Baker: >>>We need to understand how this works towards the solution. >>> >>>Paul Kwok Ho Chan: >> >>Kwok Ho Chan: >> >>>We are willing to work with this WG. >> >>We can work with the WG on this. >> >> >>>Joe Barbiaz: >> >>Joe Babiarz: >> >>>This is a WG that should be presenting an understanding of frameworks to >>>work toward solutions. >> >>This WG should have requirement and understanding of requirement before >>having framework >>to work toward solutions. >> >> >>>Jon Peterson: >>>We have to be careful in the charter when working toward solutions. For >>>example, in the case of e-mail, Ieprep may be stepping on the toes of >>>the applications Area. We should coordinate a reference with them. >>> >>>James Polk: >>>In the case of prioritised e-mail, if we cannot find a home for it, then >>>it should be done here. Perhaps we can put in the charter if there is >>>not a clear Area for certain applications, then it should be done here. >>> >>>Jon Peterson: >>>I recommend we make the charter clearer here (for this particular example). >>> >>>Kimberly: >>>To the group: Is anybody opposed to the charter in the spirit as it is >>>currently written? >>> >>>James Polk: >>>I want to know the scope of the different words that are being proposed? >>>James, to Paul, please present these words on the mailing list. >> >>James, to Kwok, please present these words on the mailing list. >> >>Kwok Ho Chan: >>Lets do this on the WG mailing list. >> >> >>>Jon Peterson: >>>To Kimberly, ask for consensus. >>> >>>Hum in support of charter with words in the spirit as the charter reads now. >> >>Hum in support of charter with words in the spirit as the charter reads >>now, with wording >>to be worked out on the mailing list. >> >>> >>>(The hum indicated support for the proposed charter. - There was not any >>>hum in opposition.). >> >>(The hum indicated support for the proposed charter in its current >>spirit, with wording to >>be worked out on the mailing list. - There was not any hum in opposition.). >> >> >>>Kimberly then asked Tony DeSimone to give his presentation, i.e., the >>>next Agenda item. >>> >>>Precedence and Pre-emption for the GIG transport Service >>> >>>Global Information Grid Network. (GIG) >>> >>>GIG is an organizing construct for a number of programs across the US >>>Department of Defence and the Intelligence Community. Various GIG WGs >>>are working on requirements across a variety of programs. >>> >>>One of these WGs is developing a strategy for precedence and >>>pre-emption. The Challenge for GIG is not just voice, but other >>>applications for all programs in the DOD and intelligence community. >>> >>>GIG is really looking at the requirements for precedence and >>>pre-emption. Requirements come from a number of documents. CJCSI >>>6215.02A is a draft document where 6 precedence levels are called out. >>>Different types of data need to be transferred across the networks. >>>Higher priority data needs to be transferred before lower priority data. >>> >>>The history of this work goes back to analog networks. Taking circuit >>>world requirements and solutions and moving to new services is the focus. >>> >>>James Polk: >>>Question on bullet 3 (on additional features), are you implying nothing >>>needs to happen in the network and that you only need to inform the user >>>of the pre-emption? >>> >>>Tony DeSimone: >>>To James, you are asking something beyond the bullet, your statement >>>that nothing needs to happen in the network is not the intent of bullet 3. >>> >>>Stu Goldman: >>>Bullet 2: In the circuit world you either have the priority or you don >>>Does bullet 2, in regard to lower precedence, talk about degrading? >>> >>>Tony DeSimone: >>>We are talking about degrading. >>> >>>Kimberly: >>>These are just high-level requirements. Let's get through this >>>presentation, in view of our time limit for this WG meeting. >>> >>>Tony DeSimone: >>>The fundamental requirement: The network needs to support the >>>commanders' intent with respect to what resources are available. >>>Pre-emption: We need to look at this with respect to how it applies to >>>data. The state of network: with respect to precedence and pre-emption. >>>Something that is meaningful to the user needs to be offered. >>> >>>Transport services, what the network nodes are implementing is important. >>> >>>Precedence and pre-emption needs to be done to support users. >>> >>>There is a GIG capabilities document that covers generic switching. >>> >>>The Fundamental Requirements slide is an important slide: it lays out >>>the issues. >>> >>>Derived goals: >>>Turn high-level requirements into goals Some requirements are incomplete >>>and inconsistent, that is why derived goals have been done. There are >>>subtleties how you can do pre-emption and precedence in the packet world. >>> >>>Ken Carlberg: >>>You should consider when you turn this into a draft that you will need a >>>terminology section. >>> >>>Tony DeSimone: We need to harmonize the terminology and that is our intent. >>> >>>James Polk: >>>Is any of this to be turned into an Internet draft? >>> >>>Tony DeSimone: >>>Yes, at the next meeting. >>> >>>Steve Silverman: >>>Will the slides be sent to the IETF for IETF participants to view? >>>Many in the audience wanted the slides available to the WG before the >>>meeting. >>> >>>Tony DeSimone: >>>The slides will be made available. Some of the other documents mentioned >>>are subject to "access control". >>> >>>Paul: Kwok Ho Chan: >> >>Kwok Ho Chan: >> >>>How is the IETF to work on something (e.g. GIG) that is under access >>>control? >>> >>>Tony DeSimone: >>>There are a large number of documents that are driving the GIG. Some of >>>these documents are classified. We are trying to extract relevant >>>unclassified requirements documents for IETF work. >>>In general some material cannot be made public. >>> >>>Paul: Kwok Ho Chan: >> >>Kwok Ho Chan: >> >>>There will be problems if we do not have access to all the requirements. >>> >>>Kimberly: >>>It is up to a specific country to make decisions on what to be made >>>available with respect to requirements. This is an open forum >>> >>>Paul Kwok Ho Chan: >> >>Kwok Ho Chan: >> >>>Some material is not open. >>> >>>Kimberly: >>>The mapping of what is not open into the requirements we define here >>>will be the responsibility of each individual company or country. The >>>requirements for our work will be openly available. >>> >>>Having completed this Agenda item, Kimberly called for An Nguyen to >>>cover the last Agenda item, the NCS presentation >>> >>>An Nguyen's short presentation covered the NCS perspective on the new >>>proposed charter for Ieprep. >>> >>>An recalled the origins of Ieprep several years ago in the original BOF >>>on Ieprep. The BOF addressed how to get priority service across packet >>>switched networks. >>> >>>An stated that NCS is happy with the requirements documents work already >>>done by Ieprep during the past few years. The NCS does not oppose DoD >>>work in Ieprep. From the NCS perspective of ETS and GETS, MLPP (of DoD) >>>is deployed in a private network. The NCS does not see any conflict. >>> >>>Now after 4 years, we have requirements that will enable us to work on >>>solutions for priority services. Accordingly, we can plan for future services. >>> >>>Note: Two current (other) documents are relevant to NCS interests. These >>>are: the QoS NSLP QSPEC document, and the resource management RMD - QOSM >>>document. >>> >>>The most important requirements from the list of 14 high level NCS >>>requirements that were stated several years ago by the NCS are: >>>interoperability, priority voice, and authentications. >>> >>>ETS (Emergency Telecommunication Service) type solutions will be >>>identified in other WGs, in the future, as they may occur. Future >>>applications of interest to the NCS include: priority data and video. >>> >>>Kimberly: >>>General priority system requirements are what we are trying to do. >>> >>>Having completed all Agenda items in the allocated time, Kimberly >>>adjourned the WG meeting. >> >> >> >> >>At 12:45 PM 8/26/2005, King, Kimberly S. wrote: >>>Kwok, >>> >>>The ieprep minutes are here >>>http://www3.ietf.org/proceedings/05aug/minutes/ieprep.html >>> >>>The re-chartering discussion will start soon... >>> >>>Kimberly >> >> >>_______________________________________________ >>Ieprep mailing list >>Ieprep@ietf.org >>https://www1.ietf.org/mailman/listinfo/ieprep > > >cheers, >James > > ******************* > Truth is not to be argued... it is to be presented. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Tue Aug 30 18:40:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAEmT-00064k-Qj; Tue, 30 Aug 2005 18:40:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAEmQ-00064f-SI for ieprep@megatron.ietf.org; Tue, 30 Aug 2005 18:40:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14468 for ; Tue, 30 Aug 2005 18:40:31 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAEo0-0008DU-Te for ieprep@ietf.org; Tue, 30 Aug 2005 18:42:16 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 30 Aug 2005 15:40:20 -0700 X-IronPort-AV: i="3.96,154,1122879600"; d="scan'208"; a="657494650:sNHT31334844" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7UMe9QU013217; Tue, 30 Aug 2005 15:40:17 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 30 Aug 2005 15:40:14 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.98.163]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 30 Aug 2005 15:40:13 -0700 Message-Id: <4.3.2.7.2.20050830173939.03392c38@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Aug 2005 17:40:12 -0500 To: "Kwok-Ho Chan" From: "James M. Polk" Subject: RE: [Ieprep] After IEPREP WG meeting in Paris In-Reply-To: <6.0.3.0.0.20050830172027.040d0098@zbl6c002.corpeast.baynet works.com> References: <4.3.2.7.2.20050830155210.03318258@email.cisco.com> <4.3.2.7.2.20050830155210.03318258@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 30 Aug 2005 22:40:13.0971 (UTC) FILETIME=[C967EE30:01C5ADB3] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: "King, Kimberly S." , Scott Bradner , ieprep@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org Kwok At 05:30 PM 8/30/2005 -0400, Kwok-Ho Chan wrote: >James: >The E-Mail I sent was just to clarify the minutes of the 63rd IETF IEPREP WG >session in Paris. With the draft and event status at the time of the meeting. >Please do not read anything more than just that. ok >IMHO, we should start/continue discussing the IEPREP re-chartering on this >(IEPREP) list. But IMHO, that should be a different E-Mail thread. ok >And discussion of the MLPP draft as its own E-Mail thread here or on >TSVWG list as suggested. ok >Thanks! >-- Kwok -- cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-bounces@ietf.org Tue Aug 30 19:13:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAFHz-0008Nn-JU; Tue, 30 Aug 2005 19:13:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAFHx-0008Nf-Vv for ieprep@megatron.ietf.org; Tue, 30 Aug 2005 19:13:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16846 for ; Tue, 30 Aug 2005 19:13:06 -0400 (EDT) Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAFJb-0000vp-7c for ieprep@ietf.org; Tue, 30 Aug 2005 19:14:51 -0400 Received: from [149.8.64.21] by mclmx.mail.saic.com; Tue, 30 Aug 2005 19:13:04 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2005083019130211525 ; Tue, 30 Aug 2005 19:13:02 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Tue, 30 Aug 2005 19:13:00 -0400 Message-Id: From: "King, Kimberly S." To: "'ieprep@ietf.org'" Date: Tue, 30 Aug 2005 19:12:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: "'sob@harvard.edu'" , "'jon.peterson@neustar.biz'" Subject: [Ieprep] Proposed Revised Charter X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Emergency Preparedness Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ieprep-bounces@ietf.org Errors-To: ieprep-bounces@ietf.org Below is an updated proposed charter for WG review. --- Internet Emergency Preparedness (ieprep) Charter Description of Working Group: Effective telecommunications capabilities are imperative to facilitate immediate recovery operations for serious disaster events including natural disasters (e.g., hurricanes, floods, earthquakes) and those created by man (e.g., terrorist attacks, combat situations or wartime events). In addition, related capabilities should be usable in normal command and control operations of military services, which often have timeliness requirements even in peacetime. Disasters can happen any time, any place, unexpectedly. Quick response for recovery operations requires immediate access to any public telecommunications capabilities at hand. These capabilities include: conventional telephone, cellular phones, and Internet access via online terminals, IP telephones, and wireless PDAs. The commercial telecommunications infrastructure is rapidly evolving to Internet-based technology. Therefore, the Internet community needs to consider how it can best support emergency management and recovery operations. The IEPREP WG will address proactive measures to congestion and recovery from various outages using three perspectives: 1. A commercial (i.e., or public) telecommunications infrastructure 2. A governmental/military or enterprise telecommunications infrastructure that retains sole administration of its own network resources 3. A governmental/military telecommunications infrastructure that combines private resources and leverages public infrastructure. This scenario may be subject to local policies, laws, and regulations. Potential disasters for governmental/military infrastructures can extend beyond what might be experienced by the commercial/public sector and can be anticipated to some degree. Proactive mechanisms to address would-be outages are required for each of these cases. Now that the initial documents describe the broad problem space and its salient characteristics have been competed, new efforts will focus on specific requirements and solutions such as those pertaining to the governmental/military sector. For example, a document exists in the Transport Area working group of interest to IEPREP that could satisfy a governmental framework/BCP is draft-ietf-tsvwg-mlpp-that-works-XX. This document will progress to completion in that WG, yet may be the basis of more work in this IEPREP WG. Some additional efforts on the governmental/military track within IEPREP could focus on this TSVWG document, analyze gaps, and provide input where needed. The following are four specific examples that can satisfy the interests of governmental/military (and potentially, commercial/public/enterprise) emergency communications: 1. Conveying information about the priority of specific flows (or sessions) that originate in a VoIP environment. This could include a requirements effort to describe extensions to NSIS or RSVP. Requirements for NSIS would be forwarded to the NSIS working group. Requirements for RSVP could be forwarded to tsvwg or worked on in IEPREP. 2. Nested VPNs require special considerations for routing and QoS if nodes in the path that make these decisions generally have limited information. 3. Some countries require civil networks to preempt sessions under state circumstances, and preemption is considered an absolute requirement in governmental networks in most countries. Unless implementation of these requirements can be objectively shown to threaten network health (via simulation or in operations), then the requirement needs to be considered by IEPREP and specific solutions must be developed. 4. Considering robustness of non-real-time applications with preferential treatments, as voice will not be the only application used by IEPREP. In the IETF, considerations for treatment and security of emergency communications stretch across a number of Areas and Working Groups, notably including the various voice/video signaling working groups, instant messaging, and the open Transport Area for path coupled signaling and various operational groups. IEPREP will cooperate closely with these groups and with those outside of the IETF such as various ITU-T study groups. If there is an existing group that can extend a protocol or mechanism, IEPREP will generate only a requirements document for those groups to evaluate. If there is not an existing group that can extend a protocol or mechanism, IEPREP will prepare requirements and discuss the extension of that protocol/mechanism or protocols/mechanisms within IEPREP. Goals and Milestones: Done Submit initial I-D of Requirements Done Submit initial I-D of Framework Done Submit initial I-D of Recommendations BCP Done Submit Requirements I-D to IESG for publication as an Informational RFC Done Submit Framework I-D to IESG for publication as an Informational RFC Oct 05 Submit an initial I-D of Emergency Threats Analysis of Government/Military Networks Dec 05 Submit an initial I-D of Differences between GETS and MLPP Networks Feb 06 Submit an initial I-D of Requirements of Government/Military Networks Mar 06 Submit an initial I-D of Considerations for potential solutions of Government/Military Networks Apr 06 Submit an initial I-D of Mechanisms to be used by Government/Military Networks Oct 05 Submit final I-D of Emergency Threats Analysis of Government/Military Networks to IESG as Informational RFC Feb 06 Submit final I-D of Requirements of Government/Military Networks to IESG as Informational RFC Apr 06 Submit final I-D of Mechanisms to be used by Government/Military Networks to IESG as BCP RFC Dec 06 Submit Recommendations I-D for commercial telecommunications infrastructure to IESG for publication as a BCP The working group will discuss re-chartering if additional efforts are agreed upon by the WG (for example, work items related to protocols outside existing WGs). _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep