RE: [Ieprep] After IEPREP WG meeting in Paris

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