From aaa-doctors-bounces@ietf.org Wed Jan 03 03:42:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H21i4-0000QI-DB; Wed, 03 Jan 2007 03:42:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H21i3-0000Pu-UN; Wed, 03 Jan 2007 03:42:55 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H21i0-0006Gw-8M; Wed, 03 Jan 2007 03:42:55 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l038girD007670; Wed, 3 Jan 2007 03:42:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Received: from 300216erh2.post.avaya.com ([198.152.7.49]) by IS0004AVEXU1.global.avaya.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 19 Dec 2006 09:54:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Received: from nj300815-ier2.net.avaya.com (nj300815-ier2.net.avaya.com [198.152.12.103]) by 300216erh2.post.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBJ9sjjv007652 for ; Tue, 19 Dec 2006 02:54:46 -0700 Received: from nj300815-nj-iereast.avaya.com (h198-152-12-104.avaya.com [198.152.12.104]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBJ7WCMs013530 for ; Tue, 19 Dec 2006 02:54:47 -0500 Received: from bierator.ibr.cs.tu-bs.de ([134.169.34.9]) by nj300815-nj-iereast.avaya.com with ESMTP; 19 Dec 2006 02:53:32 -0500 Received: from bierator.ibr.cs.tu-bs.de (list@localhost [127.0.0.1]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kBJ7s3F0016453; Tue, 19 Dec 2006 08:54:08 +0100 Received: from nj300815-ier2.net.avaya.com (nj300815-ier2.net.avaya.com [198.152.12.103]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kBJ7rsAG016433 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 19 Dec 2006 08:54:00 +0100 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBJ7rqKT024301 for ; Tue, 19 Dec 2006 02:53:53 -0500 Received: from 300815erh2.post.avaya.com ([198.152.6.49]) by IS0004AVEXU1.global.avaya.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 18 Dec 2006 21:32:37 +0200 Received: from co300216-ier2.net.avaya.com (co300216-ier2.net.avaya.com [198.152.13.103]) by 300815erh2.post.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBIJWa1g000326 for ; Mon, 18 Dec 2006 14:32:36 -0500 Received: from co300216-co-ierwest.avaya.com (h198-152-13-104.avaya.com [198.152.13.104]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBIJRLYO001667 for ; Mon, 18 Dec 2006 14:32:30 -0500 Received: from lists.ietf.org (HELO megatron.ietf.org) ([156.154.16.145]) by co300216-co-ierwest.avaya.com with ESMTP; 18 Dec 2006 14:31:38 -0500 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwOCk-00055A-Iu; Mon, 18 Dec 2006 14:31:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwOCj-00054X-Hm; Mon, 18 Dec 2006 14:31:17 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwOCh-0001Sr-2S; Mon, 18 Dec 2006 14:31:17 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBIJVBEC009649; Mon, 18 Dec 2006 14:31:14 -0500 content-class: urn:content-classes:message Date: Wed, 3 Jan 2007 10:42:43 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OPS Area BOFs in Prague Thread-Index: AcccV6ii14zulLX7R3CFlQvi3jCmlA== From: "Romascanu, Dan \(Dan\)" To: , , "MIB Doctors" , , "DNS Directorate" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: nmrg@ibr.cs.tu-bs.de Subject: [AAA-DOCTORS] OPS Area BOFs in Prague 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 =20 Happy New Year! This is a final reminder that we shall schedule for the Prague IETF a number of BOFs or mini-BOFs in the OPS area meeting slots with the intention to bring to attention new ideas in the operations and management area and discuss which of those are worth becoming subject for future standardization, research or prototyping work. We (David and Dan) will be meeting by the end of the month to discuss the proposed BOF subjects, please send your proposals as soon as you can, but not later than January 24. Any of the lists in the area would do, but ops-area@ietf.org would probably be the best.=20 Note that if you intent to ask for a separate and dedicated BOF session rather than for a mini-BOF in the OPS area meeting slots the deadline for submitting a BOF request is January 15.=20 David and Dan _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Fri Jan 05 01:28:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2iZ0-0002Kp-AJ; Fri, 05 Jan 2007 01:28:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2iYz-0002HJ-J6; Fri, 05 Jan 2007 01:28:25 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2iYx-0006v7-5i; Fri, 05 Jan 2007 01:28:25 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l056SCUX020603; Fri, 5 Jan 2007 01:28:17 -0500 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: Fri, 5 Jan 2007 08:28:11 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for January 11, 2007 Telechat Thread-Index: AccwVVOQ6AXq2LcyTfSZHh6Xl9jynQAPNhBg From: "Romascanu, Dan \(Dan\)" To: "OPS Area" , , "MIB Doctors" , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: Subject: [AAA-DOCTORS] FW: PRELIMINARY Agenda and Package for January 11, 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 =20 Please find below the preliminary agenda of the January 11, 2007 IESG meeting. Please let me know if you have any comments or concerns related to the documents brought to the approval of the IESG until January 10, 2007 COB the latest.=20 Thanks and Regards, Dan INTERNET ENGINEERING STEERING GROUP (IESG) Summarized Agenda for the January 11, 2007 IESG Teleconference =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-ccamp-automesh-03.txt Routing extensions for discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) mesh membership (Proposed Standard) -=20 1 of 10=20 Token: Ross Callon o draft-ietf-dkim-base-07.txt DomainKeys Identified Mail (DKIM) Signatures (Proposed Standard) - 2 of 10=20 Token: Russ Housley o draft-ietf-dhc-timezone-option-05.txt A Timezone Option for DHCP (Proposed Standard) - 3 of 10=20 Token: Jari Arkko o draft-narten-ipr-3979-3rd-party-fix-00.txt Clarification of the 3rd Party Disclosure procedure in RFC 3979 (BCP) - 4=20 of 10=20 Note: Update to BCP 79. Document shepherd is Harald Alvestrand. It is an=20 IPR WG draft.=20 Token: Brian Carpenter o Two-document ballot: - 5 of 10 - draft-ietf-kitten-gssapi-domain-based-names-03.txt GSS-API Domain-Based Service Names and Name Type (Proposed Standard)=20 Note: Proto Shepherd: jaltman@secure-endpoints.com=20 - draft-ietf-kitten-krb5-gssapi-domain-based-names-03.txt GSS-API Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism (Proposed Standard)=20 Token: Sam Hartman o draft-ietf-pkix-srvsan-04.txt Internet X.509 Public Key Infrastructure Subject Alternative Name for expression of service name (Proposed Standard) - 6 of 10=20 Token: Russ Housley o draft-ietf-rohc-sigcomp-impl-guide-10.txt Implementer's Guide for SigComp (Proposed Standard) - 7 of 10=20 Token: Magnus Westerlund o draft-ietf-rohc-formal-notation-13.txt Formal Notation for Robust Header Compression (ROHC-FN) (Proposed Standard)=20 - 8 of 10=20 Token: Magnus Westerlund o draft-ietf-radext-filter-06.txt RADIUS Filter Rule Attribute (Proposed Standard) - 9 of 10=20 Note: Note: David Nelson is the Document Shepherd=20 Token: David Kessens o rfc3989.txt MIDCOM Protocol Semantics (BCP) - 10 of 10=20 Token: Magnus Westerlund 2.1.2 Returning Item o draft-ietf-mip6-ikev2-ipsec-08.txt Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture=20 (Proposed Standard) - 1 of 1=20 Note: PROTO Shepherd is Basavaraj Patil =20 Token: Jari Arkko 2.2 Individual Submissions 2.2.1 New Item o draft-andersson-rtg-gmpls-change-07.txt Change Process for Multiprotocol Label Switching (MPLS) and Generalized=20 MPLS (GMPLS) Protocols and Procedures (BCP) - 1 of 2=20 Note: Brian shepherds on behalf of the Routing ADs=20 Token: Brian Carpenter o draft-housley-aaa-key-mgmt-06.txt Guidance for AAA Key Management (BCP) - 2 of 2=20 Token: Sam Hartman 2.2.2 Returning Item NONE 2.2.3 For Action o draft-diao-eipv4-01.txt Source Route Based Extensible IP Network (EIPv4) (Proposed Standard) - 1 of=20 1=20 Note: Instructed author to participate in ID-Loc split design in RAM Token: Jari Arkko 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-dna-link-information-05.txt Link-layer Event Notifications for Detecting Network Attachments=20 (Informational) - 1 of 1=20 Token: Jari Arkko 3.1.2 Returning Item NONE 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-snell-atompub-feed-license-10.txt Atom License Extension (Experimental) - 1 of 1=20 Token: Lisa Dusseault 3.2.2 Returning Item o draft-klensin-norm-ref-02.txt A Process Experiment in Normative Reference Handling (Experimental) - 1 of=20 1=20 Note: RFC 3933 process experiment, substantially reduced in scope in 02=20 version.=20 Token: Brian Carpenter _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Wed Jan 10 06:30:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4bf9-000266-En; Wed, 10 Jan 2007 06:30:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4bf8-00025P-Ke; Wed, 10 Jan 2007 06:30:34 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H4bf6-00012I-AV; Wed, 10 Jan 2007 06:30:34 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0ABUULQ024088; Wed, 10 Jan 2007 06:30:31 -0500 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: Wed, 10 Jan 2007 13:30:29 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OPS Area Open Hours Thread-Index: Acc0qrsbrZp9CZTtRDuogWddSosg9Q== From: "Romascanu, Dan \(Dan\)" To: "OPS Area" , , "MIB Doctors" , , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: IESG Subject: [AAA-DOCTORS] OPS Area Open Hours 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 David Kessens 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 10-11AM PT / 1-2PM ET / 7-8PM CET. The series of calls starts on 1/16, and the other open hours slots until the Prague IETF meeting are 2/6, 2/20, 3/6.=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 OPS Area wiki http://www1.tools.ietf.org/area/ops/trac/wiki/WikiStart, and/or to write us directly at david.kessens@nokia.com 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 David and Dan =20 _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Thu Jan 11 07:44:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4zIK-0003Ts-DK; Thu, 11 Jan 2007 07:44:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4zIJ-0003Qa-9r for aaa-doctors@ietf.org; Thu, 11 Jan 2007 07:44:35 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4zII-0004SX-1s for aaa-doctors@ietf.org; Thu, 11 Jan 2007 07:44:35 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0BCiWIL019857 for ; Thu, 11 Jan 2007 07:44:33 -0500 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, 11 Jan 2007 14:44:31 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-housley-aaa-key-mgmt-06.txt Thread-Index: Acc1fj3AGxnZmf5oTZeWEqjGJVeQtg== From: "Romascanu, Dan \(Dan\)" To: X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [AAA-DOCTORS] draft-housley-aaa-key-mgmt-06.txt 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 http://www.ietf.org/internet-drafts/draft-housley-aaa-key-mgmt-06.txt is on the IESG agenda today.=20 I know that this document is edited by Russ Housley and Bernard, but yet I will ask. Did other aaa-doctors review it, is there any comment or concern?=20 Dan _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Thu Jan 11 09:53:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H51JN-0001LD-Sg; Thu, 11 Jan 2007 09:53:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H51JM-0001Jb-Ea for aaa-doctors@ietf.org; Thu, 11 Jan 2007 09:53:48 -0500 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H51JH-0003Um-7B for aaa-doctors@ietf.org; Thu, 11 Jan 2007 09:53:48 -0500 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe2.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 09:53:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-DOCTORS] draft-housley-aaa-key-mgmt-06.txt Date: Thu, 11 Jan 2007 09:53:39 -0500 Message-ID: <3CFB564E055A594B82C4FE89D21565605A4A44@MABOSEVS2.ets.enterasys.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-DOCTORS] draft-housley-aaa-key-mgmt-06.txt Thread-Index: Acc1fj3AGxnZmf5oTZeWEqjGJVeQtgAEKf9g From: "Nelson, David" To: "Romascanu, Dan \(Dan\)" , X-OriginalArrivalTime: 11 Jan 2007 14:53:39.0973 (UTC) FILETIME=[47D01350:01C73590] X-imss-version: 2.045 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: 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 > I know that this document is edited by Russ Housley and Bernard, but yet > I will ask. Did other aaa-doctors review it, is there any comment or > concern? I have read previous versions. In giving this version one final re-read, I note the following: This text appears twice in Section 2. Probably once is enough. However, due to ad hoc development of AAA- based key management, AAA-based key distribution schemes have poorly understood security properties, even when well-studied cryptographic algorithms are employed. More academic research is needed to fully understand the security properties of AAA-based key management in the diverse protocol environments where it is being employed today. In the absence of research results, pragmatic guidance based on sound security engineering principles is needed. Otherwise, I think this document is fine. _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Fri Jan 19 01:52:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7nbZ-0007aa-7o; Fri, 19 Jan 2007 01:52:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7nbX-0007Yw-AU; Fri, 19 Jan 2007 01:52:03 -0500 Received: from 103.13.152.198.in-addr.arpa ([198.152.13.103] helo=co300216-ier2.net.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7nbV-00050k-Rk; Fri, 19 Jan 2007 01:52:03 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0J6pxJb003631; Fri, 19 Jan 2007 01:52:00 -0500 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: Fri, 19 Jan 2007 08:51:59 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Documents on IESG Telechat Agenda for January 25, 2007 Thread-Index: Acc7jq6aVbChUbQjQvuAVDiYPlES2wAB1a8w From: "Romascanu, Dan \(Dan\)" To: "MIB Doctors \(E-mail\)" , , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.1 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: Subject: [AAA-DOCTORS] FW: Documents on IESG Telechat Agenda for January 25, 2007 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 =20 Please see below for all documents on the agenda for the next IESG telechat. I would appreciate if you can send me your issues and comments by Wed January 24, 2007 COB Dan This agenda was generated at 18:0:57 EDT, January 18, 2007 Web version of this agenda can be found at: http://www.ietf.org/IESG/agenda.html 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 Two-document ballot: - 1 of 7 - draft-ietf-ips-iwarp-da-05.txt Datamover Architecture for iSCSI (DA) (Informational)=20 Note: PROTO Document Shepherd: David Black (black_david@emc.com)=20 - draft-ietf-ips-iser-06.txt iSCSI Extensions for RDMA Specification (Proposed Standard)=20 Note: Document Shepherd: David Black (black_david@emc.com)=20 Token: Lars Eggert o draft-ietf-ccamp-rsvp-restart-ext-07.txt Extensions to GMPLS RSVP Graceful Restart (Proposed Standard) - 2 of 7=20 Token: Ross Callon o draft-ietf-pim-mib-v2-09.txt Protocol Independent Multicast MIB (Proposed Standard) - 3 of 7=20 Token: Bill Fenner o draft-ietf-crisp-iris-common-transport-04.txt A Common Schema for Internet Registry Information Service Transfer=20 Protocols (Proposed Standard) - 4 of 7=20 Token: Ted Hardie o draft-ietf-crisp-iris-lwz-07.txt A Lightweight UDP Transfer Protocol for the the Internet Registry=20 Information Service (Proposed Standard) - 5 of 7=20 Token: Ted Hardie o draft-ietf-crisp-iris-xpc-05.txt XML Pipelining with Chunks for the Information Registry Information Service=20 (Proposed Standard) - 6 of 7=20 Token: Ted Hardie o draft-ietf-lemonade-compress-07.txt The IMAP COMPRESS Extension (Proposed Standard) - 7 of 7=20 Note: Eric Burger is the Shepherd for this document.=20 Token: Ted Hardie 2.1.2 Returning Item o draft-ietf-tsvwg-tcp-mib-extension-14.txt TCP Extended Statistics MIB (Proposed Standard) - 1 of 2=20 Note: PROTO Document Shepherd: James Polk. MIB Doctors: Dan Romascanu, Bert=20 Wijnen=20 Token: Lars Eggert o rfc3989.txt MIDCOM Protocol Semantics (BCP) - 2 of 2=20 Token: Magnus Westerlund 2.2 Individual Submissions 2.2.1 New Item o draft-bonica-internet-icmp-14.txt Modifying ICMP to Support Multi-part Messages (Proposed Standard) - 1 of 4=20 Token: Jari Arkko o draft-manral-ipsec-rfc4305-bis-errata-03.txt Cryptographic Algorithm Implementation Requirements for Encapsulating=20 Security Payload (ESP) and Authentication Header (AH) (Proposed Standard) -=20 2 of 4=20 Token: Russ Housley o draft-solinas-ui-suites-01.txt Suite B Cryptographic Suites for IPsec (Proposed Standard) - 3 of 4=20 Token: Russ Housley o draft-daigle-unaptr-01.txt Domain-based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS) (Proposed Standard) - 4 of 4=20 Token: Ted Hardie 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-widex-requirements-04.txt Widget Description Exchange Service (WIDEX) Requirements (Informational) -=20 1 of 1=20 Token: Lisa Dusseault 3.1.2 Returning Item NONE 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-cam-winget-eap-fast-06.txt The Flexible Authentication via Secure Tunneling Extensible Authentication=20 Protocol Method (EAP-FAST) (Informational) - 1 of 3=20 Token: Russ Housley o draft-conboy-mime-opf-00.txt Media Type Registrations for OEBPS Package File (OPF) (Informational) - 2=20 of 3=20 Note: Sent to ietf-types in October of 2006=20 Token: Ted Hardie o draft-irtf-dtnrg-arch-08.txt Delay-Tolerant Networking Architecture (Informational) - 3 of 3=20 Note: Advancing according to: draft-irtf-rfcs-00.txt. Document Shepherd:=20 Stephen Farrell (stephen.farrell@cs.tcd.ie)=20 Token: Lars Eggert 3.2.2 Returning Item NONE 3.3 Individual 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 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 NONE 3.3.2 Returning Item o draft-deoliveira-diff-te-preemption-06.txt LSP Preemption Policies for MPLS Traffic Engineering (Informational) - 1 of=20 2=20 Token: Ross Callon o draft-zorn-radius-keywrap-12.txt RADIUS Attributes for the Delivery of Keying Material (Informational) - 2=20 of 2=20 Token: Russ Housley 3.3.3 For Action o draft-burke-vxml-02.txt SIP Interface to VoiceXML Media Services (Informational) - 1 of 1=20 Token: Cullen Jennings _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Fri Jan 19 02:53:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7oZB-0007Rd-6t; Fri, 19 Jan 2007 02:53:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7oZA-0007Pj-CD for aaa-doctors@ietf.org; Fri, 19 Jan 2007 02:53:40 -0500 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7oZ9-00082l-5v for aaa-doctors@ietf.org; Fri, 19 Jan 2007 02:53:40 -0500 Received: from c-24-16-66-58.hsd1.wa.comcast.net ([24.16.66.58] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.63) (envelope-from ) id 1H7oZ8-0008Bo-MQ; Fri, 19 Jan 2007 02:53:38 -0500 Received: by internaut.com (Postfix, from userid 1000) id 03C6E396AE; Thu, 18 Jan 2007 23:53:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id EA87138E93; Thu, 18 Jan 2007 23:53:39 -0800 (PST) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.16.66.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Thu, 18 Jan 2007 23:53:39 -0800 (PST) From: Bernard Aboba To: "Romascanu, Dan (Dan)" Subject: Re: [AAA-DOCTORS] FW: Documents on IESG Telechat Agenda for January 25, 2007 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: aaa-doctors@ietf.org 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 > 3.3 Individual Submissions Via RFC Editor > o draft-zorn-radius-keywrap-12.txt > RADIUS Attributes for the Delivery of Keying Material > (Informational) - 2 I do not think this document is eligible for publication as an Independent Submission, since it requests IANA to allocate parameters (RADIUS attributes) that require "IETF Consensus" under RFC 3575. RFC 2434 defines IETF consensus as follows: IETF Consensus - New values are assigned through the IETF consensus process. Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant Working Group if one exists). Therefore I do not believe that this document can be published without at least going through IETF last call. In addition, the document updates a Draft Track RFC (RFC 2865). _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Fri Jan 19 02:56:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7obV-00018p-2b; Fri, 19 Jan 2007 02:56:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7obU-00018i-2t for aaa-doctors@ietf.org; Fri, 19 Jan 2007 02:56:04 -0500 Received: from 103.13.152.198.in-addr.arpa ([198.152.13.103] helo=co300216-ier2.net.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7obR-0008Nn-O1 for aaa-doctors@ietf.org; Fri, 19 Jan 2007 02:56:04 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0J7tveW031981 for ; Fri, 19 Jan 2007 02:55:58 -0500 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 Subject: RE: [AAA-DOCTORS] FW: Documents on IESG Telechat Agenda for January 25, 2007 Date: Fri, 19 Jan 2007 09:55:57 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-DOCTORS] FW: Documents on IESG Telechat Agenda for January 25, 2007 Thread-Index: Acc7nvHwqlNeGfOQRS+Fo0RwKZrU/QAADMQQ References: From: "Romascanu, Dan \(Dan\)" To: "Bernard Aboba" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: aaa-doctors@ietf.org 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 Thanks. I believe that your comments are worth raising a DISCUSS.=20 Dan =20 =20 > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com]=20 > Sent: Friday, January 19, 2007 9:54 AM > To: Romascanu, Dan (Dan) > Cc: aaa-doctors@ietf.org > Subject: Re: [AAA-DOCTORS] FW: Documents on IESG Telechat=20 > Agenda for January 25, 2007 >=20 > > 3.3 Individual Submissions Via RFC Editor >=20 > > o draft-zorn-radius-keywrap-12.txt > > RADIUS Attributes for the Delivery of Keying Material > > (Informational) - 2 >=20 > I do not think this document is eligible for publication as=20 > an Independent Submission, since it requests IANA to allocate=20 > parameters (RADIUS > attributes) that require "IETF Consensus" under RFC 3575. =20 > RFC 2434 defines IETF consensus as follows: >=20 > IETF Consensus - New values are assigned through the IETF > consensus process. Specifically, new assignments=20 > are made via > RFCs approved by the IESG. Typically, the IESG will seek > input on prospective assignments from appropriate persons > (e.g., a relevant Working Group if one exists). >=20 > Therefore I do not believe that this document can be=20 > published without at least going through IETF last call.=20 >=20 > In addition, the document updates a Draft Track RFC (RFC 2865).=20 >=20 _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Tue Jan 23 19:05:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Ve4-0001FO-OR; Tue, 23 Jan 2007 19:05:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Ve3-0001El-Du; Tue, 23 Jan 2007 19:05:43 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Ve1-0007Ju-DN; Tue, 23 Jan 2007 19:05:42 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0O05X24005036; Tue, 23 Jan 2007 19:05:34 -0500 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: Wed, 24 Jan 2007 02:05:33 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LAST REMINDER: OPS Area mini-BOFs in Prague Thread-Index: Acc0gtyrABLFfwSZQwe7EkhqqrpLqwGUzm1Q References: <459B763C.1000600@alaxala.net> <45A445ED.9070509@hitachi.com> From: "Romascanu, Dan \(Dan\)" To: "OPS Area" , , , "MIB Doctors \(E-mail\)" , , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [AAA-DOCTORS] LAST REMINDER: OPS Area mini-BOFs in Prague 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 To all contributors who intend to present in Prague - If you did not do it yet, please confirm the submissions for a mini-BOF slot at the OPS Area meetings in Prague and send us the following information: .=20 - short technical scope description (not much more than one paragraph) - goals of the proposal, where this can lead: e.g. new protocol or extension of an existing protocol, standard, BCP or Informational RFC, formation of a WG or individual submission, other - estimation of time you will need in Prague including Q&A - whether there is an Internet-Draft or you intent to submit one before the Prague IETF Please send us this information until 1/25 the latest. David and me will meet on 1/26 and will communicate the finalized agenda shortly after.=20 Thanks and Regards, Dan =20 =20 _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Wed Jan 24 18:56:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9ryz-0003Hy-80; Wed, 24 Jan 2007 18:56:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9ryy-0003Hl-14; Wed, 24 Jan 2007 18:56:48 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9ryv-0007xD-QP; Wed, 24 Jan 2007 18:56:48 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0ONue6u016704; Wed, 24 Jan 2007 18:56:40 -0500 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, 25 Jan 2007 01:56:39 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Enterprise codes - three or four octets Thread-Index: AcdAE0ku+NFjZYnWRLGw1/LDcSCKlQ== From: "Romascanu, Dan \(Dan\)" To: "OPS Area" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: aaa-doctors@ietf.org, "MIB Doctors \(E-mail\)" Subject: [AAA-DOCTORS] Enterprise codes - three or four octets 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 I apologize for the cross-posting. I am not sure if this is a problem, but I would like to get some advice. I see in different documents two different ways of coding the SMI Private Enterprise Code. As far as I can understand these numbers should be coded as 32-bit, or at least I could not find any reason to limit them in any document that mentions them starting with RFC 1700. However, in other documents four octets are allocated, but the most significant octet is specified to be zero - see RFC 2865, or the more recent draft-cam-winget-eap-fast which is on the agenda of the IESG telechat tomorrow. An interesting case is draft-ietf-capwap-protocol-specification-04 which uses three octets in one place and four octets in four other places of the same document.=20 I do not know where the limitation to three meaningful octets started to be applied and why. Maybe we should not care, because 24 bits are enough for more than 8 million enterprises, and this may be enough for the future at sight (28k were allocated up to now). I would however invite opinions, especially if somebody believes that there is a problem here and any actions or guidance from the area is needed.=20 Dan =20 _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Wed Jan 24 19:06:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9s8h-00008J-SZ; Wed, 24 Jan 2007 19:06:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9s8g-00007Y-9w; Wed, 24 Jan 2007 19:06:50 -0500 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9s8d-0001u7-PJ; Wed, 24 Jan 2007 19:06:50 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l0P06ihL028129; Wed, 24 Jan 2007 18:06:44 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 18:06:44 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 01:06:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-DOCTORS] Enterprise codes - three or four octets Date: Thu, 25 Jan 2007 01:03:59 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-DOCTORS] Enterprise codes - three or four octets Thread-Index: AcdAE0ku+NFjZYnWRLGw1/LDcSCKlQAAL8Fw References: From: "Wijnen, Bert \(Bert\)" To: "Romascanu, Dan \(Dan\)" , "OPS Area" X-OriginalArrivalTime: 25 Jan 2007 00:06:42.0344 (UTC) FILETIME=[B16AD280:01C74014] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: aaa-doctors@ietf.org, "MIB Doctors \(E-mail\)" 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 Since, (as you note) there is no problem in the forseeable future, and since some protocols have already defined fields that only handle a 24-bit (i.e. 3 octet) value, maybe we should add some comment in the RFC-Editor mainatined registry that if they ever get to a value close to 25 bits, that we (IETF) need to be aware that some (older) protocols have limited fields of up to 24 bits. Bert=20 > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 > Sent: woensdag 24 januari 2007 15:57 > To: OPS Area > Cc: aaa-doctors@ietf.org; MIB Doctors (E-mail) > Subject: [AAA-DOCTORS] Enterprise codes - three or four octets >=20 > I apologize for the cross-posting. I am not sure if this is a=20 > problem, but I would like to get some advice. I see in=20 > different documents two different ways of coding the SMI=20 > Private Enterprise Code. As far as I can understand these=20 > numbers should be coded as 32-bit, or at least I could not=20 > find any reason to limit them in any document that mentions=20 > them starting with RFC 1700. However, in other documents four=20 > octets are allocated, but the most significant octet is=20 > specified to be zero - see RFC 2865, or the more recent=20 > draft-cam-winget-eap-fast which is on the agenda of the IESG=20 > telechat tomorrow. An interesting case is > draft-ietf-capwap-protocol-specification-04 which uses three=20 > octets in one place and four octets in four other places of=20 > the same document.=20 >=20 > I do not know where the limitation to three meaningful octets=20 > started to be applied and why. Maybe we should not care,=20 > because 24 bits are enough for more than 8 million=20 > enterprises, and this may be enough for the future at sight=20 > (28k were allocated up to now). I would however invite=20 > opinions, especially if somebody believes that there is a=20 > problem here and any actions or guidance from the area is needed.=20 >=20 > Dan >=20 >=20 > =20 >=20 >=20 > _______________________________________________ > AAA-DOCTORS mailing list > AAA-DOCTORS@ietf.org > https://www1.ietf.org/mailman/listinfo/aaa-doctors >=20 _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Wed Jan 24 19:33:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9sY2-0007bN-HR; Wed, 24 Jan 2007 19:33:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9sY2-0007aj-4u; Wed, 24 Jan 2007 19:33:02 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9sXz-0001LB-P2; Wed, 24 Jan 2007 19:33:02 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0P0WwAA013561; Wed, 24 Jan 2007 19:32:58 -0500 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 Subject: RE: [AAA-DOCTORS] Enterprise codes - three or four octets Date: Thu, 25 Jan 2007 02:32:56 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-DOCTORS] Enterprise codes - three or four octets Thread-Index: AcdAE0ku+NFjZYnWRLGw1/LDcSCKlQAAL8FwAABRc0A= References: From: "Romascanu, Dan \(Dan\)" To: "Wijnen, Bert \(Bert\)" , "OPS Area" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: aaa-doctors@ietf.org, "MIB Doctors \(E-mail\)" 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 Bert, The fact that you mentioned '(older) protocols' means that your opinion is that we should advise that new IETF documents use only the 32-bit values? There is no such guidance now and people rather use existing protocols as reference, so we may need to issue such a guidance.=20 Dan =20 =20 > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com]=20 > Sent: Thursday, January 25, 2007 2:04 AM > To: Romascanu, Dan (Dan); OPS Area > Cc: aaa-doctors@ietf.org; MIB Doctors (E-mail) > Subject: RE: [AAA-DOCTORS] Enterprise codes - three or four octets >=20 > Since, (as you note) there is no problem in the forseeable=20 > future, and since some protocols have already defined fields=20 > that only handle a 24-bit (i.e. 3 octet) value, maybe we=20 > should add some comment in the RFC-Editor mainatined registry=20 > that if they ever get to a value close to 25 bits, that we=20 > (IETF) need to be aware that some (older) protocols have=20 > limited fields of up to 24 bits. >=20 > Bert=20 >=20 > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: woensdag 24 januari 2007 15:57 > > To: OPS Area > > Cc: aaa-doctors@ietf.org; MIB Doctors (E-mail) > > Subject: [AAA-DOCTORS] Enterprise codes - three or four octets > >=20 > > I apologize for the cross-posting. I am not sure if this is=20 > a problem,=20 > > but I would like to get some advice. I see in different=20 > documents two=20 > > different ways of coding the SMI Private Enterprise Code.=20 > As far as I=20 > > can understand these numbers should be coded as 32-bit, or=20 > at least I=20 > > could not find any reason to limit them in any document=20 > that mentions=20 > > them starting with RFC 1700. However, in other documents=20 > four octets=20 > > are allocated, but the most significant octet is specified=20 > to be zero=20 > > - see RFC 2865, or the more recent=20 > draft-cam-winget-eap-fast which is=20 > > on the agenda of the IESG telechat tomorrow. An interesting case is > > draft-ietf-capwap-protocol-specification-04 which uses=20 > three octets in=20 > > one place and four octets in four other places of the same document. > >=20 > > I do not know where the limitation to three meaningful=20 > octets started=20 > > to be applied and why. Maybe we should not care, because 24=20 > bits are=20 > > enough for more than 8 million enterprises, and this may be=20 > enough for=20 > > the future at sight (28k were allocated up to now). I would however=20 > > invite opinions, especially if somebody believes that there is a=20 > > problem here and any actions or guidance from the area is needed. > >=20 > > Dan > >=20 > >=20 > > =20 > >=20 > >=20 > > _______________________________________________ > > AAA-DOCTORS mailing list > > AAA-DOCTORS@ietf.org > > https://www1.ietf.org/mailman/listinfo/aaa-doctors > >=20 >=20 _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Wed Jan 24 19:46:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9slD-0006qG-CB; Wed, 24 Jan 2007 19:46:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9slC-0006mb-PD; Wed, 24 Jan 2007 19:46:38 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9slA-0003tk-V0; Wed, 24 Jan 2007 19:46:38 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l0P0kVIp012163; Wed, 24 Jan 2007 18:46:31 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 18:46:31 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 01:46:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-DOCTORS] Enterprise codes - three or four octets Date: Thu, 25 Jan 2007 01:46:21 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-DOCTORS] Enterprise codes - three or four octets Thread-Index: AcdAE0ku+NFjZYnWRLGw1/LDcSCKlQAAL8FwAABRc0AAAS4SAA== References: From: "Wijnen, Bert \(Bert\)" To: "Romascanu, Dan \(Dan\)" , "OPS Area" X-OriginalArrivalTime: 25 Jan 2007 00:46:28.0324 (UTC) FILETIME=[3F927A40:01C7401A] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: aaa-doctors@ietf.org, "MIB Doctors \(E-mail\)" 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 Mmm... no, my use of "older protocols" would be whatever is old at the time we get close to the limit. I think I personally would be ok to limit this Enterprise ID to 24 bits. I guess you would need IETF consensus on that before you can actually make that statement Bert=20 > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 > Sent: woensdag 24 januari 2007 16:33 > To: Wijnen, Bert (Bert); OPS Area > Cc: aaa-doctors@ietf.org; MIB Doctors (E-mail) > Subject: RE: [AAA-DOCTORS] Enterprise codes - three or four octets >=20 > Bert, >=20 > The fact that you mentioned '(older) protocols' means that=20 > your opinion is that we should advise that new IETF documents=20 > use only the 32-bit values? There is no such guidance now=20 > and people rather use existing protocols as reference, so we=20 > may need to issue such a guidance.=20 >=20 > Dan >=20 >=20 > =20 > =20 >=20 > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com] > > Sent: Thursday, January 25, 2007 2:04 AM > > To: Romascanu, Dan (Dan); OPS Area > > Cc: aaa-doctors@ietf.org; MIB Doctors (E-mail) > > Subject: RE: [AAA-DOCTORS] Enterprise codes - three or four octets > >=20 > > Since, (as you note) there is no problem in the forseeable=20 > future, and=20 > > since some protocols have already defined fields that only handle a=20 > > 24-bit (i.e. 3 octet) value, maybe we should add some=20 > comment in the=20 > > RFC-Editor mainatined registry that if they ever get to a=20 > value close=20 > > to 25 bits, that we > > (IETF) need to be aware that some (older) protocols have limited=20 > > fields of up to 24 bits. > >=20 > > Bert > >=20 > > > -----Original Message----- > > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > > Sent: woensdag 24 januari 2007 15:57 > > > To: OPS Area > > > Cc: aaa-doctors@ietf.org; MIB Doctors (E-mail) > > > Subject: [AAA-DOCTORS] Enterprise codes - three or four octets > > >=20 > > > I apologize for the cross-posting. I am not sure if this is > > a problem, > > > but I would like to get some advice. I see in different > > documents two > > > different ways of coding the SMI Private Enterprise Code.=20 > > As far as I > > > can understand these numbers should be coded as 32-bit, or > > at least I > > > could not find any reason to limit them in any document > > that mentions > > > them starting with RFC 1700. However, in other documents > > four octets > > > are allocated, but the most significant octet is specified > > to be zero > > > - see RFC 2865, or the more recent > > draft-cam-winget-eap-fast which is > > > on the agenda of the IESG telechat tomorrow. An=20 > interesting case is > > > draft-ietf-capwap-protocol-specification-04 which uses > > three octets in > > > one place and four octets in four other places of the=20 > same document. > > >=20 > > > I do not know where the limitation to three meaningful > > octets started > > > to be applied and why. Maybe we should not care, because 24 > > bits are > > > enough for more than 8 million enterprises, and this may be > > enough for > > > the future at sight (28k were allocated up to now). I=20 > would however=20 > > > invite opinions, especially if somebody believes that there is a=20 > > > problem here and any actions or guidance from the area is needed. > > >=20 > > > Dan > > >=20 > > >=20 > > > =20 > > >=20 > > >=20 > > > _______________________________________________ > > > AAA-DOCTORS mailing list > > > AAA-DOCTORS@ietf.org > > > https://www1.ietf.org/mailman/listinfo/aaa-doctors > > >=20 > >=20 >=20 _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Wed Jan 24 20:40:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9tbZ-0002kc-JG; Wed, 24 Jan 2007 20:40:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9tbY-0002jn-I9; Wed, 24 Jan 2007 20:40:44 -0500 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9tbX-00064W-8v; Wed, 24 Jan 2007 20:40:44 -0500 Received: from c-24-16-66-58.hsd1.wa.comcast.net ([24.16.66.58] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.63) (envelope-from ) id 1H9tbV-000B2C-Ou; Wed, 24 Jan 2007 20:40:41 -0500 Received: by internaut.com (Postfix, from userid 1000) id D01753A72A; Wed, 24 Jan 2007 17:40:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id C17FB39FDB; Wed, 24 Jan 2007 17:40:40 -0800 (PST) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.16.66.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Wed, 24 Jan 2007 17:40:40 -0800 (PST) From: Bernard Aboba To: "Wijnen, Bert (Bert)" Subject: RE: [AAA-DOCTORS] Enterprise codes - three or four octets In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: aaa-doctors@ietf.org, "MIB Doctors \(E-mail\)" , OPS Area 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 I would also mention that there has been talk at various points about using 2 octet values. That would seem to be inadvisable -- and it might make sense to issue a recommendation describing a recommendation (e.g. allocate 4 octets). On Thu, 25 Jan 2007, Wijnen, Bert (Bert) wrote: > Since, (as you note) there is no problem in the forseeable future, > and since some protocols have already defined fields that only > handle a 24-bit (i.e. 3 octet) value, maybe we should add some > comment in the RFC-Editor mainatined registry that if they ever get > to a value close to 25 bits, that we (IETF) need to be aware that > some (older) protocols have limited fields of up to 24 bits. > > Bert > > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: woensdag 24 januari 2007 15:57 > > To: OPS Area > > Cc: aaa-doctors@ietf.org; MIB Doctors (E-mail) > > Subject: [AAA-DOCTORS] Enterprise codes - three or four octets > > > > I apologize for the cross-posting. I am not sure if this is a > > problem, but I would like to get some advice. I see in > > different documents two different ways of coding the SMI > > Private Enterprise Code. As far as I can understand these > > numbers should be coded as 32-bit, or at least I could not > > find any reason to limit them in any document that mentions > > them starting with RFC 1700. However, in other documents four > > octets are allocated, but the most significant octet is > > specified to be zero - see RFC 2865, or the more recent > > draft-cam-winget-eap-fast which is on the agenda of the IESG > > telechat tomorrow. An interesting case is > > draft-ietf-capwap-protocol-specification-04 which uses three > > octets in one place and four octets in four other places of > > the same document. > > > > I do not know where the limitation to three meaningful octets > > started to be applied and why. Maybe we should not care, > > because 24 bits are enough for more than 8 million > > enterprises, and this may be enough for the future at sight > > (28k were allocated up to now). I would however invite > > opinions, especially if somebody believes that there is a > > problem here and any actions or guidance from the area is needed. > > > > Dan > > > > > > > > > > > > _______________________________________________ > > AAA-DOCTORS mailing list > > AAA-DOCTORS@ietf.org > > https://www1.ietf.org/mailman/listinfo/aaa-doctors > > > > _______________________________________________ > AAA-DOCTORS mailing list > AAA-DOCTORS@ietf.org > https://www1.ietf.org/mailman/listinfo/aaa-doctors > _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Thu Jan 25 00:38:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9xJT-0004lR-P0; Thu, 25 Jan 2007 00:38:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9to7-0001Dr-K6; Wed, 24 Jan 2007 20:53:43 -0500 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9to6-0008KP-7R; Wed, 24 Jan 2007 20:53:43 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc11) with SMTP id <2007012501534101100nfm0ve>; Thu, 25 Jan 2007 01:53:41 +0000 From: "David B Harrington" To: "'Romascanu, Dan \(Dan\)'" , "'Wijnen, Bert \(Bert\)'" , "'OPS Area'" References: Subject: RE: [MIB-DOCTORS] RE: [AAA-DOCTORS] Enterprise codes - three or fouroctets Date: Wed, 24 Jan 2007 20:50:04 -0500 Message-ID: <03ee01c74023$221b3570$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-reply-to: Thread-index: AcdAE0ku+NFjZYnWRLGw1/LDcSCKlQAAL8FwAABRc0AAAO7CUA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 X-Mailman-Approved-At: Thu, 25 Jan 2007 00:38:19 -0500 Cc: aaa-doctors@ietf.org, "'MIB Doctors \(E-mail\)'" 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 Hi, According to www.iana.org, the defining document for ENTERPRISE is RFC2578. I believe this is the updated defining document; the original appears to be RFC1065 (Structure and Identification of Management Information for TCP/IP-based internets). Each enterprise is assigned a subtree: "For example, if the "Flintstones, Inc." enterprise produced networking subsystems, then they could request a node under the enterprises subtree from the Assigned Numbers authority." A node is represented in SMI as a sub-identifier. According to RFC2578, a sub-identifier has a value from 0..2^32-1 (4294967295 decimal). This would argue for a 32-bit field size, wouldn't it? dbh > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Wednesday, January 24, 2007 7:33 PM > To: Wijnen, Bert (Bert); OPS Area > Cc: aaa-doctors@ietf.org; MIB Doctors (E-mail) > Subject: [MIB-DOCTORS] RE: [AAA-DOCTORS] Enterprise codes - > three or fouroctets > > Bert, > > The fact that you mentioned '(older) protocols' means that > your opinion > is that we should advise that new IETF documents use only the 32-bit > values? There is no such guidance now and people rather use existing > protocols as reference, so we may need to issue such a guidance. > > Dan > > > > > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com] > > Sent: Thursday, January 25, 2007 2:04 AM > > To: Romascanu, Dan (Dan); OPS Area > > Cc: aaa-doctors@ietf.org; MIB Doctors (E-mail) > > Subject: RE: [AAA-DOCTORS] Enterprise codes - three or four octets > > > > Since, (as you note) there is no problem in the forseeable > > future, and since some protocols have already defined fields > > that only handle a 24-bit (i.e. 3 octet) value, maybe we > > should add some comment in the RFC-Editor mainatined registry > > that if they ever get to a value close to 25 bits, that we > > (IETF) need to be aware that some (older) protocols have > > limited fields of up to 24 bits. > > > > Bert > > > > > -----Original Message----- > > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > > Sent: woensdag 24 januari 2007 15:57 > > > To: OPS Area > > > Cc: aaa-doctors@ietf.org; MIB Doctors (E-mail) > > > Subject: [AAA-DOCTORS] Enterprise codes - three or four octets > > > > > > I apologize for the cross-posting. I am not sure if this is > > a problem, > > > but I would like to get some advice. I see in different > > documents two > > > different ways of coding the SMI Private Enterprise Code. > > As far as I > > > can understand these numbers should be coded as 32-bit, or > > at least I > > > could not find any reason to limit them in any document > > that mentions > > > them starting with RFC 1700. However, in other documents > > four octets > > > are allocated, but the most significant octet is specified > > to be zero > > > - see RFC 2865, or the more recent > > draft-cam-winget-eap-fast which is > > > on the agenda of the IESG telechat tomorrow. An > interesting case is > > > draft-ietf-capwap-protocol-specification-04 which uses > > three octets in > > > one place and four octets in four other places of the > same document. > > > > > > I do not know where the limitation to three meaningful > > octets started > > > to be applied and why. Maybe we should not care, because 24 > > bits are > > > enough for more than 8 million enterprises, and this may be > > enough for > > > the future at sight (28k were allocated up to now). I > would however > > > invite opinions, especially if somebody believes that there is a > > > problem here and any actions or guidance from the area is needed. > > > > > > Dan > > > > > > > > > > > > > > > > > > _______________________________________________ > > > AAA-DOCTORS mailing list > > > AAA-DOCTORS@ietf.org > > > https://www1.ietf.org/mailman/listinfo/aaa-doctors > > > > > > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www1.ietf.org/mailman/listinfo/mib-doctors > _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Thu Jan 25 00:38:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9xJT-0004lc-Qa; Thu, 25 Jan 2007 00:38:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9wPf-0005Tz-ER; Wed, 24 Jan 2007 23:40:39 -0500 Received: from smtp-bedford.mitre.org ([192.160.51.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9wPd-000789-W5; Wed, 24 Jan 2007 23:40:39 -0500 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with SMTP id l0P4ebXb015794; Wed, 24 Jan 2007 23:40:37 -0500 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 83323BEFB; Wed, 24 Jan 2007 23:40:37 -0500 (EST) Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id l0P4eans015776; Wed, 24 Jan 2007 23:40:36 -0500 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 23:40:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [OPS-AREA] RE: [MIB-DOCTORS] RE: [AAA-DOCTORS] Enterprise codes -three or fouroctets Date: Wed, 24 Jan 2007 23:40:35 -0500 Message-ID: <4915F014FDD99049A9C3A8C1B832004F01883911@IMCSRV2.MITRE.ORG> In-Reply-To: <03ee01c74023$221b3570$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] RE: [MIB-DOCTORS] RE: [AAA-DOCTORS] Enterprise codes -three or fouroctets Thread-Index: AcdAE0ku+NFjZYnWRLGw1/LDcSCKlQAAL8FwAABRc0AAAO7CUAAIXYWw References: <03ee01c74023$221b3570$0600a8c0@china.huawei.com> From: "Natale, Bob" To: "David B Harrington" , "Romascanu, Dan (Dan)" , "Wijnen, Bert (Bert)" , "OPS Area" X-OriginalArrivalTime: 25 Jan 2007 04:40:36.0615 (UTC) FILETIME=[F5019170:01C7403A] X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 X-Mailman-Approved-At: Thu, 25 Jan 2007 00:38:19 -0500 Cc: aaa-doctors@ietf.org, "MIB Doctors \(E-mail\)" 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 Hi, Dave's analysis certainly seems correct to me. Any protocols that limit enterprise values to something less than a sub-id would seem to be flawed (albeit with low risk of causing problems per Dan's observations on usage to date...of course, with IPv6 and the changing definition of enterprise in the real world, who knows! :). Cheers, BobN=20 -----Original Message----- From: David B Harrington [mailto:dbharrington@comcast.net]=20 Sent: Wednesday, January 24, 2007 8:50 PM To: 'Romascanu, Dan (Dan)'; 'Wijnen, Bert (Bert)'; 'OPS Area' Cc: aaa-doctors@ietf.org; 'MIB Doctors (E-mail)' Subject: [OPS-AREA] RE: [MIB-DOCTORS] RE: [AAA-DOCTORS] Enterprise codes -three or fouroctets Hi, According to www.iana.org, the defining document for ENTERPRISE is RFC2578. I believe this is the updated defining document; the original appears to be RFC1065 (Structure and Identification of Management Information for TCP/IP-based internets).=20 Each enterprise is assigned a subtree: "For example, if the "Flintstones, Inc." enterprise produced networking subsystems, then they could request a node under the enterprises subtree from the Assigned Numbers authority." A node is represented in SMI as a sub-identifier. According to RFC2578, a sub-identifier has a value from 0..2^32-1 (4294967295 decimal).=20 This would argue for a 32-bit field size, wouldn't it? dbh > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 > Sent: Wednesday, January 24, 2007 7:33 PM > To: Wijnen, Bert (Bert); OPS Area > Cc: aaa-doctors@ietf.org; MIB Doctors (E-mail) > Subject: [MIB-DOCTORS] RE: [AAA-DOCTORS] Enterprise codes -=20 > three or fouroctets >=20 > Bert, >=20 > The fact that you mentioned '(older) protocols' means that=20 > your opinion > is that we should advise that new IETF documents use only the 32-bit > values? There is no such guidance now and people rather use existing > protocols as reference, so we may need to issue such a guidance.=20 >=20 > Dan >=20 >=20 > =20 > =20 >=20 > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com]=20 > > Sent: Thursday, January 25, 2007 2:04 AM > > To: Romascanu, Dan (Dan); OPS Area > > Cc: aaa-doctors@ietf.org; MIB Doctors (E-mail) > > Subject: RE: [AAA-DOCTORS] Enterprise codes - three or four octets > >=20 > > Since, (as you note) there is no problem in the forseeable=20 > > future, and since some protocols have already defined fields=20 > > that only handle a 24-bit (i.e. 3 octet) value, maybe we=20 > > should add some comment in the RFC-Editor mainatined registry=20 > > that if they ever get to a value close to 25 bits, that we=20 > > (IETF) need to be aware that some (older) protocols have=20 > > limited fields of up to 24 bits. > >=20 > > Bert=20 > >=20 > > > -----Original Message----- > > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > > Sent: woensdag 24 januari 2007 15:57 > > > To: OPS Area > > > Cc: aaa-doctors@ietf.org; MIB Doctors (E-mail) > > > Subject: [AAA-DOCTORS] Enterprise codes - three or four octets > > >=20 > > > I apologize for the cross-posting. I am not sure if this is=20 > > a problem,=20 > > > but I would like to get some advice. I see in different=20 > > documents two=20 > > > different ways of coding the SMI Private Enterprise Code.=20 > > As far as I=20 > > > can understand these numbers should be coded as 32-bit, or=20 > > at least I=20 > > > could not find any reason to limit them in any document=20 > > that mentions=20 > > > them starting with RFC 1700. However, in other documents=20 > > four octets=20 > > > are allocated, but the most significant octet is specified=20 > > to be zero=20 > > > - see RFC 2865, or the more recent=20 > > draft-cam-winget-eap-fast which is=20 > > > on the agenda of the IESG telechat tomorrow. An=20 > interesting case is > > > draft-ietf-capwap-protocol-specification-04 which uses=20 > > three octets in=20 > > > one place and four octets in four other places of the=20 > same document. > > >=20 > > > I do not know where the limitation to three meaningful=20 > > octets started=20 > > > to be applied and why. Maybe we should not care, because 24=20 > > bits are=20 > > > enough for more than 8 million enterprises, and this may be=20 > > enough for=20 > > > the future at sight (28k were allocated up to now). I=20 > would however=20 > > > invite opinions, especially if somebody believes that there is a > > > problem here and any actions or guidance from the area is needed. > > >=20 > > > Dan > > >=20 > > >=20 > > > =20 > > >=20 > > >=20 > > > _______________________________________________ > > > AAA-DOCTORS mailing list > > > AAA-DOCTORS@ietf.org > > > https://www1.ietf.org/mailman/listinfo/aaa-doctors > > >=20 > >=20 >=20 > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www1.ietf.org/mailman/listinfo/mib-doctors >=20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Thu Jan 25 10:35:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA6dI-00029Z-2E; Thu, 25 Jan 2007 10:35:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9yTr-0003Rf-Us for aaa-doctors@ietf.org; Thu, 25 Jan 2007 01:53:08 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9ySh-00049V-0a for aaa-doctors@ietf.org; Thu, 25 Jan 2007 01:51:56 -0500 Received: (qmail 6709 invoked from network); 24 Jan 2007 22:51:22 -0800 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 24 Jan 2007 22:51:22 -0800 Date: Wed, 24 Jan 2007 22:51:19 -0800 (PST) From: "David T. Perkins" X-X-Sender: dperkins@shell4.bayarea.net To: "Romascanu, Dan \\(Dan\\)" In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-Mailman-Approved-At: Thu, 25 Jan 2007 10:35:23 -0500 Cc: aaa-doctors@ietf.org, "MIB Doctors \\\(E-mail\\\)" , OPS Area Subject: [AAA-DOCTORS] Re: [MIB-DOCTORS] Enterprise codes - three or four octets 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 HI, I was behind using the approach of creating a 32-bit number in capwap that is EnterpriseId*256 + value. (That is, using only the lower 24bits and effectively limiting the range to 24 bits.) I cloned what was done in RFC 3411 for the definition of SnmpSecurityModel which is used as the value of the msgSecurityModel field (which is only 31 bits) and defined in RFC 3412. I believe that effectively limiting EnterpriseIDs to 24 bits is reasonable based on the allocation of OUIs, on which I did a pretty extensive analysis of the assignements of values values (which have been in existance before enterpriseIDs were created). I came to the conclusion that the allocated OUIs were close enough to 16 bits of allocation to make me uncomfortable with using only 16 bits of the EnterpriseID, but quite comfortable with using 24 bits. Please send me email if you have any additional questions! Regards, /david t. perkins On Thu, 25 Jan 2007, Romascanu, Dan \(Dan\) wrote: > I apologize for the cross-posting. I am not sure if this is a problem, > but I would like to get some advice. I see in different documents two > different ways of coding the SMI Private Enterprise Code. As far as I > can understand these numbers should be coded as 32-bit, or at least I > could not find any reason to limit them in any document that mentions > them starting with RFC 1700. However, in other documents four octets are > allocated, but the most significant octet is specified to be zero - see > RFC 2865, or the more recent draft-cam-winget-eap-fast which is on the > agenda of the IESG telechat tomorrow. An interesting case is > draft-ietf-capwap-protocol-specification-04 which uses three octets in > one place and four octets in four other places of the same document. > > I do not know where the limitation to three meaningful octets started to > be applied and why. Maybe we should not care, because 24 bits are enough > for more than 8 million enterprises, and this may be enough for the > future at sight (28k were allocated up to now). I would however invite > opinions, especially if somebody believes that there is a problem here > and any actions or guidance from the area is needed. > > Dan > > > > > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www1.ietf.org/mailman/listinfo/mib-doctors > _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Thu Jan 25 12:53:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA8nF-0007GT-TG; Thu, 25 Jan 2007 12:53:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA8nE-0007G4-3c; Thu, 25 Jan 2007 12:53:48 -0500 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA8nC-0000Xp-Gi; Thu, 25 Jan 2007 12:53:48 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l0PHrid4019611; Thu, 25 Jan 2007 11:53:44 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 11:53:43 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 18:53:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MIB-DOCTORS] RE: [AAA-DOCTORS] Enterprise codes - three or fouroctets Date: Thu, 25 Jan 2007 18:53:04 +0100 Message-ID: In-Reply-To: <03ee01c74023$221b3570$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MIB-DOCTORS] RE: [AAA-DOCTORS] Enterprise codes - three or fouroctets Thread-Index: AcdAE0ku+NFjZYnWRLGw1/LDcSCKlQAAL8FwAABRc0AAAO7CUAAjMLcw References: <03ee01c74023$221b3570$0600a8c0@china.huawei.com> From: "Wijnen, Bert \(Bert\)" To: "David B Harrington" , "Romascanu, Dan \(Dan\)" , "OPS Area" X-OriginalArrivalTime: 25 Jan 2007 17:53:05.0214 (UTC) FILETIME=[AA2DFDE0:01C740A9] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: aaa-doctors@ietf.org, "MIB Doctors \(E-mail\)" 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 Yes, BUT=20 - we as SNMP/SMI experts have violated the rule (as Dave Perkins=20 also stated). I know we carefully investigated this at the time, and we also made a note of it in our DESCRIPTION clause in the TC where we did the violation. Nevertheless, we DID violate the approved definition of Enterprise OID. - we are aware that others are doing (possibly have done) this too.=20 - According to Dan and Bernard, there are other wanting to violate, some even seem to want to limit it to 2 octets. So we better: - recognize/document what we have done (violated the limit) - document that others are doing so too, - specify what we all agree (consensus) to be a acceptable limit (3 octets) - document this with IANA so it is public. Possibly we need a short draft for that, although I would think that if we as MIB doctors can get agreement and if Dan runs a sortf of IETF Last Call; then possibly it can just be some text at the top of the enterprise OID registration directory at iana. Bert > -----Original Message----- > From: David B Harrington [mailto:dbharrington@comcast.net]=20 > Sent: woensdag 24 januari 2007 17:50 > To: 'Romascanu, Dan (Dan)'; Wijnen, Bert (Bert); 'OPS Area' > Cc: aaa-doctors@ietf.org; 'MIB Doctors (E-mail)' > Subject: RE: [MIB-DOCTORS] RE: [AAA-DOCTORS] Enterprise codes=20 > - three or fouroctets >=20 > Hi, >=20 > According to www.iana.org, the defining document for=20 > ENTERPRISE is RFC2578. I believe this is the updated defining=20 > document; the original appears to be RFC1065 (Structure and=20 > Identification of Management Information for TCP/IP-based internets).=20 >=20 > Each enterprise is assigned a subtree: > "For example, if the > "Flintstones, Inc." enterprise produced networking=20 > subsystems, then > they could request a node under the enterprises subtree from the > Assigned Numbers authority." >=20 > A node is represented in SMI as a sub-identifier. > According to RFC2578, a sub-identifier has a value from 0..2^32-1 > (4294967295 decimal).=20 >=20 > This would argue for a 32-bit field size, wouldn't it? >=20 > dbh >=20 > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: Wednesday, January 24, 2007 7:33 PM > > To: Wijnen, Bert (Bert); OPS Area > > Cc: aaa-doctors@ietf.org; MIB Doctors (E-mail) > > Subject: [MIB-DOCTORS] RE: [AAA-DOCTORS] Enterprise codes -=20 > three or=20 > > fouroctets > >=20 > > Bert, > >=20 > > The fact that you mentioned '(older) protocols' means that your=20 > > opinion is that we should advise that new IETF documents=20 > use only the=20 > > 32-bit values? There is no such guidance now and people rather use > existing > > protocols as reference, so we may need to issue such a guidance.=20 > >=20 > > Dan > >=20 > >=20 > > =20 > > =20 > >=20 > > > -----Original Message----- > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com] > > > Sent: Thursday, January 25, 2007 2:04 AM > > > To: Romascanu, Dan (Dan); OPS Area > > > Cc: aaa-doctors@ietf.org; MIB Doctors (E-mail) > > > Subject: RE: [AAA-DOCTORS] Enterprise codes - three or four octets > > >=20 > > > Since, (as you note) there is no problem in the=20 > forseeable future,=20 > > > and since some protocols have already defined fields that only=20 > > > handle a 24-bit (i.e. 3 octet) value, maybe we should add some=20 > > > comment in the RFC-Editor mainatined registry that if=20 > they ever get=20 > > > to a value close to 25 bits, that we > > > (IETF) need to be aware that some (older) protocols have limited=20 > > > fields of up to 24 bits. > > >=20 > > > Bert > > >=20 > > > > -----Original Message----- > > > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > > > Sent: woensdag 24 januari 2007 15:57 > > > > To: OPS Area > > > > Cc: aaa-doctors@ietf.org; MIB Doctors (E-mail) > > > > Subject: [AAA-DOCTORS] Enterprise codes - three or four octets > > > >=20 > > > > I apologize for the cross-posting. I am not sure if this is > > > a problem, > > > > but I would like to get some advice. I see in different > > > documents two > > > > different ways of coding the SMI Private Enterprise Code.=20 > > > As far as I > > > > can understand these numbers should be coded as 32-bit, or > > > at least I > > > > could not find any reason to limit them in any document > > > that mentions > > > > them starting with RFC 1700. However, in other documents > > > four octets > > > > are allocated, but the most significant octet is specified > > > to be zero > > > > - see RFC 2865, or the more recent > > > draft-cam-winget-eap-fast which is > > > > on the agenda of the IESG telechat tomorrow. An > > interesting case is > > > > draft-ietf-capwap-protocol-specification-04 which uses > > > three octets in > > > > one place and four octets in four other places of the > > same document. > > > >=20 > > > > I do not know where the limitation to three meaningful > > > octets started > > > > to be applied and why. Maybe we should not care, because 24 > > > bits are > > > > enough for more than 8 million enterprises, and this may be > > > enough for > > > > the future at sight (28k were allocated up to now). I > > would however > > > > invite opinions, especially if somebody believes that there is a >=20 > > > > problem here and any actions or guidance from the area is > needed. > > > >=20 > > > > Dan > > > >=20 > > > >=20 > > > > =20 > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > AAA-DOCTORS mailing list > > > > AAA-DOCTORS@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/aaa-doctors > > > >=20 > > >=20 > >=20 > > _______________________________________________ > > MIB-DOCTORS mailing list > > MIB-DOCTORS@ietf.org > > https://www1.ietf.org/mailman/listinfo/mib-doctors > >=20 >=20 >=20 >=20 _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Mon Jan 29 09:06:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBX99-0006DV-FI; Mon, 29 Jan 2007 09:06:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBX98-0006Co-7l; Mon, 29 Jan 2007 09:06:10 -0500 Received: from [198.152.12.103] (helo=nj300815-ier2.net.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBX95-0007li-Qx; Mon, 29 Jan 2007 09:06:10 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0TE61YF032141; Mon, 29 Jan 2007 09:06:02 -0500 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: Mon, 29 Jan 2007 16:06:00 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OPS Area Meetings and mini-BOFs: Preliminary Agenda for Prague Thread-Index: AcdDrpqUSwS6PSnaQHKopeF9pnPMag== From: "Romascanu, Dan \(Dan\)" To: "OPS Area" , , , , "MIB Doctors \(E-mail\)" , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.1 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: Subject: [AAA-DOCTORS] OPS Area Meetings and mini-BOFs: Preliminary Agenda for Prague 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 meetings in Prague, as well as the list of mini-BOFs that David and myself have approved for Prague. We were not able to grant to everybody the time that you requested - please be prepared to adjust and manage your time accordingly. Also note that there still may be changes in the dates and time of the meting slots as result of IESG-Secretary changes.=20 Please comment on the agenda items and mini-BOF proposals.=20 We are looking forward to see you all in Prague.=20 Dan =20 Operations and Management (OPS) Area AGENDA Meeting : IETF68, Monday March 19, 2007 and Thursday March 22, 2007 Location: Prague, Congress II, Monday March 19, 2007 15:20 to 17:20 and Grand Ballroom Thursday March 22, 2007 9:00 to 11:30 Chairs : David Kessens (david.kessens@nokia.com) and Dan Romascanu (dromasca@avaya.com)=20 Jabber : ops@jabber.ietf.org URL : http://www.ops.ietf.org/ Agenda : version 0.1 (draft) = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Meeting 1 - Monday March 19, 2007 15:20 to 17:20 1. Meeting Administrivia ADs (total: 5 min) - Mailing list and URL - Minutes Scribe - Jabber Scribe - Blue Sheets 2. Mini-BOF A: COPS push mode policy configuration - Tom Taylor and Tina Tsou (total: 30 min) This mini-BOF is requested to gain comments on a technical proposal to reduce the number of messages required when COPS is used to support push mode policy configuration, where each request-state corresponds to an user session. The essence of this proposal is to allow the PDP to request the opening of a new request-state in the same message that sends down policy to be stored against this request-state. At the other end of the session life cycle, allow the PDP to delete a request-state.=20 The proposed extensions to COPS could save two to three messages per session, depending on the details that are finally agreed. I-D: to be submitted=20 3. Mini-BOF B: - Manageability and Operational Guidelines - David Harrington (total: 30 min) We need to develop multi-protocol manageability and operational guidelines for developers of protocols in the IETF. An internet-draft has been published that summarizes previous work on this goal as a starting point. This work would lead to either a WG, if enough people want to be involved, or a design team to get the document finished. If we can get enough feedback from operators and from protocol designers, this could lead to a BCP; with limited input it would lead to an Informational RFC instead.=20 I-D: to be submitted 4. Mini-BOF C: Best Current Practices in Operations and Management - David Harrington (total: 20 min) This would be an effort to get operators together in a WG to develop a set of best current practices, and a description of supporting technologies, for manageability and operations, similar to the work done in the OpSec WG. There will not be an internet-draft published prior to ietf68. A WG should be created for operators to do this work. 5. Improved Efficiency of the OPS Area - proposal for the formation of a OPS Area WG - ADs (total: 20 min) 6. Open Microphone - 15 min Meeting 2 - Monday March 19, 2007 - 9:00 to 11:30AM 1. Meeting Administrivia ADs (total: 5 min) - Mailing list and URL - Minutes Scribe - Jabber Scribe - Blue Sheets 2. Mini-BOF D: NE/facilities/lines/protocols/services data modeling - Michael Alexander (total: 40 min) Network Management (NM) standards have traditionally been focused on protocols, such as pertaining to configuration management and discovery. Yet, all areas of Network Management, ranging from Element Management (EM) to Network Management Systems (NMS) and Service Management Systems have in common that they critically rely on underlying data structures describing devices and services being managed. Network elements (NE) frequently spawn ten thousands of managed objects, such as for a multiservice switch...Traditionally, standardization of access-methods (protocols), discovery, etc. have received most attention, while the more heterogeneous data models and data modeling per saw comparatively less. As there are real possibilities to standardize underlying and universal commonalities in EMS/NMS/Service Management Systems on the one side and managed attributes of NEs, protocols, transmission facilities, lines and services on the other, the two distributions should be closer aligned. Despite the complexity, it is possible to identify and define frameworks and meta models of each constituent and their relation to each other, that would substantially ease the management of present and future devices, networks and services. I-D:=20 3. Mini-BOF E: MIB module editing in XML : Emile Stephan (total: 20 min) Present the state of the art of editing MIB module in XML; Introduce a basic template to edit SMI items in pure XML instead of in raw text; Propose a simple XML template for SMI items; discuss the connections with XML schema and network management protocols. I-D: draft-stephan-ops-xml-mib-module-template-00 (under edition to be submitted before mid February) 4. Mini-BOF F: Japanese Data Model Standards: Tomoyuki Iijima (total: 20 min) I'd like to show the data model examples we developed and was adopted in the Japanese Standard body. We developed data models of VLAN, Filter (Access Control List), and so on and those data models were adopted by Japanese standardization body called INTAP/OSMIC as standard data models. I'd like to make our data model examples be adopted as an Informational RFC. I-D: to be submitted 5. Mini-BOF G: OWL techniques for MIB to XML documents and schema translation - Bob Natale (total: 40 min) Specification of a standard methodology for translating SNMP MIBs into outputs more directly usable by emerging SOA/web services management tools, and specification of a standard methodology for validating those translations. Appropriate translation outputs are TBD by the WG, but can be expected to include one or more of the following: XML, RDF, WSDL, WS-Policy, WS-Event/Notification, Ontology. The translation output(s) should allow for extension of the respective managed element data model in the native SOA/web services environment. Because of the extensibility objective, reverse translation back into SNMP MIB format is a non-goal of the WG, but the possibility should be considered when weighing alternatives. I-D: to be submitted 6. Open microphone (total: 25 min) =20 _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Mon Jan 29 09:07:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBXA8-0006nV-GC; Mon, 29 Jan 2007 09:07:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBXA6-0006mh-Rs; Mon, 29 Jan 2007 09:07:10 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBXA5-0007qw-C2; Mon, 29 Jan 2007 09:07:10 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0TE76eB020529; Mon, 29 Jan 2007 09:07:07 -0500 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: Mon, 29 Jan 2007 16:07:06 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OPS Area Meetings and mini-BOFs: Preliminary Agenda for Prague (corrected date) Thread-Index: AcdDrpqUSwS6PSnaQHKopeF9pnPMag== From: "Romascanu, Dan \(Dan\)" To: "OPS Area" , , , , "MIB Doctors \(E-mail\)" , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: Subject: [AAA-DOCTORS] OPS Area Meetings and mini-BOFs: Preliminary Agenda for Prague (corrected date) 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 meetings in Prague, as well as the list of mini-BOFs that David and myself have approved for Prague. We were not able to grant to everybody the time that you requested - please be prepared to adjust and manage your time accordingly. Also note that there still may be changes in the dates and time of the meting slots as result of IESG-Secretary changes.=20 Please comment on the agenda items and mini-BOF proposals.=20 We are looking forward to see you all in Prague.=20 Dan =20 Operations and Management (OPS) Area AGENDA Meeting : IETF68, Monday March 19, 2007 and Thursday March 22, 2007 Location: Prague, Congress II, Monday March 19, 2007 15:20 to 17:20 and Grand Ballroom Thursday March 22, 2007 9:00 to 11:30 Chairs : David Kessens (david.kessens@nokia.com) and Dan Romascanu (dromasca@avaya.com)=20 Jabber : ops@jabber.ietf.org URL : http://www.ops.ietf.org/ Agenda : version 0.1 (draft) = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Meeting 1 - Monday March 19, 2007 15:20 to 17:20 1. Meeting Administrivia ADs (total: 5 min) - Mailing list and URL - Minutes Scribe - Jabber Scribe - Blue Sheets 2. Mini-BOF A: COPS push mode policy configuration - Tom Taylor and Tina Tsou (total: 30 min) This mini-BOF is requested to gain comments on a technical proposal to reduce the number of messages required when COPS is used to support push mode policy configuration, where each request-state corresponds to an user session. The essence of this proposal is to allow the PDP to request the opening of a new request-state in the same message that sends down policy to be stored against this request-state. At the other end of the session life cycle, allow the PDP to delete a request-state.=20 The proposed extensions to COPS could save two to three messages per session, depending on the details that are finally agreed. I-D: to be submitted=20 3. Mini-BOF B: - Manageability and Operational Guidelines - David Harrington (total: 30 min) We need to develop multi-protocol manageability and operational guidelines for developers of protocols in the IETF. An internet-draft has been published that summarizes previous work on this goal as a starting point. This work would lead to either a WG, if enough people want to be involved, or a design team to get the document finished. If we can get enough feedback from operators and from protocol designers, this could lead to a BCP; with limited input it would lead to an Informational RFC instead.=20 I-D: to be submitted 4. Mini-BOF C: Best Current Practices in Operations and Management - David Harrington (total: 20 min) This would be an effort to get operators together in a WG to develop a set of best current practices, and a description of supporting technologies, for manageability and operations, similar to the work done in the OpSec WG. There will not be an internet-draft published prior to ietf68. A WG should be created for operators to do this work. 5. Improved Efficiency of the OPS Area - proposal for the formation of a OPS Area WG - ADs (total: 20 min) 6. Open Microphone - 15 min Meeting 2 - Thursday March 22, 2007 - 9:00 to 11:30AM 1. Meeting Administrivia ADs (total: 5 min) - Mailing list and URL - Minutes Scribe - Jabber Scribe - Blue Sheets 2. Mini-BOF D: NE/facilities/lines/protocols/services data modeling - Michael Alexander (total: 40 min) Network Management (NM) standards have traditionally been focused on protocols, such as pertaining to configuration management and discovery. Yet, all areas of Network Management, ranging from Element Management (EM) to Network Management Systems (NMS) and Service Management Systems have in common that they critically rely on underlying data structures describing devices and services being managed. Network elements (NE) frequently spawn ten thousands of managed objects, such as for a multiservice switch...Traditionally, standardization of access-methods (protocols), discovery, etc. have received most attention, while the more heterogeneous data models and data modeling per saw comparatively less. As there are real possibilities to standardize underlying and universal commonalities in EMS/NMS/Service Management Systems on the one side and managed attributes of NEs, protocols, transmission facilities, lines and services on the other, the two distributions should be closer aligned. Despite the complexity, it is possible to identify and define frameworks and meta models of each constituent and their relation to each other, that would substantially ease the management of present and future devices, networks and services. I-D:=20 3. Mini-BOF E: MIB module editing in XML : Emile Stephan (total: 20 min) Present the state of the art of editing MIB module in XML; Introduce a basic template to edit SMI items in pure XML instead of in raw text; Propose a simple XML template for SMI items; discuss the connections with XML schema and network management protocols. I-D: draft-stephan-ops-xml-mib-module-template-00 (under edition to be submitted before mid February) 4. Mini-BOF F: Japanese Data Model Standards: Tomoyuki Iijima (total: 20 min) I'd like to show the data model examples we developed and was adopted in the Japanese Standard body. We developed data models of VLAN, Filter (Access Control List), and so on and those data models were adopted by Japanese standardization body called INTAP/OSMIC as standard data models. I'd like to make our data model examples be adopted as an Informational RFC. I-D: to be submitted 5. Mini-BOF G: OWL techniques for MIB to XML documents and schema translation - Bob Natale (total: 40 min) Specification of a standard methodology for translating SNMP MIBs into outputs more directly usable by emerging SOA/web services management tools, and specification of a standard methodology for validating those translations. Appropriate translation outputs are TBD by the WG, but can be expected to include one or more of the following: XML, RDF, WSDL, WS-Policy, WS-Event/Notification, Ontology. The translation output(s) should allow for extension of the respective managed element data model in the native SOA/web services environment. Because of the extensibility objective, reverse translation back into SNMP MIB format is a non-goal of the WG, but the possibility should be considered when weighing alternatives. I-D: to be submitted 6. Open microphone (total: 25 min) =20 _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors