From aaa-doctors-bounces@ietf.org Thu Apr 12 07:49:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbxnZ-0006lp-Ah; Thu, 12 Apr 2007 07:49:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbxnX-0006kx-BF; Thu, 12 Apr 2007 07:49:07 -0400 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbxnW-0005lc-EK; Thu, 12 Apr 2007 07:49:07 -0400 Received: from unknown (HELO IS0004AVEXU1.global.avaya.com) ([135.64.105.51]) by co300216-co-outbound.avaya.com with ESMTP; 12 Apr 2007 07:49:04 -0400 X-IronPort-AV: i="4.14,400,1170651600"; d="scan'208"; a="2716171:sNHT10351074" X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Received: from 300815erh2.post.avaya.com ([198.152.6.49]) by IS0004AVEXU1.global.avaya.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 29 Mar 2007 14:20:54 +0200 MIME-Version: 1.0 Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by 300815erh2.post.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l2TCKrQ3029018 for ; Thu, 29 Mar 2007 08:20:53 -0400 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Received: from lists.ietf.org (HELO megatron.ietf.org) ([156.154.16.145]) by co300216-co-ierwest.avaya.com with ESMTP; 29 Mar 2007 08:23:58 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWtcQ-0000At-2E; Thu, 29 Mar 2007 08:20:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWtcO-00009p-HE; Thu, 29 Mar 2007 08:20:40 -0400 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWtcM-0000zj-Op; Thu, 29 Mar 2007 08:20:40 -0400 Received: from unknown (HELO IS0004AVEXU1.global.avaya.com) ([135.64.105.51]) by co300216-co-outbound.avaya.com with ESMTP; 29 Mar 2007 08:23:42 -0400 Received: from 300216erh2.post.avaya.com ([198.152.7.49]) by IS0004AVEXU1.global.avaya.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 27 Mar 2007 15:03:25 +0200 Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by 300216erh2.post.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l2RD2hjf000420 for ; Tue, 27 Mar 2007 07:03:23 -0600 Received: from megatron.ietf.org ([156.154.16.145]) by de307622-de-ieremea.avaya.com with ESMTP; 27 Mar 2007 09:03:22 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWBKP-0002cd-5Q; Tue, 27 Mar 2007 09:03:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWBKN-0002bm-7r; Tue, 27 Mar 2007 09:03:07 -0400 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWBKK-0000I7-Jc; Tue, 27 Mar 2007 09:03:07 -0400 Received: from unknown (HELO IS0004AVEXU1.global.avaya.com) ([135.64.105.51]) by co300216-co-outbound.avaya.com with ESMTP; 27 Mar 2007 09:05:31 -0400 content-class: urn:content-classes:message Date: Thu, 12 Apr 2007 14:48:23 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Minutes of the OPS Area open meetings in Prague - FINAL VERSION? Thread-Index: AcdwcCfEZyJt5bMOTaeTKpD3N4xYIQ== From: "Romascanu, Dan \(Dan\)" To: , , , "IETF MIBs" , , X-Spam-Score: 0.1 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Cc: Subject: [AAA-DOCTORS] Minutes of the OPS Area open meetings in Prague - FINAL VERSION? X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: aaa-doctors-bounces@ietf.org Unless I missed some mails during my vacation, I did not record any = further feedback to this version.=20 Going once ... Going twice ... (but not later than this weekend, please) Dan -------------------------------------------------------------------------= ------ Meeting 1 - Monday March 19, 2007 15:20 to 17:20=20 1. Meeting Administrivia 2. Introduction of new Area Director - Ron Bonica=20 Dan - thanking David Kessens for his years of service as Area Director 3. Mini-BOF A: - Manageability and Operational Guidelines - David = Harrington=20 http://www3.ietf.org/proceedings/07mar/slides/opsarea-1.ppt Discussions about the structure of the document - should the protocol = evaluation be part of the document?=20 4. Mini-BOF B: COPS push mode policy configuration - Tom Taylor and Tina = Tsou =20 http://www3.ietf.org/proceedings/07mar/slides/opsarea-3.ppt Sharon Chisholm: why COPS? because COPS is (apparently) going away=20 Unidentified : working at the ITU-T, still some interest=20 Kevin Johnson: in the draft, not quite clear if a new message was used. Tom: draft proposes a new message but could also use a flag, which is = the less violent solution. Discussion of the collision of handles Dbh: there are two questions to answer. question 1: is COPS going away? Worth it? Little update in the industry. = Should this be part of the manageability work (his mini-BOF)? Should we = move COPS to experimental or not recommended? question 2: technical = decision whether change is the right one? Scott Bradner: Answer Dave's first question. some enthusiasm for COPS at = the beginning, then faded away. Interest in ITU. The ITU-T is using a = few protocols including DIAMETER and COPS from the IETF that require = some extensions. If another non-IETF group wants to use COPS, why stand = in their way? Dave: "I can agree with that; somebody once said that the IETF doesn't = produce standards, but technologies; other organizations produce = standards" Dan (to Tom): what is your preferred solution?=20 Tom: A standard document with the COPS update . ITU and IETF would = progress this in parallel (approve in ITU-T as an annex), and then have = IETF (tweak and) approve it, and then update ITU-T to reference the RFC. Scott: This parallel approach has been problematic in the past. It = should either be done in ITU or in IETF, but not both. Tina: I think this can be done Dan: another approach is that the ITU-T can publish an Informational = document. I do not want to take a position at this point. ITU should = also consider what happens Dave Partain: I think there will be little energy to do this in the = IETF, so it should be done in ITU. Bert: I do not know if COPS-PR is being used or not; I know I do not = want to spend time working on COPS-PR. Is anybody interested in working = on it (including review any work done by ITU?) Tom: Does anybody work for an organization that uses COPS-PR?=20 One person raised their hands (Tina Tsou from Huawei) Tom: Is there any interest in working on COPS-PR extensions?=20 Dan: these questions should be asked on the OPS lists and ITU lists. Should it be standards track? - the authors would like it so.=20 Action item - Tom to address the ops-area list with query to determine = status of implementation and deployment of COPS and COPS-PR and level of = interest in participating in such a work 5. Mini-BOF C: Best Current Practices in Operations and Management - = David Harrington =20 http://www3.ietf.org/proceedings/07mar/slides/opsarea-2.ppt Proposal to create operation capabilities working group, modeled on the = experience of opsec WG Would bring in operators experience Framework document and operational guidelines as principal output Is opsec a success story?=20 Straw poll indicates interest - continue discussion after the next item 6. Improved Efficiency of the OPS Area - proposal for the formation of a = OPS Area WG - ADs=20 David and Dan - create structure for OPS area, similar to the one = existing in TSV and Routing Should it be merged with OPS and management capabilities WG as suggested = by David H.?=20 TSV chair - success in Transport due to multiple small items, no = dominant item Straw poll indicates interest - nobody believes it's a bad idea, = continue discussions in net meeting 7. Open Microphone=20 Meeting 2 - Wednesday March 21, 2007 - 13:00 to 16:10=20 1. Meeting Administrivia ADs (total: 5 min)=20 2. Mini-BOF D: NE/facilities/lines/protocols/services data modeling - = Michael Alexander=20 http://www3.ietf.org/proceedings/07mar/slides/opsarea-4.ppt Scott Bradner - very complex, IETF not good history in this type of = thing Pekka - benefit would go to NMS vendors? response - benefit to equipment vendors to get devices into NMSs Pekka - simpler version may be helpful, clean terminology would be = helpful potential but current scope too big, maybe more fit to the IRTF Margret Wassermann - interesting, but what gets standardized? response - focus on meta models only xx - sim (info model) underway for 4 years - achieved meta view, now = time to distribute to groups to use response - this proposal is much simpler than sim Chair: suggest create list & discuss issues raised in meeting, only one = opposed 3. MIB-Doctor-sponsored MIB-document-writing template: David Harrington=20 http://www3.ietf.org/proceedings/07mar/slides/opsarea-8.ppt No discussions 4. Mini-BOF E: MIB module editing in XML : Emile Stephan =20 http://www3.ietf.org/proceedings/07mar/slides/opsarea-5.ppt Sharon - do you actually have tools to translate XML to MIBs? response - I'm proposing to edit the MIB in XML and use XSL = transformation. Sharon - do you do SMI verification? Emile: Shows that the tool captures mistakes. Bill Fenner - wrong way to model MIB in XML - better to have element = that is syntax or XML schema for writing a MIB response - I'm using XML in a very loose way, but this is better than = nothing. Please make better proposal. Juergen - The opening argument in the beginning you wanted to move to = data model. The main issue is not syntactic problem to get there. response - I asked for a BOF in order to discuss and have proposals of = how to move forward chair - does not feel that it's a standards problem at this time but = maybe should be discussed with tools people 5. Mini-BOF F: Japanese Data Model Standards: Tomoyuki Iijima=20 http://www3.ietf.org/proceedings/07mar/slides/opsarea-6.ppt - proposed goal for NGO Sharon - why select VLANs? response - well used technology in enterprise space chair - MIB modules are used for VLAN config in enterprises - good to = see comparison between SNMP & netconf=20 chair - In Chicago we will have one or two BOFs for data modeling. This = contribution belongs to this space. Encourage to continue the work, = update the I-D and bring proposals to the NGO work. 6. Mini-BOF G: OWL techniques for MIB to XML documents and schema = translation - Bob Natale=20 http://www3.ietf.org/proceedings/07mar/slides/opsarea-7.ppt Andy Bierman - there are issues beyond mere translations - suggests that = experts in a protocol would need to be involved in determining if = conversion can even be done Scott Bradner - how fill in holes (beyond what MIB covers) bob - would need to have collaborative process for each MIB =09 chair - good to invite WS-CIM folk to join discussion Sharon xx - may be mismatch between MIBs and service-orientated = interface - also may be too high a data bandwidth generated for SOA/WS = management stations Bob - yes an issue Sharon - how much interest in WS community Bob - much need among user & developer communities=20 Dan Romascanu (from floor) - not sure that this fits the base role of = the IETF - make net work better Bob - this will help the operators run the network better Eugene - spent years in WS area - high level seems to be good - but WS = seems to rely on different fundamental information needs than what is in = MIBs - also some groups in this area do not like each other (OAIS & = DMTF for example). The other is political. Are the two standard bodies = can really work together in the long term? xx - good idea & he is optimistic that this would be useful - but there = are valid concerns about level of impact on the other communities chair - open list for discussion, consensus in the room 7. Late Submission - requirements to tunneling protocols OAM - KIKUCHI = Yutaka=20 Pekka - why is this tunnel specific? Only reordering is response - Our main objective is to measure tunnel quality. Chair - Maybe the next version of the draft you may need to better = clarify what is tunnel quality, to emphasis the difference between = interface and tunnel interface Scott Bradner - if you prepend seq # you change packet size you may have = to fragment Response - I used GRE sequence number (32 bits). Good, if you prepend = sequence number you may get into segmentation situation. chair -We'll continue to discuss this on the list, gauge interest and = answer the questions. I forwarded this to IPPM and benchmarking WG. Tries to sense the interest in the room: 4-5 hands. Is this not = relevant? None 8. Open microphone =20 Margaret: The topics today were interesting. But interesting is not good = enough. We have really bad history of trying to standardize management = approaches that were not really needed by service providers. We much = work only on what users really need. Dan: We split the OPS session to two days. Today's is more the 'new' issues. We need more feedback from operators. Work in the past lead to = NETCONF etc. Dave K.: We haven't allowed BOFs for the last few IETF being strict to = ensure that ideas that are not really required will not go forward. However we felt that we may miss some good ideas from going forward. Bob: To answer Margaret. I wanted to stress in my presentation that = there are operators and users that need the data models. What do you = want that shows this need. Margaret: I want them to be here and participate. If we don' t have = multiple sources of input. David Partain: I'd like to address Margaret point. There has been a lot = of discussions on data modeling. This is a real problem, since everyone = wants to use NETCOM but there is not any data models. Our users want = NETCONF. I think this is fair to characterizing it as real need. Margeret: Are you the customer of the data model David: Me and my customer. Ron B.: Maybe we should go to the operators and ask what are the most = critical problems and start from that, i.e. solve this first. When he = was a operator he would not have seen the issue as a lack of a data = model - rather why does pager go off - should keep doing this kind of = thing but should try to get closer to user=E2=80=99s actual perceived = needs Andy: I don't believe it is possible to have a protocol independent data = model. We don't have the expertise in web verbs etc. You should do the = work. I agree with Scott that we don't have a way to fill in the holes. Dave H: Addressing Margaret point. I'm going to have a workgroup meeting = to understand their needs. Are there any operators in the rooms? ~ 5 = hands. on Monday he proposed an ops nm WG to get operators involved - = looking for volunteers to help ops area better understand operator = needs, also - operations & managements guidelines doc - also ooking for = volunteers for that Bob: We might have minimum basic requirements for conversion of MIBs. = But most MIBs should be map-able. Dave K.: Is the experiment with the mini-BOF useful? Around 30 hands Who thinks this is not useful? None Dan: Regarding Dave H suggestion for two working groups, I suggest that = we unite it into one working group. Dave H: I think these are two different problems and should be done by = two different contributor groups. Protocol designers and Operators. Dan: I agree, but work generates feedback and input generates work. My = concern that split of resources and that there will not be enough = interest if we split it to two. Dave K: From the operator part we don't want to be too lonely=85 The = important thing is to have a good charter for the working group. Ron B: New WG chair. Applause to Dave K. I work for Juniper. I was an = operator in the VBNS network. Looking forward to work with you all. _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Thu Apr 12 08:01:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbxze-0005xo-KD; Thu, 12 Apr 2007 08:01:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbxza-0005qQ-Te; Thu, 12 Apr 2007 08:01:34 -0400 Received: from nj300815-nj-outbound.net.avaya.com ([198.152.12.100] helo=nj300815-nj-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbxzZ-0002e8-N0; Thu, 12 Apr 2007 08:01:34 -0400 Received: from 51.105.64.135.in-addr.arpa (HELO IS0004AVEXU1.global.avaya.com) ([135.64.105.51]) by nj300815-nj-outbound.avaya.com with ESMTP; 12 Apr 2007 07:59:32 -0400 X-IronPort-AV: i="4.14,400,1170651600"; d="scan'208"; a="2705580:sNHT26971566" X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Apr 2007 14:59:32 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Operations and Management Area Open Hour Calls Thread-Index: Acd8+gfH6aOrb3XeSmirednYz/Np7Q== From: "Romascanu, Dan \(Dan\)" To: , , , , , , "IETF MIBs" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [AAA-DOCTORS] Operations and Management Area Open Hour Calls X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: aaa-doctors-bounces@ietf.org Ron Bonica and Dan Romascanu are holding Open Hours to discuss issues related to the IETF Operations and Management Area on the first and third Tuesday of each month at noon-1PM PT / 3-4PM ET / 9-10PM CET.=20 All WG chairs, document editors, contributors, participants and in general all interested to talk with us about the area and IETF business are invited to ask for a meeting slot using the space below, and/or to write us directly at rbonica@juniper.net or dromasca@avaya.com. An e-mail will be sent in response to acknowledge the time slot and provide a telephone bridge number to be used in the call.=20 The next OPS area open slots are:=20 * Tue 4/17 PT CET 12-12:30pm 9-9:30pm =20 12:30-1pm 9:30-10pm =20 Ron and Dan _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Sat Apr 14 07:01:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcg0J-0007kI-U9; Sat, 14 Apr 2007 07:01:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcg0H-0007jv-IA; Sat, 14 Apr 2007 07:01:13 -0400 Received: from nj300815-nj-outbound.net.avaya.com ([198.152.12.100] helo=nj300815-nj-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hcg0G-0005as-4E; Sat, 14 Apr 2007 07:01:13 -0400 Received: from 51.105.64.135.in-addr.arpa (HELO IS0004AVEXU1.global.avaya.com) ([135.64.105.51]) by nj300815-nj-outbound.avaya.com with ESMTP; 14 Apr 2007 07:01:11 -0400 X-IronPort-AV: i="4.14,410,1170651600"; d="scan'208"; a="3555052:sNHT8998032" X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 14 Apr 2007 14:00:54 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UPDATED Agenda and Package for April 19, 2007 Telechat Thread-Index: Acd+Dru/+5xz8MzKRO28VbP1qZRp3wAdKqfA From: "Romascanu, Dan \(Dan\)" To: , , "IETF MIBs" , , "capwap" X-Spam-Score: 0.1 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Cc: Subject: [AAA-DOCTORS] FW: UPDATED Agenda and Package for April 19, 2007 Telechat X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: aaa-doctors-bounces@ietf.org Please find below the preliminary agenda of the 4/19 IESG telechat. Please have a look at the documents proposed for approval and let me know if there are any comments or concerns until 4/18 COB the latest.=20 Note that the agenda includes one MIB document proposed for standards and three CAPWAP initial submission documents that are proposed to be published as informational RFCs.=20 Thanks and Regards, Dan =20 =20 =20 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item o draft-ietf-simple-presence-rules-09.txt Presence Authorization Rules (Proposed Standard) - 1 of 5=20 Token: Jon Peterson o draft-ietf-ips-isns-mib-11.txt Definitions of Managed Objects for iSNS (Internet Storage Name Service)=20 (Proposed Standard) - 2 of 5=20 Note: PROTO Shepherd: David Black (Black_David@emc.com). MIB Doctor: Bert=20 Wijnen (bwijnen@lucent.com). Initial expert review: Keith McCloghrie (kzm@cisco.com)=20 Token: Lars Eggert o draft-ietf-rmt-fec-bb-revised-06.txt Forward Error Correction (FEC) Building Block (Proposed Standard) - 3 of 5=20 Token: Magnus Westerlund o draft-ietf-16ng-ipv6-over-ipv6cs-09.txt IPv6 Over the IP Specific part of the Packet Convergence sublayer in 802.16=20 Networks (Proposed Standard) - 4 of 5=20 Note: NOTE: There are some LC and IEEE-review comments pending=20 Token: Jari Arkko o draft-ietf-behave-tcp-06.txt NAT Behavioral Requirements for TCP (BCP) - 5 of 5=20 Token: Magnus Westerlund 2.1.2 Returning Item o draft-ietf-pkix-lightweight-ocsp-profile-08.txt Lightweight OCSP Profile for High Volume Environments (Proposed Standard) -=20 1 of 1=20 Token: Russ Housley 2.2 Individual Submissions 2.2.1 New Item o draft-siemborski-imap-sasl-initial-response-06.txt IMAP Extension for SASL Initial Client Response (Proposed Standard) - 1 of=20 1=20 Token: Chris Newman 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item o draft-ietf-16ng-ipv6-link-model-analysis-03.txt Analysis of IPv6 Link Models for 802.16 based Networks (Informational) - 1=20 of 2=20 Note: PROTO Shepherd is Soohong Daniel Park=20 <soohong.park@samsung.com>=20 Token: Jari Arkko o draft-ietf-trill-routing-reqs-02.txt TRILL Routing Requirements in Support of RBridges (Informational) - 2 of 2=20 Token: Mark Townsley 3.1.2 Returning Item o Five-document ballot: - 1 of 1 - draft-ietf-hip-base-07.txt Host Identity Protocol (Experimental)=20 - draft-ietf-hip-esp-05.txt Using ESP transport format with HIP (Experimental)=20 - draft-ietf-hip-registration-02.txt Host Identity Protocol (HIP) Registration Extension (Experimental) - draft-ietf-hip-mm-05.txt End-Host Mobility and Multihoming with the Host Identity Protocol (Experimental)=20 - draft-ietf-hip-rvs-05.txt Host Identity Protocol (HIP) Rendezvous Extension (Experimental)=20 Token: Mark Townsley 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item o draft-allen-sipping-poc-p-answer-state-header-05.txt The P-Answer-State Header Extension to the Session Initiation Protocol for=20 the Open Mobile Alliance Push-to-talk over Cellular (Informational) - 1 of=20 1=20 Note: SIPPING RFC 3427 Expert Reviewer is Gonzalo Camarillo; dependency of=20 OMA=20 Token: Jon Peterson 3.2.2 Returning Item NONE 3.3 Independent Submissions Via RFC Editor The IESG will use RFC 3932 responses: 1) The IESG has not found any conflict between this document and IETF work; 2) The IESG thinks that this work is related to IETF work done in WG , but this does not prevent publishing; 3) The IESG thinks that publication is harmful to work in WG and recommends not publishing at this time; 4) The IESG thinks that this document violates the IETF procedures for and should therefore not be published without IETF review and IESG approval; 5) The IESG thinks that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. =20 =20 Other matters may be recorded in comments to be passed on to the RFC Editor as community review of the document. 3.3.1 New Item o draft-iino-capwap-wicop-02.txt Wireless LAN Control Protocol (WiCoP) (Informational) - 1 of 2=20 Note: This document is an independent submission via the RFC Editor. In=20 conformace with RFC 3932, Section 4, the IESG requests the publication of=20 the following note: "This RFC documents the WiCoP protocol as it was when=20 submitted to the IETF as a basis for further work in the CAPWAP WG, and=20 therefore it may resemble a current IETF work in progress or a published=20 IETF work. This RFC itself is not a candidate for any level of Internet.=20 Standard. The IETF disclaims any knowledge of the fitness of this RFC for=20 any purpose, and in particular notes that it has not had complete IETF =20 review for such things as security, congestion control, or inappropriate=20 interaction with deployed protocols. The RFC Editor has chosen to publish=20 this document at its discretion."=20 Token: Dan Romascanu o draft-ohara-capwap-lwapp-04.txt Light Weight Access Point Protocol (Informational) - 2 of 2=20 Note: This document is an independent submission via the RFC Editor. In=20 conformace with RFC 3932, Section 4, the IESG requests the publication of=20 the following note: "This RFC documents the LWAPP protocol as it was when=20 submitted to the IETF as a basis for further work in the CAPWAP WG, and=20 therefore it may resemble a current IETF work in progress or a published=20 IETF work. This RFC itself is not a candidate for any level of Internet=20 Standard. The IETF disclaims any knowledge of the fitness of this RFC for=20 any purpose, and in particular notes that it has not had complete IETF =20 review for such things as security, congestion control, or inappropriate=20 interaction with deployed protocols. The RFC Editor has chosen to publish=20 this document at its discretion."=20 Token: Dan Romascanu 3.3.2 Returning Item o draft-narasimhan-ietf-slapp-01.txt SLAPP : Secure Light Access Point Protocol (Informational) - 1 of 1=20 Note: This document is an independent submission via the RFC Editor. In=20 conformace with RFC 3932, Section 4, the IESG requests the publication of=20 the following note: "This RFC documents the SLAPP protocol as it was when=20 submitted to the IETF as a basis for further work in the CAPWAP WG, and=20 therefore it may resemble a current IETF work in progress or a published=20 IETF work. This RFC itself is not a candidate for any level of Internet=20 Standard. The IETF disclaims any knowledge of the fitness of this RFC for=20 any purpose, and in particular notes that it has not had complete IETF =20 review for such things as security, congestion control, or inappropriate=20 interaction with deployed protocols. The RFC Editor has chosen to publish=20 this document at its discretion.".=20 Token: Dan Romascanu _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors