Last Modified: 2005-05-19
| 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. | |
| Dec 03 | Submit Recommendations I-D to IESG for publication as a BCP. |
| RFC | Status | Title |
|---|---|---|
| RFC3487 | I | Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP) |
| RFC3523 | I | Internet Emergency Preparedness (IEPREP)Telephony Topology Terminology |
| RFC3689 | I | General Requirements for Emergency Telecommunication Service |
| RFC3690 | I | IP Telephony Requirements for Emergency Telecommunication Service |
|
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. Kwok Ho Chan: Will the MLPP draft be done here? Jon Peterson: It will proceed in TSVWG. 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. Kwok Ho Chan: Does the charter state MLPP is the framework? Kimberly: The MLPP framework is posed as an example. Kwok Ho Chan: 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 Kwok, are you working on an alternative framework? Kwok Ho Chan: 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. Kwok Ho Chan: We can work with the WG on this. Joe Babiarz: 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 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. 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". 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. 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 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. |