From ops-area-bounces@ietf.org Tue Jan 02 14:31:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1pLz-0002xB-Fa; Tue, 02 Jan 2007 14:31:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1pLy-0002x3-4w; Tue, 02 Jan 2007 14:31:18 -0500 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 1H1pLu-0007w2-Hj; Tue, 02 Jan 2007 14:31:18 -0500 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with SMTP id l02JVAlN010309; Tue, 2 Jan 2007 14:31:10 -0500 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 0E8EFBF7B; Tue, 2 Jan 2007 14:31:10 -0500 (EST) Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id l02JV9hl010301; Tue, 2 Jan 2007 14:31:09 -0500 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Jan 2007 14:31:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 2 Jan 2007 14:31:07 -0500 Message-ID: <4915F014FDD99049A9C3A8C1B832004F017E22BA@IMCSRV2.MITRE.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OPS-AREA Prague BOF Proposal: SNMP MIB to Ontology translation Thread-Index: AccupIzz+Ehy2S0vSCOVHe02z6sCJA== From: "Natale, Bob" To: X-OriginalArrivalTime: 02 Jan 2007 19:31:09.0716 (UTC) FILETIME=[8E1D7D40:01C72EA4] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df Cc: NETCONF Goes On Subject: [OPS-AREA] OPS-AREA Prague BOF Proposal: SNMP MIB to Ontology translation 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="===============0801822460==" Errors-To: ops-area-bounces@ietf.org This is a multi-part message in MIME format. --===============0801822460== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C72EA4.8D5F3D3F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C72EA4.8D5F3D3F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Sending this proposal to both OPS-AREA and NGO lists, per guidance from Dan. I was worried that it might be a bit too far out there, but Dan convinced me to stick my neck out anyway. :) =20 - - - - - A WG to define standard methods for converting the body of existing SNMP MIBs to OWL-based ontolologies, and standard methods for validating the resulting ontologies. =20 - IETF standard MIBs are the prime target; compliant vendor-specific enterprise MIBs would naturally follow. =20 - Such a mechanism could be an accelerant for the new breed of "SOA Management" vendors who are not well-versed in IETF=20 application, systems, and network management. =20 - This WG would examine the viability of starting from or building off the existing (non-standard) methods of converting SNMP MIBs to XML schema and documents. =20 - This WG would examine the viability of extending the NETCONF protocol to work with such ontologies. =20 - This WG would then examine the viability of build-time extensibility and run-time composability mechanisms associated with compliant ontologies. =20 - At the end of this process, compliant ontologies developed independently of pre-existing SNMP MIBs would be indistinguishable from those developed from such MIBs, enabling a more modern and SOA-aware method (OWL-S) of managed object data model construction.=20 =20 - At the end of this process, compliant ontologies might be extensible in ways that are incompatible with reverse translation back into SNMP MIBs. Such reverse translation is not a goal of this effort. =20 The underlying predicates are: - The body of SNMP MIBs comprises management knowledge and artifacts of incalculable value to the industry, irrespective of instrumentation mechanisms, access methods, and protocol(s) used to manipulate MIB data. - The nascent "SOA Management" industry could be relatively quickly enriched, even if via WS-to/from-SNMP proxies, via more SOA-friendly management data models. The expectation here is that ontology-based management data models will be more accessible to and usable by "SOA Management" tools than ASN.1 MIBs are. =20 "SOA Management" in quotes throughout because, while this label is being used by a dozen or so significant vendors, I'm not sure it's accurately descriptive or that it will stick long-term. - - - - - =20 Personally, I see a clear and near-term real-world need for such standard methods in my own work, and I believe that the emerging "SOA Management" industry desperately needs it (but might not know it yet) -- but I admit that most of that is purely subjective assessment at this time. I have the impression that earlier MIB-to-XML undertaken by some thought-leaders among us was good work that did not get widely deployed ("commercialized" is what I really mean). If that is accurate, we should consider the causes and whether they will have a similar effect wrt this proposal. =20 Lastly, if anyone feels that this might be a good idea but is not as well-expressed as it could be above, please revise as appropriate. Another MITRE reviewer has commented that specifying OWL and OWL-S at this stage might be premature. That's probably a good point, but my own research has really not turned up a viable alternative (based on my limited knowledge/judgment). =20 Cheers, BobN Principal Engineer, GIG NetOps Enterprise Services Systems Engineering www.mitre.org =20 =20 ------_=_NextPart_001_01C72EA4.8D5F3D3F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Sending this proposal to both OPS-AREA and = NGO lists,=20 per guidance from Dan.  I was worried that it might be a bit too = far out=20 there, but Dan convinced me to stick my neck out anyway. = :)
 
- -=20 - - -
A WG to = define standard=20 methods for converting the body of existing SNMP MIBs to OWL-based=20 ontolologies, and standard methods for = validating=20 the resulting ontologies.
 
- IETF standard MIBs = are the prime=20 target; compliant vendor-specific enterprise MIBs would naturally=20 follow.
 
- Such a mechanism = could be an=20 accelerant for the new breed of "SOA Management" vendors who are not = well-versed=20 in IETF
application, systems, and network management.
  =
- This=20 WG would examine the viability of starting from or building off the = existing=20 (non-standard) methods of converting SNMP MIBs to XML schema and=20 documents.
 
- This WG would = examine the=20 viability of extending the NETCONF protocol to work with such=20 ontologies.
 
- This WG would then = examine the=20 viability of build-time extensibility and run-time composability = mechanisms=20 associated with compliant ontologies.
 
- At the end of this = process,=20 compliant ontologies developed independently of pre-existing SNMP MIBs = would be=20 indistinguishable from those developed from such MIBs, enabling a more = modern=20 and SOA-aware method (OWL-S) of managed object data model construction.=20
 
- At=20 the end of this process, compliant ontologies might be extensible in = ways that=20 are incompatible with reverse translation back into SNMP MIBs.  = Such=20 reverse translation is not a goal of this effort.
 
The=20 underlying predicates are:
-=20 The body of SNMP MIBs comprises management knowledge and artifacts of=20 incalculable value to the industry, irrespective of instrumentation = mechanisms,=20 access methods, and protocol(s) used to manipulate MIB=20 data.
-=20 The nascent "SOA Management" industry could be relatively quickly = enriched, even=20 if via WS<whatever>-to/from-SNMP proxies, via more SOA-friendly = management=20 data models.  The expectation here is that ontology-based = management data=20 models will be more accessible to and usable by "SOA Management" tools = than=20 ASN.1 MIBs are.
 
"SOA=20 Management" in quotes throughout because, while this label is being used = by a=20 dozen or so significant vendors, I'm not sure it's accurately = descriptive or=20 that it will stick long-term.
- -=20 - - -
 
Personally, I see a clear and near-term real-world need for=20 such standard methods in my own work, and I believe that the = emerging=20 "SOA Management" industry desperately needs it (but might not know it = yet) --=20 but I admit that most of that is purely subjective assessment at this=20 time.  I have the impression that earlier MIB-to-XML undertaken by = some=20 thought-leaders among us was good work that did not get widely deployed=20 ("commercialized" is what I really mean).  If that is accurate, we = should=20 consider the causes and whether they will have a similar effect wrt this = proposal.
 
Lastly, if anyone feels that this might be a good idea but is = not as=20 well-expressed as it could be above, please revise as appropriate.  = Another=20 MITRE reviewer has commented that specifying OWL and OWL-S at this stage = might=20 be premature.  That's probably a good point, but my own research = has really=20 not turned up a viable alternative (based on my limited=20 knowledge/judgment).
 
Cheers,
BobN
Principal Engineer, GIG NetOps
Enterprise Services Systems Engineering
www.mitre.org
 
 
------_=_NextPart_001_01C72EA4.8D5F3D3F-- --===============0801822460== 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 --===============0801822460==-- From ops-area-bounces@ietf.org Tue Jan 02 15:24:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1qBX-00069C-So; Tue, 02 Jan 2007 15:24:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1qBW-00068u-I3 for ops-area@ietf.org; Tue, 02 Jan 2007 15:24:34 -0500 Received: from omr5.networksolutionsemail.com ([205.178.146.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1qBU-0007GT-Jz for ops-area@ietf.org; Tue, 02 Jan 2007 15:24:34 -0500 Received: from mail.networksolutionsemail.com (ns-omr5.mgt.netsol.com [10.49.6.68]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l02KOUif013213 for ; Tue, 2 Jan 2007 15:24:30 -0500 Received: (qmail 3281 invoked by uid 78); 2 Jan 2007 20:24:29 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.56.110) by ns-omr5.lb.hosting.dc2.netsol.com with SMTP; 2 Jan 2007 20:24:29 -0000 Message-ID: <459ABF71.60004@andybierman.com> Date: Tue, 02 Jan 2007 12:24:17 -0800 From: Andy Bierman User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Natale, Bob" References: <4915F014FDD99049A9C3A8C1B832004F017E22BA@IMCSRV2.MITRE.ORG> In-Reply-To: <4915F014FDD99049A9C3A8C1B832004F017E22BA@IMCSRV2.MITRE.ORG> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: NETCONF Goes On , ops-area@ietf.org Subject: [OPS-AREA] Re: [NGO] OPS-AREA Prague BOF Proposal: SNMP MIB to Ontology translation 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, > Hi, > > Sending this proposal to both OPS-AREA and NGO lists, per guidance from > Dan. I was worried that it might be a bit too far out there, but Dan > convinced me to stick my neck out anyway. :) This sounds great to me, especially if you are willing to Chair the WG. ;-) I think NETCONF can support a service-oriented API, with service-specific RPC methods and notifications. IMO, the CLI model (config service, show service, etc.) is already closer to an SOA than SNMP/SMIv2, and this is how a lot of NE devices are currently being managed. However, high-level procedures to manage specific services, using standard MIB objects as parameters, should be possible. In am very much in favor of abandoning the "raw data operation" API mindset of SNMP (and NETCONF edit-config!), and viewing the API as a collection of services, each with their own set of procedures and notification definitions. The fly in the ointment is the startup config file which represents the entire configuration upon reboot -- the 'document-oriented' APIs (e.g., CLI, NETCONF standard operations) assume the entire desired state of the NE device can be represented in text commands, and any box of the same device-type can consume this startup config file at boot-time and function correctly within the network. Operators usually want visibility (i.e., human readability) of this file. Any SOA-based API, whether SNMP or CLI based, will need to be compatible with this important feature. Andy > > - - - - - > A WG to define standard methods for converting the body of existing SNMP > MIBs to OWL-based ontolologies, and standard methods for validating the > resulting ontologies. > > - IETF standard MIBs are the prime target; compliant vendor-specific > enterprise MIBs would naturally follow. > > - Such a mechanism could be an accelerant for the new breed of "SOA > Management" vendors who are not well-versed in IETF > application, systems, and network management. > > - This WG would examine the viability of starting from or building off > the existing (non-standard) methods of converting SNMP MIBs to XML > schema and documents. > > - This WG would examine the viability of extending the NETCONF protocol > to work with such ontologies. > > - This WG would then examine the viability of build-time extensibility > and run-time composability mechanisms associated with compliant ontologies. > > - At the end of this process, compliant ontologies developed > independently of pre-existing SNMP MIBs would be indistinguishable from > those developed from such MIBs, enabling a more modern and SOA-aware > method (OWL-S) of managed object data model construction. > > - At the end of this process, compliant ontologies might be extensible > in ways that are incompatible with reverse translation back into SNMP > MIBs. Such reverse translation is not a goal of this effort. > > The underlying predicates are: > - The body of SNMP MIBs comprises management knowledge and artifacts of > incalculable value to the industry, irrespective of instrumentation > mechanisms, access methods, and protocol(s) used to manipulate MIB data. > - The nascent "SOA Management" industry could be relatively quickly > enriched, even if via WS-to/from-SNMP proxies, via more > SOA-friendly management data models. The expectation here is that > ontology-based management data models will be more accessible to and > usable by "SOA Management" tools than ASN.1 MIBs are. > > "SOA Management" in quotes throughout because, while this label is being > used by a dozen or so significant vendors, I'm not sure it's accurately > descriptive or that it will stick long-term. > - - - - - > > Personally, I see a clear and near-term real-world need for > such standard methods in my own work, and I believe that the emerging > "SOA Management" industry desperately needs it (but might not know it > yet) -- but I admit that most of that is purely subjective assessment at > this time. I have the impression that earlier MIB-to-XML undertaken by > some thought-leaders among us was good work that did not get widely > deployed ("commercialized" is what I really mean). If that is accurate, > we should consider the causes and whether they will have a similar > effect wrt this proposal. > > Lastly, if anyone feels that this might be a good idea but is not as > well-expressed as it could be above, please revise as appropriate. > Another MITRE reviewer has commented that specifying OWL and OWL-S at > this stage might be premature. That's probably a good point, but my own > research has really not turned up a viable alternative (based on my > limited knowledge/judgment). > > Cheers, > BobN > Principal Engineer, GIG NetOps > Enterprise Services Systems Engineering > www.mitre.org > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > NGO mailing list > NGO@ietf.org > https://www1.ietf.org/mailman/listinfo/ngo _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Jan 03 03:43:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H21i4-0000Qw-Tw; Wed, 03 Jan 2007 03:42:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H21i3-0000Pu-UN; Wed, 03 Jan 2007 03:42:55 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H21i0-0006Gw-8M; Wed, 03 Jan 2007 03:42:55 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l038girD007670; Wed, 3 Jan 2007 03:42:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Received: from 300216erh2.post.avaya.com ([198.152.7.49]) by IS0004AVEXU1.global.avaya.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 19 Dec 2006 09:54:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Received: from nj300815-ier2.net.avaya.com (nj300815-ier2.net.avaya.com [198.152.12.103]) by 300216erh2.post.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBJ9sjjv007652 for ; Tue, 19 Dec 2006 02:54:46 -0700 Received: from nj300815-nj-iereast.avaya.com (h198-152-12-104.avaya.com [198.152.12.104]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBJ7WCMs013530 for ; Tue, 19 Dec 2006 02:54:47 -0500 Received: from bierator.ibr.cs.tu-bs.de ([134.169.34.9]) by nj300815-nj-iereast.avaya.com with ESMTP; 19 Dec 2006 02:53:32 -0500 Received: from bierator.ibr.cs.tu-bs.de (list@localhost [127.0.0.1]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kBJ7s3F0016453; Tue, 19 Dec 2006 08:54:08 +0100 Received: from nj300815-ier2.net.avaya.com (nj300815-ier2.net.avaya.com [198.152.12.103]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kBJ7rsAG016433 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 19 Dec 2006 08:54:00 +0100 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBJ7rqKT024301 for ; Tue, 19 Dec 2006 02:53:53 -0500 Received: from 300815erh2.post.avaya.com ([198.152.6.49]) by IS0004AVEXU1.global.avaya.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 18 Dec 2006 21:32:37 +0200 Received: from co300216-ier2.net.avaya.com (co300216-ier2.net.avaya.com [198.152.13.103]) by 300815erh2.post.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBIJWa1g000326 for ; Mon, 18 Dec 2006 14:32:36 -0500 Received: from co300216-co-ierwest.avaya.com (h198-152-13-104.avaya.com [198.152.13.104]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBIJRLYO001667 for ; Mon, 18 Dec 2006 14:32:30 -0500 Received: from lists.ietf.org (HELO megatron.ietf.org) ([156.154.16.145]) by co300216-co-ierwest.avaya.com with ESMTP; 18 Dec 2006 14:31:38 -0500 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwOCk-00055A-Iu; Mon, 18 Dec 2006 14:31:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwOCj-00054X-Hm; Mon, 18 Dec 2006 14:31:17 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwOCh-0001Sr-2S; Mon, 18 Dec 2006 14:31:17 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBIJVBEC009649; Mon, 18 Dec 2006 14:31:14 -0500 content-class: urn:content-classes:message Date: Wed, 3 Jan 2007 10:42:43 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OPS Area BOFs in Prague Thread-Index: AcccV6ii14zulLX7R3CFlQvi3jCmlA== From: "Romascanu, Dan \(Dan\)" To: , , "MIB Doctors" , , "DNS Directorate" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: nmrg@ibr.cs.tu-bs.de Subject: [OPS-AREA] OPS Area BOFs in Prague 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 Happy New Year! This is a final reminder that we shall schedule for the Prague IETF a number of BOFs or mini-BOFs in the OPS area meeting slots with the intention to bring to attention new ideas in the operations and management area and discuss which of those are worth becoming subject for future standardization, research or prototyping work. We (David and Dan) will be meeting by the end of the month to discuss the proposed BOF subjects, please send your proposals as soon as you can, but not later than January 24. Any of the lists in the area would do, but ops-area@ietf.org would probably be the best.=20 Note that if you intent to ask for a separate and dedicated BOF session rather than for a mini-BOF in the OPS area meeting slots the deadline for submitting a BOF request is January 15.=20 David and Dan _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Thu Jan 04 14:33:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2YKv-0008Fs-2C; Thu, 04 Jan 2007 14:33:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2YKt-0008F9-JP for ops-area@ietf.org; Thu, 04 Jan 2007 14:33:11 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2YKs-0004Qb-0I for ops-area@ietf.org; Thu, 04 Jan 2007 14:33:11 -0500 Received: (qmail 4368 invoked from network); 4 Jan 2007 11:33:06 -0800 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 4 Jan 2007 11:33:06 -0800 Date: Thu, 4 Jan 2007 11:33:06 -0800 (PST) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: Dan Romascanu Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-2133786286-443762216-1167921836=:11106" Content-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: OPS Area Subject: [OPS-AREA] Request to sponsor draft-heard-rfc4181-update-00.txt for consideration as a BCP 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 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---2133786286-443762216-1167921836=:11106 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Content-ID: Dan, As noted in the attached I-D ACTION announcement, I have prepared an individual submission draft-heard-rfc4181-update-00.txt that provides the updates to RFC 4181, "Guidelines for Authors and Reviewers of MIB Documents," that are needed to bring it into alignment with RFC 4748. The substantive content is all in the following paragraph from Section 2.1 of the draft: In the copyright notice templates in Section 3.7, replace all occurrences of "The Internet Society" with "The IETF Trust". Since conformance to the rules in RFC 4748 will become manadatory starting in February 2007, an update to RFC 4181 should be approved as a BCP and published as soon as possible. I therefore request that you, as the responsible AD, sponsor this draft for consideration as a BCP. I acknowledge that it would be preferable to republish the MIB review guidelines document in its entirety. Unfortunately, I do not have the time to serve anymore as editor of that document, and the person who has volunteered to take over that job is presently busy with other things. I am therefore offering this draft as an interim delta document, with the hope and expectation that it will be replaced by a new document in the not too distant future. I'm cc:'ing this request to the OPS Area mailing list, and invite those who wish to comment to do so on that list. Regards and thanks, Mike Heard ---2133786286-443762216-1167921836=:11106 Content-Type: MESSAGE/RFC822; CHARSET=US-ASCII Content-ID: Content-Description: I-D ACTION:draft-heard-rfc4181-update-00.txt (fwd) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2D4S-000469-5U; Wed, 03 Jan 2007 15:50:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2D4E-0003ZE-1K for i-d-announce@ietf.org; Wed, 03 Jan 2007 15:50:34 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H2D4C-0005GB-LN for i-d-announce@ietf.org; Wed, 03 Jan 2007 15:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 5C0F6176A6 for ; Wed, 3 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H2D3h-0001mK-Ub for i-d-announce@ietf.org; Wed, 03 Jan 2007 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 03 Jan 2007 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Subject: I-D ACTION:draft-heard-rfc4181-update-00.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: i-d-announce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RFC 4181 Update to Recognize the IETF Trust Author(s) : C. Heard Filename : draft-heard-rfc4181-update-00.txt Pages : Date : 2007-1-3 This document updates RFC 4181, "Guidelines for Authors and Reviewers of MIB Documents", to recognize the creation of the IETF Trust. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-heard-rfc4181-update-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-heard-rfc4181-update-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-heard-rfc4181-update-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-3132213.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-heard-rfc4181-update-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-heard-rfc4181-update-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-3132213.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- ---2133786286-443762216-1167921836=:11106 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 ---2133786286-443762216-1167921836=:11106-- From ops-area-bounces@ietf.org Thu Jan 04 14:45:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2YWD-00052k-23; Thu, 04 Jan 2007 14:44:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2YWC-00052f-2k for ops-area@ietf.org; Thu, 04 Jan 2007 14:44:52 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2YWA-0006ss-O4 for ops-area@ietf.org; Thu, 04 Jan 2007 14:44:52 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l04Jilgi022768 for ; Thu, 4 Jan 2007 14:44:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Jan 2007 21:44:46 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request to sponsor draft-heard-rfc4181-update-00.txt for consideration as a BCP Thread-Index: AccwN0rwrt1H4XuhR8+Iufey27K9TQAAEwtQ From: "Romascanu, Dan \(Dan\)" To: "C. M. Heard" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: OPS Area Subject: [OPS-AREA] RE: Request to sponsor draft-heard-rfc4181-update-00.txt for consideration as a BCP 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 Thanks, Mike.=20 OPS Area and MIB Doctors,=20 Please comment on Mike's request until 1/11.=20 The process of Area Director sponsoring of documents is described in http://www.ietf.org/internet-drafts/draft-iesg-sponsoring-guidelines-00. txt Thanks and Regards, Dan =20 =20 > -----Original Message----- > From: C. M. Heard [mailto:heard@pobox.com]=20 > Sent: Thursday, January 04, 2007 9:33 PM > To: Romascanu, Dan (Dan) > Cc: OPS Area > Subject: Request to sponsor draft-heard-rfc4181-update-00.txt=20 > for consideration as a BCP >=20 > Dan, >=20 > As noted in the attached I-D ACTION announcement, I have=20 > prepared an individual submission=20 > draft-heard-rfc4181-update-00.txt that provides the updates=20 > to RFC 4181, "Guidelines for Authors and Reviewers of MIB=20 > Documents," that are needed to bring it into alignment with=20 > RFC 4748. The substantive content is all in the following=20 > paragraph from Section 2.1 of the draft: >=20 > In the copyright notice templates in Section 3.7, replace all > occurrences of "The Internet Society" with "The IETF Trust". >=20 > Since conformance to the rules in RFC 4748 will become=20 > manadatory starting in February 2007, an update to RFC 4181=20 > should be approved as a BCP and published as soon as=20 > possible. I therefore request that you, as the responsible=20 > AD, sponsor this draft for consideration as a BCP. >=20 > I acknowledge that it would be preferable to republish the=20 > MIB review guidelines document in its entirety. =20 > Unfortunately, I do not have the time to serve anymore as=20 > editor of that document, and the person who has volunteered=20 > to take over that job is presently busy with other things. I=20 > am therefore offering this draft as an interim delta=20 > document, with the hope and expectation that it will be=20 > replaced by a new document in the not too distant future. >=20 > I'm cc:'ing this request to the OPS Area mailing list, and=20 > invite those who wish to comment to do so on that list. >=20 > Regards and thanks, >=20 > Mike Heard >=20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Thu Jan 04 14:46:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2YXP-0005LV-L4; Thu, 04 Jan 2007 14:46:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2YXO-0005L2-El; Thu, 04 Jan 2007 14:46:06 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2YXM-00077V-1m; Thu, 04 Jan 2007 14:46:06 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l04Jjw4n011274; Thu, 4 Jan 2007 14:45:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Jan 2007 21:45:57 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request to sponsor draft-heard-rfc4181-update-00.txt for consideration as a BCP Thread-Index: AccwN0rwrt1H4XuhR8+Iufey27K9TQAAEwtQ From: "Romascanu, Dan \(Dan\)" To: "C. M. Heard" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: MIB Doctors , OPS Area Subject: [OPS-AREA] RE: Request to sponsor draft-heard-rfc4181-update-00.txt for consideration as a BCP 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 Thanks, Mike.=20 OPS Area and MIB Doctors,=20 Please comment on Mike's request until 1/11.=20 The process of Area Director sponsoring of documents is described in http://www.ietf.org/internet-drafts/draft-iesg-sponsoring-guidelines-00. txt Thanks and Regards, Dan =20 =20 > -----Original Message----- > From: C. M. Heard [mailto:heard@pobox.com]=20 > Sent: Thursday, January 04, 2007 9:33 PM > To: Romascanu, Dan (Dan) > Cc: OPS Area > Subject: Request to sponsor draft-heard-rfc4181-update-00.txt=20 > for consideration as a BCP >=20 > Dan, >=20 > As noted in the attached I-D ACTION announcement, I have=20 > prepared an individual submission=20 > draft-heard-rfc4181-update-00.txt that provides the updates=20 > to RFC 4181, "Guidelines for Authors and Reviewers of MIB=20 > Documents," that are needed to bring it into alignment with=20 > RFC 4748. The substantive content is all in the following=20 > paragraph from Section 2.1 of the draft: >=20 > In the copyright notice templates in Section 3.7, replace all > occurrences of "The Internet Society" with "The IETF Trust". >=20 > Since conformance to the rules in RFC 4748 will become=20 > manadatory starting in February 2007, an update to RFC 4181=20 > should be approved as a BCP and published as soon as=20 > possible. I therefore request that you, as the responsible=20 > AD, sponsor this draft for consideration as a BCP. >=20 > I acknowledge that it would be preferable to republish the=20 > MIB review guidelines document in its entirety. =20 > Unfortunately, I do not have the time to serve anymore as=20 > editor of that document, and the person who has volunteered=20 > to take over that job is presently busy with other things. I=20 > am therefore offering this draft as an interim delta=20 > document, with the hope and expectation that it will be=20 > replaced by a new document in the not too distant future. >=20 > I'm cc:'ing this request to the OPS Area mailing list, and=20 > invite those who wish to comment to do so on that list. >=20 > Regards and thanks, >=20 > Mike Heard >=20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Thu Jan 04 15:08:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2YsX-0003vk-Kf; Thu, 04 Jan 2007 15:07:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2YsV-0003ve-7g for ops-area@ietf.org; Thu, 04 Jan 2007 15:07:55 -0500 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2YsU-0004af-L8 for ops-area@ietf.org; Thu, 04 Jan 2007 15:07:55 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id l04K7dr9016066; Thu, 4 Jan 2007 22:07:39 +0200 Date: Thu, 4 Jan 2007 22:07:39 +0200 (EET) From: Pekka Savola To: "Romascanu, Dan (Dan)" Subject: Re: [OPS-AREA] RE: Request to sponsor draft-heard-rfc4181-update-00.txt for consideration as a BCP In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.7/2412/Thu Jan 4 02:53:52 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, NO_RELAYS autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: "C. M. Heard" , OPS Area 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 Thu, 4 Jan 2007, Romascanu, Dan (Dan) wrote: > Thanks, Mike. > > OPS Area and MIB Doctors, > > Please comment on Mike's request until 1/11. > > The process of Area Director sponsoring of documents is described in > http://www.ietf.org/internet-drafts/draft-iesg-sponsoring-guidelines-00. > txt This is a bit broader context comment (and should not necessarily block this document), but I'm not sure how scalable it is to maintain MIB review guidelines in the RFC series. Certainly, we need to have a mechanism to establish IETF consensus on those guidelines, but as the requirements change quite often, I'd encourage considering finding another way to maintain and publish the guidelines. >> -----Original Message----- >> From: C. M. Heard [mailto:heard@pobox.com] >> Sent: Thursday, January 04, 2007 9:33 PM >> To: Romascanu, Dan (Dan) >> Cc: OPS Area >> Subject: Request to sponsor draft-heard-rfc4181-update-00.txt >> for consideration as a BCP >> >> Dan, >> >> As noted in the attached I-D ACTION announcement, I have >> prepared an individual submission >> draft-heard-rfc4181-update-00.txt that provides the updates >> to RFC 4181, "Guidelines for Authors and Reviewers of MIB >> Documents," that are needed to bring it into alignment with >> RFC 4748. The substantive content is all in the following >> paragraph from Section 2.1 of the draft: >> >> In the copyright notice templates in Section 3.7, replace all >> occurrences of "The Internet Society" with "The IETF Trust". >> >> Since conformance to the rules in RFC 4748 will become >> manadatory starting in February 2007, an update to RFC 4181 >> should be approved as a BCP and published as soon as >> possible. I therefore request that you, as the responsible >> AD, sponsor this draft for consideration as a BCP. >> >> I acknowledge that it would be preferable to republish the >> MIB review guidelines document in its entirety. >> Unfortunately, I do not have the time to serve anymore as >> editor of that document, and the person who has volunteered >> to take over that job is presently busy with other things. I >> am therefore offering this draft as an interim delta >> document, with the hope and expectation that it will be >> replaced by a new document in the not too distant future. >> >> I'm cc:'ing this request to the OPS Area mailing list, and >> invite those who wish to comment to do so on that list. >> >> Regards and thanks, >> >> Mike Heard >> > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www1.ietf.org/mailman/listinfo/ops-area > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Thu Jan 04 15:24:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Z85-0005iC-Cy; Thu, 04 Jan 2007 15:24:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Z84-0005f6-2M for ops-area@ietf.org; Thu, 04 Jan 2007 15:24:00 -0500 Received: from smtp-bedford.mitre.org ([192.160.51.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Z81-0001vP-NY for ops-area@ietf.org; Thu, 04 Jan 2007 15:24:00 -0500 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with SMTP id l04KNtut015991 for ; Thu, 4 Jan 2007 15:23:55 -0500 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 44060BEFB for ; Thu, 4 Jan 2007 15:23:55 -0500 (EST) Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id l04KNt55015986; Thu, 4 Jan 2007 15:23:55 -0500 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 15:23:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [OPS-AREA] RE: Request to sponsordraft-heard-rfc4181-update-00.txt for consideration as a BCP Date: Thu, 4 Jan 2007 15:23:54 -0500 Message-ID: <4915F014FDD99049A9C3A8C1B832004F017E267D@IMCSRV2.MITRE.ORG> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] RE: Request to sponsordraft-heard-rfc4181-update-00.txt for consideration as a BCP Thread-Index: AccwPB/mCz4fnuImQ9qH5Y2c2chOiwAAMHMQ From: "Natale, Bob" To: "Pekka Savola" X-OriginalArrivalTime: 04 Jan 2007 20:23:54.0675 (UTC) FILETIME=[41676830:01C7303E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: OPS Area 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 Pekka, Could you please quantify "quite often"? (I see that the current version was published in Sept of 2005.) I'm not questioning your judgment, but my impression is that MIB guidelines should not, in fact, change all that often...? How often is too often to be in the RFC series? Cheers, BobN -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi]=20 Sent: Thursday, January 04, 2007 3:08 PM To: Romascanu, Dan (Dan) Cc: C. M. Heard; OPS Area Subject: Re: [OPS-AREA] RE: Request to sponsordraft-heard-rfc4181-update-00.txt for consideration as a BCP On Thu, 4 Jan 2007, Romascanu, Dan (Dan) wrote: > Thanks, Mike. > > OPS Area and MIB Doctors, > > Please comment on Mike's request until 1/11. > > The process of Area Director sponsoring of documents is described in > http://www.ietf.org/internet-drafts/draft-iesg-sponsoring-guidelines-00 . > txt This is a bit broader context comment (and should not necessarily=20 block this document), but I'm not sure how scalable it is to maintain=20 MIB review guidelines in the RFC series. Certainly, we need to have a=20 mechanism to establish IETF consensus on those guidelines, but as the=20 requirements change quite often, I'd encourage considering finding=20 another way to maintain and publish the guidelines. >> -----Original Message----- >> From: C. M. Heard [mailto:heard@pobox.com] >> Sent: Thursday, January 04, 2007 9:33 PM >> To: Romascanu, Dan (Dan) >> Cc: OPS Area >> Subject: Request to sponsor draft-heard-rfc4181-update-00.txt >> for consideration as a BCP >> >> Dan, >> >> As noted in the attached I-D ACTION announcement, I have >> prepared an individual submission >> draft-heard-rfc4181-update-00.txt that provides the updates >> to RFC 4181, "Guidelines for Authors and Reviewers of MIB >> Documents," that are needed to bring it into alignment with >> RFC 4748. The substantive content is all in the following >> paragraph from Section 2.1 of the draft: >> >> In the copyright notice templates in Section 3.7, replace all >> occurrences of "The Internet Society" with "The IETF Trust". >> >> Since conformance to the rules in RFC 4748 will become >> manadatory starting in February 2007, an update to RFC 4181 >> should be approved as a BCP and published as soon as >> possible. I therefore request that you, as the responsible >> AD, sponsor this draft for consideration as a BCP. >> >> I acknowledge that it would be preferable to republish the >> MIB review guidelines document in its entirety. >> Unfortunately, I do not have the time to serve anymore as >> editor of that document, and the person who has volunteered >> to take over that job is presently busy with other things. I >> am therefore offering this draft as an interim delta >> document, with the hope and expectation that it will be >> replaced by a new document in the not too distant future. >> >> I'm cc:'ing this request to the OPS Area mailing list, and >> invite those who wish to comment to do so on that list. >> >> Regards and thanks, >> >> Mike Heard >> > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www1.ietf.org/mailman/listinfo/ops-area > --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ 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 Jan 04 15:28:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ZCM-0007kw-6W; Thu, 04 Jan 2007 15:28:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ZCK-0007kr-Eg for ops-area@ietf.org; Thu, 04 Jan 2007 15:28:24 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2ZCJ-0004RO-2D for ops-area@ietf.org; Thu, 04 Jan 2007 15:28:24 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l04KSL5M008795 for ; Thu, 4 Jan 2007 15:28:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [OPS-AREA] RE: Request to sponsor draft-heard-rfc4181-update-00.txt for consideration as a BCP Date: Thu, 4 Jan 2007 22:28:21 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] RE: Request to sponsor draft-heard-rfc4181-update-00.txt for consideration as a BCP Thread-Index: AccwPC2wb/K5LA5tSrGeMLzA4bkwwQAAlA2A From: "Romascanu, Dan \(Dan\)" To: "Pekka Savola" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: "C. M. Heard" , OPS Area 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 The current thinking in the OPS area is that updating periodically the RFC 4181 BCP document would do the job.=20 This specific update proposed here has a very limited scope dictated by the need to align with RFC 4748.=20 Dan =20 =20 > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi]=20 > This is a bit broader context comment (and should not=20 > necessarily block this document), but I'm not sure how=20 > scalable it is to maintain MIB review guidelines in the RFC=20 > series. Certainly, we need to have a mechanism to establish=20 > IETF consensus on those guidelines, but as the requirements=20 > change quite often, I'd encourage considering finding another=20 > way to maintain and publish the guidelines. >=20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Thu Jan 04 15:43:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ZRB-0000nq-GH; Thu, 04 Jan 2007 15:43:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ZR9-0000nZ-Nv for ops-area@ietf.org; Thu, 04 Jan 2007 15:43:43 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2ZR8-00024y-Ba for ops-area@ietf.org; Thu, 04 Jan 2007 15:43:43 -0500 Received: (qmail 27095 invoked from network); 4 Jan 2007 12:43:37 -0800 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 4 Jan 2007 12:43:37 -0800 Date: Thu, 4 Jan 2007 12:43:37 -0800 (PST) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: OPS Area Subject: Re: [OPS-AREA] Request to sponsor draft-heard-rfc4181-update-00.txt for consideration as a BCP In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Thu, 4 Jan 2007, Pekka Savola wrote: > This is a bit broader context comment (and should not necessarily > block this document), but I'm not sure how scalable it is to > maintain MIB review guidelines in the RFC series. Certainly, we > need to have a mechanism to establish IETF consensus on those > guidelines, but as the requirements change quite often, I'd > encourage considering finding another way to maintain and publish > the guidelines. I do hope that folks will accept this delta document as an acceptable interim measure, since it's the only way I can see to keep our procedure documents up-to-date with a February deadline looming. That said, I actually agree with Pekka's comment, though perhaps not for the same reasons that Pekka made it. The parts of the MIB document review guidelines document that actually deal with MIB modules had very few changes between the -02 draft issued in August 2003 and the -04 draft issued in January 2005, which is the one that eventually became RFC 4181 in September 2005. The vast majority of the changes were with document review criteria, most of which would apply to IETF documents in general. The biggest part of the long delay was spent waiting for the IPR working group to get RFCs 3978 and 3979 published. Now more churn from RFC 4748 and still more to come. This indeed does not scale! Mike _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Thu Jan 04 15:50:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ZX4-00024j-5c; Thu, 04 Jan 2007 15:49:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ZX2-000248-CI; Thu, 04 Jan 2007 15:49:48 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2ZX0-0003jN-19; Thu, 04 Jan 2007 15:49:48 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l04KndkP025655; Thu, 4 Jan 2007 15:49:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MIB-DOCTORS] Re: [OPS-AREA] Request to sponsor draft-heard-rfc4181-update-00.txt for consideration as a BCP Date: Thu, 4 Jan 2007 22:49:39 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MIB-DOCTORS] Re: [OPS-AREA] Request to sponsor draft-heard-rfc4181-update-00.txt for consideration as a BCP Thread-Index: AccwQSlKjSMC9g1CRVSgLm+LuecbBQAAG6rA From: "Romascanu, Dan \(Dan\)" To: "C. M. Heard" , "OPS Area" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: MIB Doctors 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 Frankly I am not losing sleep over this. I believe that 4181 works pretty well, and that if we could update the document each two-three years it would be good enough. The more pressing issue is resources, and following a different process will not help.=20 Dan =20 =20 > -----Original Message----- > From: C. M. Heard [mailto:heard@pobox.com]=20 > Sent: Thursday, January 04, 2007 10:44 PM > To: OPS Area > Subject: [MIB-DOCTORS] Re: [OPS-AREA] Request to sponsor=20 > draft-heard-rfc4181-update-00.txt for consideration as a BCP >=20 > On Thu, 4 Jan 2007, Pekka Savola wrote: > > This is a bit broader context comment (and should not necessarily=20 > > block this document), but I'm not sure how scalable it is=20 > to maintain=20 > > MIB review guidelines in the RFC series. Certainly, we=20 > need to have a=20 > > mechanism to establish IETF consensus on those guidelines,=20 > but as the=20 > > requirements change quite often, I'd encourage considering finding=20 > > another way to maintain and publish the guidelines. >=20 > I do hope that folks will accept this delta document as an=20 > acceptable interim measure, since it's the only way I can see=20 > to keep our procedure documents up-to-date with a February=20 > deadline looming. >=20 > That said, I actually agree with Pekka's comment, though=20 > perhaps not for the same reasons that Pekka made it. The=20 > parts of the MIB document review guidelines document that=20 > actually deal with MIB modules had very few changes between=20 > the -02 draft issued in August > 2003 and the -04 draft issued in January 2005, which is the=20 > one that eventually became RFC 4181 in September 2005. The=20 > vast majority of the changes were with document review=20 > criteria, most of which would apply to IETF documents in=20 > general. The biggest part of the long delay was spent=20 > waiting for the IPR working group to get RFCs 3978 and 3979=20 > published. Now more churn from RFC 4748 and still more to=20 > come. This indeed does not scale! >=20 > Mike >=20 > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www1.ietf.org/mailman/listinfo/mib-doctors >=20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Thu Jan 04 17:52:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2bRo-0001VS-83; Thu, 04 Jan 2007 17:52:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2bRm-0001VM-Op for ops-area@ietf.org; Thu, 04 Jan 2007 17:52:30 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2bRl-0006zQ-CQ for ops-area@ietf.org; Thu, 04 Jan 2007 17:52:30 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l04MqQ2P010715; Thu, 4 Jan 2007 16:52:26 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 16:52:25 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 23:52:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Jan 2007 23:52:09 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MIB-DOCTORS] Request to sponsor draft-heard-rfc4181-update-00.txt for consideration as a BCP Thread-Index: AccwN1P5IlUd4pk5SlWJjBJrDkMKIAAGH+Rg From: "Wijnen, Bert \(Bert\)" To: "C. M. Heard" , "Dan Romascanu" X-OriginalArrivalTime: 04 Jan 2007 22:52:09.0413 (UTC) FILETIME=[F714B750:01C73052] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: OPS Area Subject: [OPS-AREA] RE: [MIB-DOCTORS] Request to sponsor draft-heard-rfc4181-update-00.txt for consideration as a BCP 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 have read this document and can support it as an update to 4181. Bert=20 > -----Original Message----- > From: C. M. Heard [mailto:heard@pobox.com]=20 > Sent: donderdag 4 januari 2007 20:33 > To: Dan Romascanu > Cc: OPS Area > Subject: [MIB-DOCTORS] Request to sponsor=20 > draft-heard-rfc4181-update-00.txt for consideration as a BCP >=20 > Dan, >=20 > As noted in the attached I-D ACTION announcement, I have=20 > prepared an individual submission=20 > draft-heard-rfc4181-update-00.txt that provides the updates=20 > to RFC 4181, "Guidelines for Authors and Reviewers of MIB=20 > Documents," that are needed to bring it into alignment with=20 > RFC 4748. The substantive content is all in the following=20 > paragraph from Section 2.1 of the draft: >=20 > In the copyright notice templates in Section 3.7, replace all > occurrences of "The Internet Society" with "The IETF Trust". >=20 > Since conformance to the rules in RFC 4748 will become=20 > manadatory starting in February 2007, an update to RFC 4181=20 > should be approved as a BCP and published as soon as=20 > possible. I therefore request that you, as the responsible=20 > AD, sponsor this draft for consideration as a BCP. >=20 > I acknowledge that it would be preferable to republish the=20 > MIB review guidelines document in its entirety. =20 > Unfortunately, I do not have the time to serve anymore as=20 > editor of that document, and the person who has volunteered=20 > to take over that job is presently busy with other things. I=20 > am therefore offering this draft as an interim delta=20 > document, with the hope and expectation that it will be=20 > replaced by a new document in the not too distant future. >=20 > I'm cc:'ing this request to the OPS Area mailing list, and=20 > invite those who wish to comment to do so on that list. >=20 > Regards and thanks, >=20 > Mike Heard >=20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Fri Jan 05 01:29:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2iZ1-0002NW-06; Fri, 05 Jan 2007 01:28:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2iYz-0002HJ-J6; Fri, 05 Jan 2007 01:28:25 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2iYx-0006v7-5i; Fri, 05 Jan 2007 01:28:25 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l056SCUX020603; Fri, 5 Jan 2007 01:28:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Jan 2007 08:28:11 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for January 11, 2007 Telechat Thread-Index: AccwVVOQ6AXq2LcyTfSZHh6Xl9jynQAPNhBg From: "Romascanu, Dan \(Dan\)" To: "OPS Area" , , "MIB Doctors" , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: Subject: [OPS-AREA] FW: PRELIMINARY Agenda and Package for January 11, 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 =20 Please find below the preliminary agenda of the January 11, 2007 IESG meeting. Please let me know if you have any comments or concerns related to the documents brought to the approval of the IESG until January 10, 2007 COB the latest.=20 Thanks and Regards, Dan INTERNET ENGINEERING STEERING GROUP (IESG) Summarized Agenda for the January 11, 2007 IESG Teleconference =20 =20 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item o draft-ietf-ccamp-automesh-03.txt Routing extensions for discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) mesh membership (Proposed Standard) -=20 1 of 10=20 Token: Ross Callon o draft-ietf-dkim-base-07.txt DomainKeys Identified Mail (DKIM) Signatures (Proposed Standard) - 2 of 10=20 Token: Russ Housley o draft-ietf-dhc-timezone-option-05.txt A Timezone Option for DHCP (Proposed Standard) - 3 of 10=20 Token: Jari Arkko o draft-narten-ipr-3979-3rd-party-fix-00.txt Clarification of the 3rd Party Disclosure procedure in RFC 3979 (BCP) - 4=20 of 10=20 Note: Update to BCP 79. Document shepherd is Harald Alvestrand. It is an=20 IPR WG draft.=20 Token: Brian Carpenter o Two-document ballot: - 5 of 10 - draft-ietf-kitten-gssapi-domain-based-names-03.txt GSS-API Domain-Based Service Names and Name Type (Proposed Standard)=20 Note: Proto Shepherd: jaltman@secure-endpoints.com=20 - draft-ietf-kitten-krb5-gssapi-domain-based-names-03.txt GSS-API Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism (Proposed Standard)=20 Token: Sam Hartman o draft-ietf-pkix-srvsan-04.txt Internet X.509 Public Key Infrastructure Subject Alternative Name for expression of service name (Proposed Standard) - 6 of 10=20 Token: Russ Housley o draft-ietf-rohc-sigcomp-impl-guide-10.txt Implementer's Guide for SigComp (Proposed Standard) - 7 of 10=20 Token: Magnus Westerlund o draft-ietf-rohc-formal-notation-13.txt Formal Notation for Robust Header Compression (ROHC-FN) (Proposed Standard)=20 - 8 of 10=20 Token: Magnus Westerlund o draft-ietf-radext-filter-06.txt RADIUS Filter Rule Attribute (Proposed Standard) - 9 of 10=20 Note: Note: David Nelson is the Document Shepherd=20 Token: David Kessens o rfc3989.txt MIDCOM Protocol Semantics (BCP) - 10 of 10=20 Token: Magnus Westerlund 2.1.2 Returning Item o draft-ietf-mip6-ikev2-ipsec-08.txt Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture=20 (Proposed Standard) - 1 of 1=20 Note: PROTO Shepherd is Basavaraj Patil =20 Token: Jari Arkko 2.2 Individual Submissions 2.2.1 New Item o draft-andersson-rtg-gmpls-change-07.txt Change Process for Multiprotocol Label Switching (MPLS) and Generalized=20 MPLS (GMPLS) Protocols and Procedures (BCP) - 1 of 2=20 Note: Brian shepherds on behalf of the Routing ADs=20 Token: Brian Carpenter o draft-housley-aaa-key-mgmt-06.txt Guidance for AAA Key Management (BCP) - 2 of 2=20 Token: Sam Hartman 2.2.2 Returning Item NONE 2.2.3 For Action o draft-diao-eipv4-01.txt Source Route Based Extensible IP Network (EIPv4) (Proposed Standard) - 1 of=20 1=20 Note: Instructed author to participate in ID-Loc split design in RAM Token: Jari Arkko 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item o draft-ietf-dna-link-information-05.txt Link-layer Event Notifications for Detecting Network Attachments=20 (Informational) - 1 of 1=20 Token: Jari Arkko 3.1.2 Returning Item NONE 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item o draft-snell-atompub-feed-license-10.txt Atom License Extension (Experimental) - 1 of 1=20 Token: Lisa Dusseault 3.2.2 Returning Item o draft-klensin-norm-ref-02.txt A Process Experiment in Normative Reference Handling (Experimental) - 1 of=20 1=20 Note: RFC 3933 process experiment, substantially reduced in scope in 02=20 version.=20 Token: Brian Carpenter _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Jan 10 06:31:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4bf9-00027B-O6; Wed, 10 Jan 2007 06:30:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4bf8-00025P-Ke; Wed, 10 Jan 2007 06:30:34 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H4bf6-00012I-AV; Wed, 10 Jan 2007 06:30:34 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0ABUULQ024088; Wed, 10 Jan 2007 06:30:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Jan 2007 13:30:29 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OPS Area Open Hours Thread-Index: Acc0qrsbrZp9CZTtRDuogWddSosg9Q== From: "Romascanu, Dan \(Dan\)" To: "OPS Area" , , "MIB Doctors" , , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: IESG Subject: [OPS-AREA] OPS Area Open Hours 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 Kessens and Dan Romascanu are holding Open Hours to discuss issues related to the IETF Operations and Management Area on the first and third Tuesday of each month at 10-11AM PT / 1-2PM ET / 7-8PM CET. The series of calls starts on 1/16, and the other open hours slots until the Prague IETF meeting are 2/6, 2/20, 3/6.=20 All WG chairs, document editors, contributors, participants and in general all interested to talk with us about the area and IETF business are invited to ask for a meeting slot using the OPS Area wiki http://www1.tools.ietf.org/area/ops/trac/wiki/WikiStart, and/or to write us directly at david.kessens@nokia.com or dromasca@avaya.com. An e-mail will be sent in response to acknowledge the time slot and provide a telephone bridge number to be used in the call.=20 David and Dan =20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Jan 10 10:48:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4fgd-0008OP-Iw; Wed, 10 Jan 2007 10:48:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4fgc-0008NF-CB; Wed, 10 Jan 2007 10:48:22 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4fgL-0001Xz-2T; Wed, 10 Jan 2007 10:48:22 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0AFm3L1028646; Wed, 10 Jan 2007 10:48:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Jan 2007 17:48:02 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-harrington-text-mib-doc-template (A Template for Documents Containing a MIB Module) to BCP Thread-Index: Acc0zowAkKS5vxLyQo6lwx8iJyS2cgAABUtg From: "Romascanu, Dan \(Dan\)" To: "OPS Area" , "MIB Doctors" , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Subject: [OPS-AREA] FW: Last Call: draft-harrington-text-mib-doc-template (A Template for Documents Containing a MIB Module) to BCP 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: The IESG [mailto:iesg-secretary@ietf.org]=20 Sent: Wednesday, January 10, 2007 5:40 PM To: IETF-Announce Subject: Last Call: draft-harrington-text-mib-doc-template (A Template for Documents Containing a MIB Module) to BCP=20 The IESG has received a request from an individual submitter to consider the following document: - 'A Template for Documents Containing a MIB Module ' as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-02-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Note that the document includes a Normative Reference to RFC 2629 which is Informational. This is a Downward Reference as per RFC 3967.=20 The file can be obtained via http://www.ietf.org/internet-drafts/draft-harrington-text-mib-doc-templa te-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D 14807&rfc_flag=3D0 _______________________________________________ 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 Thu Jan 11 14:13:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H55LV-0000Mf-0q; Thu, 11 Jan 2007 14:12:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H55LU-0000M6-BP; Thu, 11 Jan 2007 14:12:16 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H55LS-0000dh-Qk; Thu, 11 Jan 2007 14:12:16 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0BJCCMB008630; Thu, 11 Jan 2007 14:12:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Jan 2007 21:12:11 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request to sponsor draft-heard-rfc4181-update-00.txt for consideration as a BCP Thread-Index: AccwN0rwrt1H4XuhR8+Iufey27K9TQAAEwtQAV8eXAA= From: "Romascanu, Dan \(Dan\)" To: "C. M. Heard" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: MIB Doctors , OPS Area Subject: [OPS-AREA] RE: Request to sponsor draft-heard-rfc4181-update-00.txt for consideration as a BCP 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 have heard a few support comments, and no dissent concerning the process or the content of the document. I plan to send it to IETF LC. It will be a four weeks LC, because it's a non-WG document targeting BCP.=20 Dan =20 =20 > -----Original Message----- > From: Romascanu, Dan (Dan)=20 > Sent: Thursday, January 04, 2007 9:46 PM > To: 'C. M. Heard' > Cc: 'OPS Area'; MIB Doctors > Subject: RE: Request to sponsor=20 > draft-heard-rfc4181-update-00.txt for consideration as a BCP >=20 > Thanks, Mike.=20 >=20 > OPS Area and MIB Doctors,=20 >=20 > Please comment on Mike's request until 1/11.=20 >=20 > The process of Area Director sponsoring of documents is=20 > described in=20 > http://www.ietf.org/internet-drafts/draft-iesg-sponsoring-guid > elines-00.txt >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 >=20 >=20 > =20 > =20 >=20 > > -----Original Message----- > > From: C. M. Heard [mailto:heard@pobox.com] > > Sent: Thursday, January 04, 2007 9:33 PM > > To: Romascanu, Dan (Dan) > > Cc: OPS Area > > Subject: Request to sponsor draft-heard-rfc4181-update-00.txt for=20 > > consideration as a BCP > >=20 > > Dan, > >=20 > > As noted in the attached I-D ACTION announcement, I have=20 > prepared an=20 > > individual submission draft-heard-rfc4181-update-00.txt=20 > that provides=20 > > the updates to RFC 4181, "Guidelines for Authors and=20 > Reviewers of MIB=20 > > Documents," that are needed to bring it into alignment with=20 > RFC 4748. =20 > > The substantive content is all in the following paragraph=20 > from Section=20 > > 2.1 of the draft: > >=20 > > In the copyright notice templates in Section 3.7, replace all > > occurrences of "The Internet Society" with "The IETF Trust". > >=20 > > Since conformance to the rules in RFC 4748 will become manadatory=20 > > starting in February 2007, an update to RFC 4181 should be=20 > approved as=20 > > a BCP and published as soon as possible. I therefore request that=20 > > you, as the responsible AD, sponsor this draft for=20 > consideration as a=20 > > BCP. > >=20 > > I acknowledge that it would be preferable to republish the=20 > MIB review=20 > > guidelines document in its entirety. > > Unfortunately, I do not have the time to serve anymore as editor of=20 > > that document, and the person who has volunteered to take over that=20 > > job is presently busy with other things. I am therefore=20 > offering this=20 > > draft as an interim delta document, with the hope and=20 > expectation that=20 > > it will be replaced by a new document in the not too distant future. > >=20 > > I'm cc:'ing this request to the OPS Area mailing list, and invite=20 > > those who wish to comment to do so on that list. > >=20 > > Regards and thanks, > >=20 > > Mike Heard > >=20 >=20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Tue Jan 16 10:30:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6qG8-0005Kv-Ej; Tue, 16 Jan 2007 10:30:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6qG6-0005D0-7M; Tue, 16 Jan 2007 10:29:58 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6qG4-0001Kz-UA; Tue, 16 Jan 2007 10:29:58 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0GFTnwY023963; Tue, 16 Jan 2007 10:29:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jan 2007 17:29:48 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-heard-rfc4181-update (RFC 4181 Update to Recognize the IETF Trust) to BCP Thread-Index: Acc5gsj5tf+QpATrRkK+efYbYZeRmwAAETSA From: "Romascanu, Dan \(Dan\)" To: "OPS Area" , , , "MIB Doctors" , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Subject: [OPS-AREA] FW: Last Call: draft-heard-rfc4181-update (RFC 4181 Update to Recognize the IETF Trust) to BCP 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: The IESG [mailto:iesg-secretary@ietf.org]=20 Sent: Tuesday, January 16, 2007 5:22 PM To: IETF-Announce Subject: Last Call: draft-heard-rfc4181-update (RFC 4181 Update to Recognize the IETF Trust) to BCP=20 The IESG has received a request from an individual submitter to consider the following document: - 'RFC 4181 Update to Recognize the IETF Trust ' as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-02-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-heard-rfc4181-update-00.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D 15574&rfc_flag=3D0 _______________________________________________ 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 Tue Jan 16 10:42:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6qSA-0002nh-Af; Tue, 16 Jan 2007 10:42:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6qS8-0002ky-Qi for ops-area@ietf.org; Tue, 16 Jan 2007 10:42:24 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6qQw-0003DQ-4P for ops-area@ietf.org; Tue, 16 Jan 2007 10:41:12 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0GFf7fB000681 for ; Tue, 16 Jan 2007 10:41:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C73984.BD08B4CA" Date: Tue, 16 Jan 2007 17:41:07 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Notifications] Setting up email event streams Thread-Index: Acc4+0bvmKvI+wdvRGqxnpDUxDSyQQAiR19A From: "Romascanu, Dan \(Dan\)" To: "OPS Area" , "Netconf \(E-mail\)" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b6c13497db1e4e7b275c86cfcdad7bb Cc: Lisa Dusseault Subject: [OPS-AREA] FW: [Notifications] Setting up email event streams 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C73984.BD08B4CA Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C73984.BD08B4CA" ------_=_NextPart_002_01C73984.BD08B4CA Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I apologize for the cross-posting, but the theme has some similarities with discussions that happened in the OPS area and specifically in NETCONF.=20 =20 Subscribing to the notifications list is probably the right way to follow this discussion or even contribute to it.=20 =20 Dan =20 =20 =20 =20 _____ =20 From: Lisa Dusseault [mailto:lisa@osafoundation.org]=20 Sent: Tuesday, January 16, 2007 1:16 AM To: Message Notifications interest group discussion list Subject: [Notifications] Setting up email event streams I've been meaning to send this out more broadly after a bit of private comment: two quite different models for setting up event streams based on what's easier to authenticate -- the event stream "owner" (in this case the mailbox owner) or the stream recipient. I hope it helps compare different approaches. Lisa --- The goal is to start (and stop) events flowing from an event source (in our case, an email server) to the event sink, frequently using a system with an explicit event relay. Because there are often three parties required in an event flow , we have to pick some way for the three parties to coordinate. The three parties are the event source (an email server), the event sink (a client, perhaps not an email client) and an event relay. The event relay has many users thus it has addresses for each user and possibly also addresses for devices/clients. Two kinds of application-layer explicit event relays are starting to be common: XMPP and SIP. For the purposes of considering an event feed setup model, we do not want to be concerned about the mostly orthogonal issue of what protocol to use to talk to event relay. So for now we assume that event relays have all features common to XMPP and SIP (addresses, pub/sub features, event stream aggregation). Choosing between two event stream setup models requires assumptions about - what kind of authorization is easier or more important to provide - whether there are a lot of different event sink addressess - whether direct access to the event source is always/usually available (can be affected by whether the event source is publicly available) - whether event flows stop and start frequently, or can simply be turned on for a very long term MODEL A. SUBSCRIBE Chain A-1 Description In this model, when a user decides to get an email event flow to a particular device or piece of software, the user typically works with the event sink interface to indicate where to get the events from. Then a SUBSCRIBE message of some kind gets generated by the event sink, sent to the event relay and is handled by the event source. A-2 Authorization issue The authorization problem here is to determine if the address that the SUBSCRIBE message comes from is permitted to receive these events. In the case of a publicly-subscribable resource this problem disappears. In many email use cases, only a small number of event sink addresses will be authorized to receive event notifications -- perhaps the event source (the email server) can simply be configured with a short allowed list of event recipients that doesn't change often (e.g. my personal IM address, my work address, and the one used by my phone provided by my phone service provider). Some SUBSCRIBE systems have the ability to provide a PENDING response to a subscription. This is used when an out-of-band mechanism is initiated to authorize the subscribing address. In an email event source use case, one obvious out-of-band mechanism is for the email server to create an email with a link saying "Click here to authorize this subscription". It's also possible to use a mechanism like URLAUTH to prove authorization -- in this approach, the subscriber provides a URL that has a secret token in it authorizing the subscription. It's possible that this would authorize the subscribing address for future subscriptions as well, or only for a limited period. A-3 Drawbacks: a) Only some notification protocols support SUBSCRIBE semantics. b) Complicated filters and event types (to support use cases like "Alert me on event type 'email arrives' if it is from my boss, has my full email address or the address of the developer list on the to line, and the subject does not begin with 'FUNNY'..." ) might need a little extra work. Both SIP and XMPP subscriptions can be extended in such a way that existing notification relays would pass on a filter specification in whatever language/format most appropriate for email. It might even be possible to send SIEVE conditionals in the body of the SUBSCRIBE message. XMPP has notification nodes in XEP-0060 and notification filters in XEP-0163. A-4 Advantages b) Allows for frequent starting and stopping of subscriptions, possibly an efficiency/scaling concern MODEL B. Sender RULES B-1 Description In this model, the user typically works with the event source in order to configure it to send events to a given set of addresses. For example, the user might have access to a Web interface to an email server where it can say "Send new message notifications to=20 xmpp://lisa@psg.com " or someday use MANAGESIEVE. B-2 Authorization issue The authorization problem here is to determine if the user creating the sending rule is authorized to send an event stream to the receiving address. If anybody can send to the receiving address (e.g. email) then it's publicly addressable and the problem disappears. Many kinds of addresses are publicly addressable and use whitelisting together with asking permission ("do you wish to allow messages from this source in the future"). B-3 Drawbacks: a) Only some event sources support RULE systems. We are building SIEVE for email clients and servers but it may be harder to generalize this beyond email clients and servers. Even sticking strictly the proposed scope of email server sources, we have to consider whether a client such as a calendar client (subscribing for IMIP messages) or a time-management dashboard (subscribes to "unread" counts but doesn't otherwise read email) are going to be able to implement SIEVE, authenticate to mail servers etc. b) If sender rules are setup through Web interfaces, users are definitely not going to turn them on and off frequently. c) Failure feedback: how does the event source let the user know that some address keeps bouncing? =20 ------_=_NextPart_002_01C73984.BD08B4CA Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
I apologize for the cross-posting, but the = theme has=20 some similarities with discussions that happened in the OPS area and=20 specifically in NETCONF.
 
Subscribing to the notifications list is = probably the=20 right way to follow this discussion or even contribute to it.=20
 
Dan
 
 
 
 

From: Lisa Dusseault=20 [mailto:lisa@osafoundation.org]
Sent: Tuesday, January 16, = 2007 1:16=20 AM
To: Message Notifications interest group discussion=20 list
Subject: [Notifications] Setting up email event=20 streams

I've been meaning to send this out more broadly after a bit of = private=20 comment: two quite different models for setting up event streams based = on what's=20 easier to authenticate -- the event stream "owner" (in this case the = mailbox=20 owner) or the stream recipient.  I hope it helps compare different=20 approaches.

Lisa

---

The goal is=20 to start (and stop) events flowing from an event source (in our case, an = email=20 server) to the event sink, frequently using a system with an explicit = event=20 relay.   = Because there are often three = parties=20 required in an event flow , we have to pick some way for the three = parties to=20 coordinate.

The three=20 parties are the event source (an email server), the event sink (a = client,=20 perhaps not an email client)  and an=20 event relay.  = The event relay = has many users=20 thus it has addresses for each user and possibly also addresses for=20 devices/clients. =20 Two kinds of = application-layer=20 explicit event relays are starting to be common: XMPP and = SIP.  For the purposes of considering an event feed setup = model, we do=20 not want to be concerned about the mostly orthogonal issue of what = protocol to=20 use to talk to event relay.  So for=20 now we assume that event relays have all features common to XMPP and SIP = (addresses, pub/sub features, event stream aggregation).

Choosing=20 between two event stream setup models requires assumptions = about
-=20 what kind of authorization is easier or more important to = provide
-=20 whether there are a lot of different event sink addressess
-=20 whether direct access to the event source is always/usually available = (can be=20 affected by whether the event source is publicly available)
-=20 whether event flows stop and start frequently, or can simply be turned = on for a=20 very long term

MODEL=20 A.  = SUBSCRIBE Chain

A-1=20 Description

In this=20 model, when a user decides to get an email event flow to a particular = device or=20 piece of software, the user typically works with the event sink = interface to=20 indicate where to get the events from.  Then a=20 SUBSCRIBE message of some kind gets generated by the event sink, sent to = the=20 event relay and is handled by the event source.

A-2=20 Authorization issue

The=20 authorization problem here is to determine if the address that the = SUBSCRIBE=20 message comes from is permitted to receive these events.  In the case of a publicly-subscribable resource this = problem=20 disappears.  = In many email use cases, only a = small=20 number of event sink addresses will be authorized to receive event = notifications=20 -- perhaps the event source (the email server) can simply be configured = with a=20 short allowed list of event recipients that doesn't change often (e.g. = my=20 personal IM address, my work address, and the one used by my phone = provided by=20 my phone service provider).

Some=20 SUBSCRIBE systems have the ability to provide a PENDING response to a=20 subscription. =20 This is used when = an=20 out-of-band mechanism is initiated to authorize the subscribing=20 address.  = In an email event source use = case, one=20 obvious out-of-band mechanism is for the email server to create an email = with a=20 link saying "Click here to authorize this subscription".

It's also=20 possible to use a mechanism like URLAUTH to prove authorization -- in = this=20 approach, the subscriber provides a URL that has a secret token in it=20 authorizing the subscription.  It's=20 possible that this would authorize the subscribing address for future=20 subscriptions as well, or only for a limited period.

A-3=20 Drawbacks:
  =20 a)  Only some notification protocols support SUBSCRIBE=20 semantics.

  =20 b)  Complicated filters and event types (to support use = cases like=20 "Alert me on event type 'email arrives' if it is from my boss, has my = full email=20 address or the address of the developer list on the to line, and the = subject=20 does not begin with 'FUNNY'..." )  might=20 need a little extra work.  Both SIP=20 and XMPP subscriptions can be extended in such a way that existing = notification=20 relays would pass on a filter specification in whatever language/format = most=20 appropriate for email. =20 It might even be = possible to=20 send SIEVE conditionals in the body of the SUBSCRIBE = message.  XMPP has notification nodes in XEP-0060 and notification = filters=20 in XEP-0163.

A-4=20 Advantages
  =20 b) Allows for = frequent=20 starting and stopping of subscriptions, possibly an efficiency/scaling=20 concern


MODEL B.=20 Sender RULES

B-1=20 Description

In this=20 model, the user typically works with the event source in order to = configure it=20 to send events to a given set of addresses.  For=20 example, the user might have access to a Web interface to an email = server where=20 it can say "Send new message notifications to xmpp://lisa@psg.com" or someday use MANAGESIEVE.

B-2=20 Authorization issue

The=20 authorization problem here is to determine if the user creating the = sending rule=20 is authorized to send an event stream to the receiving = address.  If anybody can send to the receiving address (e.g. = email) then=20 it's publicly addressable and the problem disappears.  Many kinds of addresses are publicly addressable and use = whitelisting together with asking permission ("do you wish to allow = messages=20 from this source in the future").

B-3=20 Drawbacks:
  =20 a) Only some event = sources=20 support RULE systems. =20 We are building = SIEVE for=20 email clients and servers but it may be harder to generalize this beyond = email=20 clients and servers. =20 Even sticking = strictly the=20 proposed scope of email server sources, we have to consider whether a = client=20 such as a calendar client (subscribing for IMIP messages) or a = time-management=20 dashboard (subscribes to "unread" counts but doesn't otherwise read = email) are=20 going to be able to implement SIEVE, authenticate to mail servers=20 etc.

  =20 b) If sender rules = are setup=20 through Web interfaces, users are definitely not going to turn them on = and off=20 frequently.

  =20 c) Failure = feedback: how does=20 the event source let the user know that some address keeps=20 bouncing?

 =20





------_=_NextPart_002_01C73984.BD08B4CA-- ------_=_NextPart_001_01C73984.BD08B4CA Content-Type: text/plain; name="ATT81747.txt" Content-Transfer-Encoding: base64 Content-Description: ATT81747.txt Content-Disposition: inline; filename="ATT81747.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5vdGlmaWNh dGlvbnMgbWFpbGluZyBsaXN0DQpOb3RpZmljYXRpb25zQGlldGYub3JnDQpodHRwczovL3d3dzEu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ub3RpZmljYXRpb25zDQo= ------_=_NextPart_001_01C73984.BD08B4CA 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 ------_=_NextPart_001_01C73984.BD08B4CA-- From ops-area-bounces@ietf.org Tue Jan 16 13:40:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6tDW-0006X2-EG; Tue, 16 Jan 2007 13:39:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6sWl-0008DO-Hb for ops-area@ietf.org; Tue, 16 Jan 2007 12:55:19 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6sWj-0000Ox-E1 for ops-area@ietf.org; Tue, 16 Jan 2007 12:55:19 -0500 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CA57C14225B; Tue, 16 Jan 2007 09:55:10 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19970-05; Tue, 16 Jan 2007 09:55:08 -0800 (PST) Received: from [192.168.1.101] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 8723214225A; Tue, 16 Jan 2007 09:55:05 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <78FD72BF-2BC2-40BB-9C03-15C1F7EC0D3F@osafoundation.org> From: Lisa Dusseault Date: Tue, 16 Jan 2007 09:55:02 -0800 To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fa183e2955b1d12e35b5783ab5b4f6df X-Mailman-Approved-At: Tue, 16 Jan 2007 13:39:29 -0500 Cc: "Netconf \(E-mail\)" , OPS Area Subject: [OPS-AREA] Re: [Notifications] Setting up email event streams 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="===============0354480685==" Errors-To: ops-area-bounces@ietf.org --===============0354480685== Content-Type: multipart/alternative; boundary=Apple-Mail-33--463141686 --Apple-Mail-33--463141686 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I'd note that the "notifications@ietf.org" list, even though it has a very generic DL address, is specifically scoped to handling notifications from email servers about email/mailboxes, not from other sources. Otherwise I think we'd get back into the trap of doing interminable notification work with too large a scope (was anybody else there when the NOTIFY BOF included people asking for sub- second notification frequency so that they could use a standard to track the position of the space shuttle?). General observations still welcome, of course. Thx, Lisa On Jan 16, 2007, at 7:41 AM, Romascanu, Dan (Dan) wrote: > I apologize for the cross-posting, but the theme has some > similarities with discussions that happened in the OPS area and > specifically in NETCONF. > > Subscribing to the notifications list is probably the right way to > follow this discussion or even contribute to it. > > Dan > > > > > > From: Lisa Dusseault [mailto:lisa@osafoundation.org] > Sent: Tuesday, January 16, 2007 1:16 AM > To: Message Notifications interest group discussion list > Subject: [Notifications] Setting up email event streams > > I've been meaning to send this out more broadly after a bit of > private comment: two quite different models for setting up event > streams based on what's easier to authenticate -- the event stream > "owner" (in this case the mailbox owner) or the stream recipient. > I hope it helps compare different approaches. > > Lisa > > --- > > The goal is to start (and stop) events flowing from an event source > (in our case, an email server) to the event sink, frequently using > a system with an explicit event relay. Because there are often > three parties required in an event flow , we have to pick some way > for the three parties to coordinate. > > The three parties are the event source (an email server), the event > sink (a client, perhaps not an email client) and an event relay. > The event relay has many users thus it has addresses for each user > and possibly also addresses for devices/clients. Two kinds of > application-layer explicit event relays are starting to be common: > XMPP and SIP. For the purposes of considering an event feed setup > model, we do not want to be concerned about the mostly orthogonal > issue of what protocol to use to talk to event relay. So for now > we assume that event relays have all features common to XMPP and > SIP (addresses, pub/sub features, event stream aggregation). > > Choosing between two event stream setup models requires assumptions > about > - what kind of authorization is easier or more important to provide > - whether there are a lot of different event sink addressess > - whether direct access to the event source is always/usually > available (can be affected by whether the event source is publicly > available) > - whether event flows stop and start frequently, or can simply be > turned on for a very long term > > MODEL A. SUBSCRIBE Chain > > A-1 Description > > In this model, when a user decides to get an email event flow to a > particular device or piece of software, the user typically works > with the event sink interface to indicate where to get the events > from. Then a SUBSCRIBE message of some kind gets generated by the > event sink, sent to the event relay and is handled by the event > source. > > A-2 Authorization issue > > The authorization problem here is to determine if the address that > the SUBSCRIBE message comes from is permitted to receive these > events. In the case of a publicly-subscribable resource this > problem disappears. In many email use cases, only a small number > of event sink addresses will be authorized to receive event > notifications -- perhaps the event source (the email server) can > simply be configured with a short allowed list of event recipients > that doesn't change often (e.g. my personal IM address, my work > address, and the one used by my phone provided by my phone service > provider). > > Some SUBSCRIBE systems have the ability to provide a PENDING > response to a subscription. This is used when an out-of-band > mechanism is initiated to authorize the subscribing address. In an > email event source use case, one obvious out-of-band mechanism is > for the email server to create an email with a link saying "Click > here to authorize this subscription". > > It's also possible to use a mechanism like URLAUTH to prove > authorization -- in this approach, the subscriber provides a URL > that has a secret token in it authorizing the subscription. It's > possible that this would authorize the subscribing address for > future subscriptions as well, or only for a limited period. > > A-3 Drawbacks: > a) Only some notification protocols support SUBSCRIBE semantics. > > b) Complicated filters and event types (to support use cases > like "Alert me on event type 'email arrives' if it is from my boss, > has my full email address or the address of the developer list on > the to line, and the subject does not begin with 'FUNNY'..." ) > might need a little extra work. Both SIP and XMPP subscriptions > can be extended in such a way that existing notification relays > would pass on a filter specification in whatever language/format > most appropriate for email. It might even be possible to send > SIEVE conditionals in the body of the SUBSCRIBE message. XMPP has > notification nodes in XEP-0060 and notification filters in XEP-0163. > > A-4 Advantages > b) Allows for frequent starting and stopping of subscriptions, > possibly an efficiency/scaling concern > > > MODEL B. Sender RULES > > B-1 Description > > In this model, the user typically works with the event source in > order to configure it to send events to a given set of addresses. > For example, the user might have access to a Web interface to an > email server where it can say "Send new message notifications to > xmpp://lisa@psg.com" or someday use MANAGESIEVE. > > B-2 Authorization issue > > The authorization problem here is to determine if the user creating > the sending rule is authorized to send an event stream to the > receiving address. If anybody can send to the receiving address > (e.g. email) then it's publicly addressable and the problem > disappears. Many kinds of addresses are publicly addressable and > use whitelisting together with asking permission ("do you wish to > allow messages from this source in the future"). > > B-3 Drawbacks: > a) Only some event sources support RULE systems. We are > building SIEVE for email clients and servers but it may be harder > to generalize this beyond email clients and servers. Even sticking > strictly the proposed scope of email server sources, we have to > consider whether a client such as a calendar client (subscribing > for IMIP messages) or a time-management dashboard (subscribes to > "unread" counts but doesn't otherwise read email) are going to be > able to implement SIEVE, authenticate to mail servers etc. > > b) If sender rules are setup through Web interfaces, users are > definitely not going to turn them on and off frequently. > > c) Failure feedback: how does the event source let the user know > that some address keeps bouncing? > > > > > > _______________________________________________ > Notifications mailing list > Notifications@ietf.org > https://www1.ietf.org/mailman/listinfo/notifications --Apple-Mail-33--463141686 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

I'd note that the "notifications@ietf.org" list, = even though it has a very generic DL address, is specifically scoped to = handling notifications from email servers about email/mailboxes, not = from other sources.=A0 Otherwise I think we'd get back into the trap of = doing interminable notification work with too large a scope (was anybody = else there when the NOTIFY BOF included people asking for sub-second = notification frequency so that they could use a standard to track the = position of the space shuttle?).=A0

General observations still = welcome, of course.

Thx,
Lisa

=
On Jan 16, 2007, at 7:41 AM, Romascanu, Dan (Dan) = wrote:

I apologize for the = cross-posting, but the theme has some similarities with discussions that = happened in the OPS area and specifically in NETCONF. =
=A0
=
Subscribing to the notifications list is = probably the right way to follow this discussion or even contribute to = it.
=A0
=
Dan
=
=A0
=
=A0
=A0
=A0

=
From: Lisa = Dusseault [mailto:lisa@osafoundation.org] =
Sent: Tuesday, January 16, 2007 1:16 AM
To: Message = Notifications interest group discussion list
Subject: = [Notifications] Setting up email event streams

=
I've been meaning to send this out more broadly after a = bit of private comment: two quite different models for setting up event = streams based on what's easier to authenticate -- the event stream = "owner" (in this case the mailbox owner) or the stream recipient.=A0 I = hope it helps compare different approaches.

Lisa

---

The goal is to start (and = stop) events flowing from an event source (in our case, an email server) = to the event sink, frequently using a system with an explicit event = relay. =A0 = Because there = are often three parties required in an event flow , we have to pick some = way for the three parties to coordinate.

The three parties are the event source (an email = server), the event sink (a client, perhaps not an email = client)=A0 = and an event = relay.=A0 = The event = relay has many users thus it has addresses for each user and possibly = also addresses for devices/clients.=A0 Two kinds of application-layer explicit event relays = are starting to be common: XMPP and SIP.=A0 For the purposes of = considering an event feed setup model, we do not want to be concerned = about the mostly orthogonal issue of what protocol to use to talk to = event relay.=A0 = So for now we = assume that event relays have all features common to XMPP and SIP = (addresses, pub/sub features, event stream aggregation).
=

Choosing between two event stream setup models = requires assumptions about
- what kind of = authorization is easier or more important to provide
- = whether there are a lot of different event sink addressess
=
- whether direct access to the event source is = always/usually available (can be affected by whether the event source is = publicly available)
- whether event flows stop = and start frequently, or can simply be turned on for a very long = term

MODEL A.=A0 SUBSCRIBE = Chain

A-1 = Description

In this model, when a user = decides to get an email event flow to a particular device or piece of = software, the user typically works with the event sink interface to = indicate where to get the events from.=A0 Then a SUBSCRIBE message of = some kind gets generated by the event sink, sent to the event relay and = is handled by the event source.

A-2 Authorization = issue

The authorization problem = here is to determine if the address that the SUBSCRIBE message comes = from is permitted to receive these events.=A0 In the case of a = publicly-subscribable resource this problem disappears.=A0 In many email use cases, = only a small number of event sink addresses will be authorized to = receive event notifications -- perhaps the event source (the email = server) can simply be configured with a short allowed list of event = recipients that doesn't change often (e.g. my personal IM address, my = work address, and the one used by my phone provided by my phone service = provider).

Some SUBSCRIBE systems have = the ability to provide a PENDING response to a subscription.=A0 This is used when an = out-of-band mechanism is initiated to authorize the subscribing = address.=A0 = In an email = event source use case, one obvious out-of-band mechanism is for the = email server to create an email with a link saying "Click here to = authorize this subscription".

It's also possible to use a = mechanism like URLAUTH to prove authorization -- in this approach, the = subscriber provides a URL that has a secret token in it authorizing the = subscription.=A0= It's possible = that this would authorize the subscribing address for future = subscriptions as well, or only for a limited period.

A-3 Drawbacks:
=A0=A0 = a)=A0 Only some notification = protocols support SUBSCRIBE semantics.

=A0=A0 b)=A0 Complicated filters and event types (to support use = cases like "Alert me on event type 'email arrives' if it is from my = boss, has my full email address or the address of the developer list on = the to line, and the subject does not begin with 'FUNNY'..." = )=A0 = might need a = little extra work.=A0 Both SIP and XMPP subscriptions can be extended in = such a way that existing notification relays would pass on a filter = specification in whatever language/format most appropriate for = email.=A0 = It might even = be possible to send SIEVE conditionals in the body of the SUBSCRIBE = message.=A0 = XMPP has = notification nodes in XEP-0060 and notification filters in = XEP-0163.

A-4 Advantages
=
=A0=A0 b) Allows for frequent starting and stopping of = subscriptions, possibly an efficiency/scaling concern


MODEL B. Sender RULES

B-1 Description

In this model, the user = typically works with the event source in order to configure it to send = events to a given set of addresses.=A0 For example, the user might have access to a Web = interface to an email server where it can say "Send new message = notifications to xmpp://lisa@psg.com" or someday use = MANAGESIEVE.

B-2 Authorization = issue

The authorization problem = here is to determine if the user creating the sending rule is authorized = to send an event stream to the receiving address.=A0 If anybody can send to the = receiving address (e.g. email) then it's publicly addressable and the = problem disappears.=A0 Many kinds of addresses are publicly addressable and = use whitelisting together with asking permission ("do you wish to allow = messages from this source in the future").

B-3 Drawbacks:
=A0=A0 = a) Only some = event sources support RULE systems.=A0 We are building SIEVE for email clients and servers = but it may be harder to generalize this beyond email clients and = servers.=A0 = Even sticking = strictly the proposed scope of email server sources, we have to consider = whether a client such as a calendar client (subscribing for IMIP = messages) or a time-management dashboard (subscribes to "unread" counts = but doesn't otherwise read email) are going to be able to implement = SIEVE, authenticate to mail servers etc.

=A0=A0 b) If sender rules are setup through Web interfaces, = users are definitely not going to turn them on and off = frequently.

=A0=A0 c) Failure feedback: how = does the event source let the user know that some address keeps = bouncing?
=A0




Notifications mailing list
https://www1= .ietf.org/mailman/listinfo/notifications
=
= --Apple-Mail-33--463141686-- --===============0354480685== 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 --===============0354480685==-- From ops-area-bounces@ietf.org Tue Jan 23 19:06:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Ve4-0001Fo-VY; Tue, 23 Jan 2007 19:05:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Ve3-0001El-Du; Tue, 23 Jan 2007 19:05:43 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Ve1-0007Ju-DN; Tue, 23 Jan 2007 19:05:42 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0O05X24005036; Tue, 23 Jan 2007 19:05:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Jan 2007 02:05:33 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LAST REMINDER: OPS Area mini-BOFs in Prague Thread-Index: Acc0gtyrABLFfwSZQwe7EkhqqrpLqwGUzm1Q References: <459B763C.1000600@alaxala.net> <45A445ED.9070509@hitachi.com> From: "Romascanu, Dan \(Dan\)" To: "OPS Area" , , , "MIB Doctors \(E-mail\)" , , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [OPS-AREA] LAST REMINDER: OPS Area mini-BOFs in Prague 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 To all contributors who intend to present in Prague - If you did not do it yet, please confirm the submissions for a mini-BOF slot at the OPS Area meetings in Prague and send us the following information: .=20 - short technical scope description (not much more than one paragraph) - goals of the proposal, where this can lead: e.g. new protocol or extension of an existing protocol, standard, BCP or Informational RFC, formation of a WG or individual submission, other - estimation of time you will need in Prague including Q&A - whether there is an Internet-Draft or you intent to submit one before the Prague IETF Please send us this information until 1/25 the latest. David and me will meet on 1/26 and will communicate the finalized agenda shortly after.=20 Thanks and Regards, Dan =20 =20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Jan 24 18:57:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9ryz-0003Iz-Dg; Wed, 24 Jan 2007 18:56:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9ryy-0003Hl-14; Wed, 24 Jan 2007 18:56:48 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9ryv-0007xD-QP; Wed, 24 Jan 2007 18:56:48 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0ONue6u016704; Wed, 24 Jan 2007 18:56:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jan 2007 01:56:39 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Enterprise codes - three or four octets Thread-Index: AcdAE0ku+NFjZYnWRLGw1/LDcSCKlQ== From: "Romascanu, Dan \(Dan\)" To: "OPS Area" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: aaa-doctors@ietf.org, "MIB Doctors \(E-mail\)" Subject: [OPS-AREA] Enterprise codes - three or four octets 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 the cross-posting. I am not sure if this is a problem, but I would like to get some advice. I see in different documents two different ways of coding the SMI Private Enterprise Code. As far as I can understand these numbers should be coded as 32-bit, or at least I could not find any reason to limit them in any document that mentions them starting with RFC 1700. However, in other documents four octets are allocated, but the most significant octet is specified to be zero - see RFC 2865, or the more recent draft-cam-winget-eap-fast which is on the agenda of the IESG telechat tomorrow. An interesting case is draft-ietf-capwap-protocol-specification-04 which uses three octets in one place and four octets in four other places of the same document.=20 I do not know where the limitation to three meaningful octets started to be applied and why. Maybe we should not care, because 24 bits are enough for more than 8 million enterprises, and this may be enough for the future at sight (28k were allocated up to now). I would however invite opinions, especially if somebody believes that there is a problem here and any actions or guidance from the area is needed.=20 Dan =20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Jan 24 19:06:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9s8i-00008W-0z; Wed, 24 Jan 2007 19:06:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9s8g-00007Y-9w; Wed, 24 Jan 2007 19:06:50 -0500 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9s8d-0001u7-PJ; Wed, 24 Jan 2007 19:06:50 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l0P06ihL028129; Wed, 24 Jan 2007 18:06:44 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 18:06:44 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 01:06:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jan 2007 01:03:59 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-DOCTORS] Enterprise codes - three or four octets Thread-Index: AcdAE0ku+NFjZYnWRLGw1/LDcSCKlQAAL8Fw References: From: "Wijnen, Bert \(Bert\)" To: "Romascanu, Dan \(Dan\)" , "OPS Area" X-OriginalArrivalTime: 25 Jan 2007 00:06:42.0344 (UTC) FILETIME=[B16AD280:01C74014] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: aaa-doctors@ietf.org, "MIB Doctors \(E-mail\)" Subject: [OPS-AREA] RE: [AAA-DOCTORS] Enterprise codes - three or four octets 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 Since, (as you note) there is no problem in the forseeable future, and since some protocols have already defined fields that only handle a 24-bit (i.e. 3 octet) value, maybe we should add some comment in the RFC-Editor mainatined registry that if they ever get to a value close to 25 bits, that we (IETF) need to be aware that some (older) protocols have limited fields of up to 24 bits. Bert=20 > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 > Sent: woensdag 24 januari 2007 15:57 > To: OPS Area > Cc: aaa-doctors@ietf.org; MIB Doctors (E-mail) > Subject: [AAA-DOCTORS] Enterprise codes - three or four octets >=20 > I apologize for the cross-posting. I am not sure if this is a=20 > problem, but I would like to get some advice. I see in=20 > different documents two different ways of coding the SMI=20 > Private Enterprise Code. As far as I can understand these=20 > numbers should be coded as 32-bit, or at least I could not=20 > find any reason to limit them in any document that mentions=20 > them starting with RFC 1700. However, in other documents four=20 > octets are allocated, but the most significant octet is=20 > specified to be zero - see RFC 2865, or the more recent=20 > draft-cam-winget-eap-fast which is on the agenda of the IESG=20 > telechat tomorrow. An interesting case is > draft-ietf-capwap-protocol-specification-04 which uses three=20 > octets in one place and four octets in four other places of=20 > the same document.=20 >=20 > I do not know where the limitation to three meaningful octets=20 > started to be applied and why. Maybe we should not care,=20 > because 24 bits are enough for more than 8 million=20 > enterprises, and this may be enough for the future at sight=20 > (28k were allocated up to now). I would however invite=20 > opinions, especially if somebody believes that there is a=20 > problem here and any actions or guidance from the area is needed.=20 >=20 > Dan >=20 >=20 > =20 >=20 >=20 > _______________________________________________ > AAA-DOCTORS mailing list > AAA-DOCTORS@ietf.org > https://www1.ietf.org/mailman/listinfo/aaa-doctors >=20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Jan 24 19:33:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9sY3-0007c1-Me; Wed, 24 Jan 2007 19:33:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9sY2-0007aj-4u; Wed, 24 Jan 2007 19:33:02 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9sXz-0001LB-P2; Wed, 24 Jan 2007 19:33:02 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0P0WwAA013561; Wed, 24 Jan 2007 19:32:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jan 2007 02:32:56 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-DOCTORS] Enterprise codes - three or four octets Thread-Index: AcdAE0ku+NFjZYnWRLGw1/LDcSCKlQAAL8FwAABRc0A= References: From: "Romascanu, Dan \(Dan\)" To: "Wijnen, Bert \(Bert\)" , "OPS Area" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: aaa-doctors@ietf.org, "MIB Doctors \(E-mail\)" Subject: [OPS-AREA] RE: [AAA-DOCTORS] Enterprise codes - three or four octets 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 Bert, The fact that you mentioned '(older) protocols' means that your opinion is that we should advise that new IETF documents use only the 32-bit values? There is no such guidance now and people rather use existing protocols as reference, so we may need to issue such a guidance.=20 Dan =20 =20 > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com]=20 > Sent: Thursday, January 25, 2007 2:04 AM > To: Romascanu, Dan (Dan); OPS Area > Cc: aaa-doctors@ietf.org; MIB Doctors (E-mail) > Subject: RE: [AAA-DOCTORS] Enterprise codes - three or four octets >=20 > Since, (as you note) there is no problem in the forseeable=20 > future, and since some protocols have already defined fields=20 > that only handle a 24-bit (i.e. 3 octet) value, maybe we=20 > should add some comment in the RFC-Editor mainatined registry=20 > that if they ever get to a value close to 25 bits, that we=20 > (IETF) need to be aware that some (older) protocols have=20 > limited fields of up to 24 bits. >=20 > Bert=20 >=20 > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: woensdag 24 januari 2007 15:57 > > To: OPS Area > > Cc: aaa-doctors@ietf.org; MIB Doctors (E-mail) > > Subject: [AAA-DOCTORS] Enterprise codes - three or four octets > >=20 > > I apologize for the cross-posting. I am not sure if this is=20 > a problem,=20 > > but I would like to get some advice. I see in different=20 > documents two=20 > > different ways of coding the SMI Private Enterprise Code.=20 > As far as I=20 > > can understand these numbers should be coded as 32-bit, or=20 > at least I=20 > > could not find any reason to limit them in any document=20 > that mentions=20 > > them starting with RFC 1700. However, in other documents=20 > four octets=20 > > are allocated, but the most significant octet is specified=20 > to be zero=20 > > - see RFC 2865, or the more recent=20 > draft-cam-winget-eap-fast which is=20 > > on the agenda of the IESG telechat tomorrow. An interesting case is > > draft-ietf-capwap-protocol-specification-04 which uses=20 > three octets in=20 > > one place and four octets in four other places of the same document. > >=20 > > I do not know where the limitation to three meaningful=20 > octets started=20 > > to be applied and why. Maybe we should not care, because 24=20 > bits are=20 > > enough for more than 8 million enterprises, and this may be=20 > enough for=20 > > the future at sight (28k were allocated up to now). I would however=20 > > invite opinions, especially if somebody believes that there is a=20 > > problem here and any actions or guidance from the area is needed. > >=20 > > Dan > >=20 > >=20 > > =20 > >=20 > >=20 > > _______________________________________________ > > AAA-DOCTORS mailing list > > AAA-DOCTORS@ietf.org > > https://www1.ietf.org/mailman/listinfo/aaa-doctors > >=20 >=20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Jan 24 19:46:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9slD-0006rC-Gb; Wed, 24 Jan 2007 19:46:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9slC-0006mb-PD; Wed, 24 Jan 2007 19:46:38 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9slA-0003tk-V0; Wed, 24 Jan 2007 19:46:38 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l0P0kVIp012163; Wed, 24 Jan 2007 18:46:31 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 18:46:31 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 01:46:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jan 2007 01:46:21 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-DOCTORS] Enterprise codes - three or four octets Thread-Index: AcdAE0ku+NFjZYnWRLGw1/LDcSCKlQAAL8FwAABRc0AAAS4SAA== References: From: "Wijnen, Bert \(Bert\)" To: "Romascanu, Dan \(Dan\)" , "OPS Area" X-OriginalArrivalTime: 25 Jan 2007 00:46:28.0324 (UTC) FILETIME=[3F927A40:01C7401A] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: aaa-doctors@ietf.org, "MIB Doctors \(E-mail\)" Subject: [OPS-AREA] RE: [AAA-DOCTORS] Enterprise codes - three or four octets 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 Mmm... no, my use of "older protocols" would be whatever is old at the time we get close to the limit. I think I personally would be ok to limit this Enterprise ID to 24 bits. I guess you would need IETF consensus on that before you can actually make that statement Bert=20 > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 > Sent: woensdag 24 januari 2007 16:33 > To: Wijnen, Bert (Bert); OPS Area > Cc: aaa-doctors@ietf.org; MIB Doctors (E-mail) > Subject: RE: [AAA-DOCTORS] Enterprise codes - three or four octets >=20 > Bert, >=20 > The fact that you mentioned '(older) protocols' means that=20 > your opinion is that we should advise that new IETF documents=20 > use only the 32-bit values? There is no such guidance now=20 > and people rather use existing protocols as reference, so we=20 > may need to issue such a guidance.=20 >=20 > Dan >=20 >=20 > =20 > =20 >=20 > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com] > > Sent: Thursday, January 25, 2007 2:04 AM > > To: Romascanu, Dan (Dan); OPS Area > > Cc: aaa-doctors@ietf.org; MIB Doctors (E-mail) > > Subject: RE: [AAA-DOCTORS] Enterprise codes - three or four octets > >=20 > > Since, (as you note) there is no problem in the forseeable=20 > future, and=20 > > since some protocols have already defined fields that only handle a=20 > > 24-bit (i.e. 3 octet) value, maybe we should add some=20 > comment in the=20 > > RFC-Editor mainatined registry that if they ever get to a=20 > value close=20 > > to 25 bits, that we > > (IETF) need to be aware that some (older) protocols have limited=20 > > fields of up to 24 bits. > >=20 > > Bert > >=20 > > > -----Original Message----- > > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > > Sent: woensdag 24 januari 2007 15:57 > > > To: OPS Area > > > Cc: aaa-doctors@ietf.org; MIB Doctors (E-mail) > > > Subject: [AAA-DOCTORS] Enterprise codes - three or four octets > > >=20 > > > I apologize for the cross-posting. I am not sure if this is > > a problem, > > > but I would like to get some advice. I see in different > > documents two > > > different ways of coding the SMI Private Enterprise Code.=20 > > As far as I > > > can understand these numbers should be coded as 32-bit, or > > at least I > > > could not find any reason to limit them in any document > > that mentions > > > them starting with RFC 1700. However, in other documents > > four octets > > > are allocated, but the most significant octet is specified > > to be zero > > > - see RFC 2865, or the more recent > > draft-cam-winget-eap-fast which is > > > on the agenda of the IESG telechat tomorrow. An=20 > interesting case is > > > draft-ietf-capwap-protocol-specification-04 which uses > > three octets in > > > one place and four octets in four other places of the=20 > same document. > > >=20 > > > I do not know where the limitation to three meaningful > > octets started > > > to be applied and why. Maybe we should not care, because 24 > > bits are > > > enough for more than 8 million enterprises, and this may be > > enough for > > > the future at sight (28k were allocated up to now). I=20 > would however=20 > > > invite opinions, especially if somebody believes that there is a=20 > > > problem here and any actions or guidance from the area is needed. > > >=20 > > > Dan > > >=20 > > >=20 > > > =20 > > >=20 > > >=20 > > > _______________________________________________ > > > AAA-DOCTORS mailing list > > > AAA-DOCTORS@ietf.org > > > https://www1.ietf.org/mailman/listinfo/aaa-doctors > > >=20 > >=20 >=20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Jan 24 20:46:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9tgg-0005wZ-Dr; Wed, 24 Jan 2007 20:46:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9tbY-0002jn-I9; Wed, 24 Jan 2007 20:40:44 -0500 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9tbX-00064W-8v; Wed, 24 Jan 2007 20:40:44 -0500 Received: from c-24-16-66-58.hsd1.wa.comcast.net ([24.16.66.58] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.63) (envelope-from ) id 1H9tbV-000B2C-Ou; Wed, 24 Jan 2007 20:40:41 -0500 Received: by internaut.com (Postfix, from userid 1000) id D01753A72A; Wed, 24 Jan 2007 17:40:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id C17FB39FDB; Wed, 24 Jan 2007 17:40:40 -0800 (PST) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.16.66.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Wed, 24 Jan 2007 17:40:40 -0800 (PST) From: Bernard Aboba To: "Wijnen, Bert (Bert)" In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe X-Mailman-Approved-At: Wed, 24 Jan 2007 20:46:01 -0500 Cc: aaa-doctors@ietf.org, "MIB Doctors \(E-mail\)" , OPS Area Subject: [OPS-AREA] RE: [AAA-DOCTORS] Enterprise codes - three or four octets 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 would also mention that there has been talk at various points about using 2 octet values. That would seem to be inadvisable -- and it might make sense to issue a recommendation describing a recommendation (e.g. allocate 4 octets). On Thu, 25 Jan 2007, Wijnen, Bert (Bert) wrote: > Since, (as you note) there is no problem in the forseeable future, > and since some protocols have already defined fields that only > handle a 24-bit (i.e. 3 octet) value, maybe we should add some > comment in the RFC-Editor mainatined registry that if they ever get > to a value close to 25 bits, that we (IETF) need to be aware that > some (older) protocols have limited fields of up to 24 bits. > > Bert > > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: woensdag 24 januari 2007 15:57 > > To: OPS Area > > Cc: aaa-doctors@ietf.org; MIB Doctors (E-mail) > > Subject: [AAA-DOCTORS] Enterprise codes - three or four octets > > > > I apologize for the cross-posting. I am not sure if this is a > > problem, but I would like to get some advice. I see in > > different documents two different ways of coding the SMI > > Private Enterprise Code. As far as I can understand these > > numbers should be coded as 32-bit, or at least I could not > > find any reason to limit them in any document that mentions > > them starting with RFC 1700. However, in other documents four > > octets are allocated, but the most significant octet is > > specified to be zero - see RFC 2865, or the more recent > > draft-cam-winget-eap-fast which is on the agenda of the IESG > > telechat tomorrow. An interesting case is > > draft-ietf-capwap-protocol-specification-04 which uses three > > octets in one place and four octets in four other places of > > the same document. > > > > I do not know where the limitation to three meaningful octets > > started to be applied and why. Maybe we should not care, > > because 24 bits are enough for more than 8 million > > enterprises, and this may be enough for the future at sight > > (28k were allocated up to now). I would however invite > > opinions, especially if somebody believes that there is a > > problem here and any actions or guidance from the area is needed. > > > > Dan > > > > > > > > > > > > _______________________________________________ > > AAA-DOCTORS mailing list > > AAA-DOCTORS@ietf.org > > https://www1.ietf.org/mailman/listinfo/aaa-doctors > > > > _______________________________________________ > AAA-DOCTORS mailing list > AAA-DOCTORS@ietf.org > https://www1.ietf.org/mailman/listinfo/aaa-doctors > _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Jan 24 20:53:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9to9-0001F5-U2; Wed, 24 Jan 2007 20:53:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9to7-0001Dr-K6; Wed, 24 Jan 2007 20:53:43 -0500 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9to6-0008KP-7R; Wed, 24 Jan 2007 20:53:43 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc11) with SMTP id <2007012501534101100nfm0ve>; Thu, 25 Jan 2007 01:53:41 +0000 From: "David B Harrington" To: "'Romascanu, Dan \(Dan\)'" , "'Wijnen, Bert \(Bert\)'" , "'OPS Area'" References: Date: Wed, 24 Jan 2007 20:50:04 -0500 Message-ID: <03ee01c74023$221b3570$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-reply-to: Thread-index: AcdAE0ku+NFjZYnWRLGw1/LDcSCKlQAAL8FwAABRc0AAAO7CUA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: aaa-doctors@ietf.org, "'MIB Doctors \(E-mail\)'" Subject: [OPS-AREA] RE: [MIB-DOCTORS] RE: [AAA-DOCTORS] Enterprise codes - three or fouroctets 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, According to www.iana.org, the defining document for ENTERPRISE is RFC2578. I believe this is the updated defining document; the original appears to be RFC1065 (Structure and Identification of Management Information for TCP/IP-based internets). Each enterprise is assigned a subtree: "For example, if the "Flintstones, Inc." enterprise produced networking subsystems, then they could request a node under the enterprises subtree from the Assigned Numbers authority." A node is represented in SMI as a sub-identifier. According to RFC2578, a sub-identifier has a value from 0..2^32-1 (4294967295 decimal). This would argue for a 32-bit field size, wouldn't it? dbh > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Wednesday, January 24, 2007 7:33 PM > To: Wijnen, Bert (Bert); OPS Area > Cc: aaa-doctors@ietf.org; MIB Doctors (E-mail) > Subject: [MIB-DOCTORS] RE: [AAA-DOCTORS] Enterprise codes - > three or fouroctets > > Bert, > > The fact that you mentioned '(older) protocols' means that > your opinion > is that we should advise that new IETF documents use only the 32-bit > values? There is no such guidance now and people rather use existing > protocols as reference, so we may need to issue such a guidance. > > Dan > > > > > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com] > > Sent: Thursday, January 25, 2007 2:04 AM > > To: Romascanu, Dan (Dan); OPS Area > > Cc: aaa-doctors@ietf.org; MIB Doctors (E-mail) > > Subject: RE: [AAA-DOCTORS] Enterprise codes - three or four octets > > > > Since, (as you note) there is no problem in the forseeable > > future, and since some protocols have already defined fields > > that only handle a 24-bit (i.e. 3 octet) value, maybe we > > should add some comment in the RFC-Editor mainatined registry > > that if they ever get to a value close to 25 bits, that we > > (IETF) need to be aware that some (older) protocols have > > limited fields of up to 24 bits. > > > > Bert > > > > > -----Original Message----- > > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > > Sent: woensdag 24 januari 2007 15:57 > > > To: OPS Area > > > Cc: aaa-doctors@ietf.org; MIB Doctors (E-mail) > > > Subject: [AAA-DOCTORS] Enterprise codes - three or four octets > > > > > > I apologize for the cross-posting. I am not sure if this is > > a problem, > > > but I would like to get some advice. I see in different > > documents two > > > different ways of coding the SMI Private Enterprise Code. > > As far as I > > > can understand these numbers should be coded as 32-bit, or > > at least I > > > could not find any reason to limit them in any document > > that mentions > > > them starting with RFC 1700. However, in other documents > > four octets > > > are allocated, but the most significant octet is specified > > to be zero > > > - see RFC 2865, or the more recent > > draft-cam-winget-eap-fast which is > > > on the agenda of the IESG telechat tomorrow. An > interesting case is > > > draft-ietf-capwap-protocol-specification-04 which uses > > three octets in > > > one place and four octets in four other places of the > same document. > > > > > > I do not know where the limitation to three meaningful > > octets started > > > to be applied and why. Maybe we should not care, because 24 > > bits are > > > enough for more than 8 million enterprises, and this may be > > enough for > > > the future at sight (28k were allocated up to now). I > would however > > > invite opinions, especially if somebody believes that there is a > > > problem here and any actions or guidance from the area is needed. > > > > > > Dan > > > > > > > > > > > > > > > > > > _______________________________________________ > > > AAA-DOCTORS mailing list > > > AAA-DOCTORS@ietf.org > > > https://www1.ietf.org/mailman/listinfo/aaa-doctors > > > > > > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www1.ietf.org/mailman/listinfo/mib-doctors > _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Jan 24 23:41:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9wPh-0005UC-0Y; Wed, 24 Jan 2007 23:40:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9wPf-0005Tz-ER; Wed, 24 Jan 2007 23:40:39 -0500 Received: from smtp-bedford.mitre.org ([192.160.51.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9wPd-000789-W5; Wed, 24 Jan 2007 23:40:39 -0500 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with SMTP id l0P4ebXb015794; Wed, 24 Jan 2007 23:40:37 -0500 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 83323BEFB; Wed, 24 Jan 2007 23:40:37 -0500 (EST) Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id l0P4eans015776; Wed, 24 Jan 2007 23:40:36 -0500 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 23:40:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [OPS-AREA] RE: [MIB-DOCTORS] RE: [AAA-DOCTORS] Enterprise codes -three or fouroctets Date: Wed, 24 Jan 2007 23:40:35 -0500 Message-ID: <4915F014FDD99049A9C3A8C1B832004F01883911@IMCSRV2.MITRE.ORG> In-Reply-To: <03ee01c74023$221b3570$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] RE: [MIB-DOCTORS] RE: [AAA-DOCTORS] Enterprise codes -three or fouroctets Thread-Index: AcdAE0ku+NFjZYnWRLGw1/LDcSCKlQAAL8FwAABRc0AAAO7CUAAIXYWw References: <03ee01c74023$221b3570$0600a8c0@china.huawei.com> From: "Natale, Bob" To: "David B Harrington" , "Romascanu, Dan (Dan)" , "Wijnen, Bert (Bert)" , "OPS Area" X-OriginalArrivalTime: 25 Jan 2007 04:40:36.0615 (UTC) FILETIME=[F5019170:01C7403A] X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: aaa-doctors@ietf.org, "MIB Doctors \(E-mail\)" 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's analysis certainly seems correct to me. Any protocols that limit enterprise values to something less than a sub-id would seem to be flawed (albeit with low risk of causing problems per Dan's observations on usage to date...of course, with IPv6 and the changing definition of enterprise in the real world, who knows! :). Cheers, BobN=20 -----Original Message----- From: David B Harrington [mailto:dbharrington@comcast.net]=20 Sent: Wednesday, January 24, 2007 8:50 PM To: 'Romascanu, Dan (Dan)'; 'Wijnen, Bert (Bert)'; 'OPS Area' Cc: aaa-doctors@ietf.org; 'MIB Doctors (E-mail)' Subject: [OPS-AREA] RE: [MIB-DOCTORS] RE: [AAA-DOCTORS] Enterprise codes -three or fouroctets Hi, According to www.iana.org, the defining document for ENTERPRISE is RFC2578. I believe this is the updated defining document; the original appears to be RFC1065 (Structure and Identification of Management Information for TCP/IP-based internets).=20 Each enterprise is assigned a subtree: "For example, if the "Flintstones, Inc." enterprise produced networking subsystems, then they could request a node under the enterprises subtree from the Assigned Numbers authority." A node is represented in SMI as a sub-identifier. According to RFC2578, a sub-identifier has a value from 0..2^32-1 (4294967295 decimal).=20 This would argue for a 32-bit field size, wouldn't it? dbh > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 > Sent: Wednesday, January 24, 2007 7:33 PM > To: Wijnen, Bert (Bert); OPS Area > Cc: aaa-doctors@ietf.org; MIB Doctors (E-mail) > Subject: [MIB-DOCTORS] RE: [AAA-DOCTORS] Enterprise codes -=20 > three or fouroctets >=20 > Bert, >=20 > The fact that you mentioned '(older) protocols' means that=20 > your opinion > is that we should advise that new IETF documents use only the 32-bit > values? There is no such guidance now and people rather use existing > protocols as reference, so we may need to issue such a guidance.=20 >=20 > Dan >=20 >=20 > =20 > =20 >=20 > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com]=20 > > Sent: Thursday, January 25, 2007 2:04 AM > > To: Romascanu, Dan (Dan); OPS Area > > Cc: aaa-doctors@ietf.org; MIB Doctors (E-mail) > > Subject: RE: [AAA-DOCTORS] Enterprise codes - three or four octets > >=20 > > Since, (as you note) there is no problem in the forseeable=20 > > future, and since some protocols have already defined fields=20 > > that only handle a 24-bit (i.e. 3 octet) value, maybe we=20 > > should add some comment in the RFC-Editor mainatined registry=20 > > that if they ever get to a value close to 25 bits, that we=20 > > (IETF) need to be aware that some (older) protocols have=20 > > limited fields of up to 24 bits. > >=20 > > Bert=20 > >=20 > > > -----Original Message----- > > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > > Sent: woensdag 24 januari 2007 15:57 > > > To: OPS Area > > > Cc: aaa-doctors@ietf.org; MIB Doctors (E-mail) > > > Subject: [AAA-DOCTORS] Enterprise codes - three or four octets > > >=20 > > > I apologize for the cross-posting. I am not sure if this is=20 > > a problem,=20 > > > but I would like to get some advice. I see in different=20 > > documents two=20 > > > different ways of coding the SMI Private Enterprise Code.=20 > > As far as I=20 > > > can understand these numbers should be coded as 32-bit, or=20 > > at least I=20 > > > could not find any reason to limit them in any document=20 > > that mentions=20 > > > them starting with RFC 1700. However, in other documents=20 > > four octets=20 > > > are allocated, but the most significant octet is specified=20 > > to be zero=20 > > > - see RFC 2865, or the more recent=20 > > draft-cam-winget-eap-fast which is=20 > > > on the agenda of the IESG telechat tomorrow. An=20 > interesting case is > > > draft-ietf-capwap-protocol-specification-04 which uses=20 > > three octets in=20 > > > one place and four octets in four other places of the=20 > same document. > > >=20 > > > I do not know where the limitation to three meaningful=20 > > octets started=20 > > > to be applied and why. Maybe we should not care, because 24=20 > > bits are=20 > > > enough for more than 8 million enterprises, and this may be=20 > > enough for=20 > > > the future at sight (28k were allocated up to now). I=20 > would however=20 > > > invite opinions, especially if somebody believes that there is a > > > problem here and any actions or guidance from the area is needed. > > >=20 > > > Dan > > >=20 > > >=20 > > > =20 > > >=20 > > >=20 > > > _______________________________________________ > > > AAA-DOCTORS mailing list > > > AAA-DOCTORS@ietf.org > > > https://www1.ietf.org/mailman/listinfo/aaa-doctors > > >=20 > >=20 >=20 > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www1.ietf.org/mailman/listinfo/mib-doctors >=20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Thu Jan 25 01:53:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9yTu-0003Sq-7D; Thu, 25 Jan 2007 01:53:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9yTr-0003Rq-Uj for ops-area@ietf.org; Thu, 25 Jan 2007 01:53:07 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9ySh-00048y-0Z for ops-area@ietf.org; Thu, 25 Jan 2007 01:51:56 -0500 Received: (qmail 6709 invoked from network); 24 Jan 2007 22:51:22 -0800 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 24 Jan 2007 22:51:22 -0800 Date: Wed, 24 Jan 2007 22:51:19 -0800 (PST) From: "David T. Perkins" X-X-Sender: dperkins@shell4.bayarea.net To: "Romascanu, Dan \\(Dan\\)" In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: aaa-doctors@ietf.org, "MIB Doctors \\\(E-mail\\\)" , OPS Area Subject: [OPS-AREA] Re: [MIB-DOCTORS] Enterprise codes - three or four octets 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, I was behind using the approach of creating a 32-bit number in capwap that is EnterpriseId*256 + value. (That is, using only the lower 24bits and effectively limiting the range to 24 bits.) I cloned what was done in RFC 3411 for the definition of SnmpSecurityModel which is used as the value of the msgSecurityModel field (which is only 31 bits) and defined in RFC 3412. I believe that effectively limiting EnterpriseIDs to 24 bits is reasonable based on the allocation of OUIs, on which I did a pretty extensive analysis of the assignements of values values (which have been in existance before enterpriseIDs were created). I came to the conclusion that the allocated OUIs were close enough to 16 bits of allocation to make me uncomfortable with using only 16 bits of the EnterpriseID, but quite comfortable with using 24 bits. Please send me email if you have any additional questions! Regards, /david t. perkins On Thu, 25 Jan 2007, Romascanu, Dan \(Dan\) wrote: > I apologize for the cross-posting. I am not sure if this is a problem, > but I would like to get some advice. I see in different documents two > different ways of coding the SMI Private Enterprise Code. As far as I > can understand these numbers should be coded as 32-bit, or at least I > could not find any reason to limit them in any document that mentions > them starting with RFC 1700. However, in other documents four octets are > allocated, but the most significant octet is specified to be zero - see > RFC 2865, or the more recent draft-cam-winget-eap-fast which is on the > agenda of the IESG telechat tomorrow. An interesting case is > draft-ietf-capwap-protocol-specification-04 which uses three octets in > one place and four octets in four other places of the same document. > > I do not know where the limitation to three meaningful octets started to > be applied and why. Maybe we should not care, because 24 bits are enough > for more than 8 million enterprises, and this may be enough for the > future at sight (28k were allocated up to now). I would however invite > opinions, especially if somebody believes that there is a problem here > and any actions or guidance from the area is needed. > > Dan > > > > > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www1.ietf.org/mailman/listinfo/mib-doctors > _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Thu Jan 25 12:54:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA8nF-0007GW-Vj; Thu, 25 Jan 2007 12:53:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA8nE-0007G4-3c; Thu, 25 Jan 2007 12:53:48 -0500 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA8nC-0000Xp-Gi; Thu, 25 Jan 2007 12:53:48 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l0PHrid4019611; Thu, 25 Jan 2007 11:53:44 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 11:53:43 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 18:53:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jan 2007 18:53:04 +0100 Message-ID: In-Reply-To: <03ee01c74023$221b3570$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MIB-DOCTORS] RE: [AAA-DOCTORS] Enterprise codes - three or fouroctets Thread-Index: AcdAE0ku+NFjZYnWRLGw1/LDcSCKlQAAL8FwAABRc0AAAO7CUAAjMLcw References: <03ee01c74023$221b3570$0600a8c0@china.huawei.com> From: "Wijnen, Bert \(Bert\)" To: "David B Harrington" , "Romascanu, Dan \(Dan\)" , "OPS Area" X-OriginalArrivalTime: 25 Jan 2007 17:53:05.0214 (UTC) FILETIME=[AA2DFDE0:01C740A9] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: aaa-doctors@ietf.org, "MIB Doctors \(E-mail\)" Subject: [OPS-AREA] RE: [MIB-DOCTORS] RE: [AAA-DOCTORS] Enterprise codes - three or fouroctets 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 Yes, BUT=20 - we as SNMP/SMI experts have violated the rule (as Dave Perkins=20 also stated). I know we carefully investigated this at the time, and we also made a note of it in our DESCRIPTION clause in the TC where we did the violation. Nevertheless, we DID violate the approved definition of Enterprise OID. - we are aware that others are doing (possibly have done) this too.=20 - According to Dan and Bernard, there are other wanting to violate, some even seem to want to limit it to 2 octets. So we better: - recognize/document what we have done (violated the limit) - document that others are doing so too, - specify what we all agree (consensus) to be a acceptable limit (3 octets) - document this with IANA so it is public. Possibly we need a short draft for that, although I would think that if we as MIB doctors can get agreement and if Dan runs a sortf of IETF Last Call; then possibly it can just be some text at the top of the enterprise OID registration directory at iana. Bert > -----Original Message----- > From: David B Harrington [mailto:dbharrington@comcast.net]=20 > Sent: woensdag 24 januari 2007 17:50 > To: 'Romascanu, Dan (Dan)'; Wijnen, Bert (Bert); 'OPS Area' > Cc: aaa-doctors@ietf.org; 'MIB Doctors (E-mail)' > Subject: RE: [MIB-DOCTORS] RE: [AAA-DOCTORS] Enterprise codes=20 > - three or fouroctets >=20 > Hi, >=20 > According to www.iana.org, the defining document for=20 > ENTERPRISE is RFC2578. I believe this is the updated defining=20 > document; the original appears to be RFC1065 (Structure and=20 > Identification of Management Information for TCP/IP-based internets).=20 >=20 > Each enterprise is assigned a subtree: > "For example, if the > "Flintstones, Inc." enterprise produced networking=20 > subsystems, then > they could request a node under the enterprises subtree from the > Assigned Numbers authority." >=20 > A node is represented in SMI as a sub-identifier. > According to RFC2578, a sub-identifier has a value from 0..2^32-1 > (4294967295 decimal).=20 >=20 > This would argue for a 32-bit field size, wouldn't it? >=20 > dbh >=20 > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: Wednesday, January 24, 2007 7:33 PM > > To: Wijnen, Bert (Bert); OPS Area > > Cc: aaa-doctors@ietf.org; MIB Doctors (E-mail) > > Subject: [MIB-DOCTORS] RE: [AAA-DOCTORS] Enterprise codes -=20 > three or=20 > > fouroctets > >=20 > > Bert, > >=20 > > The fact that you mentioned '(older) protocols' means that your=20 > > opinion is that we should advise that new IETF documents=20 > use only the=20 > > 32-bit values? There is no such guidance now and people rather use > existing > > protocols as reference, so we may need to issue such a guidance.=20 > >=20 > > Dan > >=20 > >=20 > > =20 > > =20 > >=20 > > > -----Original Message----- > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com] > > > Sent: Thursday, January 25, 2007 2:04 AM > > > To: Romascanu, Dan (Dan); OPS Area > > > Cc: aaa-doctors@ietf.org; MIB Doctors (E-mail) > > > Subject: RE: [AAA-DOCTORS] Enterprise codes - three or four octets > > >=20 > > > Since, (as you note) there is no problem in the=20 > forseeable future,=20 > > > and since some protocols have already defined fields that only=20 > > > handle a 24-bit (i.e. 3 octet) value, maybe we should add some=20 > > > comment in the RFC-Editor mainatined registry that if=20 > they ever get=20 > > > to a value close to 25 bits, that we > > > (IETF) need to be aware that some (older) protocols have limited=20 > > > fields of up to 24 bits. > > >=20 > > > Bert > > >=20 > > > > -----Original Message----- > > > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > > > Sent: woensdag 24 januari 2007 15:57 > > > > To: OPS Area > > > > Cc: aaa-doctors@ietf.org; MIB Doctors (E-mail) > > > > Subject: [AAA-DOCTORS] Enterprise codes - three or four octets > > > >=20 > > > > I apologize for the cross-posting. I am not sure if this is > > > a problem, > > > > but I would like to get some advice. I see in different > > > documents two > > > > different ways of coding the SMI Private Enterprise Code.=20 > > > As far as I > > > > can understand these numbers should be coded as 32-bit, or > > > at least I > > > > could not find any reason to limit them in any document > > > that mentions > > > > them starting with RFC 1700. However, in other documents > > > four octets > > > > are allocated, but the most significant octet is specified > > > to be zero > > > > - see RFC 2865, or the more recent > > > draft-cam-winget-eap-fast which is > > > > on the agenda of the IESG telechat tomorrow. An > > interesting case is > > > > draft-ietf-capwap-protocol-specification-04 which uses > > > three octets in > > > > one place and four octets in four other places of the > > same document. > > > >=20 > > > > I do not know where the limitation to three meaningful > > > octets started > > > > to be applied and why. Maybe we should not care, because 24 > > > bits are > > > > enough for more than 8 million enterprises, and this may be > > > enough for > > > > the future at sight (28k were allocated up to now). I > > would however > > > > invite opinions, especially if somebody believes that there is a >=20 > > > > problem here and any actions or guidance from the area is > needed. > > > >=20 > > > > Dan > > > >=20 > > > >=20 > > > > =20 > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > AAA-DOCTORS mailing list > > > > AAA-DOCTORS@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/aaa-doctors > > > >=20 > > >=20 > >=20 > > _______________________________________________ > > MIB-DOCTORS mailing list > > MIB-DOCTORS@ietf.org > > https://www1.ietf.org/mailman/listinfo/mib-doctors > >=20 >=20 >=20 >=20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Mon Jan 29 09:07:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBX99-0006E8-ON; Mon, 29 Jan 2007 09:06:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBX98-0006Co-7l; Mon, 29 Jan 2007 09:06:10 -0500 Received: from [198.152.12.103] (helo=nj300815-ier2.net.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBX95-0007li-Qx; Mon, 29 Jan 2007 09:06:10 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0TE61YF032141; Mon, 29 Jan 2007 09:06:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Jan 2007 16:06:00 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OPS Area Meetings and mini-BOFs: Preliminary Agenda for Prague Thread-Index: AcdDrpqUSwS6PSnaQHKopeF9pnPMag== From: "Romascanu, Dan \(Dan\)" To: "OPS Area" , , , , "MIB Doctors \(E-mail\)" , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.1 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: Subject: [OPS-AREA] OPS Area Meetings and mini-BOFs: Preliminary Agenda for Prague 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 of the meetings in Prague, as well as the list of mini-BOFs that David and myself have approved for Prague. We were not able to grant to everybody the time that you requested - please be prepared to adjust and manage your time accordingly. Also note that there still may be changes in the dates and time of the meting slots as result of IESG-Secretary changes.=20 Please comment on the agenda items and mini-BOF proposals.=20 We are looking forward to see you all in Prague.=20 Dan =20 Operations and Management (OPS) Area AGENDA Meeting : IETF68, Monday March 19, 2007 and Thursday March 22, 2007 Location: Prague, Congress II, Monday March 19, 2007 15:20 to 17:20 and Grand Ballroom Thursday March 22, 2007 9:00 to 11:30 Chairs : David Kessens (david.kessens@nokia.com) and Dan Romascanu (dromasca@avaya.com)=20 Jabber : ops@jabber.ietf.org URL : http://www.ops.ietf.org/ Agenda : version 0.1 (draft) = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Meeting 1 - Monday March 19, 2007 15:20 to 17:20 1. Meeting Administrivia ADs (total: 5 min) - Mailing list and URL - Minutes Scribe - Jabber Scribe - Blue Sheets 2. Mini-BOF A: COPS push mode policy configuration - Tom Taylor and Tina Tsou (total: 30 min) This mini-BOF is requested to gain comments on a technical proposal to reduce the number of messages required when COPS is used to support push mode policy configuration, where each request-state corresponds to an user session. The essence of this proposal is to allow the PDP to request the opening of a new request-state in the same message that sends down policy to be stored against this request-state. At the other end of the session life cycle, allow the PDP to delete a request-state.=20 The proposed extensions to COPS could save two to three messages per session, depending on the details that are finally agreed. I-D: to be submitted=20 3. Mini-BOF B: - Manageability and Operational Guidelines - David Harrington (total: 30 min) We need to develop multi-protocol manageability and operational guidelines for developers of protocols in the IETF. An internet-draft has been published that summarizes previous work on this goal as a starting point. This work would lead to either a WG, if enough people want to be involved, or a design team to get the document finished. If we can get enough feedback from operators and from protocol designers, this could lead to a BCP; with limited input it would lead to an Informational RFC instead.=20 I-D: to be submitted 4. Mini-BOF C: Best Current Practices in Operations and Management - David Harrington (total: 20 min) This would be an effort to get operators together in a WG to develop a set of best current practices, and a description of supporting technologies, for manageability and operations, similar to the work done in the OpSec WG. There will not be an internet-draft published prior to ietf68. A WG should be created for operators to do this work. 5. Improved Efficiency of the OPS Area - proposal for the formation of a OPS Area WG - ADs (total: 20 min) 6. Open Microphone - 15 min Meeting 2 - Monday March 19, 2007 - 9:00 to 11:30AM 1. Meeting Administrivia ADs (total: 5 min) - Mailing list and URL - Minutes Scribe - Jabber Scribe - Blue Sheets 2. Mini-BOF D: NE/facilities/lines/protocols/services data modeling - Michael Alexander (total: 40 min) Network Management (NM) standards have traditionally been focused on protocols, such as pertaining to configuration management and discovery. Yet, all areas of Network Management, ranging from Element Management (EM) to Network Management Systems (NMS) and Service Management Systems have in common that they critically rely on underlying data structures describing devices and services being managed. Network elements (NE) frequently spawn ten thousands of managed objects, such as for a multiservice switch...Traditionally, standardization of access-methods (protocols), discovery, etc. have received most attention, while the more heterogeneous data models and data modeling per saw comparatively less. As there are real possibilities to standardize underlying and universal commonalities in EMS/NMS/Service Management Systems on the one side and managed attributes of NEs, protocols, transmission facilities, lines and services on the other, the two distributions should be closer aligned. Despite the complexity, it is possible to identify and define frameworks and meta models of each constituent and their relation to each other, that would substantially ease the management of present and future devices, networks and services. I-D:=20 3. Mini-BOF E: MIB module editing in XML : Emile Stephan (total: 20 min) Present the state of the art of editing MIB module in XML; Introduce a basic template to edit SMI items in pure XML instead of in raw text; Propose a simple XML template for SMI items; discuss the connections with XML schema and network management protocols. I-D: draft-stephan-ops-xml-mib-module-template-00 (under edition to be submitted before mid February) 4. Mini-BOF F: Japanese Data Model Standards: Tomoyuki Iijima (total: 20 min) I'd like to show the data model examples we developed and was adopted in the Japanese Standard body. We developed data models of VLAN, Filter (Access Control List), and so on and those data models were adopted by Japanese standardization body called INTAP/OSMIC as standard data models. I'd like to make our data model examples be adopted as an Informational RFC. I-D: to be submitted 5. Mini-BOF G: OWL techniques for MIB to XML documents and schema translation - Bob Natale (total: 40 min) Specification of a standard methodology for translating SNMP MIBs into outputs more directly usable by emerging SOA/web services management tools, and specification of a standard methodology for validating those translations. Appropriate translation outputs are TBD by the WG, but can be expected to include one or more of the following: XML, RDF, WSDL, WS-Policy, WS-Event/Notification, Ontology. The translation output(s) should allow for extension of the respective managed element data model in the native SOA/web services environment. Because of the extensibility objective, reverse translation back into SNMP MIB format is a non-goal of the WG, but the possibility should be considered when weighing alternatives. I-D: to be submitted 6. Open microphone (total: 25 min) =20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Mon Jan 29 09:07:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBXA8-0006oH-Rh; Mon, 29 Jan 2007 09:07:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBXA6-0006mh-Rs; Mon, 29 Jan 2007 09:07:10 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBXA5-0007qw-C2; Mon, 29 Jan 2007 09:07:10 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0TE76eB020529; Mon, 29 Jan 2007 09:07:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Jan 2007 16:07:06 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OPS Area Meetings and mini-BOFs: Preliminary Agenda for Prague (corrected date) Thread-Index: AcdDrpqUSwS6PSnaQHKopeF9pnPMag== From: "Romascanu, Dan \(Dan\)" To: "OPS Area" , , , , "MIB Doctors \(E-mail\)" , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: Subject: [OPS-AREA] OPS Area Meetings and mini-BOFs: Preliminary Agenda for Prague (corrected date) 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 of the meetings in Prague, as well as the list of mini-BOFs that David and myself have approved for Prague. We were not able to grant to everybody the time that you requested - please be prepared to adjust and manage your time accordingly. Also note that there still may be changes in the dates and time of the meting slots as result of IESG-Secretary changes.=20 Please comment on the agenda items and mini-BOF proposals.=20 We are looking forward to see you all in Prague.=20 Dan =20 Operations and Management (OPS) Area AGENDA Meeting : IETF68, Monday March 19, 2007 and Thursday March 22, 2007 Location: Prague, Congress II, Monday March 19, 2007 15:20 to 17:20 and Grand Ballroom Thursday March 22, 2007 9:00 to 11:30 Chairs : David Kessens (david.kessens@nokia.com) and Dan Romascanu (dromasca@avaya.com)=20 Jabber : ops@jabber.ietf.org URL : http://www.ops.ietf.org/ Agenda : version 0.1 (draft) = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Meeting 1 - Monday March 19, 2007 15:20 to 17:20 1. Meeting Administrivia ADs (total: 5 min) - Mailing list and URL - Minutes Scribe - Jabber Scribe - Blue Sheets 2. Mini-BOF A: COPS push mode policy configuration - Tom Taylor and Tina Tsou (total: 30 min) This mini-BOF is requested to gain comments on a technical proposal to reduce the number of messages required when COPS is used to support push mode policy configuration, where each request-state corresponds to an user session. The essence of this proposal is to allow the PDP to request the opening of a new request-state in the same message that sends down policy to be stored against this request-state. At the other end of the session life cycle, allow the PDP to delete a request-state.=20 The proposed extensions to COPS could save two to three messages per session, depending on the details that are finally agreed. I-D: to be submitted=20 3. Mini-BOF B: - Manageability and Operational Guidelines - David Harrington (total: 30 min) We need to develop multi-protocol manageability and operational guidelines for developers of protocols in the IETF. An internet-draft has been published that summarizes previous work on this goal as a starting point. This work would lead to either a WG, if enough people want to be involved, or a design team to get the document finished. If we can get enough feedback from operators and from protocol designers, this could lead to a BCP; with limited input it would lead to an Informational RFC instead.=20 I-D: to be submitted 4. Mini-BOF C: Best Current Practices in Operations and Management - David Harrington (total: 20 min) This would be an effort to get operators together in a WG to develop a set of best current practices, and a description of supporting technologies, for manageability and operations, similar to the work done in the OpSec WG. There will not be an internet-draft published prior to ietf68. A WG should be created for operators to do this work. 5. Improved Efficiency of the OPS Area - proposal for the formation of a OPS Area WG - ADs (total: 20 min) 6. Open Microphone - 15 min Meeting 2 - Thursday March 22, 2007 - 9:00 to 11:30AM 1. Meeting Administrivia ADs (total: 5 min) - Mailing list and URL - Minutes Scribe - Jabber Scribe - Blue Sheets 2. Mini-BOF D: NE/facilities/lines/protocols/services data modeling - Michael Alexander (total: 40 min) Network Management (NM) standards have traditionally been focused on protocols, such as pertaining to configuration management and discovery. Yet, all areas of Network Management, ranging from Element Management (EM) to Network Management Systems (NMS) and Service Management Systems have in common that they critically rely on underlying data structures describing devices and services being managed. Network elements (NE) frequently spawn ten thousands of managed objects, such as for a multiservice switch...Traditionally, standardization of access-methods (protocols), discovery, etc. have received most attention, while the more heterogeneous data models and data modeling per saw comparatively less. As there are real possibilities to standardize underlying and universal commonalities in EMS/NMS/Service Management Systems on the one side and managed attributes of NEs, protocols, transmission facilities, lines and services on the other, the two distributions should be closer aligned. Despite the complexity, it is possible to identify and define frameworks and meta models of each constituent and their relation to each other, that would substantially ease the management of present and future devices, networks and services. I-D:=20 3. Mini-BOF E: MIB module editing in XML : Emile Stephan (total: 20 min) Present the state of the art of editing MIB module in XML; Introduce a basic template to edit SMI items in pure XML instead of in raw text; Propose a simple XML template for SMI items; discuss the connections with XML schema and network management protocols. I-D: draft-stephan-ops-xml-mib-module-template-00 (under edition to be submitted before mid February) 4. Mini-BOF F: Japanese Data Model Standards: Tomoyuki Iijima (total: 20 min) I'd like to show the data model examples we developed and was adopted in the Japanese Standard body. We developed data models of VLAN, Filter (Access Control List), and so on and those data models were adopted by Japanese standardization body called INTAP/OSMIC as standard data models. I'd like to make our data model examples be adopted as an Informational RFC. I-D: to be submitted 5. Mini-BOF G: OWL techniques for MIB to XML documents and schema translation - Bob Natale (total: 40 min) Specification of a standard methodology for translating SNMP MIBs into outputs more directly usable by emerging SOA/web services management tools, and specification of a standard methodology for validating those translations. Appropriate translation outputs are TBD by the WG, but can be expected to include one or more of the following: XML, RDF, WSDL, WS-Policy, WS-Event/Notification, Ontology. The translation output(s) should allow for extension of the respective managed element data model in the native SOA/web services environment. Because of the extensibility objective, reverse translation back into SNMP MIB format is a non-goal of the WG, but the possibility should be considered when weighing alternatives. I-D: to be submitted 6. Open microphone (total: 25 min) =20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Tue Jan 30 15:17:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBzPD-00049g-AF; Tue, 30 Jan 2007 15:16:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBzPC-00049a-GW for ops-area@ietf.org; Tue, 30 Jan 2007 15:16:38 -0500 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBzPA-0001et-MU for ops-area@ietf.org; Tue, 30 Jan 2007 15:16:38 -0500 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc13) with SMTP id <2007013020163401300i1brue>; Tue, 30 Jan 2007 20:16:34 +0000 From: "David B Harrington" To: "'Romascanu, Dan \(Dan\)'" , "'OPS Area'" , "'Netconf \(E-mail\)'" References: Date: Tue, 30 Jan 2007 15:12:48 -0500 Message-ID: <07f601c744ab$03c30f80$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-reply-to: Thread-index: Acc4+0bvmKvI+wdvRGqxnpDUxDSyQQAiR19AAskTnTA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 85fe3afc5d9560be77aa81420052017a Cc: 'Lisa Dusseault' Subject: [OPS-AREA] RE: [Notifications] Setting up email event streams 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="===============1018906262==" Errors-To: ops-area-bounces@ietf.org This is a multi-part message in MIME format. --===============1018906262== Content-Type: multipart/alternative; boundary="----=_NextPart_000_07F7_01C74481.1AED0780" This is a multi-part message in MIME format. ------=_NextPart_000_07F7_01C74481.1AED0780 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, A third common application-layer explicit event relay is syslog, and the syslog-security WG just submitted a spec for a standardized protocol and standardized transports over udp and tls to the IESG for advancement. They are resolving WGLC issues related to syslog-sign, a mechanism that "signs" messages to ensure they have not been modified in transit, and workin gon an update to RFC3195 which provides reliable in-order transport. A fourth is SNMP. The ISMS WG is dealing with the authentication/authorization issues of sending notifications, as well as request/response messages, sometimes through a proxy forwarder (relay). The netconf WG is also dealing with subscribe/unsubscribe issues and event stream aggregation issues. dbh _____ From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Tuesday, January 16, 2007 10:41 AM To: OPS Area; Netconf (E-mail) Cc: Lisa Dusseault Subject: FW: [Notifications] Setting up email event streams I apologize for the cross-posting, but the theme has some similarities with discussions that happened in the OPS area and specifically in NETCONF. Subscribing to the notifications list is probably the right way to follow this discussion or even contribute to it. Dan _____ From: Lisa Dusseault [mailto:lisa@osafoundation.org] Sent: Tuesday, January 16, 2007 1:16 AM To: Message Notifications interest group discussion list Subject: [Notifications] Setting up email event streams I've been meaning to send this out more broadly after a bit of private comment: two quite different models for setting up event streams based on what's easier to authenticate -- the event stream "owner" (in this case the mailbox owner) or the stream recipient. I hope it helps compare different approaches. Lisa --- The goal is to start (and stop) events flowing from an event source (in our case, an email server) to the event sink, frequently using a system with an explicit event relay. Because there are often three parties required in an event flow , we have to pick some way for the three parties to coordinate. The three parties are the event source (an email server), the event sink (a client, perhaps not an email client) and an event relay. The event relay has many users thus it has addresses for each user and possibly also addresses for devices/clients. Two kinds of application-layer explicit event relays are starting to be common: XMPP and SIP. For the purposes of considering an event feed setup model, we do not want to be concerned about the mostly orthogonal issue of what protocol to use to talk to event relay. So for now we assume that event relays have all features common to XMPP and SIP (addresses, pub/sub features, event stream aggregation). Choosing between two event stream setup models requires assumptions about - what kind of authorization is easier or more important to provide - whether there are a lot of different event sink addressess - whether direct access to the event source is always/usually available (can be affected by whether the event source is publicly available) - whether event flows stop and start frequently, or can simply be turned on for a very long term MODEL A. SUBSCRIBE Chain A-1 Description In this model, when a user decides to get an email event flow to a particular device or piece of software, the user typically works with the event sink interface to indicate where to get the events from. Then a SUBSCRIBE message of some kind gets generated by the event sink, sent to the event relay and is handled by the event source. A-2 Authorization issue The authorization problem here is to determine if the address that the SUBSCRIBE message comes from is permitted to receive these events. In the case of a publicly-subscribable resource this problem disappears. In many email use cases, only a small number of event sink addresses will be authorized to receive event notifications -- perhaps the event source (the email server) can simply be configured with a short allowed list of event recipients that doesn't change often (e.g. my personal IM address, my work address, and the one used by my phone provided by my phone service provider). Some SUBSCRIBE systems have the ability to provide a PENDING response to a subscription. This is used when an out-of-band mechanism is initiated to authorize the subscribing address. In an email event source use case, one obvious out-of-band mechanism is for the email server to create an email with a link saying "Click here to authorize this subscription". It's also possible to use a mechanism like URLAUTH to prove authorization -- in this approach, the subscriber provides a URL that has a secret token in it authorizing the subscription. It's possible that this would authorize the subscribing address for future subscriptions as well, or only for a limited period. A-3 Drawbacks: a) Only some notification protocols support SUBSCRIBE semantics. b) Complicated filters and event types (to support use cases like "Alert me on event type 'email arrives' if it is from my boss, has my full email address or the address of the developer list on the to line, and the subject does not begin with 'FUNNY'..." ) might need a little extra work. Both SIP and XMPP subscriptions can be extended in such a way that existing notification relays would pass on a filter specification in whatever language/format most appropriate for email. It might even be possible to send SIEVE conditionals in the body of the SUBSCRIBE message. XMPP has notification nodes in XEP-0060 and notification filters in XEP-0163. A-4 Advantages b) Allows for frequent starting and stopping of subscriptions, possibly an efficiency/scaling concern MODEL B. Sender RULES B-1 Description In this model, the user typically works with the event source in order to configure it to send events to a given set of addresses. For example, the user might have access to a Web interface to an email server where it can say "Send new message notifications to xmpp://lisa@psg.com" or someday use MANAGESIEVE. B-2 Authorization issue The authorization problem here is to determine if the user creating the sending rule is authorized to send an event stream to the receiving address. If anybody can send to the receiving address (e.g. email) then it's publicly addressable and the problem disappears. Many kinds of addresses are publicly addressable and use whitelisting together with asking permission ("do you wish to allow messages from this source in the future"). B-3 Drawbacks: a) Only some event sources support RULE systems. We are building SIEVE for email clients and servers but it may be harder to generalize this beyond email clients and servers. Even sticking strictly the proposed scope of email server sources, we have to consider whether a client such as a calendar client (subscribing for IMIP messages) or a time-management dashboard (subscribes to "unread" counts but doesn't otherwise read email) are going to be able to implement SIEVE, authenticate to mail servers etc. b) If sender rules are setup through Web interfaces, users are definitely not going to turn them on and off frequently. c) Failure feedback: how does the event source let the user know that some address keeps bouncing? ------=_NextPart_000_07F7_01C74481.1AED0780 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
A third common application-layer explicit event = relay is=20 syslog, and the syslog-security WG just submitted a spec for a = standardized=20 protocol and standardized transports over udp and tls to the IESG for=20 advancement. They are resolving WGLC issues related to syslog-sign, a = mechanism=20 that "signs" messages to ensure they have not been modified in transit, = and=20 workin gon an update to RFC3195 which provides reliable in-order=20 transport.
 
A fourth is SNMP. The ISMS WG is dealing with = the=20 authentication/authorization issues of sending notifications, as well as = request/response messages, sometimes through a proxy forwarder=20 (relay).
 
The netconf WG is also dealing with = subscribe/unsubscribe=20 issues and event stream aggregation issues.
 
dbh

From: owner-netconf@ops.ietf.org=20 [mailto:owner-netconf@ops.ietf.org] On Behalf Of Romascanu, Dan = (Dan)
Sent: Tuesday, January 16, 2007 10:41 AM
To: = OPS=20 Area; Netconf (E-mail)
Cc: Lisa Dusseault
Subject: = FW:=20 [Notifications] Setting up email event streams

I apologize for the cross-posting, but the = theme has=20 some similarities with discussions that happened in the OPS area and=20 specifically in NETCONF.
 
Subscribing to the notifications list is = probably the=20 right way to follow this discussion or even contribute to it.=20
 
Dan
 
 
 
 

From: Lisa Dusseault=20 [mailto:lisa@osafoundation.org]
Sent: Tuesday, January 16, = 2007=20 1:16 AM
To: Message Notifications interest group discussion=20 list
Subject: [Notifications] Setting up email event=20 streams

I've been meaning to send this out more broadly after a bit of = private=20 comment: two quite different models for setting up event streams based = on=20 what's easier to authenticate -- the event stream "owner" (in this = case the=20 mailbox owner) or the stream recipient.  I hope it helps compare=20 different approaches.

Lisa

---

The goal=20 is to start (and stop) events flowing from an event source (in our = case, an=20 email server) to the event sink, frequently using a system with an = explicit=20 event relay.  =20 Because there = are often=20 three parties required in an event flow , we have to pick some way for = the=20 three parties to coordinate.

The three=20 parties are the event source (an email server), the event sink (a = client,=20 perhaps not an email client)  and an=20 event relay. =20 The event relay = has many=20 users thus it has addresses for each user and possibly also addresses = for=20 devices/clients. =20 Two kinds of=20 application-layer explicit event relays are starting to be common: = XMPP and=20 SIP.  = For the purposes of = considering an event=20 feed setup model, we do not want to be concerned about the mostly = orthogonal=20 issue of what protocol to use to talk to event relay.  So for now we assume that = event relays=20 have all features common to XMPP and SIP (addresses, pub/sub features, = event=20 stream aggregation).

Choosing=20 between two event stream setup models requires assumptions = about
-=20 what kind of authorization is easier or more important to = provide
-=20 whether there are a lot of different event sink = addressess
-=20 whether direct access to the event source is always/usually available = (can be=20 affected by whether the event source is publicly = available)
-=20 whether event flows stop and start frequently, or can simply be turned = on for=20 a very long term

MODEL=20 A.  = SUBSCRIBE Chain

A-1=20 Description

In this=20 model, when a user decides to get an email event flow to a particular = device=20 or piece of software, the user typically works with the event sink = interface=20 to indicate where to get the events from.  Then a=20 SUBSCRIBE message of some kind gets generated by the event sink, sent = to the=20 event relay and is handled by the event source.

A-2=20 Authorization issue

The=20 authorization problem here is to determine if the address that the = SUBSCRIBE=20 message comes from is permitted to receive these events.  In the case of a = publicly-subscribable=20 resource this problem disappears.  In many=20 email use cases, only a small number of event sink addresses will be=20 authorized to receive event notifications -- perhaps the event source = (the=20 email server) can simply be configured with a short allowed list of = event=20 recipients that doesn't change often (e.g. my personal IM address, my = work=20 address, and the one used by my phone provided by my phone service=20 provider).

Some=20 SUBSCRIBE systems have the ability to provide a PENDING response to a=20 subscription. =20 This is used = when an=20 out-of-band mechanism is initiated to authorize the subscribing=20 address.  = In an email event source use = case, one=20 obvious out-of-band mechanism is for the email server to create an = email with=20 a link saying "Click here to authorize this = subscription".

It's also=20 possible to use a mechanism like URLAUTH to prove authorization -- in = this=20 approach, the subscriber provides a URL that has a secret token in it=20 authorizing the subscription.  It's=20 possible that this would authorize the subscribing address for future=20 subscriptions as well, or only for a limited period.

A-3=20 Drawbacks:
   a) =20 Only some = notification=20 protocols support SUBSCRIBE semantics.

   b) =20 Complicated = filters and=20 event types (to support use cases like "Alert me on event type 'email = arrives'=20 if it is from my boss, has my full email address or the address of the = developer list on the to line, and the subject does not begin with = 'FUNNY'..."=20 )  = might need a little extra=20 work.  = Both SIP and XMPP = subscriptions can be=20 extended in such a way that existing notification relays would pass on = a=20 filter specification in whatever language/format most appropriate for=20 email.  = It might even be possible to = send SIEVE=20 conditionals in the body of the SUBSCRIBE message.  XMPP has notification nodes = in XEP-0060=20 and notification filters in XEP-0163.

A-4=20 Advantages
   b) Allows for frequent starting and stopping of = subscriptions,=20 possibly an efficiency/scaling concern


MODEL B.=20 Sender RULES

B-1=20 Description

In this=20 model, the user typically works with the event source in order to = configure it=20 to send events to a given set of addresses.  For=20 example, the user might have access to a Web interface to an email = server=20 where it can say "Send new message notifications to xmpp://lisa@psg.com" or someday use MANAGESIEVE.

B-2=20 Authorization issue

The=20 authorization problem here is to determine if the user creating the = sending=20 rule is authorized to send an event stream to the receiving=20 address.  = If anybody can send to the = receiving=20 address (e.g. email) then it's publicly addressable and the problem=20 disappears. =20 Many kinds of = addresses are=20 publicly addressable and use whitelisting together with asking = permission ("do=20 you wish to allow messages from this source in the = future").

B-3=20 Drawbacks:
   a) Only some event sources support RULE = systems.  We are building SIEVE for = email clients=20 and servers but it may be harder to generalize this beyond email = clients and=20 servers.  = Even sticking strictly the = proposed scope=20 of email server sources, we have to consider whether a client such as = a=20 calendar client (subscribing for IMIP messages) or a time-management = dashboard=20 (subscribes to "unread" counts but doesn't otherwise read email) are = going to=20 be able to implement SIEVE, authenticate to mail servers = etc.

   b) If sender rules are setup through Web interfaces, = users are=20 definitely not going to turn them on and off frequently.

   c) Failure feedback: how does the event source let the = user know=20 that some address keeps bouncing?

 





------=_NextPart_000_07F7_01C74481.1AED0780-- --===============1018906262== 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 --===============1018906262==--