From ops-area-bounces@ietf.org Fri Jun 01 04:09:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu2CL-000649-M1; Fri, 01 Jun 2007 04:09:25 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1Hu2CK-000644-K7 for ops-area-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 04:09:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu2CH-000632-8h for ops-area@ietf.org; Fri, 01 Jun 2007 04:09:21 -0400 Received: from nj300815-nj-outbound.net.avaya.com ([198.152.12.100] helo=nj300815-nj-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu2CH-0000c6-0o for ops-area@ietf.org; Fri, 01 Jun 2007 04:09:21 -0400 Received: from 12.140.64.135.in-addr.arpa (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-outbound.avaya.com with ESMTP; 01 Jun 2007 04:09:20 -0400 X-IronPort-AV: i="4.16,371,1175486400"; d="scan'208"; a="22378642:sNHT10949700" 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: Fri, 1 Jun 2007 10:09:19 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Internet-Drafts Submission Cutoff Dates for the 69th IETF Meeting in Chicago, IL, USA Thread-Index: AcekAc65BU8l5D4HSKq6VeVtTwAMkgAIlXXg From: "Romascanu, Dan (Dan)" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [OPS-AREA] FW: Internet-Drafts Submission Cutoff Dates for the 69th IETF Meeting in Chicago, IL, USA X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org =20 =20 -----Original Message----- From: ietf-secretariat@ietf.org [mailto:ietf-secretariat@ietf.org]=20 Sent: Friday, June 01, 2007 7:00 AM To: ietf-announce@ietf.org Subject: Internet-Drafts Submission Cutoff Dates for the 69th IETF Meeting in Chicago, IL, USA=20 There are two (2) Internet-Draft cutoff dates for the 69th IETF Meeting in Chicago, IL, USA: July 2nd: Cutoff Date for Initial (i.e., version -00) Internet-Draft Submissions=20 All initial Internet-Drafts (version -00) must be submitted by Monday, July 2nd at 9:00 AM ET. As always, all initial submissions with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. The Secretariat would appreciate receiving WG Chair approval by Monday, June 25th at 9:00 AM ET. July 9th: Cutoff Date for Revised (i.e., version -01 and higher) Internet-Draft Submissions=20 All revised Internet-Drafts (version -01 and higher) must be submitted by Monday, July 9th at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced until on or after Monday, July 23rd at 9:00 AM ET, when Internet-Draft posting resumes. Please do not wait until the last minute to submit. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 69th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_69.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Fri Jun 01 04:26:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu2TA-0000WY-Hk; Fri, 01 Jun 2007 04:26:48 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1Hu2T9-0000WI-FK for ops-area-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 04:26:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu2Sz-0000UE-Ps; Fri, 01 Jun 2007 04:26:37 -0400 Received: from nj300815-nj-outbound.net.avaya.com ([198.152.12.100] helo=nj300815-nj-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu2Sz-0006kO-Dk; Fri, 01 Jun 2007 04:26:37 -0400 Received: from 12.140.64.135.in-addr.arpa (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-outbound.avaya.com with ESMTP; 01 Jun 2007 04:26:36 -0400 X-IronPort-AV: i="4.16,371,1175486400"; d="scan'208"; a="22381610:sNHT9705624" 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: Fri, 1 Jun 2007 10:26:36 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for June 7, 2007 Telechat Thread-Index: Acej3dUV2yNFxNJZRoO4cnLadwAkogASEnEA From: "Romascanu, Dan (Dan)" To: , , "MIB Doctors (E-mail)" , "Aaa-Doctors (E-mail)" X-Spam-Score: 0.1 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: Subject: [OPS-AREA] FW: PRELIMINARY Agenda and Package for June 7, 2007 Telechat X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Please see below the preliminary agenda for the 6/7 IESG Telechat. If there are any questions or concerns, please let me know before Wednesday 6/6 COB. Thanks and Regards, Dan =20 2.1 WG Submissions 2.1.1 New Item o draft-ietf-ips-iscsi-impl-guide-08.txt iSCSI Corrections and Clarifications (Proposed Standard) - 1 of 7=20 Note: Document Shepherd: David Black=20 Token: Lars Eggert o draft-ietf-atompub-protocol-15.txt The Atom Publishing Protocol (Proposed Standard) - 2 of 7=20 Token: Lisa Dusseault o draft-ietf-dhc-dhcpv6-leasequery-00.txt DHCPv6 Leasequery (Proposed Standard) - 3 of 7=20 Note: Document Shepherd is Ralph Droms =20 Token: Jari Arkko o draft-ietf-rohc-sigcomp-sip-06.txt Applying Signaling Compression (SigComp) to the Session Initiation Protocol=20 (SIP) (Proposed Standard) - 4 of 7=20 Token: Magnus Westerlund o draft-ietf-dnsext-nsec3-10.txt DNSSEC Hashed Authenticated Denial of Existence (Proposed Standard) - 5 of=20 7=20 Note: Exiting IETF LC 5/23=20 Token: Mark Townsley o draft-ietf-dhc-dhcpv6-ero-01.txt DHCPv6 Relay Agent Echo Request Option (Proposed Standard) - 6 of 7=20 Note: Document Shepherd is Stig Venaas Token: Jari Arkko o draft-ietf-midcom-rfc3989-bis-00.txt Middlebox Communications (MIDCOM) Protocol Semantics (Proposed Standard) -=20 7 of 7=20 Note: This document is an draft update of the process of taking RFC 3989 to=20 proposed standard. It inherits the state RFC3989 to proposed had.. . The=20 ones that has reviewed it before should just copy their ballot position to=20 this new ballot.=20 Token: Magnus Westerlund 2.1.2 Returning Item o draft-ietf-dnsext-nsid-02.txt DNS Name Server Identifier Option (NSID) (Proposed Standard) - 1 of 1 Token: Mark Townsley 2.2 Individual Submissions 2.2.1 New Item NONE 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-hip-dns-09.txt Host Identity Protocol (HIP) Domain Name System (DNS) Extensions=20 (Experimental) - 1 of 6=20 Token: Mark Townsley o draft-ietf-sipping-dialogusage-06.txt Multiple Dialog Usages in the Session Initiation Protocol (Informational) -=20 2 of 6=20 Token: Jon Peterson o draft-ietf-nemo-multihoming-issues-07.txt Analysis of Multihoming in Network Mobility Support (Informational) - 3 of=20 6=20 Note: Proto shepherd is TJ Kniveton =20 Token: Jari Arkko o draft-ietf-hip-applications-01.txt Using the Host Identity Protocol with Legacy Applications (Experimental) -=20 4 of 6=20 Token: Mark Townsley o draft-ietf-ccamp-gmpls-addressing-07.txt Use of Addresses in Generalized Multi-Protocol Label Switching (GMPLS) =20 Networks (Informational) - 5 of 6=20 Token: Ross Callon o draft-ietf-mip4-fmipv4-07.txt Mobile IPv4 Fast Handovers (Experimental) - 6 of 6=20 Note: Document Shepherd is Pete McCann=20 Token: Jari Arkko 3.1.2 Returning Item o draft-ietf-mip6-dsmip-problem-03.txt Problem Statement: Dual Stack Mobility (Informational) - 1 of 1=20 Note: PROTO shepherd is Basavaraj Patil .=20 NOTE 1: There are significant RFC Editor notes!. NOTE 2: Bringing back to=20 agenda to resolve discusses and get more votes=20 Token: Jari Arkko 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-chakrabarti-ipv6-addrselect-api-06.txt IPv6 Socket API for Address Selection (Informational) - 1 of 1=20 Token: Jari Arkko 3.2.2 Returning Item NONE 3.3 Independent Submissions Via RFC Editor The IESG will use RFC 3932 responses: 1) The IESG has not found any conflict between this document and IETF work; 2) The IESG thinks that this work is related to IETF work done in WG , but this does not prevent publishing; 3) The IESG thinks that publication is harmful to work in WG and recommends not publishing at this time; 4) The IESG thinks that this document violates the IETF procedures for and should therefore not be published without IETF review and IESG approval; 5) The IESG thinks that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. =20 =20 Other matters may be recorded in comments to be passed on to the RFC Editor as community review of the document. 3.3.1 New Item NONE 3.3.2 Returning Item o draft-ooms-xcast-basic-spec-11.txt Explicit Multicast (Xcast) Concepts and Options (Experimental) - 1 of 1=20 Token: Ross Callon 3.3.3 For Action o draft-jurski-pppext-iphc-02.txt Limited IP Header Compression over PPP (Informational) - 1 of 1=20 Token: Russ Housley 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval o Operations and Management Area Working Group (opsawg) - 1 of 2 Token: Dan Romascanu o Basic Level of Interoperability for SIP Services (bliss) - 2 of 2 Token: Cullen Jennings 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review o Mobility for IP: Performance, Signaling and Handoff Optimization (mipshop) - 1 of 1 Token: Jari Arkko 4.2.2 Proposed for Approval NONE _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Mon Jun 04 05:21:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv8kq-0006iP-Mi; Mon, 04 Jun 2007 05:21:36 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1Hv7qM-0001Di-DT for ops-area-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 04:23:14 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1Hv7qL-00018X-QX for ops-area@ietf.org; Mon, 04 Jun 2007 04:23:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv7kC-0000Es-V2 for ops-area@ietf.org; Mon, 04 Jun 2007 04:16:52 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hv7kB-0005Uc-IR for ops-area@ietf.org; Mon, 04 Jun 2007 04:16:52 -0400 Received: from mail1.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id l548Gbtw005642; Mon, 4 Jun 2007 10:16:37 +0200 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id l548GZCX019765; Mon, 4 Jun 2007 10:16:37 +0200 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Jun 2007 10:16:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [OPS-AREA] Two BOF proposals for the Chicago IETF Date: Mon, 4 Jun 2007 10:16:35 +0200 Message-ID: <662C3EB2067DD64FBB2CDA77CD2B1A5601C82429@MCHP7R6A.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [OPS-AREA] Two BOF proposals for the Chicago IETF Thread-Index: AcemgKpsngNdIpOmQtS3xFt8P8nfcQ== From: "Ersue, Mehmet" To: , X-OriginalArrivalTime: 04 Jun 2007 08:16:36.0376 (UTC) FILETIME=[AB53A980:01C7A680] X-Spam-Score: 0.0 (/) X-Scan-Signature: 312bb437839230b5894c6b1686dbca1d X-TMDA-Confirmed: Mon, 04 Jun 2007 04:23:13 -0400 X-Mailman-Approved-At: Mon, 04 Jun 2007 05:21:36 -0400 Cc: X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1285001576==" Errors-To: ops-area-bounces@ietf.org This is a multi-part message in MIME format. --===============1285001576== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A680.AB09EEA2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A680.AB09EEA2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi David, we shouldn't try to handle too many topics in one maillist. Opsarea=20 maillist is already overloaded with different issues and IMO a BOF=20 should have its own maillist to show whether there is sufficient=20 pressure behind it. Mehmet > -----Original Message----- > From: David Harrington [mailto:dharrington@huawei.com]=20 > Sent: Thursday, May 24, 2007 5:31 PM > To: 'Romascanu, Dan (Dan)'; ops-area@ietf.org > Subject: RE: [OPS-AREA] Two BOF proposals for the Chicago IETF >=20 > Hi, >=20 > The XSD for SMIv2 proposal says discussion should occur on the netconf > WG mailing list. I believe that is not the right choice because the > netconf WG is about the netconf protocol, while this proposal is about > translting SMIv2 to XSD. Discussion should happen on the OPS Area > list ops-area@ietf.org. >=20 > Thanks, > dbh >=20 > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 > > Sent: Monday, May 21, 2007 2:45 AM > > To: ops-area@ietf.org > > Subject: [OPS-AREA] Two BOF proposals for the Chicago IETF > >=20 > > Today is the deadline for submitting preliminary requests for BOF > > sessions at the Chicago IETF. Up to now we received two such=20 > > proposals, > > which are listed at http://www3.tools.ietf.org/bof/trac/wiki > >=20 > >=20 > > XSD for accessing SMIv2 data models (xsdmi) BOF=20 > > Status: request submitted including proposed WG charter=20 > > Discussions: NETCONF WG list netconf@ops.ietf.org=20 > > Responsible AD: Dan Romascanu=20 > > BOF Chair: David Harrington (ietfdbh@comcast.net)=20 > > Internet-Drafts:=20 > > draft-romascanu-netconf-datatypes-02 (XSD for SMIv2 Data Types and > > Textual Conventions)=20 > > draft-li-ngo-access-mib-01 (SMIv2 Data Access for NETCONF)=20 > > Summary and Scope: Future WG Formation - The XSDMI WG will=20 > > undertake the > > following work items:=20 > > (A) Development of a standard XML Schema Definition [XSD] to=20 > > specify the > > XML encoding of the core SMIv2 data types defined in RFC2578.=20 > > (B) Development of a standard XML Schema Definition [XSD] to=20 > > specify the > > XML encoding of some generic and common SMIv2 textual conventions, > as > > identified at http://www.ops.ietf.org/mib-common-tcs.html.=20 > > (C) Definition of a standard set of security requirements for=20 > > accessing > > MIB management data by potentially multiple protocols.=20 > > (D) Development of a standard set of algorithms for accessing SMIv2 > > management information, possibly using the NETCONF operation > > and/or data delivery mechanism.=20 > >=20 > >=20 > > Applications Performance Management (APM) BOF=20 > > Status - request submitted=20 > > Discussions - OPS Area list ops-area@ietf.org=20 > > Responsible AD: Dan Romascanu=20 > > BOF Chairs: Alan Clark (alan.d.clark@telchemy.com) and Al Morton > > (acmorton@att.com)=20 > > Internet-Drafts:=20 > > http://www.ietf.org/internet-drafts/draft-malas-performance-me > > trics-06.t > > xt=20 > > http://tools.ietf.org/html/draft-venna-ippm-app-loss-metrics-00=20 > > Summary and Scope: examination of a perceived gap in the=20 > > development of > > performance metrics for application-layer protocols that can=20 > > be used to > > characterize traffic on live networks=20 > > Comparison of Possible Solutions:=20 > > APM Directorate (with working process)=20 > > APM WG (with charter and working process)=20 > >=20 > > These proposals are not yet approved. The IESG and IAB will=20 > > meet on 5/29 > > to discuss them and the final decision will be made by 6/11. I > suggest > > that the authors post the detailed BOF requests and that they are > > discussed on separate threads on this list (ops-area@ietf.org).=20 > >=20 > > Dan > >=20 > >=20 > > _______________________________________________ > > OPS-AREA mailing list > > OPS-AREA@ietf.org > > https://www1.ietf.org/mailman/listinfo/ops-area > >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www1.ietf.org/mailman/listinfo/ops-area >=20 Cheers,=20 Best Regards, Viele Gr=FC=DFe,=20 Mehmet Ersue _____________________________________________________=20 Nokia Siemens Networks=20 > COO RTP IE Internet St.-Martinstrasse 76 81541 Munich Germany Tel: +49 89 636 75193 =20 Fax: +49 89 636 13 75193 Mobile: +49 172 84 323 01 Mailto:Mehmet.Ersue@nsn.com=20 ___________________________________________________________=20 Nokia Siemens Networks GmbH & Co. KG Sitz der Gesellschaft: M=FCnchen / = Registered office: Munich Registergericht: M=FCnchen / Commercial registry: Munich, HRA 88537 = WEEE-Reg.-Nr.: DE 52984304 Pers=F6nlich haftende Gesellschafterin / General Partner: Nokia Siemens = Networks Management GmbH Gesch=E4ftsleitung / Board of Directors: Joachim Malterer, Lydia Sommer = Sitz der Gesellschaft: M=FCnchen /=20 Registered office: Munich Registergericht: M=FCnchen / Commercial = registry: Munich, HRB 163416 ------_=_NextPart_001_01C7A680.AB09EEA2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [OPS-AREA] Two BOF proposals for the Chicago IETF

Hi = David,

we shouldn't try to = handle too many topics in one maillist. Opsarea
maillist is = already overloaded with different issues and IMO a BOF
should have its = own maillist to show whether there is sufficient
pressure behind = it.

Mehmet


> -----Original = Message-----
> From: David = Harrington [mailto:dharrington@huawei.com]
> Sent: = Thursday, May 24, 2007 5:31 PM
> To: = 'Romascanu, Dan (Dan)'; ops-area@ietf.org
> Subject: RE: = [OPS-AREA] Two BOF proposals for the Chicago IETF
> =
> = Hi,
> =
> The XSD for = SMIv2 proposal says discussion should occur on the netconf
> WG mailing = list. I believe that is not the right choice because the
> netconf WG is = about the netconf protocol, while this proposal is about
> translting = SMIv2 to XSD.  Discussion should happen on the OPS = Area
> list = ops-area@ietf.org.
> =
> = Thanks,
> = dbh
> =
> > = -----Original Message-----
> > From: = Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
> > Sent: = Monday, May 21, 2007 2:45 AM
> > To: = ops-area@ietf.org
> > Subject: = [OPS-AREA] Two BOF proposals for the Chicago IETF
> > =
> > Today is = the deadline for submitting preliminary requests for BOF
> > sessions = at the Chicago IETF. Up to now we received two such
> > = proposals,
> > which = are listed at http://www3.tools.ietf.org/bof/trac/wiki
> > =
> > =
> > XSD for = accessing SMIv2 data models (xsdmi) BOF
> > Status: = request submitted including proposed WG charter
> > = Discussions: NETCONF WG list netconf@ops.ietf.org
> > = Responsible AD: Dan Romascanu
> > BOF = Chair: David Harrington (ietfdbh@comcast.net)
> > = Internet-Drafts:
> > = draft-romascanu-netconf-datatypes-02 (XSD for SMIv2 Data Types = and
> > Textual = Conventions)
> > = draft-li-ngo-access-mib-01 (SMIv2 Data Access for NETCONF) =
> > Summary = and Scope: Future WG Formation - The XSDMI WG will
> > = undertake the
> > = following work items:
> > (A) = Development of a standard XML Schema Definition [XSD] to
> > specify = the
> > XML = encoding of the core SMIv2 data types defined in RFC2578.
> > (B) = Development of a standard XML Schema Definition [XSD] to
> > specify = the
> > XML = encoding of some generic and common SMIv2 textual = conventions,
> = as
> > = identified at http://www.ops.ietf.org/mib-common-tcs.html. =
> > (C) = Definition of a standard set of security requirements for
> > = accessing
> > MIB = management data by potentially multiple protocols.
> > (D) = Development of a standard set of algorithms for accessing = SMIv2
> > = management information, possibly using the NETCONF <get> = operation
> > and/or = <notification> data delivery mechanism.
> > =
> > =
> > = Applications Performance Management (APM) BOF
> > Status - = request submitted
> > = Discussions - OPS Area list ops-area@ietf.org
> > = Responsible AD: Dan Romascanu
> > BOF = Chairs: Alan Clark (alan.d.clark@telchemy.com) and Al = Morton
> > = (acmorton@att.com)
> > = Internet-Drafts:
> > = <= SPAN LANG=3D"de">http://www.ietf.org/internet-drafts/draft-malas-performa= nce-me
> > = trics-06.t
> > xt =
> > = = http://tools.ietf.org/html/draft-venna-ippm-app-loss-met= rics-00
> > Summary = and Scope: examination of a perceived gap in the
> > = development of
> > = performance metrics for application-layer protocols that can =
> > be used = to
> > = characterize traffic on live networks
> > = Comparison of Possible Solutions:
> > APM = Directorate (with working process)
> > APM WG = (with charter and working process)
> > =
> > These = proposals are not yet approved. The IESG and IAB will
> > meet on = 5/29
> > to = discuss them and the final decision will be made by 6/11. = I
> = suggest
> > that the = authors post the detailed BOF requests and that they are
> > = discussed on separate threads on this list (ops-area@ietf.org). =
> > =
> > = Dan
> > =
> > =
> > = _______________________________________________
> > OPS-AREA = mailing list
> > = OPS-AREA@ietf.org
> > = https://www1.ietf.org/mailman/listinfo/ops-area
> > =
> =
> =
> =
> =
> = _______________________________________________
> OPS-AREA = mailing list
> = OPS-AREA@ietf.org
> = https://www1.ietf.org/mailman/listinfo/ops-area
> =
Cheers,
Best Regards,
Viele Gr=FC=DFe,
Mehmet Ersue
_____________________________________________________

Nokia Siemens Networks
COO RTP IE Internet
St.-Martinstrasse 76
81541 Munich
Germany

Tel:       +49 89 636 = 75193 
Fax:      +49 89 636 13 = 75193
Mobile: +49 172 84 323 01
Mailto:Mehmet.Ersue@nsn.com<= SPAN LANG=3D"de"> =
___________________________________________________________
Nokia Siemens = Networks GmbH & Co. KG Sitz der Gesellschaft: M=FCnchen / Registered = office: Munich
Registergericht: M=FCnchen / Commercial registry: Munich, HRA 88537 = WEEE-Reg.-Nr.: DE 52984304
Pers=F6nlich haftende Gesellschafterin / General Partner: Nokia Siemens = Networks Management GmbH
Gesch=E4ftsleitung / Board of Directors: Joachim Malterer, Lydia Sommer = Sitz der Gesellschaft: M=FCnchen /
Registered office: Munich Registergericht: M=FCnchen / Commercial = registry: Munich, HRB 163416

------_=_NextPart_001_01C7A680.AB09EEA2-- --===============1285001576== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area --===============1285001576==-- From ops-area-bounces@ietf.org Mon Jun 04 12:13:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvFBH-0006PE-22; Mon, 04 Jun 2007 12:13:19 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1HvFBE-0006Mx-BZ for ops-area-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 12:13:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvFBD-0006ME-MM for ops-area@ietf.org; Mon, 04 Jun 2007 12:13:15 -0400 Received: from smtp102.sbc.mail.mud.yahoo.com ([68.142.198.201]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvFBA-00066b-6f for ops-area@ietf.org; Mon, 04 Jun 2007 12:13:15 -0400 Received: (qmail 16696 invoked from network); 4 Jun 2007 16:13:11 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.195.156.84 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 4 Jun 2007 16:13:11 -0000 X-YMail-OSG: DXPweWwVM1kdQH8pMUuzFp.ylI2YjrjoP8jQyGGaRLGiiikc2TsS6OUGnCgFUZBJoGzMqjaPZ.waQRlEkMe6DqOe5Q-- Message-ID: <466439E2.1020401@andybierman.com> Date: Mon, 04 Jun 2007 09:12:18 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Ersue, Mehmet" Subject: Re: [OPS-AREA] Two BOF proposals for the Chicago IETF References: <662C3EB2067DD64FBB2CDA77CD2B1A5601C82429@MCHP7R6A.ww002.siemens.net> In-Reply-To: <662C3EB2067DD64FBB2CDA77CD2B1A5601C82429@MCHP7R6A.ww002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: dharrington@huawei.com, ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Ersue, Mehmet wrote: > > Hi David, > > we shouldn't try to handle too many topics in one maillist. Opsarea > maillist is already overloaded with different issues and IMO a BOF > should have its own maillist to show whether there is sufficient > pressure behind it. > Actually, I agree with you and David. I would be happy with the discussion on ops-area, but maybe ops-nm would be better. As long as I don't have to subscribe to another mailing list! > Mehmet Andy > > >> -----Original Message----- >> From: David Harrington [_mailto:dharrington@huawei.com_] >> Sent: Thursday, May 24, 2007 5:31 PM >> To: 'Romascanu, Dan (Dan)'; ops-area@ietf.org >> Subject: RE: [OPS-AREA] Two BOF proposals for the Chicago IETF >> >> Hi, >> >> The XSD for SMIv2 proposal says discussion should occur on the netconf >> WG mailing list. I believe that is not the right choice because the >> netconf WG is about the netconf protocol, while this proposal is about >> translting SMIv2 to XSD. Discussion should happen on the OPS Area >> list ops-area@ietf.org. >> >> Thanks, >> dbh >> >> > -----Original Message----- >> > From: Romascanu, Dan (Dan) [_mailto:dromasca@avaya.com_] >> > Sent: Monday, May 21, 2007 2:45 AM >> > To: ops-area@ietf.org >> > Subject: [OPS-AREA] Two BOF proposals for the Chicago IETF >> > >> > Today is the deadline for submitting preliminary requests for BOF >> > sessions at the Chicago IETF. Up to now we received two such >> > proposals, >> > which are listed at _http://www3.tools.ietf.org/bof/trac/wiki_ >> > >> > >> > XSD for accessing SMIv2 data models (xsdmi) BOF >> > Status: request submitted including proposed WG charter >> > Discussions: NETCONF WG list netconf@ops.ietf.org >> > Responsible AD: Dan Romascanu >> > BOF Chair: David Harrington (ietfdbh@comcast.net) >> > Internet-Drafts: >> > draft-romascanu-netconf-datatypes-02 (XSD for SMIv2 Data Types and >> > Textual Conventions) >> > draft-li-ngo-access-mib-01 (SMIv2 Data Access for NETCONF) >> > Summary and Scope: Future WG Formation - The XSDMI WG will >> > undertake the >> > following work items: >> > (A) Development of a standard XML Schema Definition [XSD] to >> > specify the >> > XML encoding of the core SMIv2 data types defined in RFC2578. >> > (B) Development of a standard XML Schema Definition [XSD] to >> > specify the >> > XML encoding of some generic and common SMIv2 textual conventions, >> as >> > identified at _http://www.ops.ietf.org/mib-common-tcs.html_. >> > (C) Definition of a standard set of security requirements for >> > accessing >> > MIB management data by potentially multiple protocols. >> > (D) Development of a standard set of algorithms for accessing SMIv2 >> > management information, possibly using the NETCONF operation >> > and/or data delivery mechanism. >> > >> > >> > Applications Performance Management (APM) BOF >> > Status - request submitted >> > Discussions - OPS Area list ops-area@ietf.org >> > Responsible AD: Dan Romascanu >> > BOF Chairs: Alan Clark (alan.d.clark@telchemy.com) and Al Morton >> > (acmorton@att.com) >> > Internet-Drafts: >> > _http://www.ietf.org/internet-drafts/draft-malas-performance-me_ >> > trics-06.t >> > xt >> > _http://tools.ietf.org/html/draft-venna-ippm-app-loss-metrics-00_ >> > Summary and Scope: examination of a perceived gap in the >> > development of >> > performance metrics for application-layer protocols that can >> > be used to >> > characterize traffic on live networks >> > Comparison of Possible Solutions: >> > APM Directorate (with working process) >> > APM WG (with charter and working process) >> > >> > These proposals are not yet approved. The IESG and IAB will >> > meet on 5/29 >> > to discuss them and the final decision will be made by 6/11. I >> suggest >> > that the authors post the detailed BOF requests and that they are >> > discussed on separate threads on this list (ops-area@ietf.org). >> > >> > Dan >> > >> > >> > _______________________________________________ >> > OPS-AREA mailing list >> > OPS-AREA@ietf.org >> > _https://www1.ietf.org/mailman/listinfo/ops-area_ >> > >> >> >> >> >> _______________________________________________ >> OPS-AREA mailing list >> OPS-AREA@ietf.org >> _https://www1.ietf.org/mailman/listinfo/ops-area_ >> > Cheers, > Best Regards, > Viele Grüße, > Mehmet Ersue > _____________________________________________________ > > *Nokia Siemens Networks * > *COO RTP IE Internet* > *St.-Martinstrasse 76* > *81541 Munich* > *Germany* > > */Tel: +49 89 636 75193 /* > */Fax: +49 89 636 13 75193 > Mobile: +49 172 84 323 01 > /**/___Mailto:Mehmet.Ersue@nsn.com_/**/ /* > ___________________________________________________________ > Nokia Siemens Networks GmbH & Co. KG Sitz der Gesellschaft: München / > Registered office: Munich > Registergericht: München / Commercial registry: Munich, HRA 88537 > WEEE-Reg.-Nr.: DE 52984304 > Persönlich haftende Gesellschafterin / General Partner: Nokia Siemens > Networks Management GmbH > Geschäftsleitung / Board of Directors: Joachim Malterer, Lydia Sommer > Sitz der Gesellschaft: München / > Registered office: Munich Registergericht: München / Commercial > registry: Munich, HRB 163416 > > > ------------------------------------------------------------------------ > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www1.ietf.org/mailman/listinfo/ops-area _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Mon Jun 04 15:07:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvHtN-0001un-2X; Mon, 04 Jun 2007 15:07:01 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1HvHtL-0001uh-Rz for ops-area-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 15:06:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvHtL-0001uZ-IR for ops-area@ietf.org; Mon, 04 Jun 2007 15:06:59 -0400 Received: from smtpproxy1.mitre.org ([192.160.51.76] helo=smtp-bedford.mitre.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvHtJ-0005PU-Nd for ops-area@ietf.org; Mon, 04 Jun 2007 15:06:59 -0400 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 l54J6uvn011645 for ; Mon, 4 Jun 2007 15:06:56 -0400 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 6F7E7BF7B for ; Mon, 4 Jun 2007 15:06:56 -0400 (EDT) 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 l54J6ogW011440 for ; Mon, 4 Jun 2007 15:06:56 -0400 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Jun 2007 15:06:50 -0400 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] Two BOF proposals for the Chicago IETF Date: Mon, 4 Jun 2007 15:06:49 -0400 Message-ID: <4915F014FDD99049A9C3A8C1B832004F01DFAF66@IMCSRV2.MITRE.ORG> In-Reply-To: <000801c79e18$8a2d0b40$290c7c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] Two BOF proposals for the Chicago IETF Thread-Index: Acebc5FmFdAIEWAHSpmZLwdh0TPFswAN8ijAAsv9i+A= References: <000801c79e18$8a2d0b40$290c7c0a@china.huawei.com> From: "Natale, Bob" To: X-OriginalArrivalTime: 04 Jun 2007 19:06:50.0795 (UTC) FILETIME=[81BB8FB0:01C7A6DB] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Hi, Does "draft-li-ngo-access-mib-01" exist?...I only see the "-00" version via an IETF I-D search. Thanks, BobN -----Original Message----- From: David Harrington [mailto:dharrington@huawei.com]=20 Sent: Thursday, May 24, 2007 11:31 AM To: 'Romascanu, Dan (Dan)'; ops-area@ietf.org Subject: RE: [OPS-AREA] Two BOF proposals for the Chicago IETF Hi, The XSD for SMIv2 proposal says discussion should occur on the netconf WG mailing list. I believe that is not the right choice because the netconf WG is about the netconf protocol, while this proposal is about translting SMIv2 to XSD. Discussion should happen on the OPS Area list ops-area@ietf.org. Thanks, dbh > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 > Sent: Monday, May 21, 2007 2:45 AM > To: ops-area@ietf.org > Subject: [OPS-AREA] Two BOF proposals for the Chicago IETF >=20 > Today is the deadline for submitting preliminary requests for BOF > sessions at the Chicago IETF. Up to now we received two such=20 > proposals, > which are listed at http://www3.tools.ietf.org/bof/trac/wiki >=20 >=20 > XSD for accessing SMIv2 data models (xsdmi) BOF=20 > Status: request submitted including proposed WG charter=20 > Discussions: NETCONF WG list netconf@ops.ietf.org=20 > Responsible AD: Dan Romascanu=20 > BOF Chair: David Harrington (ietfdbh@comcast.net)=20 > Internet-Drafts:=20 > draft-romascanu-netconf-datatypes-02 (XSD for SMIv2 Data Types and > Textual Conventions)=20 > draft-li-ngo-access-mib-01 (SMIv2 Data Access for NETCONF)=20 > Summary and Scope: Future WG Formation - The XSDMI WG will=20 > undertake the > following work items:=20 > (A) Development of a standard XML Schema Definition [XSD] to=20 > specify the > XML encoding of the core SMIv2 data types defined in RFC2578.=20 > (B) Development of a standard XML Schema Definition [XSD] to=20 > specify the > XML encoding of some generic and common SMIv2 textual conventions, as > identified at http://www.ops.ietf.org/mib-common-tcs.html.=20 > (C) Definition of a standard set of security requirements for=20 > accessing > MIB management data by potentially multiple protocols.=20 > (D) Development of a standard set of algorithms for accessing SMIv2 > management information, possibly using the NETCONF operation > and/or data delivery mechanism.=20 >=20 >=20 > Applications Performance Management (APM) BOF=20 > Status - request submitted=20 > Discussions - OPS Area list ops-area@ietf.org=20 > Responsible AD: Dan Romascanu=20 > BOF Chairs: Alan Clark (alan.d.clark@telchemy.com) and Al Morton > (acmorton@att.com)=20 > Internet-Drafts:=20 > http://www.ietf.org/internet-drafts/draft-malas-performance-me > trics-06.t > xt=20 > http://tools.ietf.org/html/draft-venna-ippm-app-loss-metrics-00=20 > Summary and Scope: examination of a perceived gap in the=20 > development of > performance metrics for application-layer protocols that can=20 > be used to > characterize traffic on live networks=20 > Comparison of Possible Solutions:=20 > APM Directorate (with working process)=20 > APM WG (with charter and working process)=20 >=20 > These proposals are not yet approved. The IESG and IAB will=20 > meet on 5/29 > to discuss them and the final decision will be made by 6/11. I suggest > that the authors post the detailed BOF requests and that they are > discussed on separate threads on this list (ops-area@ietf.org).=20 >=20 > Dan >=20 >=20 > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www1.ietf.org/mailman/listinfo/ops-area >=20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Mon Jun 04 17:35:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvKD1-0008H1-PJ; Mon, 04 Jun 2007 17:35:27 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1HvKD0-0008AM-M3 for ops-area-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 17:35:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvKCz-00089I-Ll for ops-area@ietf.org; Mon, 04 Jun 2007 17:35:26 -0400 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvKCz-0003qW-BQ for ops-area@ietf.org; Mon, 04 Jun 2007 17:35:25 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc13) with SMTP id <2007060421352401300ivifge>; Mon, 4 Jun 2007 21:35:24 +0000 From: "David Harrington" To: "'Natale, Bob'" , References: <000801c79e18$8a2d0b40$290c7c0a@china.huawei.com> <4915F014FDD99049A9C3A8C1B832004F01DFAF66@IMCSRV2.MITRE.ORG> Subject: RE: [OPS-AREA] Two BOF proposals for the Chicago IETF Date: Mon, 4 Jun 2007 17:35:12 -0400 Message-ID: <023f01c7a6f0$3bfff320$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 In-Reply-To: <4915F014FDD99049A9C3A8C1B832004F01DFAF66@IMCSRV2.MITRE.ORG> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acebc5FmFdAIEWAHSpmZLwdh0TPFswAN8ijAAsv9i+AABR95gA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Hi Bob, Whoops. My mistake. There is an -01- but -00- should be used for the BOF, unless we get a revision out. It's rough, but we need to answer some questions (C) before (D) can be done properly. Thanks, dbh > -----Original Message----- > From: Natale, Bob [mailto:RNATALE@mitre.org] > Sent: Monday, June 04, 2007 3:07 PM > To: ops-area@ietf.org > Subject: RE: [OPS-AREA] Two BOF proposals for the Chicago IETF > > Hi, > > Does "draft-li-ngo-access-mib-01" exist?...I only see the > "-00" version > via an IETF I-D search. > > Thanks, > BobN > > -----Original Message----- > From: David Harrington [mailto:dharrington@huawei.com] > Sent: Thursday, May 24, 2007 11:31 AM > To: 'Romascanu, Dan (Dan)'; ops-area@ietf.org > Subject: RE: [OPS-AREA] Two BOF proposals for the Chicago IETF > > Hi, > > The XSD for SMIv2 proposal says discussion should occur on the netconf > WG mailing list. I believe that is not the right choice because the > netconf WG is about the netconf protocol, while this proposal is about > translting SMIv2 to XSD. Discussion should happen on the OPS Area > list ops-area@ietf.org. > > Thanks, > dbh > > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: Monday, May 21, 2007 2:45 AM > > To: ops-area@ietf.org > > Subject: [OPS-AREA] Two BOF proposals for the Chicago IETF > > > > Today is the deadline for submitting preliminary requests for BOF > > sessions at the Chicago IETF. Up to now we received two such > > proposals, > > which are listed at http://www3.tools.ietf.org/bof/trac/wiki > > > > > > XSD for accessing SMIv2 data models (xsdmi) BOF > > Status: request submitted including proposed WG charter > > Discussions: NETCONF WG list netconf@ops.ietf.org > > Responsible AD: Dan Romascanu > > BOF Chair: David Harrington (ietfdbh@comcast.net) > > Internet-Drafts: > > draft-romascanu-netconf-datatypes-02 (XSD for SMIv2 Data Types and > > Textual Conventions) > > draft-li-ngo-access-mib-01 (SMIv2 Data Access for NETCONF) > > Summary and Scope: Future WG Formation - The XSDMI WG will > > undertake the > > following work items: > > (A) Development of a standard XML Schema Definition [XSD] to > > specify the > > XML encoding of the core SMIv2 data types defined in RFC2578. > > (B) Development of a standard XML Schema Definition [XSD] to > > specify the > > XML encoding of some generic and common SMIv2 textual conventions, > as > > identified at http://www.ops.ietf.org/mib-common-tcs.html. > > (C) Definition of a standard set of security requirements for > > accessing > > MIB management data by potentially multiple protocols. > > (D) Development of a standard set of algorithms for accessing SMIv2 > > management information, possibly using the NETCONF operation > > and/or data delivery mechanism. > > > > > > Applications Performance Management (APM) BOF > > Status - request submitted > > Discussions - OPS Area list ops-area@ietf.org > > Responsible AD: Dan Romascanu > > BOF Chairs: Alan Clark (alan.d.clark@telchemy.com) and Al Morton > > (acmorton@att.com) > > Internet-Drafts: > > http://www.ietf.org/internet-drafts/draft-malas-performance-me > > trics-06.t > > xt > > http://tools.ietf.org/html/draft-venna-ippm-app-loss-metrics-00 > > Summary and Scope: examination of a perceived gap in the > > development of > > performance metrics for application-layer protocols that can > > be used to > > characterize traffic on live networks > > Comparison of Possible Solutions: > > APM Directorate (with working process) > > APM WG (with charter and working process) > > > > These proposals are not yet approved. The IESG and IAB will > > meet on 5/29 > > to discuss them and the final decision will be made by 6/11. I > suggest > > that the authors post the detailed BOF requests and that they are > > discussed on separate threads on this list (ops-area@ietf.org). > > > > Dan > > > > > > _______________________________________________ > > OPS-AREA mailing list > > OPS-AREA@ietf.org > > https://www1.ietf.org/mailman/listinfo/ops-area > > > > > > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www1.ietf.org/mailman/listinfo/ops-area > > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www1.ietf.org/mailman/listinfo/ops-area > _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Tue Jun 05 15:50:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvf2T-0006wq-GO; Tue, 05 Jun 2007 15:49:57 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1Hvf2S-0006wa-Ji for ops-area-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 15:49:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvf2R-0006wH-VI; Tue, 05 Jun 2007 15:49:55 -0400 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvf2R-0002WC-Hc; Tue, 05 Jun 2007 15:49:55 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc14) with SMTP id <2007060519495501400deje2e>; Tue, 5 Jun 2007 19:49:55 +0000 From: "David Harrington" To: "'Andy Bierman'" , "'Ops-Nm'" References: <4664489B.1000406@andybierman.com> Date: Tue, 5 Jun 2007 15:49:46 -0400 Message-ID: <02c901c7a7aa$ab924fc0$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 In-Reply-To: <4664489B.1000406@andybierman.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcemzA59oB5ulVZRR7W5+F6lyv4NKQAzMFkA X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Cc: ops-area@ietf.org Subject: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF proposal X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Hi, comments inline (I am cross-posting to the ops-area mailing list because no official decision was made to relocate discussion for XSDMI to the ops-nm list. I will ask Dan to change the BOF page to direct discussion to the ops-nm list. Interested parties please find XSDMI discussion on the ops-nm list.) dbh > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com] > Sent: Monday, June 04, 2007 1:15 PM > To: Ops-Nm > Subject: [OPS-NM] Comments on XSDMI BoF proposal > > General: > > I strongly support the formation of this WG, and think > it should be the "only next step" in NETCONF Data Modeling > standards development. > Trying to standardize too much at once without enough implementation > experience is not going to help. The most critical DM need is to > figure out how to use the standard NM data definitions we > already have. My intention is to develop a way to access MIB data via XML-based NM protocols, to take advantage of the existing NM data definitions in the MIB. This is a migration strategy to move from a mainly-SNMP-and-MIB management framework to a multi-protocol-and-multi-data-model management framework. I do not think MIB access is enough. A binary data-based approach like the MIB is fine for automated management, but it is not good for operator-interactive management, and it fails to take advantage of advances in computer networking technology like WWW technologies. For operator-interactice NM, I think we need task-based NM interfaces. The CLI is one approach, and standardizing it would probably be helpful, but the engineering departments of vendors are not very cooperative on doing that; it is easier for engineers to use freeform text when developing CLIs and syslog-style reporting than to use standardized content. XML-based management leverages lessons learned from the WWW. While document-based rather than command-based, tasks can often be grouped into a document-type interface, such as a web page. With automated translation from XML into HTML (and related technologies), we can work on developing task-based-document NM interfaces. I think we need to spend more time thinking about operator use-cases, not just technical designs of SMIs. I think it would help to start thinking in terms of modular data models similar to MIB modules, not just a config, but we need to develop an SMI that helps to differentiate config and state info, which SMIv2 doesn't do, Maybe all we need to do is recommend that MIB modules have separate subtrees for config and for state, much as we now recommend separate subtrees for objects and notifications. While I would like to see the reuse of existing standards, such as XSD, we need to support programmatic interfaces to allow (incremental) automation of repetitive tasks. That means we need to provide machine-readable "clues" about the meta-nature of management information. Maybe that can be done in XML using attributes, or namespaces, or hierarchical organization. Maybe it will require a new SMI with all the special fields found in SMIv2 - and more. I think one of the big questions we need to address is whether a new SMI should be developed that is an extension/superset of SMIv2, or is distinct from SMIv2. I think that work involves getting operator feedback of how they work, so we can understand whether we should be trying to merge the existing NM protocols, or should keep them (and their data) distinct. I think we should be considering how to componentize existing standards work, so we can reuse some parts, such as secure transport, while keeping other parts distinct. That work can advance while we work on developing support for one or more XML-based interfaces to SMIv2 data models, as a migratory step toward multi-protocol management. > > Nit: The WG acronym is kind of cryptic and I'm not sure what > it supposed to mean. Also, the WG name only describes work items > (A) and (B). Security requirements for multi-protocol access > to MIB data is definitely not covered by the title, and (D) > is 'possibly' NETCONF protocol-specific. (?? XSMI ?? SMIX ?? > SMINET ??) I deliberately avoided the use of SMI. As somebody pointed out (you?), this work (A and B) is not developing a new SMI, it is merely translating elements of SMIv2 from one language to another. > > Milestones: Any idea how long you think it will take to do > all this work? > > Work items: > > (A)(B) > The XSD for SMIv2 data types and TCs draft has been reviewed > and refined > over > a couple years, and it is very much needed, and ready, for > standardization. Yan will be publishing a base datatype translation document, based on libsmi translations. Since this has been defined and used(?) fo ryears, I expect this should be fast - in IETF terms, we can probably finish in seven or eight years ;-). Seriously, I hope this can be done in six months or so, if there is enough interest to work on it. That will be supplemented by the (romascanu) TC translations document. We need to decide whether XSD can express the restrictions adequately to support machine-validation, and whether the amount of machine-validation supported justifies having an XSD for the TC. Having TC translations might be helpful for netconf to go read existng MIB data, without having to also parse SMIv2 MIB documents to understand what the values mean. I think the bigger benefit is defining TCs that can be used by multiple protocols to support consistent semantics across protocols, and XML is the preferred language for most new protocols. This will require case-by-case analysis, and might take time to reach consensus. Of course, not every contentious TC must be included in this document, so if we cut out the contentious ones, this should be able to be wrapped up within a year, I hope. > > (C) > This work item is a bit vague. I'm not sure if it means > a mapping between an SNMP EngineID to a NETCONF session identity, > or something to do with VACM, or something else undefined. > I think it is a smart idea to understand all the security issues > associated with (D). I'm looking at the bigger picture of multi-protocol management. There are lots of protocols being developed, both inside and outside IETF, to perform management functionality. As Bob Natale pointed out, the MIB is the "crown jewel" of IETF Management (I think SNMP is as well, when used for what it is good at). I think lots of WGs and lots of other SDOs are going to look at the MIB and say "gee, we should leverage that!" I think we need to set some guidelines about how protocols should deal with the MIB, so that it is not ruined by unconstrained access by multiple protocols, especially write access. But even read-access can be problematic. Security is a process, not a product. The IETF needs to decide how to "balance" security in an environment of multi-protocol management. It makes no sense to protect your house with a front door that has multiple deadbolt locks, if your back door has no locks. It makes no sense to expect operators to go to the trouble of configuring VACM to protect the data in the MIB when using SNMP, if the operator's VACM configuration will just be ignored by netconf and other protocols accessing the MIB. I think we need some guidelines that provide for a more consistent approach to multi-protocol MIB access, than VACM-for-SNMP and nothing-for-others. Personally, I would like to see VACM not be mandatory-to-implement for SNMP, if there is no corresponding mandatory-to-implement access control for other protocols. I don't think the operator community is actually ready for standardized cross-protocol access control, and if it isn't balanced across protocols, then we shouldn't require any NM protocol standards to have a mandatory-to-implement access control model. > > (D) > I support a standard algorithmic translation between SMIv2 conceptual > data models and NETCONF configuration databases, which includes > data organization and standard protocol operation mappings. > I think read-only access instead of full access will be easier > to achieve, so it should be done first. The use case for > write access is not as strong, and the multi-protocol access and > security issues are harder. I agree that read-only access would probably be sufficient for netconf to gather state information, statistical information, and notifications. I do not see a lot of reason to support write access to the MIB via netconf. > > I do not support a generic XSD representation of SMIv2 macros, > without consideration of the specific XML-based protocol being used. > The 'embedded' SNMP protocol operations in SMIv2, as well as > the explicit > SNMP operations discussed in MIB object DESCRIPTION clauses, > RowPointer, > RowStatus, StorageType, etc., all have to be explicitly mapped to the > specific NETCONF (or whatever) protocol operations and > architecture assumptions. I think these need to be supported to understand the values of certain fields that might be read from the MIB. RowStatus reflects the operational state of the row, and if netconf is accessing the MIB to determine operational state of the thing represented by that row, it is an important piece of information. But if netconf has no write capability to the MIB, it does not need to know how to manipulate the values. StorageType is also state information about a row that might be important for a netconf client to understand; it might be helpful to know that the MIB representation (or the underlying instrumentation) is in ROM. But if it has no write capability, it does not need to know how to manipulate the row within the constraints of StorageType. The MIB is more or less a relational database, where the relations between rows is important information. If netconf reads a row that has a relationship to another row via a RowPointer, netconf better know how to interpret a RowPointer. (It is important to understand that I make no assumptions that a netconf-client will have a direct connection to an SNMP manager that knows how to parse this information from an SMIv2 MIB module document.) I think we need to walk through these TCs on a case-by-case basis to decide whether we need each one for use with netconf, and what XSD restrictions apply. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Jun 06 11:56:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvxs7-0007zR-EM; Wed, 06 Jun 2007 11:56:31 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1Hvxs5-0007z6-CW for ops-area-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 11:56:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvxs5-0007yq-15 for ops-area@ietf.org; Wed, 06 Jun 2007 11:56:29 -0400 Received: from smtp104.sbc.mail.re2.yahoo.com ([68.142.229.101]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hvxs2-0006Tv-9y for ops-area@ietf.org; Wed, 06 Jun 2007 11:56:29 -0400 Received: (qmail 28698 invoked from network); 6 Jun 2007 15:55:57 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.195.156.84 with plain) by smtp104.sbc.mail.re2.yahoo.com with SMTP; 6 Jun 2007 15:55:56 -0000 X-YMail-OSG: taIO1uYVM1kyEkHeRNItWzjSdzPhysHWgLBOvBK1wav6tvO7 Message-ID: <4666D8D7.80807@andybierman.com> Date: Wed, 06 Jun 2007 08:55:03 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: David Harrington References: <4664489B.1000406@andybierman.com> <02c901c7a7aa$ab924fc0$0600a8c0@china.huawei.com> In-Reply-To: <02c901c7a7aa$ab924fc0$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb Cc: 'Ops-Nm' , ops-area@ietf.org Subject: [OPS-AREA] Re: [OPS-NM] Comments on XSDMI BoF proposal X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org David Harrington wrote: > Hi, > > comments inline > ditto > (I am cross-posting to the ops-area mailing list because no official > decision was made to relocate discussion for XSDMI to the ops-nm list. > I will ask Dan to change the BOF page to direct discussion to the > ops-nm list. Interested parties please find XSDMI discussion on the > ops-nm list.) > > dbh > >> -----Original Message----- >> From: Andy Bierman [mailto:ietf@andybierman.com] >> Sent: Monday, June 04, 2007 1:15 PM >> To: Ops-Nm >> Subject: [OPS-NM] Comments on XSDMI BoF proposal >> >> General: >> >> I strongly support the formation of this WG, and think >> it should be the "only next step" in NETCONF Data Modeling >> standards development. > >> Trying to standardize too much at once without enough implementation >> experience is not going to help. The most critical DM need is to >> figure out how to use the standard NM data definitions we >> already have. > > My intention is to develop a way to access MIB data via XML-based NM > protocols, > to take advantage of the existing NM data definitions in the MIB. > This is fine, but it should be based on use cases, as you say later on. IMO, there is a use case to read MIB data via a NETCONF session. The goal can be abstract, but the solutions has to be specific, in order to have an inter-operable standard. > This is a migration strategy to move from a mainly-SNMP-and-MIB > management framework to a multi-protocol-and-multi-data-model > management framework. > > I do not think MIB access is enough. A binary data-based approach like > the MIB is fine for automated management, but it is not good for > operator-interactive management, and it fails to take advantage of > advances in computer networking technology like WWW technologies. > I am not interested in an SNMP-like interface to SMI data, encoded in XML. IMO, via NETCONF , the access should be per-row-instance, via subtree and Xpath filters, not per-column-instance, via lexi-next (getnext). Other protocols will have completely different requirements and retrieval operations, and the solution might not be the same. > For operator-interactice NM, I think we need task-based NM interfaces. > The CLI is one approach, and standardizing it would probably be > helpful, but the engineering departments of vendors are not very > cooperative on doing that; it is easier for engineers to use freeform > text when developing CLIs and syslog-style reporting than to use > standardized content. > > XML-based management leverages lessons learned from the WWW. While > document-based rather than command-based, tasks can often be grouped > into a document-type interface, such as a web page. With automated > translation from XML into HTML (and related technologies), we can work > on developing task-based-document NM interfaces. > > I think we need to spend more time thinking about operator use-cases, > not just technical designs of SMIs. I think it would help to start > thinking in terms of modular data models similar to MIB modules, not > just a config, but we need to develop an SMI that helps to > differentiate config and state info, which SMIv2 doesn't do, Maybe all > we need to do is recommend that MIB modules have separate subtrees for > config and for state, much as we now recommend separate subtrees for > objects and notifications. > > While I would like to see the reuse of existing standards, such as > XSD, we need to support programmatic interfaces to allow (incremental) > automation of repetitive tasks. That means we need to provide > machine-readable "clues" about the meta-nature of management > information. Maybe that can be done in XML using attributes, or > namespaces, or hierarchical organization. Maybe it will require a new > SMI with all the special fields found in SMIv2 - and more. > > I think one of the big questions we need to address is whether a new > SMI should be developed that is an extension/superset of SMIv2, or is > distinct from SMIv2. I think that work involves getting operator > feedback of how they work, so we can understand whether we should be > trying to merge the existing NM protocols, or should keep them (and > their data) distinct. I think we should be considering how to > componentize existing standards work, so we can reuse some parts, such > as secure transport, while keeping other parts distinct. > > That work can advance while we work on developing support for one or > more XML-based interfaces to SMIv2 data models, as a migratory step > toward multi-protocol management. > >> Nit: The WG acronym is kind of cryptic and I'm not sure what >> it supposed to mean. Also, the WG name only describes work items >> (A) and (B). Security requirements for multi-protocol access >> to MIB data is definitely not covered by the title, and (D) >> is 'possibly' NETCONF protocol-specific. (?? XSMI ?? SMIX ?? >> SMINET ??) > > I deliberately avoided the use of SMI. As somebody pointed out (you?), > this work (A and B) is not developing a new SMI, it is merely > translating elements of SMIv2 from one language to another. > I do not think this limited and generalized translation (D) is very useful, or realistically possible to do well in the IETF, in finite time. I prefer to view the Network Management problem in specific terms, e.g., understanding how conceptual data defined in SMIv2 can be mapped into a NETCONF Configuration Database, and accessed with NETCONF protocol operations. Abstracting the NM problem as if there was nothing going on beyond editing the XML instance document itself does not really help. >> Milestones: Any idea how long you think it will take to do >> all this work? >> >> Work items: >> >> (A)(B) >> The XSD for SMIv2 data types and TCs draft has been reviewed >> and refined >> over >> a couple years, and it is very much needed, and ready, for >> standardization. > > Yan will be publishing a base datatype translation document, based on > libsmi translations. Since this has been defined and used(?) fo > ryears, I expect this should be fast - in IETF terms, we can probably > finish in seven or eight years ;-). Seriously, I hope this can be done > in six months or so, if there is enough interest to work on it. > > That will be supplemented by the (romascanu) TC translations document. > We need to decide whether XSD can express the restrictions adequately > to support machine-validation, and whether the amount of > machine-validation supported justifies having an XSD for the TC. > Having TC translations might be helpful for netconf to go read existng > MIB data, without having to also parse SMIv2 MIB documents to > understand what the values mean. I think the bigger benefit is > defining TCs that can be used by multiple protocols to support > consistent semantics across protocols, and XML is the preferred > language for most new protocols. > > This will require case-by-case analysis, and might take time to reach > consensus. Of course, not every contentious TC must be included in > this document, so if we cut out the contentious ones, this should be > able to be wrapped up within a year, I hope. > >> (C) >> This work item is a bit vague. I'm not sure if it means >> a mapping between an SNMP EngineID to a NETCONF session identity, >> or something to do with VACM, or something else undefined. >> I think it is a smart idea to understand all the security issues >> associated with (D). > > I'm looking at the bigger picture of multi-protocol management. There > are lots of protocols being developed, both inside and outside IETF, > to perform management functionality. As Bob Natale pointed out, the > MIB is the "crown jewel" of IETF Management (I think SNMP is as well, > when used for what it is good at). I think lots of WGs and lots of > other SDOs are going to look at the MIB and say "gee, we should > leverage that!" > > I think we need to set some guidelines about how protocols should deal > with the MIB, so that it is not ruined by unconstrained access by > multiple protocols, especially write access. > > But even read-access can be problematic. Security is a process, not a > product. The IETF needs to decide how to "balance" security in an > environment of multi-protocol management. It makes no sense to protect > your house with a front door that has multiple deadbolt locks, if your > back door has no locks. > > It makes no sense to expect operators to go to the trouble of > configuring VACM to protect the data in the MIB when using SNMP, if > the operator's VACM configuration will just be ignored by netconf and > other protocols accessing the MIB. I think we need some guidelines > that provide for a more consistent approach to multi-protocol MIB > access, than VACM-for-SNMP and nothing-for-others. > > Personally, I would like to see VACM not be mandatory-to-implement for > SNMP, if there is no corresponding mandatory-to-implement access > control for other protocols. I don't think the operator community is > actually ready for standardized cross-protocol access control, and if > it isn't balanced across protocols, then we shouldn't require any NM > protocol standards to have a mandatory-to-implement access control > model. > Previous discussions wrt/ NETCONF access control have indicated that a simple solution allowed just 2 access levels (read and write) is favored. Perhaps as a backlash to VACM. >> (D) >> I support a standard algorithmic translation between SMIv2 > conceptual >> data models and NETCONF configuration databases, which includes >> data organization and standard protocol operation mappings. >> I think read-only access instead of full access will be easier >> to achieve, so it should be done first. The use case for >> write access is not as strong, and the multi-protocol access and >> security issues are harder. > > I agree that read-only access would probably be sufficient for netconf > to gather state information, statistical information, and > notifications. I do not see a lot of reason to support write access to > the MIB via netconf. > >> I do not support a generic XSD representation of SMIv2 macros, >> without consideration of the specific XML-based protocol being used. >> The 'embedded' SNMP protocol operations in SMIv2, as well as >> the explicit >> SNMP operations discussed in MIB object DESCRIPTION clauses, >> RowPointer, >> RowStatus, StorageType, etc., all have to be explicitly mapped to > the >> specific NETCONF (or whatever) protocol operations and >> architecture assumptions. > > I think these need to be supported to understand the values of certain > fields that might be read from the MIB. > > RowStatus reflects the operational state of the row, and if netconf is > accessing the MIB to determine operational state of the thing > represented by that row, it is an important piece of information. But > if netconf has no write capability to the MIB, it does not need to > know how to manipulate the values. > > StorageType is also state information about a row that might be > important for a netconf client to understand; it might be helpful to > know that the MIB representation (or the underlying instrumentation) > is in ROM. But if it has no write capability, it does not need to know > how to manipulate the row within the constraints of StorageType. > > The MIB is more or less a relational database, where the relations > between rows is important information. If netconf reads a row that has > a relationship to another row via a RowPointer, netconf better know > how to interpret a RowPointer. > > (It is important to understand that I make no assumptions that a > netconf-client will have a direct connection to an SNMP manager that > knows how to parse this information from an SMIv2 MIB module > document.) > > I think we need to walk through these TCs on a case-by-case basis to > decide whether we need each one for use with netconf, and what XSD > restrictions apply. I was pointing these complexities out as a reason not to deal with write access. If there are products used by operators someday, that have some sort of XML-based "set" operation for MIB data, then maybe it would be interesting to standardize it. > > David Harrington Andy _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Fri Jun 15 02:57:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz5kY-0004GT-9I; Fri, 15 Jun 2007 02:57:38 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1Hz5kX-0004Fm-4S for ops-area-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 02:57:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz5kK-00046J-Rq; Fri, 15 Jun 2007 02:57:24 -0400 Received: from de307622-de-outbound.net.avaya.com ([198.152.71.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz5kI-0000Ng-9Q; Fri, 15 Jun 2007 02:57:24 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by de307622-de-outbound.net.avaya.com with ESMTP; 15 Jun 2007 02:57:21 -0400 X-IronPort-AV: i="4.16,423,1175486400"; d="scan'208"; a="27044734:sNHT9173490" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Jun 2007 08:56:36 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for June 21, 2007 Telechat Thread-Index: Aceu1DHlSwqjbi+aRgS8aMC0+kR0WAARac6A From: "Romascanu, Dan (Dan)" To: , "Ops-Nm" , "MIB Doctors (E-mail)" , "Aaa-Doctors (E-mail)" X-Spam-Score: 0.1 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: Subject: [OPS-AREA] FW: PRELIMINARY Agenda and Package for June 21, 2007 Telechat X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org 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?" Please find below the preliminary agenda of the June 21 IESG Telechat. = Please review the documents brought to the approval of the IESG and let = me know if you have any comments or concerns until COB June 20.=20 Thanks and Regards, Dan 2.1 WG Submissions 2.1.1 New Item o draft-ietf-rtgwg-rfc3682bis-09.txt The Generalized TTL Security Mechanism (GTSM) (Proposed Standard) - = 1 of 6=20 Token: Ross Callon o draft-ietf-mpls-lsr-self-test-07.txt Label Switching Router Self-Test (Proposed Standard) - 2 of 6=20 Token: Ross Callon o draft-ietf-dccp-rtp-06.txt RTP and the Datagram Congestion Control Protocol (DCCP) (Proposed Standard)=20 - 3 of 6=20 Note: Document Shepherd: Tom Phelan (tphelan@sonusnet.com)=20 Token: Lars Eggert o draft-ietf-ecrit-service-urn-06.txt A Uniform Resource Name (URN) for Services (Proposed Standard) - 4 = of 6=20 Token: Jon Peterson o draft-ietf-mip6-bootstrapping-split-05.txt Mobile IPv6 bootstrapping in split scenario (Proposed Standard) - 5 = of 6=20 Note: Document Shepherd is Basavaraj Patil=20 . NOTE: Last Call expires June 25, 4 days=20 after IESG telechat=20 Token: Jari Arkko o draft-ietf-dhc-relay-agent-flags-03.txt DHCPv4 Relay Agent Flags Suboption (Proposed Standard) - 6 of 6=20 Note: Document Shepherd is =20 Token: Jari Arkko 2.1.2 Returning Item o draft-ietf-openpgp-rfc2440bis-22.txt OpenPGP Message Format (Proposed Standard) - 1 of 1=20 Token: Sam Hartman 2.1.3 For Action o Two-document ballot: - 1 of 1 - draft-ietf-syslog-protocol-21.txt The syslog Protocol (Proposed Standard)=20 Note: The WG chairs believe they may have backed out enough = changes =20 that. this no longer requires an second IETF last call.=A0 In the=20 hopes that I. will get a chance to review this weekend and issue = a ballot I'm placining it on the agenda.. If I fail to issue a ballot by=20 Monday I will remove.=20 - draft-ietf-syslog-transport-udp-09.txt Transmission of syslog messages over UDP (Proposed Standard)=20 Note: The WG chairs believe they may have backed out enough = changes =20 that. this no longer requires an second IETF last call.=A0 In the=20 hopes that I. will get a chance to review this weekend and issue = a ballot I'm placining it on the agenda.. If I fail to issue a ballot by=20 Monday I will remove.=20 Token: Sam Hartman 2.2 Individual Submissions 2.2.1 New Item NONE 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 Two-document ballot: - 1 of 6 - draft-ietf-pana-pana-16.txt Protocol for Carrying Authentication for Network Access (PANA) (Proposed=20 Standard)=20 - draft-ietf-pana-framework-09.txt Protocol for Carrying Authentication for Network Access (PANA) Framework=20 (Informational)=20 Token: Mark Townsley o draft-ietf-ipfix-as-11.txt IPFIX Applicability (Informational) - 2 of 6=20 Token: Dan Romascanu o draft-ietf-ecrit-security-threats-04.txt Security Threats and Requirements for Emergency Call Marking and Mapping=20 (Informational) - 3 of 6=20 Token: Jon Peterson o draft-ietf-ecrit-requirements-13.txt Requirements for Emergency Context Resolution with Internet Technologies=20 (Informational) - 4 of 6=20 Token: Jon Peterson o draft-ietf-ipfix-reducing-redundancy-04.txt Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet = Sampling (PSAMP) Reports (Informational) - 5 of 6=20 Note: Nevil Brownlee is the proto-shepherd=20 Token: Dan Romascanu o draft-ietf-mip4-radius-requirements-03.txt Mobile IPv4 RADIUS requirements (Informational) - 6 of 6=20 Note: Document Shepherd is Pete McCann .=20 NOTE: Last Call ends on June 25th, 4 days after IESG telechat=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-camarillo-sipping-profile-key-02.txt The Session Initiation Protocol (SIP) P-Profile-Key Private Header=20 (P-Header) (Informational) - 1 of 4=20 Token: Jon Peterson o draft-ejzak-sipping-p-em-auth-04.txt Private Header (P-Header) Extension to the Session Initiation = Protocol =20 (SIP) for Authorization of Early Media (Informational) - 2 of 4=20 Token: Jon Peterson o draft-chakrabarti-ipv6-addrselect-api-06.txt IPv6 Socket API for Address Selection (Informational) - 3 of 4=20 Note: A new revision is needed to address Last Call comments=20 Token: Jari Arkko o draft-housley-smime-suite-b-02.txt Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)=20 (Informational) - 4 of 4=20 Token: Tim Polk _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Fri Jun 15 06:06:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz8hf-0006F0-2V; Fri, 15 Jun 2007 06:06:51 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1Hz8hc-0005o6-Rz for ops-area-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 06:06:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz8hY-0005Fi-LZ; Fri, 15 Jun 2007 06:06:44 -0400 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz8hY-0001MU-7O; Fri, 15 Jun 2007 06:06:44 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-outbound.avaya.com with ESMTP; 15 Jun 2007 06:06:42 -0400 X-IronPort-AV: i="4.16,423,1175486400"; d="scan'208"; a="29488801:sNHT12818154" 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: Fri, 15 Jun 2007 12:06:06 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Action: Operations and Management Area Working Group (opsawg) Thread-Index: Aceth4Kv03PmtY43SjyrSAHAIhik3wBrRh7Q From: "Romascanu, Dan (Dan)" To: , "Ops-Nm" , "MIB Doctors (E-mail)" , "Aaa-Doctors (E-mail)" , , X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: Subject: [OPS-AREA] FW: WG Action: Operations and Management Area Working Group (opsawg) X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org I apologize for cross-posting.=20 Dan =20 -----Original Message----- From: IESG Secretary [mailto:iesg-secretary@ietf.org]=20 Sent: Wednesday, June 13, 2007 9:50 AM To: ietf-announce@ietf.org Cc: opsawg@ietf.org; Scott Bradner Subject: WG Action: Operations and Management Area Working Group (opsawg)=20 A new IETF working group has been formed in the Operations and Management Area. For additional information, please contact the Area Directors or the WG Chairs. +++ Operations and Management Area Working Group (opsawg) =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 Current Status: Active Working Group Chair(s): Scott Bradner Operations and Management Area Directors: Dan Romascanu Ronald Bonica General Discussion: opsawg@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/opsawg Archive: http://www1.ietf.org/mail-archive/web/opsawg/current/index.html Description: The Operations and Management Area receives occasional proposals for the development and publication of RFCs dealing with operational and management topics that are not in scope of an existing working group and do not justify the formation of a new working group. The OPSAWG will serve as the forum for developing such work items in the IETF. The OPSAWG mailing list is an open discussion forum for such work items, when they arise. The working group meets if there are active proposals that require discussion. The working group milestones are updated as needed to reflect the current work items and their associated milestones. All new work items and rechartering proposals will be brought for approval with the IESG. The focus of the work will be on topics that govern the behavior or WGs in the O&M area (e.g., manageability requirements) and on small, highly focused projects that don't merit a WG of their own or belong to WGs that have already concluded (e.g. advancement of documents on the standards track, application statements, extensions of MIB modules). The OPSAWG will undertake only work items that are proved to have at least a reasonable level of interest from the operators and users community and have a committed number of editors and reviewers. It is not within the scope of the OPSAWG to pick up failed WG work or parts of a WG charter items that could not come to convergence on what they were chartered to do. The currently active OPSAWG work items mostly fall under the following topics: (A) Development of a BCP document that will provide guidelines for authors and a reference for reviewers of IETF documents that specify new protocols or protocol extensions about the information about operational and manageability requirements that needs to be covered in these documents (B) Templates and tools for Operations and Management Area Documents (C) Maintenance and small scale extensions of documents that were developed in working groups that have concluded (e.g. MIB modules). Goals and Milestones: June 2007 - Initial submission for the "Guidelines for Considering Operations and Management of New Protocols" Internet-Draft June 2007 - Initial submission for the "SNMP Engine ID Discovery" Internet-Draft October 2007 - Initial submission for the "Template for Generic Management Data Models" Internet-Draft October 2007 - Initial submission for the "Structured Data Elements (SDEs) for syslog" Internet-Draft October 2007 - WGLC for the "SNMP Engine ID Discovery" Internet-Draft December 2007 - WGLC for the "Guidelines for Considering Operations and Management of New Protocols" Internet-Draft December 2007 - Submit the "SNMP Engine ID Discovery" Internet-Draft to the IESG for consideration as Proposed Standard February 2008 - Submit the "Guidelines for Considering Operations and Management of New Protocols" Internet-Draft to the IESG for consideration as BCP April 2008 - WGLC for the "Template for Generic Management Data Models"=20 April 2008 - WGLC for the "Structured Data Elements (SDEs) for syslog" June 2008 - Submit the "Template for Generic Management Data Models" to the IESG for consideration as BCP June 2008 - Submit the "Structured Data Elements (SDEs) for syslog" to the IESG for consideration as Proposed Standard _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Mon Jun 18 02:10:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0AR1-0006kC-8p; Mon, 18 Jun 2007 02:09:55 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1I0AQz-0006im-Fp for ops-area-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 02:09:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0AQt-0006hI-TP; Mon, 18 Jun 2007 02:09:47 -0400 Received: from de307622-de-outbound.net.avaya.com ([198.152.71.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0AQs-0007sQ-0v; Mon, 18 Jun 2007 02:09:47 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by de307622-de-outbound.net.avaya.com with ESMTP; 18 Jun 2007 02:09:44 -0400 X-IronPort-AV: i="4.16,433,1175486400"; d="scan'208"; a="27969696:sNHT12457254" 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: Mon, 18 Jun 2007 08:08:56 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request to forward the Nomcom 2007-8 Announcement to lists youmanage Thread-Index: AcewN0+aaYBjAEmrQgWJQH6H2csCrwBN4uig From: "Romascanu, Dan (Dan)" To: , "Ops-Nm" , "MIB Doctors (E-mail)" , "Aaa-Doctors (E-mail)" , , , , "Hub Mib" X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [OPS-AREA] FW: Request to forward the Nomcom 2007-8 Announcement to lists youmanage X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Please consider the message below forwarded at the request of the Nomcom chair.=20 Dan =20 -----Original Message----- From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]=20 Sent: Saturday, June 16, 2007 7:55 PM To: wgchairs@ietf.org; irsg@isi.edu; bofchairs@ietf.org Subject: Request to forward the Nomcom 2007-8 Announcement to lists youmanage Folks, We have around 50 volunteers so far for Nomcom 2007-8 voting member selection. We need a lot more! Not everyone subscribes to the IETF-Announce list. Could you please forward the announcement https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=3D1234 to WG, RG, BoF, Area lists that you manage? Thanks in advance. best regards, Lakshminath _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Mon Jun 18 14:46:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0MFE-0005Ik-0R; Mon, 18 Jun 2007 14:46:32 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1I0MFC-0005Gf-Ej for ops-area-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 14:46:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0MFC-0005GX-54; Mon, 18 Jun 2007 14:46:30 -0400 Received: from nj300815-nj-outbound.net.avaya.com ([198.152.12.100] helo=nj300815-nj-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0MFA-00064J-UZ; Mon, 18 Jun 2007 14:46:30 -0400 Received: from 16.140.64.135.in-addr.arpa (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-outbound.avaya.com with ESMTP; 18 Jun 2007 14:46:27 -0400 X-IronPort-AV: i="4.16,435,1175486400"; d="scan'208"; a="28702339:sNHT7851684" 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: Mon, 18 Jun 2007 20:46:26 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Submission cut-off dates before Chicago Thread-Index: Acex2PmEtxbDklB8TrC3YaXjv/x7Yw== From: "Romascanu, Dan (Dan)" To: , , "Netconf (E-mail)" , , , , , X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [OPS-AREA] Submission cut-off dates before Chicago X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Working Group and BOF Chairs and Contributors, Please note the submission dates for Internet-Drafts before Chicago.=20 July 2, Monday - Internet Draft Cut-off for initial document (-00) submission by 09:00 ET (13:00 UTC/GMT) July 9, Monday - Internet Draft final submission cut-off by 09:00 ET (13:00 UTC/GMT) Dan =20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Tue Jun 19 15:38:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jWY-0005Xn-Mq; Tue, 19 Jun 2007 15:37:58 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1I0jWY-0005XX-2q for ops-area-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 15:37:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jWX-0005Wu-PB; Tue, 19 Jun 2007 15:37:57 -0400 Received: from kremlin.juniper.net ([207.17.137.120] helo=smtpa.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0jWW-0004Ne-I1; Tue, 19 Jun 2007 15:37:57 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpa.juniper.net with ESMTP; 19 Jun 2007 12:37:56 -0700 X-IronPort-AV: i="4.16,439,1175497200"; d="scan'208"; a="21670657:sNHT30456548" Received: from [172.23.1.54] ([172.23.1.54] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 15:37:54 -0400 Message-ID: <4678308E.1040107@juniper.net> Date: Tue, 19 Jun 2007 15:37:50 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: grow@ietf.org, ops-area@ietf.org X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jun 2007 19:37:55.0049 (UTC) FILETIME=[551C6590:01C7B2A9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [OPS-AREA] WG Chairs X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Folks, Dan and I wish to thank Geoff Huston for his outstanding contributions to the GROW working group. However, Geoff has informed us that it is time for a change. So, we would like for you to welcome Peter Schoenmaker and Chris Morrow as the new working group chairs. Best wishes to Peter and Chris. Ron Bonica _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Tue Jun 19 15:44:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jcc-0004kl-5k; Tue, 19 Jun 2007 15:44:14 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1I0jca-0004kd-E6 for ops-area-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 15:44:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jca-0004kU-4b; Tue, 19 Jun 2007 15:44:12 -0400 Received: from borg.juniper.net ([207.17.137.119] helo=smtpb.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0jcY-0005ds-Tf; Tue, 19 Jun 2007 15:44:12 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpb.juniper.net with ESMTP; 19 Jun 2007 12:44:10 -0700 Received: from [172.23.1.54] ([172.23.1.54] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 15:44:09 -0400 Message-ID: <46783204.5020806@juniper.net> Date: Tue, 19 Jun 2007 15:44:04 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: opsawg@ietf.org, ops-area@ietf.org X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jun 2007 19:44:09.0450 (UTC) FILETIME=[344574A0:01C7B2AA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: Subject: [OPS-AREA] WG chairs X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Folks, Dan and I are happy to announces that Scott Bradner and Ted Seely will be serving as chairs of the OPS AREA WG. Best wishes to both of them. Ron _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Tue Jun 19 19:10:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0mpw-0006i2-9Z; Tue, 19 Jun 2007 19:10:12 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1I0mpu-0006hs-Rq for ops-area-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 19:10:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0mpu-0006hk-IJ for ops-area@ietf.org; Tue, 19 Jun 2007 19:10:10 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0mpt-0001vS-3r for ops-area@ietf.org; Tue, 19 Jun 2007 19:10:10 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5JNA4N1016759; Wed, 20 Jun 2007 02:10:07 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 02:10:04 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 02:10:05 +0300 Received: from dadhcp-172019068052.americas.nokia.com ([172.19.68.52]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 02:10:04 +0300 Received: from dadhcp-172019068052.americas.nokia.com (localhost.localdomain [127.0.0.1]) by dadhcp-172019068052.americas.nokia.com (8.13.5/8.13.5) with ESMTP id l5JN9vlK021197; Tue, 19 Jun 2007 16:09:57 -0700 Received: (from david@localhost) by dadhcp-172019068052.americas.nokia.com (8.13.5/8.13.5/Submit) id l5JN9sjT021196; Tue, 19 Jun 2007 16:09:54 -0700 Date: Tue, 19 Jun 2007 16:09:54 -0700 From: David Kessens To: Ron Bonica Message-ID: <20070619230954.GA21109@nsn.com> References: <4678308E.1040107@juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4678308E.1040107@juniper.net> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 19 Jun 2007 23:10:04.0716 (UTC) FILETIME=[F8956EC0:01C7B2C6] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ops-area@ietf.org Subject: [OPS-AREA] Re: [GROW] WG Chairs X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Ron, On Tue, Jun 19, 2007 at 03:37:50PM -0400, ext Ron Bonica wrote: > > So, we would like for you to welcome Peter Schoenmaker and Chris > Morrow as the new working group chairs. Not to question your particular choice of chairs here, but this seems to be the second time that you don't use an open call for volunteers for the chairposition of a working group in the Ops Area. Is there any particular reason that you are no longer following the tradition of an open call for volunteers for deciding working group chair choices in the Ops Area ? David Kessens --- _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Jun 20 11:19:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I11xs-0000sj-NU; Wed, 20 Jun 2007 11:19:24 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1I11xr-0000sQ-Ej for ops-area-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 11:19:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I11xr-0000sG-5A for ops-area@ietf.org; Wed, 20 Jun 2007 11:19:23 -0400 Received: from kremlin.juniper.net ([207.17.137.120] helo=smtpa.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I11xp-00028M-Rt for ops-area@ietf.org; Wed, 20 Jun 2007 11:19:23 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpa.juniper.net with ESMTP; 20 Jun 2007 08:19:21 -0700 X-IronPort-AV: i="4.16,443,1175497200"; d="scan'208"; a="22160881:sNHT38129360" Received: from [172.23.1.54] ([172.23.1.54] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 11:19:19 -0400 Message-ID: <4679456C.1030308@juniper.net> Date: Wed, 20 Jun 2007 11:19:08 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Kessens References: <4678308E.1040107@juniper.net> <20070619230954.GA21109@nsn.com> In-Reply-To: <20070619230954.GA21109@nsn.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2007 15:19:20.0116 (UTC) FILETIME=[5FE73F40:01C7B34E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ops-area@ietf.org Subject: [OPS-AREA] Re: [GROW] WG Chairs X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Hi Dave, As you are aware, area directors are not required to post an open call for volunteers. However, since you raised the issue, I would like to shed some light on the WG chair selection process. Operators are under-represented in the IETF. We feel this problem most severely in the *Operations* and Management Area. So, my goal was to appoint active operators to working group chair positions. Specifically, I recruited folks with the following credentials: - currently active as a network operator - currently active in the IETF - current and sufficient IETF experience - good management and people skills Needless to say, the candidate pool was small. We are still looking for people who fulfill these requirements to fill positions on the OPS Directorate and to be candidates for chairing positions that might come open in the future. If anyone reading this email feels that they fulfill these requirements and are willing to participate in such activities, please email Dan and I privately. Ron David Kessens wrote: > Ron, > > On Tue, Jun 19, 2007 at 03:37:50PM -0400, ext Ron Bonica wrote: > >>So, we would like for you to welcome Peter Schoenmaker and Chris >>Morrow as the new working group chairs. > > > Not to question your particular choice of chairs here, but this seems > to be the second time that you don't use an open call for volunteers > for the chairposition of a working group in the Ops Area. > > Is there any particular reason that you are no longer following the > tradition of an open call for volunteers for deciding working group > chair choices in the Ops Area ? > > David Kessens > --- > _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Jun 20 12:18:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I12t6-0002ol-4A; Wed, 20 Jun 2007 12:18:32 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1I12t4-0002o5-Ka for ops-area-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 12:18:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I12t4-0002mM-AE for ops-area@ietf.org; Wed, 20 Jun 2007 12:18:30 -0400 Received: from smtp108.sbc.mail.mud.yahoo.com ([68.142.198.207]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I12t3-0004fd-Py for ops-area@ietf.org; Wed, 20 Jun 2007 12:18:30 -0400 Received: (qmail 39385 invoked from network); 20 Jun 2007 16:18:29 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.204.47.177 with plain) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 20 Jun 2007 16:18:28 -0000 X-YMail-OSG: Ub37._IVM1n7f.1u5GAJRYSXVucRNiOvP.bEW_uP0CgA5gBH0onlJLd9GRzITCsNwMi9BFy4SSLpqEQHvXDBMwnvow-- Message-ID: <46795316.3090507@andybierman.com> Date: Wed, 20 Jun 2007 09:17:26 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Ron Bonica Subject: Re: [OPS-AREA] Re: [GROW] WG Chairs References: <4678308E.1040107@juniper.net> <20070619230954.GA21109@nsn.com> <4679456C.1030308@juniper.net> In-Reply-To: <4679456C.1030308@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Ron Bonica wrote: > Hi Dave, > I am glad to get network operators directly involved in the IETF, by any means possible. I think it is up to the ADs how they want to get WG Chairs to "work for them". I would be more concerned about open calls for solution proposals in a WG, than an open call for selecting WG Chairs. Andy > As you are aware, area directors are not required to post an open call > for volunteers. However, since you raised the issue, I would like to > shed some light on the WG chair selection process. > > Operators are under-represented in the IETF. We feel this problem most > severely in the *Operations* and Management Area. So, my goal was to > appoint active operators to working group chair positions. > > Specifically, I recruited folks with the following credentials: > > - currently active as a network operator > - currently active in the IETF > - current and sufficient IETF experience > - good management and people skills > > Needless to say, the candidate pool was small. We are still looking for > people who fulfill these requirements to fill positions on the OPS > Directorate and to be candidates for chairing positions that might come > open in the future. If anyone reading this email feels that they fulfill > these requirements and are willing to participate in such activities, > please email Dan and I privately. > > Ron > > David Kessens wrote: >> Ron, >> >> On Tue, Jun 19, 2007 at 03:37:50PM -0400, ext Ron Bonica wrote: >> >>> So, we would like for you to welcome Peter Schoenmaker and Chris >>> Morrow as the new working group chairs. >> >> Not to question your particular choice of chairs here, but this seems >> to be the second time that you don't use an open call for volunteers >> for the chairposition of a working group in the Ops Area. >> >> Is there any particular reason that you are no longer following the >> tradition of an open call for volunteers for deciding working group >> chair choices in the Ops Area ? >> >> David Kessens >> --- >> > > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www1.ietf.org/mailman/listinfo/ops-area > > _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Jun 20 12:54:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I13Rh-0006J0-Fu; Wed, 20 Jun 2007 12:54:17 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1I13Rf-0006Hh-TD for ops-area-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 12:54:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I13Rf-0006HM-8o; Wed, 20 Jun 2007 12:54:15 -0400 Received: from cirrus.av8.net ([130.105.36.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I13Rd-0005mm-Ud; Wed, 20 Jun 2007 12:54:15 -0400 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id l5KGsBI1024162 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 20 Jun 2007 12:54:11 -0400 Date: Wed, 20 Jun 2007 12:54:09 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Ron Bonica In-Reply-To: <4678308E.1040107@juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.8 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: grow@ietf.org, ops-area@ietf.org Subject: [OPS-AREA] Re: [GROW] WG Chairs X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Can you explain how these chairs were selected? As far as I can tell, they have not participated in the GROW WG, going back more than 2 years. Why not select someone who participates in the working group to be the chairs? --Dean On Tue, 19 Jun 2007, Ron Bonica wrote: > Folks, > > Dan and I wish to thank Geoff Huston for his outstanding contributions > to the GROW working group. However, Geoff has informed us that it is > time for a change. So, we would like for you to welcome Peter > Schoenmaker and Chris Morrow as the new working group chairs. > > Best wishes to Peter and Chris. > > Ron Bonica > > > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www1.ietf.org/mailman/listinfo/grow > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Jun 20 13:47:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I14Gx-0001OO-Fe; Wed, 20 Jun 2007 13:47:15 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1I12xJ-0001mO-E3 for ops-area-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 12:22:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I12xJ-0001mG-4W for ops-area@ietf.org; Wed, 20 Jun 2007 12:22:53 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I12xH-0005ac-SG for ops-area@ietf.org; Wed, 20 Jun 2007 12:22:53 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id l5KGMpQ1015675 for ; Wed, 20 Jun 2007 16:22:51 GMT Subject: RE: [OPS-AREA] BOF: Applications Performance Management (APM) BOF From: Daryl Malas To: ops-area@ietf.org In-Reply-To: <662C3EB2067DD64FBB2CDA77CD2B1A5601C82429@MCHP7R6A.ww002.siemens.net> References: <662C3EB2067DD64FBB2CDA77CD2B1A5601C82429@MCHP7R6A.ww002.siemens.net> Content-Type: text/plain Date: Wed, 20 Jun 2007 09:23:00 -0600 Message-Id: <1182352980.16393.14.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-Mailman-Approved-At: Wed, 20 Jun 2007 13:47:14 -0400 X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org IMO, I completely agree there is a gap in the IETF for this type of work, and I absolutely think an APM Directorate is the right approach. There are only two drafts associated with this BOF at this point. It does not appear there are a lot of other drafts in the pipeline for this work. Since this is the case, I don't see a need to create a new working group for 1 or 2 drafts. Unfortunately, I don't think this type of work is "sexy" from an IETF perspective. I am concerned if a working group is created, this type of work will not receive the necessary visibility to be successful and truly valuable. On the flip side, I also know that it will take up time within the existing working groups, but I think those are the right locations to get a temperature reading on their value. --Daryl On Mon, 2007-06-04 at 10:16 +0200, Ersue, Mehmet wrote: > Applications Performance Management (APM) BOF _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Jun 20 13:47:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I14Gx-0001OJ-BI; Wed, 20 Jun 2007 13:47:15 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1I0k0K-00076w-Q2 for ops-area-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 16:08:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0k0K-00076Z-7L; Tue, 19 Jun 2007 16:08:44 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0k0I-00037y-J1; Tue, 19 Jun 2007 16:08:43 -0400 Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8/Debian-2) with ESMTP id l5JK8f6H020664; Tue, 19 Jun 2007 13:08:41 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.0/8.13.8/Submit) id l5JK8fwT020663; Tue, 19 Jun 2007 13:08:41 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 19 Jun 2007 13:08:41 -0700 From: David Meyer To: Ron Bonica Message-ID: <20070619200841.GA20625@1-4-5.net> References: <4678308E.1040107@juniper.net> MIME-Version: 1.0 In-Reply-To: <4678308E.1040107@juniper.net> X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "No wasted time, we're alive today, Churnin up the past, there's no easier way, Time's been between us, a means to an end, G_d it's good to be here walking together my friend" -- srv, Life By The Drop User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-Mailman-Approved-At: Wed, 20 Jun 2007 13:47:14 -0400 Cc: grow@ietf.org, ops-area@ietf.org Subject: [OPS-AREA] Re: [GROW] WG Chairs X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0566445360==" Errors-To: ops-area-bounces@ietf.org --===============0566445360== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > Dan and I wish to thank Geoff Huston for his outstanding contributions > to the GROW working group. However, Geoff has informed us that it is > time for a change.=20 I'll second that. Geoff was a great co-chair during my time. > So, we would like for you to welcome Peter Schoenmaker and > Chris Morrow as the new working group chairs.=20 >=20 > Best wishes to Peter and Chris. Ditto. --dmm --PNTmBPCT7hxwcZjr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFGeDfJORgD1qCZ2KcRAkJRAJ4gQzFBtwrSLg0iHcIWO3sbzSzRMACgg9il kQUZm/jAJXn5BB57v/kwsgI= =vrga -----END PGP SIGNATURE----- --PNTmBPCT7hxwcZjr-- --===============0566445360== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area --===============0566445360==-- From ops-area-bounces@ietf.org Wed Jun 20 14:37:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I153i-0002aI-0c; Wed, 20 Jun 2007 14:37:38 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1I153h-0002aC-Bv for ops-area-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 14:37:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I153h-0002a4-2M for ops-area@ietf.org; Wed, 20 Jun 2007 14:37:37 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I153g-0001Y9-JN for ops-area@ietf.org; Wed, 20 Jun 2007 14:37:37 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5KIbJv1028696; Wed, 20 Jun 2007 21:37:34 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 21:37:33 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 21:37:33 +0300 Received: from dadhcp-172019068052.americas.nokia.com ([172.19.68.52]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 21:37:32 +0300 Received: from dadhcp-172019068052.americas.nokia.com (localhost.localdomain [127.0.0.1]) by dadhcp-172019068052.americas.nokia.com (8.13.5/8.13.5) with ESMTP id l5KIbUkF029984; Wed, 20 Jun 2007 11:37:30 -0700 Received: (from david@localhost) by dadhcp-172019068052.americas.nokia.com (8.13.5/8.13.5/Submit) id l5KIbRZv029983; Wed, 20 Jun 2007 11:37:27 -0700 Date: Wed, 20 Jun 2007 11:37:27 -0700 From: David Kessens To: Ron Bonica Message-ID: <20070620183727.GA29685@nsn.com> References: <4678308E.1040107@juniper.net> <20070619230954.GA21109@nsn.com> <4679456C.1030308@juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4679456C.1030308@juniper.net> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 20 Jun 2007 18:37:32.0880 (UTC) FILETIME=[108B0500:01C7B36A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: ops-area@ietf.org Subject: [OPS-AREA] Re: [GROW] WG Chairs X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Ron, On Wed, Jun 20, 2007 at 11:19:08AM -0400, Ron Bonica wrote: > > As you are aware, area directors are not required to post an open call > for volunteers. Correct. On the other hand, we did establish such a tradition in the Operations & Management Area in the past few years so I wondered why you departed from that tradition. I felt that it was both useful in finding more candidates, but also, even more importantly, it helped us to find other candidates than the "obvious" candidates, especially from within the group of active operators. The only real drawback was that the process took more time and effort for the AD but I felt that that was really worth it compared to the overall benefits. I just don't see how this method is incompatible with your desire to appoint more operators into available positions in the Operations Area (which was not required either, but has been the policy for a long time as well!). David Kessens PS I prefer people calling me David, my name is not Dave. --- > However, since you raised the issue, I would like to > shed some light on the WG chair selection process. > > Operators are under-represented in the IETF. We feel this problem most > severely in the *Operations* and Management Area. So, my goal was to > appoint active operators to working group chair positions. > > Specifically, I recruited folks with the following credentials: > > - currently active as a network operator > - currently active in the IETF > - current and sufficient IETF experience > - good management and people skills > > Needless to say, the candidate pool was small. We are still looking for > people who fulfill these requirements to fill positions on the OPS > Directorate and to be candidates for chairing positions that might come > open in the future. If anyone reading this email feels that they fulfill > these requirements and are willing to participate in such activities, > please email Dan and I privately. > > Ron > > David Kessens wrote: > > Ron, > > > > On Tue, Jun 19, 2007 at 03:37:50PM -0400, ext Ron Bonica wrote: > > > >>So, we would like for you to welcome Peter Schoenmaker and Chris > >>Morrow as the new working group chairs. > > > > > > Not to question your particular choice of chairs here, but this seems > > to be the second time that you don't use an open call for volunteers > > for the chairposition of a working group in the Ops Area. > > > > Is there any particular reason that you are no longer following the > > tradition of an open call for volunteers for deciding working group > > chair choices in the Ops Area ? > > > > David Kessens > > --- _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Jun 20 14:53:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I15JD-0007KR-Mp; Wed, 20 Jun 2007 14:53:39 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1I15JC-0007KM-7U for ops-area-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 14:53:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I15JB-0007KD-UF for ops-area@ietf.org; Wed, 20 Jun 2007 14:53:37 -0400 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I15JA-0004Cx-Ke for ops-area@ietf.org; Wed, 20 Jun 2007 14:53:37 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-outbound.avaya.com with ESMTP; 20 Jun 2007 14:53:35 -0400 X-IronPort-AV: i="4.16,443,1175486400"; d="scan'208"; a="31756906:sNHT11958618" 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 Jun 2007 20:52:59 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Call for IESG narrative scribe volunteers Thread-Index: Acet24eQCNt3YehqRM2BJvWB4XzhCgFkAnSA From: "Romascanu, Dan (Dan)" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Russ Housley Subject: [OPS-AREA] FW: Call for IESG narrative scribe volunteers X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org =20 Please see the following call for volunteers for the IESG scribe position. The job requires attending from time to time the IESG telechats and meetings, recording them in written and editing as per the IESG members comments. To the job description below I would add that this is an opportunity to have a closer look to the work of the IESG and contribute to making this work more visible to the IETF community.=20 Dan =20 -----Original Message----- From: The IESG [mailto:iesg@ietf.org]=20 Sent: Monday, June 11, 2007 11:42 PM To: IETF Announcement list Subject: Call for IESG narrative scribe volunteers=20 The IESG narrative minutes are posted, whenever available, at http://www.ietf.org/IESG/iesg-narrative.html. Currently, three scribes (Spencer Dawkins, Marshall Eubanks, and Marc Blanchet) share the work load. The IESG would like to recruit another scribe. Spencer has indicated that he needs to cut back on the time he spends on IESG scribe activities so that he can focus on his recently-assigned Working Group Chair role. Volunteers should write to iesg@ietf.org by June 29th. We'll keep names confidential, unless people choose to volunteer in public. The general guidelines are: - at least one scribe attends the regular IESG telechats (11:30 - 14:00 US ET on alternate Thursdays). - the scribe(s) will record narrative minutes of the discussions, but they will not take part in the discussions except to ask for clarifications. - the narrative minutes will be published after review by the IESG. The intent is to do this two to four weeks after the meeting in question. - confidential items (principally personnel discussions) will not be reported in detail. The scribe will not take part in any sessions from which liaisons are excluded (e.g. nomination and appeal discussions). Russ Housley On behalf of the IESG _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Jun 20 18:50:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I190c-0000wh-2F; Wed, 20 Jun 2007 18:50:42 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1I190a-0000p9-8x for ops-area-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 18:50:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I190Z-0000nB-L0 for ops-area@ietf.org; Wed, 20 Jun 2007 18:50:39 -0400 Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I190W-0005dh-TG for ops-area@ietf.org; Wed, 20 Jun 2007 18:50:39 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id C1A7C39A136; Wed, 20 Jun 2007 15:50:42 -0700 (PDT) From: Wes Hardaker To: Andy Bierman Subject: Re: [OPS-AREA] Re: [GROW] WG Chairs Organization: Sparta References: <4678308E.1040107@juniper.net> <20070619230954.GA21109@nsn.com> <4679456C.1030308@juniper.net> <46795316.3090507@andybierman.com> Date: Wed, 20 Jun 2007 15:50:42 -0700 In-Reply-To: <46795316.3090507@andybierman.com> (Andy Bierman's message of "Wed, 20 Jun 2007 09:17:26 -0700") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.19 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org >>>>> "AB" == Andy Bierman writes: AB> I would be more concerned about open calls for solution proposals in AB> a WG, than an open call for selecting WG Chairs. I'd be most concerned about getting the right person for the job that doesn't have conflicts of interest with the work being performed within the group. That's the biggest problem with not having an adequate pool of candidates and a potential reason for doing a wider call for support. WG chairs should be selected based on their knowledge, but independence from, the work. That's a tough role to fill, certainly. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Jun 20 19:00:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I199y-0006e0-ID; Wed, 20 Jun 2007 19:00:22 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1I199x-0006ds-Im for ops-area-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 19:00:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I199x-0006dc-99 for ops-area@ietf.org; Wed, 20 Jun 2007 19:00:21 -0400 Received: from smtp120.sbc.mail.sp1.yahoo.com ([69.147.64.93]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I199s-00009N-TA for ops-area@ietf.org; Wed, 20 Jun 2007 19:00:21 -0400 Received: (qmail 41566 invoked from network); 20 Jun 2007 23:00:16 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.204.47.177 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 20 Jun 2007 23:00:16 -0000 X-YMail-OSG: rpC7YMkVM1lFCUVIMIZdpf7IQYz9iY3G8pODGnzPoLT3Utt9 Message-ID: <4679B141.3090006@andybierman.com> Date: Wed, 20 Jun 2007 15:59:13 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Wes Hardaker Subject: Re: [OPS-AREA] Re: [GROW] WG Chairs References: <4678308E.1040107@juniper.net> <20070619230954.GA21109@nsn.com> <4679456C.1030308@juniper.net> <46795316.3090507@andybierman.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Wes Hardaker wrote: >>>>>> "AB" == Andy Bierman writes: > > AB> I would be more concerned about open calls for solution proposals in > AB> a WG, than an open call for selecting WG Chairs. > > I'd be most concerned about getting the right person for the job that > doesn't have conflicts of interest with the work being performed within > the group. That's the biggest problem with not having an adequate pool > of candidates and a potential reason for doing a wider call for > support. WG chairs should be selected based on their knowledge, but > independence from, the work. That's a tough role to fill, certainly. IMO, It is up to the AD to decide how to appoint the right person. If that person does not behave appropriately, then there is an appeals process to address that. An open call seems reasonable if the AD has no suitable person able to commit the resources to do the job. Andy _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Jun 20 19:11:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I19Kj-0005D0-Bp; Wed, 20 Jun 2007 19:11:29 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1I19Ki-0005Ae-8G for ops-area-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 19:11:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I19Kh-0005AW-Uz for ops-area@ietf.org; Wed, 20 Jun 2007 19:11:27 -0400 Received: from cirrus.av8.net ([130.105.36.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I19Kg-0002My-Kl for ops-area@ietf.org; Wed, 20 Jun 2007 19:11:27 -0400 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id l5KNBLeH024343 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 20 Jun 2007 19:11:26 -0400 Date: Wed, 20 Jun 2007 19:11:19 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Ron Bonica Subject: Re: [OPS-AREA] Re: [GROW] WG Chairs In-Reply-To: <4679456C.1030308@juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.8 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org On Wed, 20 Jun 2007, Ron Bonica wrote: > Operators are under-represented in the IETF. We feel this problem most > severely in the *Operations* and Management Area. I don't know how you came by that conclusion. It seems to me that some operators have way too much influence over the IETF and use the IETF to advance their profit potential. I'm for more science, more engineering, and less router-jockey mysticism. Global routing should be an applied science, not trial by error, and not fanciful claims supporting a few companies sales of discredited schemes. > So, my goal was to appoint active operators to working group chair > positions. I don't see how avoiding a call for volunteers advances that goal. I don't see that the present group of participants in the GROW Working Group doesn't consist of operators, engineers, and scientists more suitable to the work of GROW WG. It seems to me a recipe for disaster to place people in chair positions who are unfamiliar with IETF processes and procedures, ethics, conflict of interest, and other issues relating to management roles at a 501(c)3 non-profit. There might be fewer scandals if candidates were chosen more selectively, and better educated in critical management knowledge. More generally, there may be a problem with the process by which chairs are selected by the AD. Usually changes aren't so abrupt, nor are the changes so surprising. It seems to be a bad idea to allow both chairs to be arbitrarily selected by the AD without some kind of review and genuine qualification. Otherwise, there is the risk that the chairs selected are just cronies of the AD, advancing the AD's personal interests rather than the interests of the ISOC. There needs to be some check that the ISOC's interests are being served by the chairs, and that the chairs have qualifications beyond just being preferred by the AD. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Thu Jun 21 03:41:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1HIG-0004bz-2h; Thu, 21 Jun 2007 03:41:28 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1I1HIF-0004aN-Ad for ops-area-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 03:41:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1HIB-0004aE-9C for ops-area@ietf.org; Thu, 21 Jun 2007 03:41:23 -0400 Received: from [82.206.136.75] (helo=smtp.unijos.edu.ng) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I1HI7-0000l5-41 for ops-area@ietf.org; Thu, 21 Jun 2007 03:41:22 -0400 Received: from localhost (smtp.unijos.edu.ng [127.0.0.1]) by smtp.unijos.edu.ng (Postfix) with ESMTP id 6A376680B4; Thu, 21 Jun 2007 08:21:35 +0100 (WAT) X-Virus-Scanned: amavisd-new at unijos.edu.ng X-Spam-Score: -3.938 X-Spam-Level: X-Spam-Status: No, score=-3.938 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.8, AWL=0.461, BAYES_00=-2.599] Received: from smtp.unijos.edu.ng ([127.0.0.1]) by localhost (smtp.unijos.edu.ng [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtO5yy-cFtFf; Thu, 21 Jun 2007 08:21:26 +0100 (WAT) Received: from imap.unijos.edu.ng (imap.unijos.edu.ng [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.unijos.edu.ng (Postfix) with ESMTP id D19FA680B3; Thu, 21 Jun 2007 08:21:26 +0100 (WAT) Received: from 10.0.0.4 (localhost [127.0.0.1]) by imap.unijos.edu.ng (Postfix) with ESMTP id 50A26280D8; Thu, 21 Jun 2007 09:03:08 +0100 (WAT) Received: from 192.168.129.101 (SquirrelMail authenticated user gogwim) by 10.0.0.4 with HTTP; Thu, 21 Jun 2007 09:03:08 +0100 (WAT) Message-ID: <1163.192.168.129.101.1182412988.squirrel@10.0.0.4> In-Reply-To: References: <4679456C.1030308@juniper.net> Date: Thu, 21 Jun 2007 09:03:08 +0100 (WAT) Subject: Re: [OPS-AREA] Re: [GROW] WG Chairs From: "GOGWIM, JOEL GODWIN" To: "Dean Anderson" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gogwim@unijos.edu.ng List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org On Thu, June 21, 2007 12:11 am, Dean Anderson said: > On Wed, 20 Jun 2007, Ron Bonica wrote: > >> Operators are under-represented in the IETF. We feel this problem most >> severely in the *Operations* and Management Area. > > I don't know how you came by that conclusion. It seems to me that some > operators have way too much influence over the IETF and use the IETF to > advance their profit potential. I'm for more science, more engineering= , > and less router-jockey mysticism. Global routing should be an applied > science, not trial by error, and not fanciful claims supporting a few > companies sales of discredited schemes. I supported Dean in this regard. We need innovations, scientive changes the not marketing and profit-making mind-set. > >> So, my goal was to appoint active operators to working group chair >> positions. > > I don't see how avoiding a call for volunteers advances that goal. > > I don't see that the present group of participants in the GROW Working > Group doesn't consist of operators, engineers, and scientists more > suitable to the work of GROW WG. > > It seems to me a recipe for disaster to place people in chair positions > who are unfamiliar with IETF processes and procedures, ethics, conflict > of interest, and other issues relating to management roles at a 501(c)3 > non-profit. There might be fewer scandals if candidates were chosen > more selectively, and better educated in critical management knowledge. Conflict of interest is always a factor for a set-back in any setup. > > > > More generally, there may be a problem with the process by which chairs > are selected by the AD. Usually changes aren't so abrupt, nor are the > changes so surprising. It seems to be a bad idea to allow both chairs t= o > be arbitrarily selected by the AD without some kind of review and > genuine qualification. Otherwise, there is the risk that the chairs > selected are just cronies of the AD, advancing the AD's personal > interests rather than the interests of the ISOC. There needs to be som= e > check that the ISOC's interests are being served by the chairs, and tha= t > the chairs have qualifications beyond just being preferred by the AD. The goal/mission of IETF need to be promote and maintain in all that we do. Anything that will deprive this is/are worth stopping. --Gogwim > > --Dean > > -- > Av8 Internet Prepared to pay a premium for better service? > www.av8.net faster, more reliable, better service > 617 344 9000 > > > > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www1.ietf.org/mailman/listinfo/ops-area > _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Thu Jun 21 11:09:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1OHu-0001bP-Tb; Thu, 21 Jun 2007 11:09:34 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1I1OHs-0001aw-Ue for ops-area-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 11:09:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1OHs-0001ao-L7 for ops-area@ietf.org; Thu, 21 Jun 2007 11:09:32 -0400 Received: from smtp114.sbc.mail.mud.yahoo.com ([68.142.198.213]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I1OHr-000120-Af for ops-area@ietf.org; Thu, 21 Jun 2007 11:09:32 -0400 Received: (qmail 7660 invoked from network); 21 Jun 2007 15:09:30 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@76.204.47.177 with plain) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 21 Jun 2007 15:09:30 -0000 X-YMail-OSG: bdGsLKIVM1nonpxGTjhbuDmsn3znvDRGxwR2Kjx5aqHK6lbC Message-ID: <467A946A.9080701@andybierman.com> Date: Thu, 21 Jun 2007 08:08:26 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: gogwim@unijos.edu.ng Subject: Re: [OPS-AREA] Re: [GROW] WG Chairs References: <4679456C.1030308@juniper.net> <1163.192.168.129.101.1182412988.squirrel@10.0.0.4> In-Reply-To: <1163.192.168.129.101.1182412988.squirrel@10.0.0.4> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org GOGWIM, JOEL GODWIN wrote: > On Thu, June 21, 2007 12:11 am, Dean Anderson said: >> On Wed, 20 Jun 2007, Ron Bonica wrote: >> >>> Operators are under-represented in the IETF. We feel this problem most >>> severely in the *Operations* and Management Area. >> I don't know how you came by that conclusion. It seems to me that some >> operators have way too much influence over the IETF and use the IETF to >> advance their profit potential. I'm for more science, more engineering, >> and less router-jockey mysticism. Global routing should be an applied >> science, not trial by error, and not fanciful claims supporting a few >> companies sales of discredited schemes. > I supported Dean in this regard. We need innovations, scientive changes > the not marketing and profit-making mind-set. > My perspective (as someone working on the NM side of the OPS-NM area) is that during discussions on whether a particular mechanism in a draft will actually work or not, it is extremely useful to hear about direct experience from somebody who actually runs a network for their paycheck. Three benefits from real experience: 1) Sometimes, things that are not supposed to be a problem, really are. 2) Sometimes, things that are supposed to be a problem, really are not. 3) Sometimes, things that are supposed to be helpful, really are not. >.... > --Gogwim >> --Dean >> >> -- Andy _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Thu Jun 21 11:15:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1ON9-0001hS-3p; Thu, 21 Jun 2007 11:14:59 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1I1ON8-0001hN-Bq for ops-area-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 11:14:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1ON8-0001fx-1T for ops-area@ietf.org; Thu, 21 Jun 2007 11:14:58 -0400 Received: from kremlin.juniper.net ([207.17.137.120] helo=smtpa.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1ON6-0001m9-OR for ops-area@ietf.org; Thu, 21 Jun 2007 11:14:58 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpa.juniper.net with ESMTP; 21 Jun 2007 08:14:56 -0700 X-IronPort-AV: i="4.16,448,1175497200"; d="scan'208"; a="22779916:sNHT35973876" Received: from [172.23.1.54] ([172.23.1.54] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 11:14:54 -0400 Message-ID: <467A95E9.50106@juniper.net> Date: Thu, 21 Jun 2007 11:14:49 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Kessens References: <4678308E.1040107@juniper.net> <20070619230954.GA21109@nsn.com> <4679456C.1030308@juniper.net> <20070620183727.GA29685@nsn.com> In-Reply-To: <20070620183727.GA29685@nsn.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jun 2007 15:14:55.0184 (UTC) FILETIME=[EC679500:01C7B416] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: ops-area@ietf.org Subject: [OPS-AREA] Re: [GROW] WG Chairs X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org David, OK. I'm convinced. In the future I will make a public call for volunteers. Ron David Kessens wrote: > Ron, > > On Wed, Jun 20, 2007 at 11:19:08AM -0400, Ron Bonica wrote: > >>As you are aware, area directors are not required to post an open call >>for volunteers. > > > Correct. On the other hand, we did establish such a tradition in the > Operations & Management Area in the past few years so I wondered why you > departed from that tradition. I felt that it was both useful in > finding more candidates, but also, even more importantly, it helped us > to find other candidates than the "obvious" candidates, especially from > within the group of active operators. The only real drawback was > that the process took more time and effort for the AD but I felt that > that was really worth it compared to the overall benefits. > > I just don't see how this method is incompatible with your desire to > appoint more operators into available positions in the Operations Area > (which was not required either, but has been the policy for a long > time as well!). > > David Kessens > PS I prefer people calling me David, my name is not Dave. > --- > > >>However, since you raised the issue, I would like to >>shed some light on the WG chair selection process. >> >>Operators are under-represented in the IETF. We feel this problem most >>severely in the *Operations* and Management Area. So, my goal was to >>appoint active operators to working group chair positions. >> >>Specifically, I recruited folks with the following credentials: >> >>- currently active as a network operator >>- currently active in the IETF >>- current and sufficient IETF experience >>- good management and people skills >> >>Needless to say, the candidate pool was small. We are still looking for >>people who fulfill these requirements to fill positions on the OPS >>Directorate and to be candidates for chairing positions that might come >>open in the future. If anyone reading this email feels that they fulfill >>these requirements and are willing to participate in such activities, >>please email Dan and I privately. >> >> Ron >> >>David Kessens wrote: >> >>>Ron, >>> >>>On Tue, Jun 19, 2007 at 03:37:50PM -0400, ext Ron Bonica wrote: >>> >>> >>>>So, we would like for you to welcome Peter Schoenmaker and Chris >>>>Morrow as the new working group chairs. >>> >>> >>>Not to question your particular choice of chairs here, but this seems >>>to be the second time that you don't use an open call for volunteers >>>for the chairposition of a working group in the Ops Area. >>> >>>Is there any particular reason that you are no longer following the >>>tradition of an open call for volunteers for deciding working group >>>chair choices in the Ops Area ? >>> >>>David Kessens >>>--- > > _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Thu Jun 21 11:28:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1OZy-0004rI-Mm; Thu, 21 Jun 2007 11:28:14 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1I1OZx-0004r5-ER for ops-area-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 11:28:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1OZx-0004pU-2Q for ops-area@ietf.org; Thu, 21 Jun 2007 11:28:13 -0400 Received: from smtpproxy1.mitre.org ([192.160.51.76] helo=smtp-bedford.mitre.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I1OZu-0004bY-V6 for ops-area@ietf.org; Thu, 21 Jun 2007 11:28:12 -0400 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 l5LFSADD017838 for ; Thu, 21 Jun 2007 11:28:10 -0400 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 40090BF7D for ; Thu, 21 Jun 2007 11:28:10 -0400 (EDT) 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 l5LFSAsR017825; Thu, 21 Jun 2007 11:28:10 -0400 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 11:28:09 -0400 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: [GROW] WG Chairs Date: Thu, 21 Jun 2007 11:28:15 -0400 Message-ID: <4915F014FDD99049A9C3A8C1B832004F01F391A2@IMCSRV2.MITRE.ORG> In-Reply-To: <467A95E9.50106@juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] Re: [GROW] WG Chairs Thread-Index: Ace0FvD8MNA+qqvfRX6C3VqsOErK3gAAMQMg References: <4678308E.1040107@juniper.net> <20070619230954.GA21109@nsn.com><4679456C.1030308@juniper.net> <20070620183727.GA29685@nsn.com> <467A95E9.50106@juniper.net> From: "Natale, Bob" To: "Ron Bonica" X-OriginalArrivalTime: 21 Jun 2007 15:28:09.0611 (UTC) FILETIME=[C5EB85B0:01C7B418] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Hi Ron, Thanks...I applaud your decision and note that this thread itself has been an example of openness working well. One aspect I would like to suggest is that as important as operators are to the success of O&M Area work, we should also seek out representatives of significant user communities to lead or substantially contribute to our work. While we are all users of the Internet and, therefore, stakeholders in its operational quality, there are also large user communities with specialized needs in certain respects. Industry segments, governmental organizations, NGOs, academic communities, consumers, etc. Given the ubiquity and growing centrality of Internet-enhanced human activity, we should be more deliberate and inclusive wrt user segments, IMHO. Cheers, BobN -----Original Message----- From: Ron Bonica [mailto:rbonica@juniper.net]=20 Sent: Thursday, June 21, 2007 11:15 AM To: David Kessens Cc: ops-area@ietf.org Subject: [OPS-AREA] Re: [GROW] WG Chairs David, OK. I'm convinced. In the future I will make a public call for volunteers. Ron David Kessens wrote: > Ron, >=20 > On Wed, Jun 20, 2007 at 11:19:08AM -0400, Ron Bonica wrote: >=20 >>As you are aware, area directors are not required to post an open call >>for volunteers. >=20 >=20 > Correct. On the other hand, we did establish such a tradition in the > Operations & Management Area in the past few years so I wondered why you > departed from that tradition. I felt that it was both useful in > finding more candidates, but also, even more importantly, it helped us > to find other candidates than the "obvious" candidates, especially from > within the group of active operators. The only real drawback was > that the process took more time and effort for the AD but I felt that > that was really worth it compared to the overall benefits. >=20 > I just don't see how this method is incompatible with your desire to > appoint more operators into available positions in the Operations Area > (which was not required either, but has been the policy for a long > time as well!). >=20 > David Kessens > PS I prefer people calling me David, my name is not Dave. > --- >=20 >=20 >>However, since you raised the issue, I would like to >>shed some light on the WG chair selection process. >> >>Operators are under-represented in the IETF. We feel this problem most >>severely in the *Operations* and Management Area. So, my goal was to >>appoint active operators to working group chair positions. >> >>Specifically, I recruited folks with the following credentials: >> >>- currently active as a network operator >>- currently active in the IETF >>- current and sufficient IETF experience >>- good management and people skills >> >>Needless to say, the candidate pool was small. We are still looking for >>people who fulfill these requirements to fill positions on the OPS >>Directorate and to be candidates for chairing positions that might come >>open in the future. If anyone reading this email feels that they fulfill >>these requirements and are willing to participate in such activities, >>please email Dan and I privately. >> >> Ron >> >>David Kessens wrote: >> >>>Ron, >>> >>>On Tue, Jun 19, 2007 at 03:37:50PM -0400, ext Ron Bonica wrote: >>> >>> >>>>So, we would like for you to welcome Peter Schoenmaker and Chris >>>>Morrow as the new working group chairs. >>> >>> >>>Not to question your particular choice of chairs here, but this seems >>>to be the second time that you don't use an open call for volunteers >>>for the chairposition of a working group in the Ops Area. >>> >>>Is there any particular reason that you are no longer following the >>>tradition of an open call for volunteers for deciding working group >>>chair choices in the Ops Area ? >>> >>>David Kessens >>>--- >=20 >=20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Thu Jun 21 18:38:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1VIX-0008Kc-27; Thu, 21 Jun 2007 18:38:41 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1I1UhV-0004HE-HG for ops-area-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 18:00:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1UhV-0004H6-5r for ops-area@ietf.org; Thu, 21 Jun 2007 18:00:25 -0400 Received: from [2001:418:1:0:230:48ff:fe82:537e] (helo=nagasaki.bogus.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1UhT-0007TD-O0 for ops-area@ietf.org; Thu, 21 Jun 2007 18:00:25 -0400 Received: from [202.65.42.173] (202-65-42-173.pacnog.net.oyster.net.ck [202.65.42.173]) (authenticated bits=0) by nagasaki.bogus.com (8.14.1/8.13.8) with ESMTP id l5LM0Fs8014035 for ; Thu, 21 Jun 2007 22:00:21 GMT (envelope-from joelja@bogus.com) Message-ID: <467AF4EB.2080303@bogus.com> Date: Thu, 21 Jun 2007 15:00:11 -0700 From: Joel Jaeggli User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: ops-area@ietf.org X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.90.2/3487/Thu Jun 21 19:42:41 2007 on nagasaki.bogus.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-Mailman-Approved-At: Thu, 21 Jun 2007 18:38:40 -0400 Subject: [OPS-AREA] GROW - New work? X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org As recently as March, we were discussing shutting down the grow working group as all milestones had been achieved and there was one remaining document. At the time there was support of the then working group chair for such an action? What changed? and what new work do we expect to see there? thanks joelja _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Thu Jun 21 19:35:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1WB2-0005NX-KD; Thu, 21 Jun 2007 19:35:00 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1I1WB0-0005NQ-WF for ops-area-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 19:34:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1WB0-0005NI-Mk for ops-area@ietf.org; Thu, 21 Jun 2007 19:34:58 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1WAz-00082x-7y for ops-area@ietf.org; Thu, 21 Jun 2007 19:34:58 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5LNYrhm004712; Fri, 22 Jun 2007 02:34:55 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 02:34:55 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 02:34:54 +0300 Received: from dadhcp-172019068052.americas.nokia.com ([172.19.68.52]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 02:34:53 +0300 Received: from dadhcp-172019068052.americas.nokia.com (localhost.localdomain [127.0.0.1]) by dadhcp-172019068052.americas.nokia.com (8.13.5/8.13.5) with ESMTP id l5LNYpmY010583; Thu, 21 Jun 2007 16:34:51 -0700 Received: (from david@localhost) by dadhcp-172019068052.americas.nokia.com (8.13.5/8.13.5/Submit) id l5LNYp0g010582; Thu, 21 Jun 2007 16:34:51 -0700 Date: Thu, 21 Jun 2007 16:34:51 -0700 From: David Kessens To: Ron Bonica Message-ID: <20070621233451.GA10537@nsn.com> References: <4678308E.1040107@juniper.net> <20070619230954.GA21109@nsn.com> <4679456C.1030308@juniper.net> <20070620183727.GA29685@nsn.com> <467A95E9.50106@juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <467A95E9.50106@juniper.net> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 21 Jun 2007 23:34:54.0302 (UTC) FILETIME=[C545B7E0:01C7B45C] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ops-area@ietf.org Subject: [OPS-AREA] Re: [GROW] WG Chairs X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Ron, On Thu, Jun 21, 2007 at 11:14:49AM -0400, ext Ron Bonica wrote: > > OK. I'm convinced. In the future I will make a public call for volunteers. Thanks for reconsidering your position. For completeness sake, I believe that this is a good mechanism to use by default - I do see cases where it is simply not worth the effort. One can think of a working group that is in it's final stages with just a single document to go. I am sure that you will be able to make a good judgement call in such cases. David Kessens --- _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Fri Jun 22 08:11:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1hym-0005ji-H2; Fri, 22 Jun 2007 08:11:08 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1I1hyl-0005jd-Ul for ops-area-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 08:11:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1hyl-0005jM-J7 for ops-area@ietf.org; Fri, 22 Jun 2007 08:11:07 -0400 Received: from borg.juniper.net ([207.17.137.119] helo=smtpb.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1hyk-0003N4-9N for ops-area@ietf.org; Fri, 22 Jun 2007 08:11:07 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpb.juniper.net with ESMTP; 22 Jun 2007 05:11:05 -0700 Received: from [172.23.1.54] ([172.23.1.54] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 08:11:04 -0400 Message-ID: <467BBC54.2000002@juniper.net> Date: Fri, 22 Jun 2007 08:11:00 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joel Jaeggli Subject: Re: [OPS-AREA] GROW - New work? References: <467AF4EB.2080303@bogus.com> In-Reply-To: <467AF4EB.2080303@bogus.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jun 2007 12:11:04.0542 (UTC) FILETIME=[680AEFE0:01C7B4C6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Geoff Huston , ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Joel, The GROW chairs are working on a new charter that should address your question. But in the mean time, I will try to give a brief answer. The GROW WG should address the following tasks on an ongoing basis: 1) document trends in routing (table growth, churn etc.) 2) document anomalies in the routing subsystem (e.g., persistent route oscillation, bgp wedgies, etc) 3) recommend BCPs that address undesirable trends in routing 4) generate requirements for the IETF routing area The first two tasks are clearly ongoing. Tends change from year to year and nobody can plan when an anomaly will be discovered. However, we have a little more control over the time line with regard to the third and fourth tasks. Let's explore an example... >From previous work, we have learned that most BGP churn is caused by a very small number of "bad actors". However, we aren't sure what we want to do about it. Many ISPs, as a result of discussion held in NANOG/RIPE/APNIC, have disabled BGP damping. Could this problem be addressed by damping if damping parameters were configured properly? Does BGP damping need better default parameters? If BGP damping won't solve the problem, do we need a new BGP feature that will? I don't know the answers to these questions, but introduce them as examples of the questions that GROW should be asking. You ask if the previous GROW chair supported shutting down the WG in March. I will let Geoff speak for himself on that issue. Ron Joel Jaeggli wrote: > As recently as March, we were discussing shutting down the grow working > group as all milestones had been achieved and there was one remaining > document. > > At the time there was support of the then working group chair for such > an action? > > What changed? and what new work do we expect to see there? > > thanks > joelja > > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www1.ietf.org/mailman/listinfo/ops-area > _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Mon Jun 25 08:17:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2nV4-0007lJ-19; Mon, 25 Jun 2007 08:16:58 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1I2nV2-0007l5-KL for ops-area-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 08:16:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2nV2-0007ka-AH for ops-area@ietf.org; Mon, 25 Jun 2007 08:16:56 -0400 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2nV2-0001o7-25 for ops-area@ietf.org; Mon, 25 Jun 2007 08:16:56 -0400 Received: from [192.168.1.7] (VDSL-151-118-149-96.DNVR.QWEST.NET [151.118.149.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id B6ECA64347; Mon, 25 Jun 2007 06:16:51 -0600 (MDT) In-Reply-To: <467BBC54.2000002@juniper.net> References: <467AF4EB.2080303@bogus.com> <467BBC54.2000002@juniper.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [OPS-AREA] GROW - New work? Date: Mon, 25 Jun 2007 06:16:48 -0600 To: Ron Bonica X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Joel Jaeggli , Geoff Huston , ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org On Jun 22, 2007, at 6:11 AM, Ron Bonica wrote: > Joel, > > The GROW chairs are working on a new charter that should address your > question. But in the mean time, I will try to give a brief answer. > > The GROW WG should address the following tasks on an ongoing basis: > > 1) document trends in routing (table growth, churn etc.) > 2) document anomalies in the routing subsystem (e.g., persistent route > oscillation, bgp wedgies, etc) > 3) recommend BCPs that address undesirable trends in routing > 4) generate requirements for the IETF routing area Just so it doesn't get lost, I sent this email back in March to the grow list about a couple other items: --- From: danny@tcb.net Subject: Re: [GROW] Proposal to close grow working group (decision deferred) Date: March 23, 2007 4:27:15 AM MDT To: grow@ietf.org, david.kessens@nokia.com Cc: rbonica@juniper.net, dromasca@avaya.com [top post only] Two work items that I believe GROW should add to their Goals & Milestones: o I-D reviewing implications of routing design on scalability of intra-domain routing (e.g., impact of hierarchy on paths and implications on routing system resources, impact of path vectors, impact on optimizations like update packing, etc..) o I-D discussing implications of IPv4 & IPv6 bogon and special use addresses. Something like what the v6ops folks tried to capture in the v6ops routing guidelines ID, though it applies equally to IPv4 and needs this WGs full consideration. Neither of the above items are worded as they likely need to be, but the general idea is captured there, i believe. *AND there are 4 operators I know of that have already agreed to work on these items. -danny _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Mon Jun 25 10:16:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2pMx-0002ED-KF; Mon, 25 Jun 2007 10:16:43 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1I2pMw-0002E8-N6 for ops-area-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 10:16:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2pMw-0002E0-DW for ops-area@ietf.org; Mon, 25 Jun 2007 10:16:42 -0400 Received: from kremlin.juniper.net ([207.17.137.120] helo=smtpa.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2pMw-0006Hn-5U for ops-area@ietf.org; Mon, 25 Jun 2007 10:16:42 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpa.juniper.net with ESMTP; 25 Jun 2007 07:16:41 -0700 X-IronPort-AV: i="4.16,460,1175497200"; d="scan'208"; a="24867550:sNHT35824352" Received: from [172.25.51.54] ([172.25.51.54] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 10:16:40 -0400 Message-ID: <467FCE45.7020906@juniper.net> Date: Mon, 25 Jun 2007 10:16:37 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny McPherson Subject: Re: [OPS-AREA] GROW - New work? References: <467AF4EB.2080303@bogus.com> <467BBC54.2000002@juniper.net> In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jun 2007 14:16:40.0072 (UTC) FILETIME=[72CED080:01C7B733] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Joel Jaeggli , "Chris L. Morrow" , Peter Schoenmaker , Geoff Huston , ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Danny, Please work with the GROW chairs to have this added to the charter. I have copied them on this email. Ron Danny McPherson wrote: > > On Jun 22, 2007, at 6:11 AM, Ron Bonica wrote: > >> Joel, >> >> The GROW chairs are working on a new charter that should address your >> question. But in the mean time, I will try to give a brief answer. >> >> The GROW WG should address the following tasks on an ongoing basis: >> >> 1) document trends in routing (table growth, churn etc.) >> 2) document anomalies in the routing subsystem (e.g., persistent route >> oscillation, bgp wedgies, etc) >> 3) recommend BCPs that address undesirable trends in routing >> 4) generate requirements for the IETF routing area > > > Just so it doesn't get lost, I sent this email back in March to > the grow list about a couple other items: > > --- > From: danny@tcb.net > Subject: Re: [GROW] Proposal to close grow working group > (decision deferred) > Date: March 23, 2007 4:27:15 AM MDT > To: grow@ietf.org, david.kessens@nokia.com > Cc: rbonica@juniper.net, dromasca@avaya.com > > [top post only] > > Two work items that I believe GROW should add to their > Goals & Milestones: > > o I-D reviewing implications of routing design on scalability > of intra-domain routing (e.g., impact of hierarchy on paths > and implications on routing system resources, impact of > path vectors, impact on optimizations like update packing, > etc..) > > o I-D discussing implications of IPv4 & IPv6 bogon and > special use addresses. Something like what the v6ops folks > tried to capture in the v6ops routing guidelines ID, though > it applies equally to IPv4 and needs this WGs full > consideration. > > Neither of the above items are worded as they likely need > to be, but the general idea is captured there, i believe. > > *AND there are 4 operators I know of that have already > agreed to work on these items. > > -danny > > > _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Tue Jun 26 15:33:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3GnA-0004l8-Q4; Tue, 26 Jun 2007 15:33:36 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1I3Gn9-0004l1-RE for ops-area-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 15:33:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Gn9-0004kt-HD for ops-area@ietf.org; Tue, 26 Jun 2007 15:33:35 -0400 Received: from nj300815-nj-outbound.net.avaya.com ([198.152.12.100] helo=nj300815-nj-outbound.avaya.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3Gn9-0003wm-8w for ops-area@ietf.org; Tue, 26 Jun 2007 15:33:35 -0400 Received: from 14.140.64.135.in-addr.arpa (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-outbound.avaya.com with ESMTP; 26 Jun 2007 15:32:01 -0400 X-IronPort-AV: i="4.16,464,1175486400"; d="scan'208"; a="31710270:sNHT9285240" 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: Tue, 26 Jun 2007 21:32:00 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] meeting in Chicago Thread-Index: Ace4J7eYwIIla/x9STitcEcGuMlcvAAACYAg From: "Romascanu, Dan (Dan)" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [OPS-AREA] FW: [OPSAWG] meeting in Chicago X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Please take note of the opsawg meeting in Chicago. Any requests for agenda time should be sent to opsawg@ietf.org and/or to Scott and Ted.=20 Dan =20 -----Original Message----- From: Scott O. Bradner [mailto:sob@harvard.edu]=20 Sent: Tuesday, June 26, 2007 10:24 PM To: opsawg@ietf.org Subject: [OPSAWG] meeting in Chicago the opsawg is scheduled to meet Tuesday afternoon at 15:20 - we have a 2 hour slot we are working on the agenda - if you have topics you would like to discuss please let us know -=20 Scott & Ted _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Fri Jun 29 06:18:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4DY6-0006kG-QC; Fri, 29 Jun 2007 06:17:58 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1I4DY4-0006g2-86 for ops-area-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 06:17:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4DXy-0006Rz-Ms; Fri, 29 Jun 2007 06:17:50 -0400 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4DXy-0006Lv-CT; Fri, 29 Jun 2007 06:17:50 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-outbound.avaya.com with ESMTP; 29 Jun 2007 06:17:16 -0400 X-IronPort-AV: i="4.16,474,1175486400"; d="scan'208"; a="35529193:sNHT8690886" 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: Fri, 29 Jun 2007 12:16:40 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for July 5, 2007 Telechat Thread-Index: Ace51bGZD3VD9TOARX+lQsp8kJaqbgAYHqBg From: "Romascanu, Dan (Dan)" To: , "Ops-Nm" , "Aaa-Doctors (E-mail)" , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: Subject: [OPS-AREA] FW: PRELIMINARY Agenda and Package for July 5, 2007 Telechat X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Please find below the preliminary agenda for the 7/5 IESG telechat. Please forward to me all comments and concerns until Wednesday 7/4 COB.=20 Thanks and Regards, Dan 2.1 WG Submissions 2.1.1 New Item o draft-ietf-ipfix-biflow-05.txt Bidirectional Flow Export using IPFIX (Proposed Standard) - 1 of 3=20 Note: Nevil Brownlee is the proto-shepherd=20 Token: Dan Romascanu o draft-ietf-radext-rfc4590bis-01.txt RADIUS Extension for Digest Authentication (Proposed Standard) - 2 of 3=20 Note: A revised version of non-normative Section 6 (Examples) will be provided in order to fix problems detected during the Last Call.=20 Token: Dan Romascanu o draft-ietf-radext-fixes-04.txt Common Remote Authentication Dial In User Service (RADIUS) Implementation=20 Issues and Suggested Fixes (Proposed Standard) - 3 of 3=20 Token: Dan Romascanu 2.1.2 Returning Item o draft-ietf-dhc-server-override-04.txt DHCP Server Identifier Override Suboption (Proposed Standard) - 1 of 2 =20 Note: Bringing this document back to agenda, hopefully with the past issue=20 solved=20 Token: Jari Arkko o draft-ietf-midcom-mib-09.txt Definitions of Managed Objects for Middlebox Communication (Proposed Standard) - 2 of 2=20 Note: Needs positions from the new people.. SEC-DIR Reviewer: Radia Perlman=20 (Radia.Perlman@sun.com). WG Shephard Melinda Shore.=20 Token: Magnus Westerlund 2.2 Individual Submissions 2.2.1 New Item o draft-williams-on-channel-binding-02.txt On the Use of Channel Bindings to Secure Channels (Proposed Standard) - 1=20 of 2=20 Token: Sam Hartman o draft-mcgrew-auth-enc-02.txt An Interface and Algorithms for Authenticated Encryption (Proposed=20 Standard) - 2 of 2=20 Token: Tim Polk 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 NONE 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-martin-ibcs-04.txt Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve=20 Implementations of the BF and BB1 Cryptosystems (Informational) - 1 of 2=20 Token: Tim Polk o draft-mrose-apex-historic-02.txt Reclassification of the APEX RFCs to Historic (Informational) - 2 of 2 =20 Token: Chris Newman =20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area