Subject: RE: [Ieprep] After IEPREP WG meeting in Paris

From: "King, Kimberly S." <[email-masked]>
Date: Fri, 26 Aug 2005 12:45:43 -0400

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Fri, 26 Aug 2005 15:41:20 -0400

Kimberly:
Thank you very much!
Will be providing any comments on the minute's content to the list.
-- Kwok --

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Tue, 30 Aug 2005 15:25:00 -0400

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.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 30 Aug 2005 16:06:42 -0500

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:
>>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.)
>>
>>example of one of these. James said that many things are "inferred" in 
>>the charter, i.e., not explicitly stated, but understood.
>>
>>Ken Carlberg:
>>It is obvious that there has not been much procedural progress in TSV, 
>>but this will be addressed shortly.
>>
>>James Polk:
>>Kimberly then asked Tony DeSimone to give his presentation, i.e., the 
>>next Agenda item.
>>
>>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.
>>
>>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.
>>
>>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.
>>

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Tue, 30 Aug 2005 17:30:41 -0400

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:
>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.
>
>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.
>
>>>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.)
>>>
>>>having explained that the proposed revised charter had been posted to 
>>>the ieprep list before the meeting.
>>>
>>>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:
>>>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:
>>>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:
>>(The hum indicated support for the proposed charter in its current 
>>spirit, with wording to
>>>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.
>>>
>>>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:
>>>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.
>>>
>>>The Fundamental Requirements slide is an important slide: it lays out 
>>>the issues.
>>>
>>>Derived goals:
>>>The mapping of what is not open into the requirements we define here 
>>>will be the responsibility of each individual company or country. The 
>>>Having completed this Agenda item, Kimberly called for An Nguyen to 
>>>cover the last Agenda item, the NCS presentation
>>>

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 30 Aug 2005 17:40:12 -0500

Kwok

>Please do not read anything more than just that.

ok

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

ok

cheers,
James

                                 *******************