From aaa-doctors-bounces@ietf.org Fri Dec 08 05:08:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsceU-0004q9-Cs; Fri, 08 Dec 2006 05:08:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsceS-0004pr-JP; Fri, 08 Dec 2006 05:08:20 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsceR-0003MZ-7p; Fri, 08 Dec 2006 05:08:20 -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 kB8A8CwR030185; Fri, 8 Dec 2006 05:08:13 -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, 8 Dec 2006 12:08:12 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for December 14, 2006 Telechat Thread-Index: AccaXCuXuNgpddtiSnC7qOto87PcWQAVB4CA From: "Romascanu, Dan \(Dan\)" To: "MIB Doctors" , , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: Subject: [AAA-DOCTORS] FW: PRELIMINARY Agenda and Package for December 14, 2006 Telechat X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: aaa-doctors-bounces@ietf.org Please see below the preliminary agenda of the December 14, 2007 IESG telechat. If there are any comments or issues with the documents brought to the IESG for approval, please send me an e-mail until December 13, 2007 COB.=20 Thanks and Regards, Dan =20 -----Original Message----- From: IESG Secretary [mailto:iesg-secretary@ietf.org]=20 =20 =20 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item o draft-ietf-ccamp-rsvp-te-exclude-route-06.txt Exclude Routes - Extension to RSVP-TE (Proposed Standard) - 1 of 6=20 Token: Ross Callon o draft-ietf-ips-iscsi-nodearch-key-03.txt Declarative Public Extension Key for iSCSI Node Architecture (Proposed =20 Standard) - 2 of 6=20 Note: Document Shepherd: David Black (Black_David@emc.com)=20 Token: Lars Eggert o draft-ietf-tsvwg-sctp-padding-02.txt Padding Chunk and Parameter for SCTP (Proposed Standard) - 3 of 6=20 Note: PROTO Document Shepherd: James Polk=20 Token: Lars Eggert o draft-ietf-dkim-base-07.txt DomainKeys Identified Mail (DKIM) Signatures (Proposed Standard) - 4 of 6=20 Token: Russ Housley o draft-ietf-mpls-rsvp-te-p2mp-06.txt Extensions to RSVP-TE for Point-to-Multipoint TE LSPs (Proposed Standard) -=20 5 of 6=20 Token: Ross Callon o draft-ietf-rohc-rfc3095bis-framework-04.txt The RObust Header Compression (ROHC) Framework (Proposed Standard) - 6 of 6=20 Token: Magnus Westerlund 2.1.2 Returning Item o draft-ietf-mip6-ikev2-ipsec-07.txt Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture=20 (Proposed Standard) - 1 of 2=20 Note: PROTO Shepherd is Basavaraj Patil =20 Token: Jari Arkko o draft-ietf-radext-delegated-prefix-05.txt RADIUS Delegated-IPv6-Prefix Attribute (Proposed Standard) - 2 of 2=20 Note: PROTO Shepherd: Bernard Aboba . Back on=20 the agenda to check whether Mark's concerns have been addressed.=20 Token: David Kessens 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 1=20 Note: Brian shepherds on behalf of the Routing ADs=20 Token: Brian Carpenter 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-dccp-tfrc-voip-07.txt TCP Friendly Rate Control (TFRC): the Small-Packet (SP) Variant=20 (Experimental) - 1 of 4=20 Note: PROTO Document Shepherd: Gorry Fairhurst=20 Token: Lars Eggert o draft-ietf-mboned-maccnt-req-04.txt Requirements for Accounting, Authentication and Authorization in Well Managed IP Multicasting Services (Informational) - 2 of 4=20 Note: Marshall Eubanks is the Document Shepherd=20 Token: David Kessens o draft-ietf-bmwg-hash-stuffing-07.txt Hash and Stuffing: Overlooked Factors in Network Device Benchmarking (Informational) - 3 of 4=20 Note: Al Morton is the Document Shepherd=20 Token: David Kessens o draft-ietf-v6ops-ipsec-tunnels-04.txt Using IPsec to Secure IPv6-in-IPv4 Tunnels (Informational) - 4 of 4=20 Note: Fred Baker is the document shepherd=20 Token: David Kessens 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-heffner-frag-harmful-03.txt IPv4 Fragmentation Considered Very Harmful (Informational) - 1 of 1=20 Token: Lars Eggert _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Sat Dec 09 17:50:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtB1w-0002ll-Qt; Sat, 09 Dec 2006 17:50:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtB1v-0002ld-8L for aaa-doctors@ietf.org; Sat, 09 Dec 2006 17:50:51 -0500 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtB1r-0007HQ-Qn for aaa-doctors@ietf.org; Sat, 09 Dec 2006 17:50:51 -0500 Received: from c-24-16-67-215.hsd1.wa.comcast.net ([24.16.67.215] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.63) (envelope-from ) id 1GtB1r-000CrA-40; Sat, 09 Dec 2006 17:50:47 -0500 Received: by internaut.com (Postfix, from userid 1000) id 1ED653A76D; Sat, 9 Dec 2006 14:50:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 1089C3A72A; Sat, 9 Dec 2006 14:50:50 -0800 (PST) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.16.67.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Sat, 9 Dec 2006 14:50:50 -0800 (PST) From: Bernard Aboba To: "Romascanu, Dan (Dan)" 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: a92270ba83d7ead10c5001bb42ec3221 Cc: aaa-doctors@ietf.org Subject: [AAA-DOCTORS] Review of draft-ietf-mboned-maccnt-req-04.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 Review of draft-ietf-mboned-maccnt-req-04.txt Overall: Although this document mentions MSEC in Section 3.2, in a number of places it makes assertions that seem to ignore MSEC, or imply that it is deficient in some way, without explaining why this is true. One of the reasons that MSEC was developed was because of the security issues inherent in attempting to authenticate and account for usage via IGMP. Since any listener on the path can access multicast traffic, access to content can't be controlled by authenticating IGMP, it can only be controlled by encrypting the content. While Section 3.3 talks about why the document does not apply to shared media, the use of shared media multicast is quite widespread so that this restriction seems quite severe. This document talks about usage-based billing. As noted in RFC 2975, there may be legal requirements associated with usage-based billing, such as requirements on the reliability of accounting transport as well as the accuracy of usage determination. It was not clear that this document takes those issues into account, and as a result, solutions based on this requirements document may not pass scrutiny. In a number of places, it is unclear why requirements relate specifically to AAA, as opposed to management facilities made available in switches and routers. Overall, there are enough problems with this document, that publication in its current form is inadvisable. More detailed comments ---------------------------------- " IP multicasting is becoming widely used as a method to save network resources such as bandwidth or CPU processing power of the sender's server for cases where a large volume of information needs to be distributed to a large number of receivers." While IP multicasting always saves resources on the sender, on wireless link it does not necessarily save network resources, because multicast traffic may have to be sent at lower rate than unicast traffic. For example, in IEEE 802.11 networks an Access Point will send multicast/broadcast traffic at the lowest supported rate, in order to be assured of reaching all potential receivers, whereas unicast traffic can be sent at the highest rate that can be supported by link conditions. As a result, sending a packet via link layer multicast may consume more resources than replicating the same packet via link layer unicast. As an example, consider an IEEE 802.11n network with a minimum supported rate of 1 Mbps, and a maximum supported rate of 200 Mbps. In this situation, a frame sent via link layer multicast would consume as much network resources as 100 frames sent at the maximum rate. Unless there were 100 potential receiver, it would therefore make more sense to send the packet via unicast. Of course these considerations do not apply on wired links where multicast traffic is sent at the same rate as unicast traffic. IP multicasting can be used to distribute free material efficiently, but there are limitations to multicasting in usage models where usage accounting is necessary, such as many commercial applications. These limitations have prevented the widespread deployment of multicasting. I believe that it is an exaggeration to state that accounting issues are the primary reason why multicast has not been deployed on a widespread basis. I say this as someone who was involved in one of the earliest commercial multicast service offerings. In my experience, there were quite a few issues that were as or more important, including problems of traffic engineering, diagnostics, user-interest, etc. Later on the document does talk about the "on demand" versus other multicast delivery mechanisms, but I think the document could be more balanced here. Then, the multicast router replicates the data to any link which has at least one client requesting the information. In this process, no eligibility check is conducted. Any client can receive information just by requesting it. In other words, the current standards do not provide multicasting with authorization or access control capabilities sufficient to meet the requirements of accounting. Given the discussion of MSEC in Section 3.2 I do not understand this statement. If MSEC is used, why wouldn't it be possible to authenticate receivers and account for usage? This is the major reason why multicasting is only used for cases where no user-based accounting capabilities are necessary. I also don't understand this statement given the discussion of MSEC. Are you saying that MSEC is inadequate or undeployable? If so, then the reasons should be stated. For example, accounting is needed if one wants to charge for distributed information on a non-flat-fee basis. RFC 2975 describes the requirements for usage-based billing; among other things, the requirements are considerably greater for usage-based billing because in those situations packets = money. That means that accurate usage-determination and reliable transport is not just a "nice to have" as it might be if the accounting data were only used for traffic engineering; they may actually be a legal requirement. Section 3.2 " The functional requirements do not require content encryption although it might solve some of the related problems. At this point, it is not yet clear whether encryption would be part of a solution and if so, what other components (if any) would also be required. " The document does not discuss what the "related problems" are, or provide a reference to such a discussion. The result is that on reading this paragraph I'm left without an understanding of what the issues are -- or why content encryption is not a requirement. Section 3.3 "However, IP multicast solutions with shared Layer 2 access media between the user and multicast router and no logical user separation (e.g. Ethernet with shared links and no VLAN) are out of scope of this memo. " Why is this out of scope? As I understand it, virtually all wireless media fit within this category, as do technologies such as EPON. Earlier an argument is made that the accounting functionality is more or less the same for MSEC as opposed to other methods, so why not just say that the IGMP-based approach doesn't work for these cases? Section 4 Also, it is necessary to identify the source (user) of each request (e.g., join/leave) for user accounting purposes. Identifying the IP address originating a request is not the same thing as determining the user. With current protocols (IGMP/MLD), the sender cannot distinguish which receivers (end hosts) are actually receiving the information. The sender must rely on the information from the multicasting routers. This can be complicated if the sender and routers are maintained by different entities. I think you need to distinguish the inability to determine which receivers are receiving the information on a shared media (which will be the case even with authentication). (2) Issue of Network Resource Protection In order to guarantee certain QoS it is important for network providers to be able to protect their network resources from being wasted, (either maliciously or accidentally). For comparisons sake, in the case of unicast this issue can be resolved e.g. by using RSVP. Why is RSVP not relevant to the multicast case (particularly since it supports authentication)? The network may need to control the combined bandwidth for all groups at the physical port of the edge router or switch so that these given physical entities are not overflowed with traffic. Why is this a AAA requirement and not a QoS requirement? (2.3) Control mechanism of number of groups delivered from a physical port of edge router and switch Why is this a AAA requirement (as opposed to a requirement for management functionality on a switch or router)? To assemble such an understanding of end-user behavior, it is necessary to precisely log information such as who (host/user) is accessing what content at what time (join action) until what time (leave action). The result of the access-control decision (e.g. results of authorization) would also be valuable information. If we are talking about usage-based billing, we will need more than this. We will need some assurance that the accounting data itself is being transported reliably. There may be also issues arising from loss of IGMP join/leave messages. For example, if a leave is lost, will a user be charged inappropriately? _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Mon Dec 18 14:31:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwOCk-00055A-IE; 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 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, 18 Dec 2006 21:31:11 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: reminder about 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.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: nmrg@ibr.cs.tu-bs.de, IESG Subject: [AAA-DOCTORS] reminder about 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 David, =20 This is a reminder that we intent to 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. Although there are still three months to go until the Prague IETF it is not too early to send proposals, both in order to help planning the sessions, as well as in order to better prepare the sessions by holding preliminary discussions. Any of the lists in the area would do, but ops-area@ietf.org would probably be the best.=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 Tue Dec 19 02:54:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwZnX-0005cu-BW; Tue, 19 Dec 2006 02:54:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwZnV-0005cJ-NM; Tue, 19 Dec 2006 02:54:01 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwZnO-0006jc-Gr; Tue, 19 Dec 2006 02:54:01 -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 kBJ7rq0W032607; Tue, 19 Dec 2006 02:53:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Received: from 300815erh2.post.avaya.com ([198.152.6.49]) by IS0004AVEXU1.global.avaya.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 18 Dec 2006 21:32:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: Tue, 19 Dec 2006 09:53:50 +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: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: nmrg@ibr.cs.tu-bs.de, IESG 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 This is a reminder that we intent to 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. Although there are still three months to go until the Prague IETF it is not too early to send proposals, both in order to help planning the sessions, as well as in order to better prepare the sessions by holding preliminary discussions. Any of the lists in the area would do, but ops-area@ietf.org would probably be the best.=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 Wed Dec 20 01:21:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwupM-0007as-Ve; Wed, 20 Dec 2006 01:21:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwnoZ-0001uZ-HR; Tue, 19 Dec 2006 17:52:03 -0500 Received: from alnrmhc13.comcast.net ([204.127.225.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwnoY-0004q5-7a; Tue, 19 Dec 2006 17:52:03 -0500 Received: from harrington73653 (135-152.186-72.tampabay.res.rr.com?[72.186.152.135]) by comcast.net (alnrmhc13) with SMTP id <20061219225200b1300q8t3qe>; Tue, 19 Dec 2006 22:52:01 +0000 From: "David B Harrington" To: "'Romascanu, Dan \(Dan\)'" , , , "'MIB Doctors'" , , "'DNS Directorate'" Date: Tue, 19 Dec 2006 17:48:54 -0500 Message-ID: <191a01c723bf$dd9b80f0$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 Thread-Index: AcccV6ii14zulLX7R3CFlQvi3jCmlAHZmmUA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-Mailman-Approved-At: Wed, 20 Dec 2006 01:21:19 -0500 Cc: nmrg@ibr.cs.tu-bs.de, 'IESG' Subject: [AAA-DOCTORS] RE: [MIB-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 Hi, Please respond only to the OPS-area mailing list. I would like to raise three potential areas of discussion. These may be suitable for BOFs or mini-BOFs. 1) An OpsNM BOF, designed to lead to a WG similar to the OpSec WG, to have **operators** document how they actually manage networks today, and to document what features they utilize in equipment today to accomplish such management. For example, DavidK mentioned during the last OPSarea open-office meetings that there are three major approaches to managing service provider networks (Motorola, ??, ??). I don't think this is documented anyplace in IETF documents. I don't know if these approaches are documented elsewhere. I don't know what they are, since my background is not SP-oriented, which is true of many IETF NM people. As we move toward a more SP-centric Internet, it would be helpful to get these approaches documented in the IETF. 2) The IETF has limited resources to accomplish its work, and it would be good to not waste resources trying to solve problems we think might exist, when we could be working on the problems we know exist. In the OpSec WG, few enterprise equipment vendors participated. It might be time to have a discussion of whether the IETF should simply move to be more SP-centric, especially the IETF management protocols. If enterprise equipment vendors do not believe it is important for them to contribute to IETF protocol designs, then enterprise equipment vendors (and their customers) may need to move toward an SP-centric approach to utilize emerging/future IETF protocols. How do we want to focus our Operations and Management resources? Is the IETF OPS area still relevant for operating and managing the Internet? Should we adopt the management standards from other SDOs, or let the other IETF areas design their own focus-appropriate management solutions? 3) A manageability considerations BOF. There is already work being done on manageability considerations guidelines (how to consider manageability requirements, not a required section in all documents). There was a lot of discussion about this in the last OPS Area open meeting as well. This would benefit from achieving consensus from operators and standards writers, and would probably be a good choice for an EDU tutorial once consensus is reached. Obviously, this would benefit from the discussions of #1 and #2. dbh > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Tuesday, December 19, 2006 2:54 AM > To: ops-area@ietf.org; ops-nm@ietf.org; MIB Doctors; > aaa-doctors@ietf.org; DNS Directorate > Cc: nmrg@ibr.cs.tu-bs.de; IESG > Subject: [MIB-DOCTORS] OPS Area BOFs in Prague > > > This is a reminder that we intent to 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. > Although there > are still three months to go until the Prague IETF it is not too early > to send proposals, both in order to help planning the > sessions, as well > as in order to better prepare the sessions by holding preliminary > discussions. Any of the lists in the area would do, but > ops-area@ietf.org would probably be the best. > > David and 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 Dec 21 07:02:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxMdO-0007Yn-Se; Thu, 21 Dec 2006 07:02:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxMdM-0007WT-RA; Thu, 21 Dec 2006 07:02:48 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxMdK-0001ly-Hs; Thu, 21 Dec 2006 07:02:48 -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 kBLC2dwZ025059; Thu, 21 Dec 2006 07:02: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, 21 Dec 2006 14:02:38 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-NM] RE: [OPS-AREA] Re: [MIB-DOCTORS] OPS Area BOFs in Prague Thread-Index: Acckav4kHdal9oCGSUqvFbDMNASGOAAALfewACLaaKA= From: "Romascanu, Dan \(Dan\)" To: "Natale, Bob" , , , , "IESG" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: aaa-doctors@ietf.org, MIB Doctors , DNS Directorate Subject: [AAA-DOCTORS] RE: [OPS-NM] RE: [OPS-AREA] Re: [MIB-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 I am not in the position to disagree :-) We need however to start from something. This 'something' is in my opinion a document to guide IETF authors in writing manageability and operational requirements in their protocol documents. Today in the absence of such a reference I encounter huge problems in my role of Area Director when I come and say 'we cannot approve this new protocol because it says nothing about how it will be managed or what impact it will have in the operation of the network'. The typical answers are 'who says it needs to say something about management and operations?' or 'what is the reference for what we need to include about manageability and operations'?=20 Dan =20 =20 > -----Original Message----- > From: Natale, Bob [mailto:RNATALE@mitre.org]=20 > Sent: Wednesday, December 20, 2006 9:23 PM > To: ops-nm@ietf.org; ops-area@ietf.org; nmrg@ibr.cs.tu-bs.de; IESG > Cc: aaa-doctors@ietf.org; MIB Doctors; DNS Directorate > Subject: [OPS-NM] RE: [OPS-AREA] Re: [MIB-DOCTORS] OPS Area=20 > BOFs in Prague >=20 >=20 > Hi, >=20 > I strongly agree with Andy's position (from below): >=20 > "IMO, to advance to Draft Standard, a protocol should meet=20 > strict manageability requirements, which would obviously need=20 > to be documented in an RFC." >=20 > Cheers, > BobN >=20 > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com] > Sent: Wednesday, December 20, 2006 2:10 PM > To: David B Harrington > Cc: ops-nm@ietf.org; aaa-doctors@ietf.org; 'MIB Doctors';=20 > 'DNS Directorate'; 'IESG'; nmrg@ibr.cs.tu-bs.de; ops-area@ietf.org > Subject: [OPS-AREA] Re: [MIB-DOCTORS] OPS Area BOFs in Prague >=20 > David B Harrington wrote: > > Hi, > >=20 > > Please respond only to the OPS-area mailing list. > >=20 > > I would like to raise three potential areas of discussion.=20 > These may=20 > > be suitable for BOFs or mini-BOFs. > >=20 > > 1) An OpsNM BOF, designed to lead to a WG similar to the=20 > OpSec WG, to=20 > > have **operators** document how they actually manage=20 > networks today,=20 > > and to document what features they utilize in equipment today to=20 > > accomplish such management. >=20 >=20 > I think such a documentation project could be a lot of work. > If there were enough participation, it would be very useful. >=20 >=20 > >=20 > > For example, DavidK mentioned during the last OPSarea open-office=20 > > meetings that there are three major approaches to managing service=20 > > provider networks (Motorola, ??, ??). I don't think this is > documented > > anyplace in IETF documents. I don't know if these approaches are=20 > > documented elsewhere. > >=20 > > I don't know what they are, since my background is not SP-oriented,=20 > > which is true of many IETF NM people. As we move toward a more=20 > > SP-centric Internet, it would be helpful to get these approaches=20 > > documented in the IETF. > >=20 > > 2) The IETF has limited resources to accomplish its work, and it > would > > be good to not waste resources trying to solve problems we think > might > > exist, when we could be working on the problems we know exist. > >=20 > > In the OpSec WG, few enterprise equipment vendors participated. It=20 > > might be time to have a discussion of whether the IETF=20 > should simply=20 > > move to be more SP-centric, especially the IETF management=20 > protocols. > > If enterprise equipment vendors do not believe it is important for=20 > > them to contribute to IETF protocol designs, then enterprise > equipment > > vendors (and their customers) may need to move toward an SP-centric=20 > > approach to utilize emerging/future IETF protocols. > >=20 > > How do we want to focus our Operations and Management resources? Is=20 > > the IETF OPS area still relevant for operating and managing the=20 > > Internet? Should we adopt the management standards from other SDOs, > or > > let the other IETF areas design their own focus-appropriate > management > > solutions? >=20 >=20 > IMO this tends to work itself out in the end. > The people involved in a WG will influence its outcome, and=20 > the people not involved in a WG will not influence its outcome. >=20 > Labels like Enterprise and SP are not that helpful here. > Some companies have both kinds of products. >=20 >=20 > >=20 > > 3) A manageability considerations BOF. There is already work being=20 > > done on manageability considerations guidelines (how to consider=20 > > manageability requirements, not a required section in all=20 > documents). > > There was a lot of discussion about this in the last OPS Area open=20 > > meeting as well. This would benefit from achieving consensus from=20 > > operators and standards writers, and would probably be a=20 > good choice=20 > > for an EDU tutorial once consensus is reached. > >=20 > > Obviously, this would benefit from the discussions of #1 and #2. > >=20 >=20 > More documentation work. It would be useful to both RFC=20 > readers and writers, so I couldn't argue against it. I want=20 > every WG that creates a protocol to think about how operators=20 > and developers are going to securely and efficiently manage=20 > the protocol, including configuration. It should not be left=20 > as a proprietary component forever. IMO, to advance to Draft=20 > Standard, a protocol should meet strict manageability=20 > requirements, which would obviously need to be documented in an RFC. >=20 >=20 > > dbh >=20 > Andy >=20 > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www1.ietf.org/mailman/listinfo/ops-area >=20 > _______________________________________________ > OPS-NM mailing list > OPS-NM@ietf.org > https://www1.ietf.org/mailman/listinfo/ops-nm >=20 _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Thu Dec 21 09:57:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxPMF-0001WK-HI; Thu, 21 Dec 2006 09:57:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx6sE-0003w2-Jp for aaa-doctors@ietf.org; Wed, 20 Dec 2006 14:13:06 -0500 Received: from omr3.networksolutionsemail.com ([205.178.146.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx6pb-00053z-76 for aaa-doctors@ietf.org; Wed, 20 Dec 2006 14:10:25 -0500 Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id kBKJAI3e004645 for ; Wed, 20 Dec 2006 14:10:21 -0500 Received: (qmail 13830 invoked by uid 78); 20 Dec 2006 19:10:18 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.56.110) by ns-omr3.lb.hosting.dc2.netsol.com with SMTP; 20 Dec 2006 19:10:18 -0000 Message-ID: <45898A91.70305@andybierman.com> Date: Wed, 20 Dec 2006 11:10:09 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: David B Harrington References: <191a01c723bf$dd9b80f0$0600a8c0@china.huawei.com> In-Reply-To: <191a01c723bf$dd9b80f0$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 X-Mailman-Approved-At: Thu, 21 Dec 2006 09:57:19 -0500 Cc: ops-nm@ietf.org, aaa-doctors@ietf.org, 'MIB Doctors' , 'DNS Directorate' , 'IESG' , nmrg@ibr.cs.tu-bs.de, ops-area@ietf.org Subject: [AAA-DOCTORS] Re: [MIB-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 David B Harrington wrote: > Hi, > > Please respond only to the OPS-area mailing list. > > I would like to raise three potential areas of discussion. These may > be suitable for BOFs or mini-BOFs. > > 1) An OpsNM BOF, designed to lead to a WG similar to the OpSec WG, to > have **operators** document how they actually manage networks today, > and to document what features they utilize in equipment today to > accomplish such management. I think such a documentation project could be a lot of work. If there were enough participation, it would be very useful. > > For example, DavidK mentioned during the last OPSarea open-office > meetings that there are three major approaches to managing service > provider networks (Motorola, ??, ??). I don't think this is documented > anyplace in IETF documents. I don't know if these approaches are > documented elsewhere. > > I don't know what they are, since my background is not SP-oriented, > which is true of many IETF NM people. As we move toward a more > SP-centric Internet, it would be helpful to get these approaches > documented in the IETF. > > 2) The IETF has limited resources to accomplish its work, and it would > be good to not waste resources trying to solve problems we think might > exist, when we could be working on the problems we know exist. > > In the OpSec WG, few enterprise equipment vendors participated. It > might be time to have a discussion of whether the IETF should simply > move to be more SP-centric, especially the IETF management protocols. > If enterprise equipment vendors do not believe it is important for > them to contribute to IETF protocol designs, then enterprise equipment > vendors (and their customers) may need to move toward an SP-centric > approach to utilize emerging/future IETF protocols. > > How do we want to focus our Operations and Management resources? Is > the IETF OPS area still relevant for operating and managing the > Internet? Should we adopt the management standards from other SDOs, or > let the other IETF areas design their own focus-appropriate management > solutions? IMO this tends to work itself out in the end. The people involved in a WG will influence its outcome, and the people not involved in a WG will not influence its outcome. Labels like Enterprise and SP are not that helpful here. Some companies have both kinds of products. > > 3) A manageability considerations BOF. There is already work being > done on manageability considerations guidelines (how to consider > manageability requirements, not a required section in all documents). > There was a lot of discussion about this in the last OPS Area open > meeting as well. This would benefit from achieving consensus from > operators and standards writers, and would probably be a good choice > for an EDU tutorial once consensus is reached. > > Obviously, this would benefit from the discussions of #1 and #2. > More documentation work. It would be useful to both RFC readers and writers, so I couldn't argue against it. I want every WG that creates a protocol to think about how operators and developers are going to securely and efficiently manage the protocol, including configuration. It should not be left as a proprietary component forever. IMO, to advance to Draft Standard, a protocol should meet strict manageability requirements, which would obviously need to be documented in an RFC. > dbh Andy _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Thu Dec 21 09:57:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxPMF-0001WY-JH; Thu, 21 Dec 2006 09:57:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx72Q-0002OD-EK; Wed, 20 Dec 2006 14:23:38 -0500 Received: from smtpproxy2.mitre.org ([192.80.55.71] helo=smtp-mclean.mitre.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gx72L-0000oI-UD; Wed, 20 Dec 2006 14:23:38 -0500 Received: from smtp-mclean.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-mclean.mitre.org (8.12.11.20060308/8.12.11) with SMTP id kBKJNVhs013628; Wed, 20 Dec 2006 14:23:31 -0500 Received: from smtp-mclean.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-mclean.mitre.org (Postfix) with ESMTP id 59D4E1BD82; Wed, 20 Dec 2006 14:23:31 -0500 (EST) Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-mclean.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id kBKJNUkR013610; Wed, 20 Dec 2006 14:23:31 -0500 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 14:23:30 -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 Date: Wed, 20 Dec 2006 14:23:26 -0500 Message-ID: <4915F014FDD99049A9C3A8C1B832004F017732AB@IMCSRV2.MITRE.ORG> In-Reply-To: <45898A91.70305@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] Re: [MIB-DOCTORS] OPS Area BOFs in Prague Thread-Index: Acckav4kHdal9oCGSUqvFbDMNASGOAAALfew From: "Natale, Bob" To: , , , "IESG" X-OriginalArrivalTime: 20 Dec 2006 19:23:30.0673 (UTC) FILETIME=[55225610:01C7246C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 X-Mailman-Approved-At: Thu, 21 Dec 2006 09:57:19 -0500 Cc: aaa-doctors@ietf.org, MIB Doctors , DNS Directorate Subject: [AAA-DOCTORS] RE: [OPS-AREA] Re: [MIB-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 Hi, I strongly agree with Andy's position (from below): "IMO, to advance to Draft Standard, a protocol should meet strict manageability requirements, which would obviously need to be documented in an RFC." Cheers, BobN -----Original Message----- From: Andy Bierman [mailto:ietf@andybierman.com]=20 Sent: Wednesday, December 20, 2006 2:10 PM To: David B Harrington Cc: ops-nm@ietf.org; aaa-doctors@ietf.org; 'MIB Doctors'; 'DNS Directorate'; 'IESG'; nmrg@ibr.cs.tu-bs.de; ops-area@ietf.org Subject: [OPS-AREA] Re: [MIB-DOCTORS] OPS Area BOFs in Prague David B Harrington wrote: > Hi, >=20 > Please respond only to the OPS-area mailing list. >=20 > I would like to raise three potential areas of discussion. These may > be suitable for BOFs or mini-BOFs. >=20 > 1) An OpsNM BOF, designed to lead to a WG similar to the OpSec WG, to > have **operators** document how they actually manage networks today, > and to document what features they utilize in equipment today to > accomplish such management.=20 I think such a documentation project could be a lot of work. If there were enough participation, it would be very useful. >=20 > For example, DavidK mentioned during the last OPSarea open-office > meetings that there are three major approaches to managing service > provider networks (Motorola, ??, ??). I don't think this is documented > anyplace in IETF documents. I don't know if these approaches are > documented elsewhere.=20 >=20 > I don't know what they are, since my background is not SP-oriented, > which is true of many IETF NM people. As we move toward a more > SP-centric Internet, it would be helpful to get these approaches > documented in the IETF. >=20 > 2) The IETF has limited resources to accomplish its work, and it would > be good to not waste resources trying to solve problems we think might > exist, when we could be working on the problems we know exist. >=20 > In the OpSec WG, few enterprise equipment vendors participated. It > might be time to have a discussion of whether the IETF should simply > move to be more SP-centric, especially the IETF management protocols. > If enterprise equipment vendors do not believe it is important for > them to contribute to IETF protocol designs, then enterprise equipment > vendors (and their customers) may need to move toward an SP-centric > approach to utilize emerging/future IETF protocols.=20 >=20 > How do we want to focus our Operations and Management resources? Is > the IETF OPS area still relevant for operating and managing the > Internet? Should we adopt the management standards from other SDOs, or > let the other IETF areas design their own focus-appropriate management > solutions? IMO this tends to work itself out in the end. The people involved in a WG will influence its outcome, and the people not involved in a WG will not influence its outcome. Labels like Enterprise and SP are not that helpful here. Some companies have both kinds of products. >=20 > 3) A manageability considerations BOF. There is already work being > done on manageability considerations guidelines (how to consider > manageability requirements, not a required section in all documents). > There was a lot of discussion about this in the last OPS Area open > meeting as well. This would benefit from achieving consensus from > operators and standards writers, and would probably be a good choice > for an EDU tutorial once consensus is reached. >=20 > Obviously, this would benefit from the discussions of #1 and #2. >=20 More documentation work. It would be useful to both RFC readers and writers, so I couldn't argue against it. I want every WG that creates a protocol to think about how operators and developers are going to securely and efficiently manage the protocol, including configuration. It should not be left as a proprietary component forever. IMO, to advance to Draft Standard, a protocol should meet strict manageability requirements, which would obviously need to be documented in an RFC. > dbh=20 Andy _______________________________________________ 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 Dec 21 09:57:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxPMF-0001Wz-LM; Thu, 21 Dec 2006 09:57:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxNyc-0002G2-4x; Thu, 21 Dec 2006 08:28:50 -0500 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxNyZ-0007HB-DU; Thu, 21 Dec 2006 08:28:50 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.8/8.13.8) with ESMTP id kBLDSkk7171472; Thu, 21 Dec 2006 13:28:46 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kBLDSkPe3141884; Thu, 21 Dec 2006 14:28:46 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kBLDSjHe000499; Thu, 21 Dec 2006 14:28:46 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kBLDSiCA000469; Thu, 21 Dec 2006 14:28:45 +0100 Received: from zurich.ibm.com ([9.4.210.199]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA116486; Thu, 21 Dec 2006 14:28:43 +0100 Message-ID: <458A8C0C.3020805@zurich.ibm.com> Date: Thu, 21 Dec 2006 14:28:44 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: "Romascanu, Dan \(Dan\)" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 X-Mailman-Approved-At: Thu, 21 Dec 2006 09:57:19 -0500 Cc: ops-nm@ietf.org, aaa-doctors@ietf.org, MIB Doctors , DNS Directorate , "Natale, Bob" , IESG , nmrg@ibr.cs.tu-bs.de, ops-area@ietf.org Subject: [AAA-DOCTORS] Re: [OPS-NM] RE: [OPS-AREA] Re: [MIB-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 I think Dan has it right, as far as a practical first step is concerned. It's far from clear that we have IETF consensus for anything stronger than guidance, but guidance is certainly needed. Brian Romascanu, Dan (Dan) wrote: > I am not in the position to disagree :-) > > We need however to start from something. This 'something' is in my > opinion a document to guide IETF authors in writing manageability and > operational requirements in their protocol documents. Today in the > absence of such a reference I encounter huge problems in my role of Area > Director when I come and say 'we cannot approve this new protocol > because it says nothing about how it will be managed or what impact it > will have in the operation of the network'. The typical answers are 'who > says it needs to say something about management and operations?' or > 'what is the reference for what we need to include about manageability > and operations'? > > Dan > > > > > > >>-----Original Message----- >>From: Natale, Bob [mailto:RNATALE@mitre.org] >>Sent: Wednesday, December 20, 2006 9:23 PM >>To: ops-nm@ietf.org; ops-area@ietf.org; nmrg@ibr.cs.tu-bs.de; IESG >>Cc: aaa-doctors@ietf.org; MIB Doctors; DNS Directorate >>Subject: [OPS-NM] RE: [OPS-AREA] Re: [MIB-DOCTORS] OPS Area >>BOFs in Prague >> >> >>Hi, >> >>I strongly agree with Andy's position (from below): >> >>"IMO, to advance to Draft Standard, a protocol should meet >>strict manageability requirements, which would obviously need >>to be documented in an RFC." >> >>Cheers, >>BobN >> >>-----Original Message----- >>From: Andy Bierman [mailto:ietf@andybierman.com] >>Sent: Wednesday, December 20, 2006 2:10 PM >>To: David B Harrington >>Cc: ops-nm@ietf.org; aaa-doctors@ietf.org; 'MIB Doctors'; >>'DNS Directorate'; 'IESG'; nmrg@ibr.cs.tu-bs.de; ops-area@ietf.org >>Subject: [OPS-AREA] Re: [MIB-DOCTORS] OPS Area BOFs in Prague >> >>David B Harrington wrote: >> >>>Hi, >>> >>>Please respond only to the OPS-area mailing list. >>> >>>I would like to raise three potential areas of discussion. >> >>These may >> >>>be suitable for BOFs or mini-BOFs. >>> >>>1) An OpsNM BOF, designed to lead to a WG similar to the >> >>OpSec WG, to >> >>>have **operators** document how they actually manage >> >>networks today, >> >>>and to document what features they utilize in equipment today to >>>accomplish such management. >> >> >>I think such a documentation project could be a lot of work. >>If there were enough participation, it would be very useful. >> >> >> >>>For example, DavidK mentioned during the last OPSarea open-office >>>meetings that there are three major approaches to managing service >>>provider networks (Motorola, ??, ??). I don't think this is >> >>documented >> >>>anyplace in IETF documents. I don't know if these approaches are >>>documented elsewhere. >>> >>>I don't know what they are, since my background is not SP-oriented, >>>which is true of many IETF NM people. As we move toward a more >>>SP-centric Internet, it would be helpful to get these approaches >>>documented in the IETF. >>> >>>2) The IETF has limited resources to accomplish its work, and it >> >>would >> >>>be good to not waste resources trying to solve problems we think >> >>might >> >>>exist, when we could be working on the problems we know exist. >>> >>>In the OpSec WG, few enterprise equipment vendors participated. It >>>might be time to have a discussion of whether the IETF >> >>should simply >> >>>move to be more SP-centric, especially the IETF management >> >>protocols. >> >>>If enterprise equipment vendors do not believe it is important for >>>them to contribute to IETF protocol designs, then enterprise >> >>equipment >> >>>vendors (and their customers) may need to move toward an SP-centric >>>approach to utilize emerging/future IETF protocols. >>> >>>How do we want to focus our Operations and Management resources? Is >>>the IETF OPS area still relevant for operating and managing the >>>Internet? Should we adopt the management standards from other SDOs, >> >>or >> >>>let the other IETF areas design their own focus-appropriate >> >>management >> >>>solutions? >> >> >>IMO this tends to work itself out in the end. >>The people involved in a WG will influence its outcome, and >>the people not involved in a WG will not influence its outcome. >> >>Labels like Enterprise and SP are not that helpful here. >>Some companies have both kinds of products. >> >> >> >>>3) A manageability considerations BOF. There is already work being >>>done on manageability considerations guidelines (how to consider >>>manageability requirements, not a required section in all >> >>documents). >> >>>There was a lot of discussion about this in the last OPS Area open >>>meeting as well. This would benefit from achieving consensus from >>>operators and standards writers, and would probably be a >> >>good choice >> >>>for an EDU tutorial once consensus is reached. >>> >>>Obviously, this would benefit from the discussions of #1 and #2. >>> >> >>More documentation work. It would be useful to both RFC >>readers and writers, so I couldn't argue against it. I want >>every WG that creates a protocol to think about how operators >>and developers are going to securely and efficiently manage >>the protocol, including configuration. It should not be left >>as a proprietary component forever. IMO, to advance to Draft >>Standard, a protocol should meet strict manageability >>requirements, which would obviously need to be documented in an RFC. >> >> >> >>>dbh >> >>Andy >> >>_______________________________________________ >>OPS-AREA mailing list >>OPS-AREA@ietf.org >>https://www1.ietf.org/mailman/listinfo/ops-area >> >>_______________________________________________ >>OPS-NM mailing list >>OPS-NM@ietf.org >>https://www1.ietf.org/mailman/listinfo/ops-nm >> > > > _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Sun Dec 24 06:10:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GyRFa-0004C8-HX; Sun, 24 Dec 2006 06:10:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxQMD-0002eq-Uv for aaa-doctors@ietf.org; Thu, 21 Dec 2006 11:01:21 -0500 Received: from omr8.networksolutionsemail.com ([205.178.146.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxQMB-0004CL-Kp for aaa-doctors@ietf.org; Thu, 21 Dec 2006 11:01:21 -0500 Received: from mail.networksolutionsemail.com (ns-omr8.mgt.netsol.com [10.49.6.71]) by omr8.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id kBLG1HVs012851 for ; Thu, 21 Dec 2006 11:01:18 -0500 Received: (qmail 2994 invoked by uid 78); 21 Dec 2006 16:01:16 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.56.110) by ns-omr8.lb.hosting.dc2.netsol.com with SMTP; 21 Dec 2006 16:01:16 -0000 Message-ID: <458AB03E.9010907@andybierman.com> Date: Thu, 21 Dec 2006 08:03:10 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Brian E Carpenter References: <458A8C0C.3020805@zurich.ibm.com> In-Reply-To: <458A8C0C.3020805@zurich.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Sun, 24 Dec 2006 06:10:41 -0500 Cc: ops-nm@ietf.org, aaa-doctors@ietf.org, MIB Doctors , DNS Directorate , IESG , nmrg@ibr.cs.tu-bs.de, ops-area@ietf.org Subject: [AAA-DOCTORS] Re: [OPS-NM] RE: [OPS-AREA] Re: [MIB-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 Brian E Carpenter wrote: > I think Dan has it right, as far as a practical first step is concerned. > It's far from clear that we have IETF consensus for anything stronger > than guidance, but guidance is certainly needed. > Agreed -- it is just my opinion that Draft Standard should actually stand for something objectively useful. But that is a different thread which has certainly been discussed at length already. > Brian Andy _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors