From mailman-bounces@ietf.org Sat Jan 1 06:30:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11635 for ; Sat, 1 Jan 2005 06:30:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ckhef-0007bW-G5 for ipcdn-archive@ietf.org; Sat, 01 Jan 2005 06:42:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CkgKt-00030v-7w for ipcdn-archive@ietf.org; Sat, 01 Jan 2005 05:18:15 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: ipcdn-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sat, 01 Jan 2005 05:05:32 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for ipcdn-archive@ietf.org: List Password // URL ---- -------- ipcdn@ietf.org ichuas https://www1.ietf.org/mailman/options/ipcdn/ipcdn-archive%40ietf.org From ipcdn-bounces@ietf.org Wed Jan 5 18:21:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02131 for ; Wed, 5 Jan 2005 18:21:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmKgA-0004xH-50 for ipcdn-archive@ietf.org; Wed, 05 Jan 2005 18:35:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmKL2-0002c7-HF; Wed, 05 Jan 2005 18:13:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmKIg-0000pK-Kv for ipcdn@megatron.ietf.org; Wed, 05 Jan 2005 18:10:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29078 for ; Wed, 5 Jan 2005 18:10:43 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmKVK-0002L1-JK for ipcdn@ietf.org; Wed, 05 Jan 2005 18:23:51 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j05NA91e025548; Wed, 5 Jan 2005 16:10:09 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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, 5 Jan 2005 16:10:09 -0700 Message-ID: Thread-Topic: OID MIB rooting of draft-ietf-ipcdn-qos-mib-10.txt and other pending IPCDN DOCSIS mib modules Thread-Index: AcTze7K9vaJQo3QxQBawDc6wAKD08A== From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: Murwin William-LWM008 , bwijnen@lucent.com, Patrick Michael-LZZ007 Subject: [ipcdn] OID MIB rooting of draft-ietf-ipcdn-qos-mib-10.txt and other pending IPCDN DOCSIS mib modules X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable All, As you know, the authors of the ipcdn docsis qos mib are close to finalizing the draft. In the final IETF reviews of the QoS MIB (http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib-10.txt), it was requested that we consider changing the OID root assignment from ..mib-2(1) transmission(10) docsIfMib(127) to just ..mib-2(1). The alternative is that we document the motivations and rationale for continuing to assign MIBs under ..mib-2(1) transmission(10) docsIfMib(127)) - I am willing to do this if the wg feels strongly about it. After some considerations, Eduardo and I do not see any real implications of this proposed change. Out of all the internet-drafts on our charter, if we do not count the RFI MIB v2 which updates rfc2670, the QoS MIB is the only one in this case, the others do currently request OID assignment under ..mib-2(1). 2 OID assignments have already been made for the bis version of rfc2669 and rfc2670: - Cable device mib v2 ::=3D { mib-2 69 } - RF MIB v2 ::=3D { transmission 127 } The other IPCDN DOCSIS IDs in the queue to become RFC are: - Bpi+ (the IETF ID already asks for OID ::=3D { mib-2 yy }=20 - Event notif ::=3D { mib-2 xxx } - QoS MIB (subject of this discussion) - subs mgmt (already approved for IETF publicaiton ::=3D { mib-2 xx } = ) Therefore, I would like to ping the list to see if anyone has any objection to changing the OID MIB root of the QoS MIB to ..mib-2(1) from ..mib-2(1) transmission(10) docsIfMib(127). Unless we receive any objections, the ID will be updated for Bert to put it on the IESG agenda. Thanks,=20 Jean-Francois IPCDN co-chair. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Jan 5 22:42:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20668 for ; Wed, 5 Jan 2005 22:42:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmOkj-0006oZ-U7 for ipcdn-archive@ietf.org; Wed, 05 Jan 2005 22:56:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmOPQ-0003La-JD; Wed, 05 Jan 2005 22:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmOHx-0001vn-7j for ipcdn@megatron.ietf.org; Wed, 05 Jan 2005 22:26:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19223 for ; Wed, 5 Jan 2005 22:26:14 -0500 (EST) Received: from mail.stargus.com ([65.193.169.166] helo=xchange.stargus.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CmOUb-0001nW-0I for ipcdn@ietf.org; Wed, 05 Jan 2005 22:39:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Jan 2005 22:26:03 -0500 Message-ID: <6FEBB4954538C7408210BEDBE4843642311E3A@xchange.stargus.com> Thread-Topic: IETF IPCDN proposed standard drafts MIB Modules OID assignmen ts: Assigning new RFCs under mib-2 Thread-Index: AcTzUaddqE3Ia/N7Q9+N1USBeX79RAAAGBKQAAkl2wAAB83tEA== From: "Fred Oko" To: "Jean-Francois Mule" , X-Spam-Score: 0.0 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 Content-Transfer-Encoding: quoted-printable Cc: gnakanishi@motorola.com, Eduardo Cardona , ipcdn@ietf.org, DOCSIS OSS Majordomo List Subject: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules OID assignmen ts: Assigning new RFCs under mib-2 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 73f7847c44628482de9d5f1018acf469 Content-Transfer-Encoding: quoted-printable I would agree that a MIB for which the author had the foresight to root = in the experimental(3) branch would be expected (both by MIB consumers = and IETF) to be re-rooted for RFC transition. However, this only applies = to the subscriber-mgmt MIB. I would argue that there is no value, only = negative operational implications, and no impervious mandate for = re-rooting any other MIB that has already seen widespread implementation = and consumption. I would argue this not only for the QOS MIB, but for = any draft MIB for which originally had a sub-docsIfMib or enterprise = root that was mandated to be supported in any already passed CableLabs = certification wave. The reasoning is that since these objects were = implemented by CM/CMTS vendor and qualified, they have most certainly = been also implemented against by existing OSS software, wherein lies = definite operational impact of such a major change. Impact points of any re-root: 1) common to any change: CMTS and CM vendor must change code, CL must = update ATP etc for qualifications, vendors must re-qualify code, and = MSO's must deploy new code (granted required just for other MIB updates = if not re-root) 2) a decision must be made whether a CMTS or CM is backward-compatible = (either as mandated by CL or discretion of vendor as advised by MSOs) = and supporting two instance of a MIB has implications -- and regardless = the decision of backward-compatibility on a single device, any OSS that = monitors across a non-homogeneous field will of course have chance to = run into new and old instances a) multiple OIDs for same subidentifiers must be known by clients which = may have preference to use non-fully-qualified b) if back-compat, collection must limit itself to one of the two = instances to avoid double collection thus requiring conditional logic = based on probing c) I would expect any MSO with utilities that are broken by such a = re-root will demand this "bug" be fixed by the vendor thus forcing = effective back-compat d) it may be difficult for some SNMP agent implementations to support = efficient backward-compatability (i.e. two OIDs mapping to same = in-memory data) as such efficiency would be a must for some of the = expensive MIB tables 3) Since CL CW have continued to require very old drafts we know that = implementation against the "old"/only OIDs have been in use for a while No real impact points of not re-rooting anything -- simplest path: 1) current OID assignments, while not actually assigned by IANA are = guaranteed to be non-conflicting 2) no re-roots have been implemented in any code -- they only exist in = more recent drafts thus nullifying them is only on paper Additionally I personally see little value in the any re-roots beyond = philosophical cleanliness. I do agree that all MIBs may not be = semantically perfect below docsIf, but I take it as the best = hierarchical umbrella we have on that road that has been traveled. If we = were forced to re-root I would advocate at least leveraging hierarchy by = contextually group all CL/IPCDN related objects together instead of = having them assigned loosely and likely non-contiguously into the mib-2 = free space. E.g. in that sense I was a fan of the enterprise clab root. The very nature of so many representative MIB-rooting conventions across = the many CL-related MIBs (docsIf, experimental, mib-2-pending, clab) = suggests if this is not exactly a contentious issue, it is definitely = one still open to the author's discretion which one might tend to agree = has been non-optimal. I also see a variable modification time of these = drafts at some middle revision to change OID roots which indicates it = was not guided by a single firm guiding consensus (but perhaps MIB = doctor advice trickle effect?). I would advocate that a firm = future-guiding decision be made that would apply to all as-of-yet = unwritten MIBs. Though were these proposed re-roots to make their way unimpeded into = continued-draft/RFC/ECR/cert-wave would a good time estimate to seeing = such in the field be late 2006? -----Original Message----- From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 Sent: Wednesday, January 05, 2005 5:50 PM To: andre.lejeune@terayon.com Cc: gnakanishi@motorola.com; Eduardo Cardona; DOCSIS OSS Majordomo List Subject: RE: IETF IPCDN proposed standard drafts MIB Modules OID = assignmen ts: Assigning new RFCs under mib-2 I concur with the comments made by Greg and Eduardo re: the fact that = the IETF version of the mibs have somehow to be re-rooted. Thanks = Andr=E9 for the rationale you provided. Andre wrote: > However, your original suggestion was to allow for "the OID=20 > assignment of all the new IETF IPCDN DOCSIS RFCs under=20 > mib-2". Purely based on taxonomy reasons, I don't think that=20 > would be the right thing to do. Each MIB needs to be=20 > considered separately.=20 I would agree but this is more a question for the IETF mib police and = how they would like to organize the IETF OID tree. From what we hear = there, they do not necessarily like the multiplication of branches under = mib2 for reasons I don't really know. Hence the question to the docsis = oss team. The main point we wanted to understand from this thread is = whether we had any specific reasons to have the OID assignment under = docsIfMib(127). Based on this dialog, we have no particular concerns = with moving the mibs under a different root. > What other experimental MIBs are about=20 > to become RFC and therefore are being considered for this? See all the IPCDN DOCSIS drafts at: http://www.ipcdn.org/ipcdn-ids.html 2 OIDs are already assigned for rfc2669bis and rfc2670bis: - Cable device mib v2 ::=3D { mib-2 69 } - RF MIB v2 ::=3D { transmission 127 } The other Ids in the queue to become RFC are: - Bpi+ (the IETF ID already asks for OID ::=3D { mib-2 yy }=20 - Event notif ::=3D { mib-2 xxx } - QoS MIB (subject of this discussion, we will request a change to = mib-2 xxx) - subs mgmt (already approved for IETF publicaiton ::=3D { mib-2 xx } = ) Others are PacketCable MIBs for which mib-2 is ok. Jean-Fran=E7ois=20 =20 =20 > -----Original Message----- > From: Eduardo Cardona=20 > Sent: Wednesday, January 05, 2005 12:45 PM > To: andre.lejeune@Terayon.com; gnakanishi@motorola.com;=20 > DOCSIS OSS Majordomo List > Cc: Jean-Francois Mule > Subject: RE: IETF IPCDN proposed standard drafts MIB Modules=20 > OID assignmen ts: Assigning new RFCs under mib-2 >=20 >=20 > Andre,=20 >=20 > We have done same analysis as you did,=20 > moreover in your case of subscriber MIB, the original=20 > intention of the MIB was to simulate the CPE control=20 > available in the CM but centralized ( MAX CPE and Filters) CM=20 > Filters are in DocsDev so would be also appropriate to have=20 > that mib in mib-2(1) docsDev(69) ? >=20 > By the way IETF normalized the filtering mechanism to follow=20 > the classification mechanism available in diffServ=20 > (mib-2) diffServMib(97)=20 >=20 > mib-2 ? > diffServMib? > docsDevMib? > docsIfMib? >=20 > Then your conclusion of setting that in mib-2 is more evident here, >=20 > For interface specific MIBs ( Cable MAC interface ) we=20 > recognize that as a point to consider, and we appreciate you=20 > pointed out to that. that's the purpose of this quick=20 > survey: Confronting IETF recommendations with Cable Industry=20 > perception.=20 >=20 > Any other cons pros, vendors and DOCSIS community may think of? >=20 > Thanks >=20 > Eduardo >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: andre.lejeune@Terayon.com [mailto:andre.lejeune@Terayon.com]=20 > Sent: Wednesday, January 05, 2005 11:08 AM > To: Eduardo Cardona; gnakanishi@motorola.com; DOCSIS OSS=20 > Majordomo List > Cc: Jean-Francois Mule > Subject: RE: IETF IPCDN proposed standard drafts MIB Modules=20 > OID assignmen ts: Assigning new RFCs under mib-2 >=20 >=20 > OK. This is more like a taxonomy question then. >=20 > The question then becomes: are these MIBs related to a type=20 > of interface or not. For example, docsIfMib was assigned=20 > number 127, which corresponds to ifType=20 > docsCableMaclayer(127). MIBs found under the docsIfMib would=20 > therefore be related to the DOCSIS Cable MAC Layer=20 > interfaces. This is why most of the MIBs found under the=20 > transmission group are indexed by ifIndex (with,=20 > unfortunately I guess, a few exceptions). A system with=20 > multiple interfaces of the same type would have multiple=20 > entries under the transmission tree to provide independent control. >=20 > Taking the subscriber management MIB, it seems to be a mixed=20 > answer. The docsSubMgtCpeIpEntry is indexed by=20 > docsIfCmtsCmStatusIndex and docsSubMgtCpeIpIndex. As such, it=20 > looks like an extension to the docsIfCmtsCmStatusTable,=20 > located under transmission, but not indexed by ifIndex. So I=20 > guess we created a precedent already where we require=20 > docsIfCmtsCmStatusIndex to be unique per CMTS, and not per=20 > interface, even though it was placed under "transmission".=20 > The subscriber management MIB also contains filter group=20 > entries, which appear to be unique per CMTS and not really=20 > related to the interface. So given these 2 considerations, it=20 > seems acceptable to place this MIB under MIB-2, although one=20 > could have argued that the docsIfCmtsCmStatusTable should=20 > have been indexed by ifIndex in the first place, in which=20 > case splitting the subscriber management MIB would have been=20 > a possibility. >=20 > However, your original suggestion was to allow for "the OID=20 > assignment of all the new IETF IPCDN DOCSIS RFCs under=20 > mib-2". Purely based on taxonomy reasons, I don't think that=20 > would be the right thing to do. Each MIB needs to be=20 > considered separately. What other experimental MIBs are about=20 > to become RFC and therefore are being considered for this? >=20 > Thanks, > Andr=E9 >=20 > -----Original Message----- > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > Sent: Wednesday, January 05, 2005 11:56 AM > To: Nakanishi Greg-MGI8179; andre.lejeune@Terayon.com; DOCSIS=20 > OSS Majordomo List > Cc: Jean-Francois Mule > Subject: RE: IETF IPCDN proposed standard drafts MIB Modules=20 > OID assignmen ts: Assigning new RFCs under mib-2 >=20 >=20 > Correct,=20 >=20 > we are not looking in avoiding the root change, just to find=20 > out if DOCSIS community have issues on moving the upcoming =20 > brand new RFCs from docsIfMib (current spec drafts=20 > requirement) to mib-2 (as a clarification, RFI MIB is not in=20 > this category since it is an update of RFC 2670) >=20 > Thanks >=20 > Eduardo > -----Original Message----- > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com]=20 > Sent: Wednesday, January 05, 2005 9:46 AM > To: 'andre.lejeune@Terayon.com'; Eduardo Cardona; DOCSIS OSS=20 > Majordomo List > Cc: Jean-Francois Mule > Subject: RE: IETF IPCDN proposed standard drafts MIB Modules=20 > OID assignmen ts: Assigning new RFCs under mib-2 >=20 >=20 > Note that the currently required Subscriber Mgmt MIB (-02) is=20 > rooted in the experimental branch. When the MIB gets=20 > standardized by the IETF it will move under the mib-2 branch.=20 > Regardless of whether it is located directly under mib-2 or=20 > under mib-2.transmission.docsIfMib, the root is going to=20 > change from the current experimental branch. I don't see=20 > anyway to avoid this. >=20 > greg >=20 > -----Original Message----- > From: owner-docsis-oss@cablelabs.com=20 > [mailto:owner-docsis-oss@cablelabs.com] On Behalf Of=20 > andre.lejeune@Terayon.com > Sent: Wednesday, January 05, 2005 8:15 AM > To: e.cardona@cablelabs.com; docsis-oss@cablelabs.com > Cc: jf.mule@cablelabs.com > Subject: RE: IETF IPCDN proposed standard drafts MIB Modules=20 > OID assignmen ts: Assigning new RFCs under mib-2 >=20 >=20 > Eduardo, >=20 > You are probably familiar with the backwards compatibility=20 > issues that occurred with the relocation of the docDev MIB=20 > from experimental to its final location in RFC2669. In this=20 > case, the problem was exacerbated by the fact that docsDev=20 > MIB object entries often appear in configuration files. I=20 > believe configuration files rarely contain entries from any=20 > other MIB, with probably the exception of enterprise MIBs. If=20 > this is true, then configuration files would not be an issue.=20 > However, there are probably a lot of Support Systems out=20 > there that make extensive use of these MIBs. So backwards=20 > compatibility would probably be a requirement. >=20 > So my question is simple... Would we be required to support=20 > these MIBs at both the old and new locations from the SNMP=20 > agent interface? From the configuration file? If backwards=20 > compatibility is required, I am afraid we would have to=20 > oppose such change and request that the MIBs be left where=20 > they are currently located. >=20 > Andr=E9 > -----Original Message----- > From: owner-docsis-oss@cablelabs.com=20 > [mailto:owner-docsis-oss@cablelabs.com]On Behalf Of Eduardo Cardona > Sent: Wednesday, January 05, 2005 10:55 AM > To: DOCSIS OSS Majordomo List > Cc: Jean-Francois Mule; Eduardo Cardona > Subject: IETF IPCDN proposed standard drafts MIB Modules OID=20 > assignments: Assigning new RFCs under mib-2 >=20 >=20 >=20 > All, > As you know, the IETF IPCDN wg is finalizing a number of=20 > DOCSIS mibs. The subs mgmt MIB is done and will become an RFC=20 > in the near future. In the final IETF reviews, it was=20 > requested that we consider changing some of the OID=20 > assignments from ..mib-2(1) transmission(10) docsIfMib(127)=20 > to just ..mib-2(1) (some draft DOCSIS MIBs including the QoS=20 > MIB Internet-Drafts=20 > http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib-1 0.txt still request that the OID be assigned under mib-2..docsIfMib). After some considerations, Jean-Francois and I do not see any real = implications of this proposed change: the OID assignment of all the new = IETF IPCDN DOCSIS RFCs under mib-2 seems ok since the MIB definitions of = the published RFCs will be different and we would not gain much in = retaining existing docsIfMIB OID values. Can anyone see any issues with the change of assignments under mib-2? is = there any pros & cons you would like to point out? Please get back to us = by Thursday January 6. Thanks Jean-Francois, Eduardo NOTICE: This communication contains information which may be = proprietary, privileged or confidential. If you are not the intended = recipient (or authorized to receive for the intended recipient), or = believe that you have received this communication in error, please do = not print, copy,retransmit, disseminate, disclose or otherwise use the = information. Also, please indicate to the sender that you have received = this communication in error and delete the copy you received. Thank you. NOTICE: This communication contains information which may be = proprietary, privileged or confidential. If you are not the intended = recipient (or authorized to receive for the intended recipient), or = believe that you have received this communication in error, please do = not print, copy,retransmit, disseminate, disclose or otherwise use the = information. Also, please indicate to the sender that you have received = this communication in error and delete the copy you received. Thank you. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Jan 6 01:32:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29082 for ; Thu, 6 Jan 2005 01:32:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmROw-0005Z5-L2 for ipcdn-archive@ietf.org; Thu, 06 Jan 2005 01:45:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmR9i-0002CU-JW; Thu, 06 Jan 2005 01:29:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmQyK-0007Kg-0h for ipcdn@megatron.ietf.org; Thu, 06 Jan 2005 01:18:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28323 for ; Thu, 6 Jan 2005 01:18:10 -0500 (EST) Received: from pop-a065c28.pas.sa.earthlink.net ([207.217.121.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmRB2-00007q-8x for ipcdn@ietf.org; Thu, 06 Jan 2005 01:31:20 -0500 Received: from h-68-165-174-239.snvacaid.dynamic.covad.net ([68.165.174.239] helo=oemcomputer) by pop-a065c28.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CmQyC-00047B-00; Wed, 05 Jan 2005 22:18:05 -0800 Message-ID: <001501c4f3b7$8fcc1d60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn \(E-mail\)" References: <7D5D48D2CAA3D84C813F5B154F43B1550604F03E@nl0006exch001u.nl.lucent.com> Date: Wed, 5 Jan 2005 22:18:38 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Subject: [ipcdn] Editorial comments on draft-ietf-ipcdn-docs-rfmibv2-12.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Hi - Bert asked me to take a look at draft-ietf-ipcdn-docs-rfmibv2-12.txt, and a few editorial editorial problems jumped out at me. I have omitted items covered by Bert Wijnen's recent posting. More technical comments will follow. 1) Period at the end of a sentence should be followed by two spaces. The document sometimes uses just one. A simple way to find these is the ed/vi expression /\. [^ ]/ Though the rfc editor can fix these, you may find that that will making checking for errors harder in the AUTH48 period. 2) Abbreviations and acronyms should be spelled out on first use. Presumably this includes DOCSIS in the title. Others: CATV (though explained in the next paragraph, so this isn't serious) PDU (or is this sufficiently well known?) TDMA CDMA FCS PHY usec msec RNG-RSP mac (is the all lower-case version distinct?) REG-REQ TFTP dBc SP-RFI OSSI UCD RNG-REQ DHCP REQ ETSI OSS UCC SID IUC 3) EDITORIAL: "5-42MHZ" would be better as "5-42 MHz", ditto other uses of "MHz". (Current text is not consistent; in some places there isn't a space, in others there is.) 4) EDITORIAL: in section 2, acronym expansions sometimes appear in the section title (e.g., 2.16 QPSK), while at others in the text of the section (e.g., 2.18 RF) 5) EDITORIAL: "reinit" -> "reinitialization" 6) EDITORIAL: "ie" -> "i.e.", or better "that is" 7) EDITORIAL: "ipv6" -> "IPv6" 8) EDITORIAL: "and and" -> "and" 9) EDITORIAL: "IPDR" -> "IPR" on page 129 10) EDITORIAL: "Andr?" -> "Andre" 11) EDITORIAL: document layout is odd. Sometimes there is no blank line between paragraphs, making it even harder to read. Suggest adding them now, rather than relying on the RFC editor to figure out what you meant, to avoid problems in AUTH48. For example, does section 2.9.2 consist of one ill-formatted paragraph or three? Another problem is that some lines clearly end prematurely. For example, "CMTS to a" should be in the first line of the paragraph in 2.15. 12) EDITORIAL: "head-end" or "headend"? pick one, preferably the former. 13) EDITORIAL: there are some strange capitalizations: "Lineup" in 2.11 "Addressed" in 3.2 "Downstream" in 3.2.5.1 and elsewhere "Cable" in 3.2.5.1.2 "Unicast" on page 12 & 14 & more "Multicast" on page 12 & 14 & more "Broadcast" on page 12 & 14 & more "Upstream" in 3.2.5.2.1 "Contributions" in 5 14) EDITORIAL: in section 3.1.3, for docIfCmtsCmStatusTable, is "i.e." really intended, or should it be an "e.g."? (This could potentially be a technical issue.) 15) EDITORIAL: "empty string" would be more precise as "zero length string" (This could potentially be technical.) Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Jan 6 06:53:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00931 for ; Thu, 6 Jan 2005 06:53:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmWPJ-0004j4-Ey for ipcdn-archive@ietf.org; Thu, 06 Jan 2005 07:06:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmW5S-0001BI-Br; Thu, 06 Jan 2005 06:45:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmW1w-0000Rk-N5 for ipcdn@megatron.ietf.org; Thu, 06 Jan 2005 06:42:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00267 for ; Thu, 6 Jan 2005 06:42:14 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmWEi-0007fW-86 for ipcdn@ietf.org; Thu, 06 Jan 2005 06:55:28 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j06BfgOk008775 for ; Thu, 6 Jan 2005 05:41:42 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 6 Jan 2005 12:41:41 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155061B6884@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Fred Oko , Jean-Francois Mule , andre.lejeune@terayon.com Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2 Date: Thu, 6 Jan 2005 12:41:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: gnakanishi@motorola.com, Eduardo Cardona , ipcdn@ietf.org, DOCSIS OSS Majordomo List X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Inline > -----Original Message----- > From: ipcdn-bounces@ietf.org > [mailto:ipcdn-bounces@ietf.org]On Behalf Of > Fred Oko > Sent: Thursday, January 06, 2005 04:26 > To: Jean-Francois Mule; andre.lejeune@terayon.com > Cc: gnakanishi@motorola.com; Eduardo Cardona; ipcdn@ietf.org; > DOCSIS OSS Majordomo List > Subject: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules OID > assignmen ts: Assigning new RFCs under mib-2 > > > I would agree that a MIB for which the author had the > foresight to root in the experimental(3) branch would be > expected (both by MIB consumers and IETF) to be re-rooted for > RFC transition. However, this only applies to the > subscriber-mgmt MIB. I would argue that there is no value, > only negative operational implications, and no impervious > mandate for re-rooting any other MIB that has already seen > widespread implementation and consumption. I would argue this > not only for the QOS MIB, but for any draft MIB for which > originally had a sub-docsIfMib or enterprise root that was > mandated to be supported in any already passed CableLabs > certification wave. The reasoning is that since these objects > were implemented by CM/CMTS vendor and qualified, they have > most certainly been also implemented against by existing OSS > software, wherein lies definite operational impact of such a > major change. > I think the above shows where we have a BASIC problem (and we discussed this in the past as well). When trying to standardize a MIB document in the IETF, then there should be NO assumptions on where the module gets rooted. That will ONLY be known once the document has been approved by the IESG. After that approval, it is IANA who assigns the OID. And that is exactly one of the reasons why we do not like that WGs start assigning MIB modules underneath some OID branch for that WG/technology. The reason for not wanting such early assignments (other than experimental) is that the MIB module may change (dramatically even) during the process in the IETF WG, IETF Last Call, MIB Doctor review, IESG review. And so if anyone implemented the MIB module based on some random revision of an Internte-Draft then that module (with assigned OID) might be completely different than the one that finally gets approved (same OID if you followed your logic). And so that WILL result in INTEROPERABILITY problems in the market place. See also draft-ietf-ops-mib-review-guidelines-03.txt sections 4.3 and 4.5 > Impact points of any re-root: > 1) common to any change: CMTS and CM vendor must change code, > CL must update ATP etc for qualifications, vendors must > re-qualify code, and MSO's must deploy new code (granted > required just for other MIB updates if not re-root) While a MIB is under development in the IETF, no one should be assuming that such a MIB module is final and so no-one should be using a pre-assigned OID for the MIB module. If anything, one could use experimental (need to request an assignment though; also see warnings about that in mib review guidleines) or your own (vendor specific OID tree. Make sure you UNDERSTAND that the names (OIDs) should not conflict with any future final OID for the MIB once approved. > 2) a decision must be made whether a CMTS or CM is > backward-compatible (either as mandated by CL or discretion > of vendor as advised by MSOs) and supporting two instance of > a MIB has implications -- and regardless the decision of > backward-compatibility on a single device, any OSS that > monitors across a non-homogeneous field will of course have > chance to run into new and old instances If one follows MIB guidelines/rules (and you MUST follow those to get a MIB module or an update to a MIB module approved in IETF), then these guidelines/rules (and associated MIB doctor review in IETF) will guarantee backward compatibility. If such needs to be compromised, then it would only happen with serious and explicit agreement of the WG and otehr IETF review (for example when everyone agrees that there was a BUG in an earlier module) > a) multiple OIDs for same subidentifiers must be known > by clients which may have preference to use non-fully-qualified > b) if back-compat, collection must limit itself to one > of the two instances to avoid double collection thus > requiring conditional logic based on probing > c) I would expect any MSO with utilities that are > broken by such a re-root will demand this "bug" be fixed by > the vendor thus forcing effective back-compat > d) it may be difficult for some SNMP agent > implementations to support efficient backward-compatability > (i.e. two OIDs mapping to same in-memory data) as such > efficiency would be a must for some of the expensive MIB tables > 3) Since CL CW have continued to require very old drafts we > know that implementation against the "old"/only OIDs have > been in use for a while > Not sure I understand all points a-b. What is an MSO? What is CL CW? > No real impact points of not re-rooting anything -- simplest path: > 1) current OID assignments, while not actually assigned by > IANA are guaranteed to be non-conflicting that is good. But, since they only exists in Internet-Drafts, they have not really been assigned!!!! That is the thing to understand!!! PLEASE! > 2) no re-roots have been implemented in any code -- they only > exist in more recent drafts thus nullifying them is only on paper > As explained above, they SHOULD NOT exist in running code!!! This is a real basic approach of how we do Iinternet-Drafts and how and why we assign OIDs AFTER an Internet-Draft has gone through the whole IETF developement and review process and has been APPROVED by the IESG. > Additionally I personally see little value in the any > re-roots beyond philosophical cleanliness. I do agree that > all MIBs may not be semantically perfect below docsIf, but I > take it as the best hierarchical umbrella we have on that > road that has been traveled. If we were forced to re-root I > would advocate at least leveraging hierarchy by contextually > group all CL/IPCDN related objects together instead of having > them assigned loosely and likely non-contiguously into the > mib-2 free space. E.g. in that sense I was a fan of the > enterprise clab root. > I have explained to teh chairs, that a reroot is not MANDATORY. But IF you want to continue to allocate (or keep the current allocations) under docIfMib, then I would URGE you to create a document similar to RFC3737. And in the future, you would NOT let an Internet-Draft have any pre-assigned value, but instead have something aka: ::= { docsIfMib xx } -- xx to be assigned by IANA as per -- procedures outlined in So you (the WG) has basically been mis-using the fact that you had a docIfMib branch and were pre-assigning values against the normal process, and with the risk of having incomp-atible versions of MIB modules in implementations! > The very nature of so many representative MIB-rooting > conventions across the many CL-related MIBs (docsIf, > experimental, mib-2-pending, clab) suggests if this is not > exactly a contentious issue, it is definitely one still open > to the author's discretion which one might tend to agree has > been non-optimal. I also see a variable modification time of > these drafts at some middle revision to change OID roots > which indicates it was not guided by a single firm guiding > consensus (but perhaps MIB doctor advice trickle effect?). I > would advocate that a firm future-guiding decision be made > that would apply to all as-of-yet unwritten MIBs. > Totally agree. And having 4 or 5 potential places to root a new MIB mdoule aka docsIf, experimental, mib-2-pending, clab seems REALLY REALLY bad to me. > Though were these proposed re-roots to make their way > unimpeded into continued-draft/RFC/ECR/cert-wave would a good > time estimate to seeing such in the field be late 2006? > Bert Wijnen, speaking as co-AD for the IETF OPS area. open to a good discussion on this topic and to try and document the correct and agreed way for new and furture MIB dvelopement in this space. Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Jan 6 10:48:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17418 for ; Thu, 6 Jan 2005 10:48:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cma4j-00006J-6S for ipcdn-archive@ietf.org; Thu, 06 Jan 2005 11:01:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmZog-0005oc-GB; Thu, 06 Jan 2005 10:44:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmDvq-0006ua-77 for ipcdn@megatron.ietf.org; Wed, 05 Jan 2005 11:22:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18008 for ; Wed, 5 Jan 2005 11:22:43 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmE8P-0000WV-Fn for ipcdn@ietf.org; Wed, 05 Jan 2005 11:35:47 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j05GOVfL004341 for ; Wed, 5 Jan 2005 09:24:31 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id j05GLK9v008089 for ; Wed, 5 Jan 2005 10:21:20 -0600 Received: by ca25exm01 with Internet Mail Service (5.5.2657.72) id ; Wed, 5 Jan 2005 08:22:40 -0800 Message-ID: From: Beacham Gordon-CGB005 To: "'ipcdn@ietf.org'" , "'sumanth@cablelabs.com'" Date: Wed, 5 Jan 2005 08:22:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 1.8 (+) X-Scan-Signature: 08adf1ecf9a7559e8dfb3fd702475ca0 X-Mailman-Approved-At: Thu, 06 Jan 2005 10:44:44 -0500 Subject: [ipcdn] IETF NCS Sig MIB Tone Table X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1048304465==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 1.8 (+) X-Scan-Signature: 6f53c4f7595c3c08703c46a38a136a69 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1048304465== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4F342.C5F586D0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4F342.C5F586D0 Content-Type: text/plain ITU-T supplement 2 (E.180) identifies several tone definitions that cannot be currently satisfied by the IETF NCS Sig MIB tone table definition. It is important for the IETF NCS Sig MIB to support E.180 tone definitions for: 1. embedded tone cadences (i.e., Romania number unobtainable tone, etc) [2 examples shown below] 2. amplitude modulation (i.e., Japan call waiting tone) [1 example shown below] To address these issues, the following changes are recommended: PktcSigDevToneEntry ::= SEQUENCE { pktcSigDevToneType INTEGER, pktcSigDevToneDbLevel TenthdBm, pktcSigDevToneFreqType INTEGER, pktcSigDevToneNumFrequencies Unsigned32, pktcSigDevToneFirstFrequency Unsigned32, pktcSigDevToneFirstToneSecondaryFrequency Unsigned32, pktcSigDevToneFirstToneSecondaryMode Unsigned32, pktcSigDevToneFirstToneSecondaryAttribute Unsigned32, pktcSigDevToneSecondFrequency Unsigned32, pktcSigDevToneSecondToneSecondaryFrequency Unsigned32, pktcSigDevToneSecondToneSecondaryMode Unsigned32, pktcSigDevToneSecondToneSecondaryAttribute Unsigned32, pktcSigDevToneThirdFrequency Unsigned32, pktcSigDevToneThirdToneSecondaryFrequency Unsigned32, pktcSigDevToneThirdToneSecondaryMode Unsigned32, pktcSigDevToneThirdToneSecondaryAttribute Unsigned32, pktcSigDevToneFourthFrequency Unsigned32, pktcSigDevToneFourthToneSecondaryFrequency Unsigned32, pktcSigDevToneFourthToneSecondaryMode Unsigned32, pktcSigDevToneFourthToneSecondaryAttribute Unsigned32, pktcSigDevToneFifthFrequency Unsigned32, pktcSigDevToneFifthToneSecondaryFrequency Unsigned32, pktcSigDevToneFifthToneSecondaryMode Unsigned32, pktcSigDevToneFifthToneSecondaryAttribute Unsigned32, pktcSigDevToneNumOnOffTimes Unsigned32, pktcSigDevToneFirstToneOn Unsigned32, pktcSigDevToneFirstToneOff Unsigned32, pktcSigDevToneFirstToneRepeatCount Unsigned32, pktcSigDevToneSecondToneOn Unsigned32, pktcSigDevToneSecondToneOff Unsigned32, pktcSigDevToneSecondToneRepeatCount Unsigned32, pktcSigDevToneThirdToneOn Unsigned32, pktcSigDevToneThirdToneOff Unsigned32, pktcSigDevToneThirdToneRepeatCount Unsigned32, pktcSigDevToneFourthToneOn Unsigned32, pktcSigDevToneFourthToneOff Unsigned32, pktcSigDevToneFourthToneRepeatCount Unsigned32, pktcSigDevToneFifthToneOn Unsigned32, pktcSigDevToneFifthToneOff Unsigned32, pktcSigDevToneFifthToneRepeatCount Unsigned32, pktcSigDevToneWholeToneRepeatCount Unsigned32, pktcSigDevToneSteady TruthValue } pktcSigDevToneFirstToneSecondaryFrequency SYNTAX Unsigned32 (0..4000) MAX-ACCESS read-write STATUS current DESCRIPTION "The secondary frequency used to amplitude modulate or which is summed with the pktcSigDevToneFirstFrequency depending on the setting of pktcSigDevToneFirstToneSecondaryMode." ::={pktcSigDevToneEntry x} A similar object definition is required for: pktcSigDevToneSecondToneSecondaryFrequency pktcSigDevToneThirdToneSecondaryFrequency pktcSigDevToneFourthToneSecondaryFrequency pktcSigDevToneFifthToneSecondaryFrequency pktcSigDevToneFirstToneSecondaryMode SYNTAX INTEGER { noModNoSum (1), primaryModulatedBySecondary (2), primarySummedWithSecondary (3) } MAX-ACCESS read-write STATUS current DESCRIPTION "When pktcSigDevToneFirstToneSecondaryMode is set to primaryModulatedBySecondary, the pktcSigDevToneFirstToneSecondaryFrequency is used to amplitude modulate the pktcSigDevToneFirstFrequency. When pktcSigDevToneFirstToneSecondaryMode is set to primarySummedWithSecondary, the pktcSigDevToneFirstToneSecondaryFrequency is summed with the pktcSigDevToneFirstFrequency without any modulation. When pktcSigDevToneFirstToneSecondaryMode is set to noModNoSum, the pktcSigDevToneFirstToneSecondaryFrequency MUST NOT be used." DEFVAL { 1 } ::={pktcSigDevToneEntry x} pktcSigDevToneFirstToneSecondaryAttribute SYNTAX Unsigned32 (0..100) MAX-ACCESS read-write STATUS current DESCRIPTION "The percentage of amplitude modulation applied to the pktcSigDevToneFirstToneSecondaryFrequency. This object is only used if pktcSigDevToneFirstToneSecondaryMode is primaryModulatedBySecondary. An attempt to set this object while the value of pktcSigDevToneFirstToneSecondaryMode is not primaryModulatedBySecondary will result in an inconsistentValue error." ::={pktcSigDevToneEntry x} A similar object definition is required for: pktcSigDevToneSecondToneSecondaryAttribute pktcSigDevToneThirdToneSecondaryAttribute pktcSigDevToneFourthToneSecondaryAttribute pktcSigDevToneFifthToneSecondaryAttribute pktcSigDevToneFirstToneRepeatCount SYNTAX Unsigned32 (0..5000) MAX-ACCESS read-write STATUS current DESCRIPTION "The repeat count which indicates the number of times to repeat the pktcSigDevToneFirstToneOn and pktcSigDevToneFirstToneOff cadence cycle. Setting this object may result in a tone duration longer or shorter than the overall signal duration specified by the time out (TO) object for a particular signal. If the repeat count results in a longer tone duration than the signal duration specified by the TO, the tone duration defined by the TO object for a particular signal always represents the overall signal duration for a tone. In this case, the tone duration repeat count will not be fully exercised and the desired tone duration will be truncated per the TO setting. If the repeat count results in a shorter tone duration than the signal duration specified by the TO, the tone duration defined by the repeat count takes precedence over the TO and will end the signal event. In this case, the TO represents a time not to be exceeded for the signal. It is recommended to ensure proper telephony signaling that the TO duration setting should always be longer than the desired repeat count time duration. A value of zero means the tone sequence is to be played once but not repeated." ::={pktcSigDevToneEntry x} A similar object definition is required for: pktcSigDevToneSecondToneRepeatCount pktcSigDevToneThirdToneRepeatCount pktcSigDevToneFourthToneRepeatCount pktcSigDevToneFifthToneRepeatCount The following objects should be deleted. They are no longer applicable in lieu of the above changes. pktcSigDevToneFreqType OBJECT-TYPE SYNTAX INTEGER { allFrequencies (1), singleFrequencySequence (2), dualFrequencySequence (3), allFrequenciesModulated (4) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object describes how the frequencies are applied. allFrequencies indicates all frequencies specifed by pktcSigDevToneNumFrequencies are mixed to form a single tone. The tone is then applied in sequence using the number of on/off times specified in pktcSigDevToneNumOnOffTimes. SingleFrequecySequence indicates all frequencies specified by pktcSigDevToneNumFrequencies are applied in sequence using the corresponding frequency number on/off time (e.g., pktcSigDevToneFirstFrequency uses pktcSigDevToneFirstToneOn and pktcSigDevToneFirstToneOff, pktcSigDevToneSecondFrequency uses pktcSigDevToneSecondToneOn and pktcSigDevToneSecondToneOff). For this tone type pktcSigDevToneNumFrequencies MUST equal pktcSigDevToneNumOnOffTimes. DualFrequencySequence indicates two pairs of frequencies are added to form two sequenced tones. The first and second frequency are added to form tone one and are applied using pktcSigDevToneFirstToneOn and pktcSigDevToneFirstToneOff. The third and forth frequency are added to form tone two and are applied using pktcSigDevToneSecondToneOn and pktcSigDevToneSecondToneOff. For this tone type pktcSigDevToneNumFrequencies MUST equal 4 and pktcSigDevToneNumOnOffTimes MUST equal 2. allFrequenciesModulated indicates all frequencies specified by pktcSigDevToneNumFrequencies are modulated to form a single tone. The tone is then applied in sequence using the number of on/off times specified in pktcSigDevToneNumOnOffTimes. For allFrequenciesModulated, the pktcSigDevToneNumFrequencies MUST equal 2, and the frequency in pktcSigDevToneFirstFrequency modulates the frequency in pktcSigDevToneSecondFrequency." REFERENCE "ITU-T E.180" DEFVAL { allFrequencies } ::={ pktcSigDevToneEntry 3 } pktcSigDevToneNumFrequencies OBJECT-TYPE Example 1 - Modulated/Unmodulated Tone: Japan call waiting tone with the following definition per ITU-T E.180: f1 mod f2, where f1=400 Hz AM modulated by 16 Hz, f2=400 Hz not AM modulated cadence: first tone: 500ms ON then 0 to 400ms OFF second tone: 50ms ON then 450ms OFF third tone: 50ms ON then 3450ms OFF fourth tone: 50ms ON then 450ms OFF fifth tone: 50ms ON then 3450 ms OFF not repeated, not continuous Example 2 - Embedded Cadence: This example of an embedded cadence is based on an operator variation of a national standard. A similar example of an embedded cadence can be found in ITU-T supplement 2 (E.180) for Romania. Frequency: 425Hz Cadence: - 1) ton:1000msec, toff: 40msec - 2) 9 sec repeat of (ton: 40mesc, toff: 40msec) - 3) ton: continuous Example 3 - Embedded Cadence: This example of an embedded cadence is based on an operator variation of a national standard. Frequency: 425Hz Cadence: - 1) ton: 160msec, toff: 40msec - 2) 7* (ton: 40msec, toff: 40msec) - 3) ton: 160msec, toff 40msec - 4) 7* (ton: 40msec, toff: 40msec) - 5) ton: 160msec, toff 40msec - 6) 7* (ton: 40msec, toff: 40msec) ------_=_NextPart_001_01C4F342.C5F586D0 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zOm8gPSAidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6 b2ZmaWNlIiB4bWxuczpzdDEgPSANCiJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpz bWFydHRhZ3MiPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5U PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExFPg0K DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0NzkiIG5hbWU9R0VORVJBVE9SPjwv SEVBRD4NCjxCT0RZPg0KPERJVj48Rk9OVCBzaXplPTI+SVRVLVQgc3VwcGxlbWVudCAyIChFLjE4 MCkgaWRlbnRpZmllcyBzZXZlcmFsIHRvbmUgZGVmaW5pdGlvbnMgDQp0aGF0IGNhbm5vdCBiZSBj dXJyZW50bHkgc2F0aXNmaWVkIGJ5IHRoZSBJRVRGIE5DUyBTaWcgTUlCIHRvbmUgdGFibGUgDQpk ZWZpbml0aW9uLiZuYnNwOzxTUEFOIGNsYXNzPTk5NDI2NTcxNy0xMjExMjAwND5JdCBpcyBpbXBv cnRhbnQgZm9yIHRoZSANCjwvU1BBTj5JRVRGIE5DUyBTaWcgTUlCIHRvIHN1cHBvcnQ8U1BBTiBj bGFzcz05OTQyNjU3MTctMTIxMTIwMDQ+IEUuMTgwIHRvbmUgDQpkZWZpbml0aW9ucyBmb3I8L1NQ QU4+OjxvOnA+PC9vOnA+PC9GT05UPjwvRElWPg0KPEJMT0NLUVVPVEUgZGlyPWx0ciBzdHlsZT0i TUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8T0wgc3R5bGU9Ik1BUkdJTi1UT1A6IDBpbiIgdHlwZT0x Pg0KICAgIDxMSSBjbGFzcz1Nc29Ob3JtYWwgDQogICAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiA2 cHQ7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC41aW4iPjxGT05U IA0KICAgIHNpemU9Mj5lbWJlZGRlZCB0b25lIGNhZGVuY2VzIChpLmUuLCANCiAgICA8c3QxOmNv dW50cnktcmVnaW9uPjxzdDE6cGxhY2U+Um9tYW5pYTwvc3QxOnBsYWNlPjwvc3QxOmNvdW50cnkt cmVnaW9uPiANCiAgICBudW1iZXIgdW5vYnRhaW5hYmxlIHRvbmUsIGV0Yyk8bzpwPjwvbzpwPjwv Rk9OVD4mbmJzcDs8U1BBTiANCiAgICBjbGFzcz05OTQyNjU3MTctMTIxMTIwMDQ+PEZPTlQgc2l6 ZT0yPlsyIGV4YW1wbGVzIHNob3duIGJlbG93XTwvRk9OVD48L1NQQU4+IA0KDQogICAgPExJIGNs YXNzPU1zb05vcm1hbCANCiAgICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDZwdDsgbXNvLWxpc3Q6 IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PEZPTlQgDQogICAgc2l6ZT0y PmFtcGxpdHVkZSBtb2R1bGF0aW9uIChpLmUuLCANCiAgICA8c3QxOmNvdW50cnktcmVnaW9uPjxz dDE6cGxhY2U+SmFwYW48L3N0MTpwbGFjZT48L3N0MTpjb3VudHJ5LXJlZ2lvbj4gY2FsbCANCiAg ICB3YWl0aW5nIHRvbmUpPFNQQU4gY2xhc3M9OTk0MjY1NzE3LTEyMTEyMDA0PiBbMSBleGFtcGxl IHNob3duIA0KICAgIGJlbG93XTwvU1BBTj48L0ZPTlQ+PC9MST48L09MPg0KICA8RElWIGNsYXNz PU1zb05vcm1hbCANCiAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiA2cHQ7IG1zby1saXN0OiBsMCBs ZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC41aW4iPjxGT05UIA0KICBzaXplPTI+PG86cD48 U1BBTiBjbGFzcz05OTQyNjU3MTctMTIxMTIwMDQ+VG8gYWRkcmVzcyB0aGVzZSBpc3N1ZXMsIHRo ZSANCiAgZm9sbG93aW5nIGNoYW5nZXMgYXJlIHJlY29tbWVuZGVkOjwvU1BBTj48L286cD48L0ZP TlQ+PC9ESVY+PEZPTlQgDQogIHNpemU9Mj48bzpwPjxTUEFOIGNsYXNzPTk5NDI2NTcxNy0xMjEx MjAwND4NCiAgPFAgY2xhc3M9UkZDVGV4dCANCiAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQ7 IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC41aW4iPjxGT05UIA0K ICBzaXplPTM+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPlBrdGNTaWdEZXZUb25lRW50cnkgOjo9 IFNFUVVFTkNFIHsgDQogIDxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1A+DQogIDxQIGNsYXNz PVJGQ1RleHQgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0OyBtc28tbGlzdDogbDAgbGV2 ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlzdCAuNWluIj48Rk9OVCANCiAgc2l6ZT0zPjxGT05UIGZh Y2U9IkNvdXJpZXIgTmV3Ij48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJz cDsmbmJzcDsmbmJzcDsgPC9TUEFOPnBrdGNTaWdEZXZUb25lVHlwZTxTUEFOIA0KICBzdHlsZT0i bXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9TUEFOPklOVEVHRVIsIDxvOnA+ PC9vOnA+PC9GT05UPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPVJGQ1RleHQgDQogIHN0eWxlPSJN QVJHSU46IDBpbiAwaW4gMHB0OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9wczog bGlzdCAuNWluIj48Rk9OVCANCiAgc2l6ZT0zPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij48U1BB TiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsgPC9TUEFO PnBrdGNTaWdEZXZUb25lRGJMZXZlbDxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAg PC9TUEFOPlRlbnRoZEJtLCA8bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9QPg0KICA8UCBjbGFz cz1SRkNUZXh0IA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdDsgbXNvLWxpc3Q6IGwwIGxl dmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PEZPTlQgDQogIHNpemU9Mz48Rk9OVCBm YWNlPSJDb3VyaWVyIE5ldyI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+cGt0Y1NpZ0RldlRvbmVGcmVxVHlwZTxTUEFOIA0K ICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyANCiAgPC9TUEFOPklOVEVHRVIsIDxvOnA+PC9vOnA+PC9GT05UPjwv Rk9OVD48L1A+DQogIDxQIGNsYXNzPVJGQ1RleHQgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4g MHB0OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlzdCAuNWluIj48Rk9O VCANCiAgc2l6ZT0zPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij48U1BBTiANCiAgc3R5bGU9Im1z by1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsgDQogIDwvU1BBTj5wa3RjU2lnRGV2 VG9uZU51bUZyZXF1ZW5jaWVzPFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IA0KICA8L1NQQU4+VW5zaWduZWQzMiwgPG86cD48L286cD48L0ZPTlQ+PC9GT05UPjwv UD4NCiAgPFAgY2xhc3M9UkZDVGV4dCANCiAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQ7IG1z by1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC41aW4iPjxGT05UIA0KICBz aXplPTM+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNl cnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9TUEFOPnBrdGNTaWdEZXZUb25lRmly c3RGcmVxdWVuY3k8U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg DQogIDwvU1BBTj5VbnNpZ25lZDMyLCA8bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9QPg0KICA8 UCBjbGFzcz1SRkNUZXh0IA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdDsgbXNvLWxpc3Q6 IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PEZPTlQgDQogIHNpemU9Mz48 Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHll cyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+cGt0Y1NpZ0RldlRvbmVGaXJzdFRvbmVT ZWNvbmRhcnlGcmVxdWVuY3kgVW5zaWduZWQzMiwgDQogIDxvOnA+PC9vOnA+PC9GT05UPjwvRk9O VD48L1A+DQogIDxQIGNsYXNzPVJGQ1RleHQgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0 OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlzdCAuNWluIj48Rk9OVCAN CiAgc2l6ZT0zPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij48U1BBTiANCiAgc3R5bGU9Im1zby1z cGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsgDQogIDwvU1BBTj5wa3RjU2lnRGV2VG9u ZUZpcnN0VG9uZVNlY29uZGFyeU1vZGU8U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVz Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9TUEFOPlVuc2lnbmVkMzIsIA0KICA8 bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1SRkNUZXh0IA0KICBzdHls ZT0iTUFSR0lOOiAwaW4gMGluIDBwdDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3Rv cHM6IGxpc3QgLjVpbiI+PEZPTlQgDQogIHNpemU9Mz48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+ PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0K ICA8L1NQQU4+cGt0Y1NpZ0RldlRvbmVGaXJzdFRvbmVTZWNvbmRhcnlBdHRyaWJ1dGUgVW5zaWdu ZWQzMiwgDQogIDxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPVJGQ1Rl eHQgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxm bzE7IHRhYi1zdG9wczogbGlzdCAuNWluIj48Rk9OVCANCiAgc2l6ZT0zPjxGT05UIGZhY2U9IkNv dXJpZXIgTmV3Ij48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJz cDsmbmJzcDsgDQogIDwvU1BBTj5wa3RjU2lnRGV2VG9uZVNlY29uZEZyZXF1ZW5jeTxTUEFOIA0K ICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9TUEFOPlVuc2lnbmVkMzIsIDxv OnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPVJGQ1RleHQgDQogIHN0eWxl PSJNQVJHSU46IDBpbiAwaW4gMHB0OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9w czogbGlzdCAuNWluIj48Rk9OVCANCiAgc2l6ZT0zPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij48 U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsgDQog IDwvU1BBTj5wa3RjU2lnRGV2VG9uZVNlY29uZFRvbmVTZWNvbmRhcnlGcmVxdWVuY3kgVW5zaWdu ZWQzMiwgDQogIDxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPVJGQ1Rl eHQgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxm bzE7IHRhYi1zdG9wczogbGlzdCAuNWluIj48Rk9OVCANCiAgc2l6ZT0zPjxGT05UIGZhY2U9IkNv dXJpZXIgTmV3Ij48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJz cDsmbmJzcDsgDQogIDwvU1BBTj5wa3RjU2lnRGV2VG9uZVNlY29uZFRvbmVTZWNvbmRhcnlNb2Rl PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDwvU1BBTj5VbnNpZ25lZDMyLCANCiAgPG86cD48L286cD48L0ZPTlQ+PC9GT05U PjwvUD4NCiAgPFAgY2xhc3M9UkZDVGV4dCANCiAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQ7 IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC41aW4iPjxGT05UIA0K ICBzaXplPTM+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPjxTUEFOIA0KICBzdHlsZT0ibXNvLXNw YWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9TUEFOPnBrdGNTaWdEZXZUb25l U2Vjb25kVG9uZVNlY29uZGFyeUF0dHJpYnV0ZSBVbnNpZ25lZDMyLCANCiAgPG86cD48L286cD48 L0ZPTlQ+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9UkZDVGV4dCANCiAgc3R5bGU9Ik1BUkdJTjog MGluIDBpbiAwcHQ7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC41 aW4iPjxGT05UIA0KICBzaXplPTM+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPjxTUEFOIA0KICBz dHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9TUEFOPnBr dGNTaWdEZXZUb25lVGhpcmRGcmVxdWVuY3k8U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjog eWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgDQogIDwvU1BBTj5VbnNpZ25lZDMyLCA8bzpwPjwvbzpwPjwvRk9OVD48 L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1SRkNUZXh0IA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGlu IDBwdDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PEZP TlQgDQogIHNpemU9Mz48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+PFNQQU4gDQogIHN0eWxlPSJt c28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+cGt0Y1NpZ0Rl dlRvbmVUaGlyZFRvbmVTZWNvbmRhcnlGcmVxdWVuY3kgVW5zaWduZWQzMiwgDQogIDxvOnA+PC9v OnA+PC9GT05UPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPVJGQ1RleHQgDQogIHN0eWxlPSJNQVJH SU46IDBpbiAwaW4gMHB0OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlz dCAuNWluIj48Rk9OVCANCiAgc2l6ZT0zPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij48U1BBTiAN CiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsgDQogIDwvU1BB Tj5wa3RjU2lnRGV2VG9uZVRoaXJkVG9uZVNlY29uZGFyeU1vZGU8U1BBTiANCiAgc3R5bGU9Im1z by1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9TUEFOPlVu c2lnbmVkMzIsIA0KICA8bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1S RkNUZXh0IA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdDsgbXNvLWxpc3Q6IGwwIGxldmVs MSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PEZPTlQgDQogIHNpemU9Mz48Rk9OVCBmYWNl PSJDb3VyaWVyIE5ldyI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+cGt0Y1NpZ0RldlRvbmVUaGlyZFRvbmVTZWNvbmRhcnlB dHRyaWJ1dGUgVW5zaWduZWQzMiwgDQogIDxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1A+DQog IDxQIGNsYXNzPVJGQ1RleHQgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0OyBtc28tbGlz dDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlzdCAuNWluIj48Rk9OVCANCiAgc2l6ZT0z PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjog eWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsgDQogIDwvU1BBTj5wa3RjU2lnRGV2VG9uZUZvdXJ0aEZy ZXF1ZW5jeTxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9TUEFOPlVuc2lnbmVkMzIsIA0KICA8 bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1SRkNUZXh0IA0KICBzdHls ZT0iTUFSR0lOOiAwaW4gMGluIDBwdDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3Rv cHM6IGxpc3QgLjVpbiI+PEZPTlQgDQogIHNpemU9Mz48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+ PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0K ICA8L1NQQU4+cGt0Y1NpZ0RldlRvbmVGb3VydGhUb25lU2Vjb25kYXJ5RnJlcXVlbmN5IFVuc2ln bmVkMzIsIA0KICA8bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1SRkNU ZXh0IA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBs Zm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PEZPTlQgDQogIHNpemU9Mz48Rk9OVCBmYWNlPSJD b3VyaWVyIE5ldyI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IA0KICA8L1NQQU4+cGt0Y1NpZ0RldlRvbmVGb3VydGhUb25lU2Vjb25kYXJ5TW9k ZTxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA8L1NQQU4+VW5zaWduZWQzMiwgDQogIDxvOnA+PC9vOnA+PC9GT05UPjwvRk9O VD48L1A+DQogIDxQIGNsYXNzPVJGQ1RleHQgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0 OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlzdCAuNWluIj48Rk9OVCAN CiAgc2l6ZT0zPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij48U1BBTiANCiAgc3R5bGU9Im1zby1z cGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsgDQogIDwvU1BBTj5wa3RjU2lnRGV2VG9u ZUZvdXJ0aFRvbmVTZWNvbmRhcnlBdHRyaWJ1dGUgVW5zaWduZWQzMiwgDQogIDxvOnA+PC9vOnA+ PC9GT05UPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPVJGQ1RleHQgDQogIHN0eWxlPSJNQVJHSU46 IDBpbiAwaW4gMHB0OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlzdCAu NWluIj48Rk9OVCANCiAgc2l6ZT0zPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij48U1BBTiANCiAg c3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsgDQogIDwvU1BBTj5w a3RjU2lnRGV2VG9uZUZpZnRoRnJlcXVlbmN5PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46 IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+VW5zaWduZWQzMiwgPG86cD48L286cD48L0ZPTlQ+ PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9UkZDVGV4dCANCiAgc3R5bGU9Ik1BUkdJTjogMGluIDBp biAwcHQ7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC41aW4iPjxG T05UIA0KICBzaXplPTM+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPjxTUEFOIA0KICBzdHlsZT0i bXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9TUEFOPnBrdGNTaWdE ZXZUb25lRmlmdGhUb25lU2Vjb25kYXJ5RnJlcXVlbmN5IFVuc2lnbmVkMzIsIA0KICA8bzpwPjwv bzpwPjwvRk9OVD48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1SRkNUZXh0IA0KICBzdHlsZT0iTUFS R0lOOiAwaW4gMGluIDBwdDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxp c3QgLjVpbiI+PEZPTlQgDQogIHNpemU9Mz48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+PFNQQU4g DQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQ QU4+cGt0Y1NpZ0RldlRvbmVGaWZ0aFRvbmVTZWNvbmRhcnlNb2RlPFNQQU4gDQogIHN0eWxlPSJt c28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BBTj5V bnNpZ25lZDMyLCANCiAgPG86cD48L286cD48L0ZPTlQ+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9 UkZDVGV4dCANCiAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQ7IG1zby1saXN0OiBsMCBsZXZl bDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC41aW4iPjxGT05UIA0KICBzaXplPTM+PEZPTlQgZmFj ZT0iQ291cmllciBOZXciPjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNw OyZuYnNwOyZuYnNwOyANCiAgPC9TUEFOPnBrdGNTaWdEZXZUb25lRmlmdGhUb25lU2Vjb25kYXJ5 QXR0cmlidXRlIFVuc2lnbmVkMzIsIA0KICA8bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9QPg0K ICA8UCBjbGFzcz1SRkNUZXh0IA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdDsgbXNvLWxp c3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PEZPTlQgDQogIHNpemU9 Mz48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46 IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+cGt0Y1NpZ0RldlRvbmVOdW1Pbk9m ZlRpbWVzPFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IA0KICA8L1NQQU4+VW5zaWduZWQzMiwgPG86cD48L286cD48L0ZPTlQ+PC9GT05UPjwvUD4NCiAg PFAgY2xhc3M9UkZDVGV4dCANCiAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQ7IG1zby1saXN0 OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC41aW4iPjxGT05UIA0KICBzaXplPTM+ PEZPTlQgZmFjZT0iQ291cmllciBOZXciPjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5 ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9TUEFOPnBrdGNTaWdEZXZUb25lRmlyc3RUb25l T248U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgDQogIDwvU1BBTj5VbnNpZ25lZDMyLCA8bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+ PC9QPg0KICA8UCBjbGFzcz1SRkNUZXh0IA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdDsg bXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PEZPTlQgDQog IHNpemU9Mz48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3Bh Y2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+cGt0Y1NpZ0RldlRvbmVG aXJzdFRvbmVPZmY8U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgDQogIDwvU1BBTj5VbnNpZ25lZDMyLCA8bzpwPjwvbzpwPjwvRk9OVD48L0ZP TlQ+PC9QPg0KICA8UCBjbGFzcz1SRkNUZXh0IA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBw dDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PEZPTlQg DQogIHNpemU9Mz48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+PFNQQU4gDQogIHN0eWxlPSJtc28t c3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+cGt0Y1NpZ0RldlRv bmVGaXJzdFRvbmVSZXBlYXRDb3VudDxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+VW5zaWduZWQzMiwgDQogIDxv OnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPVJGQ1RleHQgDQogIHN0eWxl PSJNQVJHSU46IDBpbiAwaW4gMHB0OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9w czogbGlzdCAuNWluIj48Rk9OVCANCiAgc2l6ZT0zPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij48 U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsgDQog IDwvU1BBTj5wa3RjU2lnRGV2VG9uZVNlY29uZFRvbmVPbjxTUEFOIA0KICBzdHlsZT0ibXNvLXNw YWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9TUEFOPlVuc2lnbmVkMzIs IDxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPVJGQ1RleHQgDQogIHN0 eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1z dG9wczogbGlzdCAuNWluIj48Rk9OVCANCiAgc2l6ZT0zPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3 Ij48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsg DQogIDwvU1BBTj5wa3RjU2lnRGV2VG9uZVNlY29uZFRvbmVPZmY8U1BBTiANCiAgc3R5bGU9Im1z by1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIDwvU1BBTj5VbnNpZ25lZDMyLCA8 bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1SRkNUZXh0IA0KICBzdHls ZT0iTUFSR0lOOiAwaW4gMGluIDBwdDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3Rv cHM6IGxpc3QgLjVpbiI+PEZPTlQgDQogIHNpemU9Mz48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+ PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0K ICA8L1NQQU4+cGt0Y1NpZ0RldlRvbmVTZWNvbmRUb25lUmVwZWF0Q291bnQ8U1BBTiANCiAgc3R5 bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9TUEFOPlVu c2lnbmVkMzIsIA0KICA8bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1S RkNUZXh0IA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdDsgbXNvLWxpc3Q6IGwwIGxldmVs MSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PEZPTlQgDQogIHNpemU9Mz48Rk9OVCBmYWNl PSJDb3VyaWVyIE5ldyI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+cGt0Y1NpZ0RldlRvbmVUaGlyZFRvbmVPbjxTUEFOIA0K ICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAN CiAgPC9TUEFOPlVuc2lnbmVkMzIsIDxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1A+DQogIDxQ IGNsYXNzPVJGQ1RleHQgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0OyBtc28tbGlzdDog bDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlzdCAuNWluIj48Rk9OVCANCiAgc2l6ZT0zPjxG T05UIGZhY2U9IkNvdXJpZXIgTmV3Ij48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVz Ij4mbmJzcDsmbmJzcDsmbmJzcDsgDQogIDwvU1BBTj5wa3RjU2lnRGV2VG9uZVRoaXJkVG9uZU9m ZjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyANCiAgPC9TUEFOPlVuc2lnbmVkMzIsIDxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1A+DQog IDxQIGNsYXNzPVJGQ1RleHQgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0OyBtc28tbGlz dDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlzdCAuNWluIj48Rk9OVCANCiAgc2l6ZT0z PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjog eWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsgDQogIDwvU1BBTj5wa3RjU2lnRGV2VG9uZVRoaXJkVG9u ZVJlcGVhdENvdW50PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BBTj5VbnNpZ25lZDMyLCANCiAgPG86cD48L286cD48 L0ZPTlQ+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9UkZDVGV4dCANCiAgc3R5bGU9Ik1BUkdJTjog MGluIDBpbiAwcHQ7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC41 aW4iPjxGT05UIA0KICBzaXplPTM+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPjxTUEFOIA0KICBz dHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9TUEFOPnBr dGNTaWdEZXZUb25lRm91cnRoVG9uZU9uPFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHll cyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+VW5zaWduZWQzMiwgPG86cD48L286 cD48L0ZPTlQ+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9UkZDVGV4dCANCiAgc3R5bGU9Ik1BUkdJ TjogMGluIDBpbiAwcHQ7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0 IC41aW4iPjxGT05UIA0KICBzaXplPTM+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPjxTUEFOIA0K ICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9TUEFO PnBrdGNTaWdEZXZUb25lRm91cnRoVG9uZU9mZjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVu OiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9TUEFOPlVuc2lnbmVkMzIsIDxvOnA+PC9vOnA+ PC9GT05UPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPVJGQ1RleHQgDQogIHN0eWxlPSJNQVJHSU46 IDBpbiAwaW4gMHB0OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlzdCAu NWluIj48Rk9OVCANCiAgc2l6ZT0zPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij48U1BBTiANCiAg c3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsgDQogIDwvU1BBTj5w a3RjU2lnRGV2VG9uZUZvdXJ0aFRvbmVSZXBlYXRDb3VudDxTUEFOIA0KICBzdHlsZT0ibXNvLXNw YWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+VW5zaWduZWQzMiwg DQogIDxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPVJGQ1RleHQgDQog IHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7IHRh Yi1zdG9wczogbGlzdCAuNWluIj48Rk9OVCANCiAgc2l6ZT0zPjxGT05UIGZhY2U9IkNvdXJpZXIg TmV3Ij48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJz cDsgDQogIDwvU1BBTj5wa3RjU2lnRGV2VG9uZUZpZnRoVG9uZU9uPFNQQU4gDQogIHN0eWxlPSJt c28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+PFNQQU4gc3R5bGU9Im1zby1zcGFjZXJ1 bjogeWVzIj4mbmJzcDs8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9TUEFOPlVuc2lnbmVkMzIsIA0KICA8bzpwPjwvbzpwPjwvRk9O VD48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1SRkNUZXh0IA0KICBzdHlsZT0iTUFSR0lOOiAwaW4g MGluIDBwdDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+ PEZPTlQgDQogIHNpemU9Mz48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+PFNQQU4gDQogIHN0eWxl PSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+cGt0Y1Np Z0RldlRvbmVGaWZ0aFRvbmVPZmY8U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgDQogIDwvU1BBTj48U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOzwvU1BB Tj48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDs8L1NQQU4+ VW5zaWduZWQzMiwgDQogIDxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1A+DQogIDxQIGNsYXNz PVJGQ1RleHQgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0OyBtc28tbGlzdDogbDAgbGV2 ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlzdCAuNWluIj48Rk9OVCANCiAgc2l6ZT0zPjxGT05UIGZh Y2U9IkNvdXJpZXIgTmV3Ij48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJz cDsmbmJzcDsmbmJzcDsgDQogIDwvU1BBTj5wa3RjU2lnRGV2VG9uZUZpZnRoVG9uZVJlcGVhdENv dW50PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDwvU1BBTj48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDs8L1NQQU4+ PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7PC9TUEFOPlVuc2lnbmVk MzIsIA0KICA8bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1SRkNUZXh0 IA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8x OyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PEZPTlQgDQogIHNpemU9Mz48Rk9OVCBmYWNlPSJDb3Vy aWVyIE5ldyI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IA0KICA8L1NQQU4+cGt0Y1NpZ0RldlRvbmVXaG9sZVRvbmVSZXBlYXRDb3VudDxTUEFO IA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8L1NQQU4+VW5zaWduZWQzMiwgDQogIDxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1A+ DQogIDxQIGNsYXNzPVJGQ1RleHQgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0OyBtc28t bGlzdDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlzdCAuNWluIj48Rk9OVCANCiAgc2l6 ZT0zPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1 bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsgPC9TUEFOPnBrdGNTaWdEZXZUb25lU3RlYWR5PFNQ QU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+VHJ1dGhWYWx1ZSA8 bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1SRkNUZXh0IA0KICBzdHls ZT0iTUFSR0lOOiAwaW4gMGluIDBwdDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3Rv cHM6IGxpc3QgLjVpbiI+PEZPTlQgDQogIHNpemU9Mz48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+ PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwv U1BBTj59IA0KICA8bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29O b3JtYWwgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gNnB0OyBtc28tbGlzdDogbDAgbGV2ZWwx IGxmbzE7IHRhYi1zdG9wczogbGlzdCAuNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvUD4NCiAgPFAg Y2xhc3M9TXNvTm9ybWFsIA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDZwdDsgbXNvLWxpc3Q6 IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PFNQQU4gDQogIHN0eWxlPSJG T05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj5wa3RjU2lnRGV2VG9u ZUZpcnN0VG9uZVNlY29uZGFyeUZyZXF1ZW5jeTxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAg Y2xhc3M9TXNvTm9ybWFsIA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDZwdDsgbXNvLWxpc3Q6 IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PFNQQU4gDQogIHN0eWxlPSJG T05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj48U1BBTiANCiAgc3R5 bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9TUEFOPlNZ TlRBWDxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA8L1NQQU4+VW5zaWduZWQzMiANCiAgKDAuLjQwMDApPG86cD48L286cD48L1NQQU4+ PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gNnB0 OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlzdCAuNWluIj48U1BBTiAN CiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPjxT UEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyA8L1NQQU4+TUFYLUFDQ0VTUyANCiAgcmVhZC13cml0ZTxvOnA+PC9vOnA+PC9TUEFOPjwvUD4N CiAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDZwdDsgbXNv LWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PFNQQU4gDQogIHN0 eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj48U1BBTiAN CiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9T UEFOPlNUQVRVUzxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyANCiAgPC9TUEFOPmN1cnJlbnQ8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQog IDxQIGNsYXNzPU1zb05vcm1hbCANCiAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiA2cHQ7IG1zby1s aXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC41aW4iPjxTUEFOIA0KICBzdHls ZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+PFNQQU4gDQog IHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BBTj48U1BB TiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDs8L1NQQU4+REVTQ1JJUFRJT048 bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCANCiAgc3R5bGU9Ik1B UkdJTjogMGluIDBpbiA2cHQ7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBs aXN0IC41aW4iPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTog J0NvdXJpZXIgTmV3JyI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDwvU1BBTj48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4m bmJzcDs8L1NQQU4+IlRoZSBzZWNvbmRhcnkgZnJlcXVlbmN5IHVzZWQgdG8gDQogIGFtcGxpdHVk ZSBtb2R1bGF0ZSBvcjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFs IA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDZwdDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8x OyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7 IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1 bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9TUEFOPndoaWNoIGlzIA0K ICBzdW1tZWQgd2l0aCB0aGUgcGt0Y1NpZ0RldlRvbmVGaXJzdEZyZXF1ZW5jeTxvOnA+PC9vOnA+ PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICBzdHlsZT0iTUFSR0lOOiAwaW4g MGluIDZwdDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+ PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBO ZXcnIj48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgPC9TUEFOPjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNw OzwvU1BBTj5kZXBlbmRpbmcgb24gdGhlIHNldHRpbmcgDQogIG9mPG86cD48L286cD48L1NQQU4+ PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gNnB0 OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlzdCAuNWluIj48U1BBTiAN CiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPjxT UEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyA8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7PC9TUEFO PnBrdGNTaWdEZXZUb25lRmlyc3RUb25lU2Vjb25kYXJ5TW9kZS4iPG86cD48L286cD48L1NQQU4+ PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gNnB0 OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlzdCAuNWluIj48U1BBTiAN CiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPjxT UEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQ QU4+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7PC9TUEFOPjo6PXtw a3RjU2lnRGV2VG9uZUVudHJ5IA0KICB4fTxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xh c3M9TXNvTm9ybWFsIA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDZwdDsgbXNvLWxpc3Q6IGww IGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PFNQQU4gDQogIHN0eWxlPSJGT05U LVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj48bzpwPiZuYnNwOzwvbzpw PjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCANCiAgc3R5bGU9Ik1BUkdJTjogMGlu IDBpbiA2cHQ7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC41aW4i PjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIg TmV3JyI+QSBzaW1pbGFyIG9iamVjdCANCiAgZGVmaW5pdGlvbiBpcyByZXF1aXJlZCBmb3I6PG86 cD48L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxlPSJNQVJH SU46IDBpbiAwaW4gNnB0OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlz dCAuNWluIj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6ICdD b3VyaWVyIE5ldyciPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNv Tm9ybWFsIA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDZwdDsgbXNvLWxpc3Q6IGwwIGxldmVs MSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6 IDEycHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj5wa3RjU2lnRGV2VG9uZVNlY29uZFRv bmVTZWNvbmRhcnlGcmVxdWVuY3k8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1z b05vcm1hbCANCiAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiA2cHQ7IG1zby1saXN0OiBsMCBsZXZl bDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC41aW4iPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpF OiAxMnB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+cGt0Y1NpZ0RldlRvbmVUaGlyZFRv bmVTZWNvbmRhcnlGcmVxdWVuY3k8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1z b05vcm1hbCANCiAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiA2cHQ7IG1zby1saXN0OiBsMCBsZXZl bDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC41aW4iPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpF OiAxMnB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+cGt0Y1NpZ0RldlRvbmVGb3VydGhU b25lU2Vjb25kYXJ5RnJlcXVlbmN5PG86cD48L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1N c29Ob3JtYWwgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gNnB0OyBtc28tbGlzdDogbDAgbGV2 ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlzdCAuNWluIj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0la RTogMTJwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPnBrdGNTaWdEZXZUb25lRmlmdGhU b25lU2Vjb25kYXJ5RnJlcXVlbmN5PG86cD48L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1N c29Ob3JtYWwgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gNnB0OyBtc28tbGlzdDogbDAgbGV2 ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlzdCAuNWluIj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0la RTogMTJwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPjxvOnA+Jm5ic3A7PC9vOnA+PC9T UEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGlu IDZwdDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PFNQ QU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcn Ij5wa3RjU2lnRGV2VG9uZUZpcnN0VG9uZVNlY29uZGFyeU1vZGU8bzpwPjwvbzpwPjwvU1BBTj48 L1A+DQogIDxQIGNsYXNzPVJGQ1RleHQgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0OyBt c28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9wczogLjZpbiAuOWluIDEuMmluIDEuNWlu IDEuOGluIDIuMWluIDIuNGluIDIuN2luIDMuMGluIDMuM2luIDMuNmluIDMuOWluIDQuMmluIDQu NWluIDQuOGluIDUuMWluIDUuNGluIDUuN2luIDYuMGluIDYuM2luIDYuNmluIDYuOWluIj48Rk9O VCANCiAgc2l6ZT0zPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij48U1BBTiANCiAgc3R5bGU9Im1z by1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsgPC9TUEFOPlNZTlRBWDxTUEFOIA0K ICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA8L1NQQU4+SU5URUdFUiANCiAgeyA8bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9Q Pg0KICA8UCBjbGFzcz1SRkNUZXh0IA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdDsgbXNv LWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IC42aW4gLjlpbiAxLjJpbiAxLjVpbiAx LjhpbiAyLjFpbiAyLjRpbiAyLjdpbiAzLjBpbiAzLjNpbiAzLjZpbiAzLjlpbiA0LjJpbiA0LjVp biA0LjhpbiA1LjFpbiA1LjRpbiA1LjdpbiA2LjBpbiA2LjNpbiA2LjZpbiA2LjlpbiI+PEZPTlQg DQogIGZhY2U9IkNvdXJpZXIgTmV3Ij48Rk9OVCBzaXplPTM+PFNQQU4gDQogIHN0eWxlPSJtc28t c3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+bm9Nb2ROb1N1bSAoMSk8U1BBTiBj bGFzcz05OTQyNjU3MTctMTIxMTIwMDQ+LDwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvUD4NCiAgPFAg Y2xhc3M9UkZDVGV4dCANCiAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQ7IG1zby1saXN0OiBs MCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiAuNmluIC45aW4gMS4yaW4gMS41aW4gMS44aW4gMi4x aW4gMi40aW4gMi43aW4gMy4waW4gMy4zaW4gMy42aW4gMy45aW4gNC4yaW4gNC41aW4gNC44aW4g NS4xaW4gNS40aW4gNS43aW4gNi4waW4gNi4zaW4gNi42aW4gNi45aW4iPjxGT05UIA0KICBzaXpl PTM+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVu OiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyANCiAgPC9TUEFOPnByaW1hcnlNb2R1bGF0ZWRCeVNlY29uZGFyeSAo MiksIDxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPVJGQ1RleHQgDQog IHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7IHRh Yi1zdG9wczogLjZpbiAuOWluIDEuMmluIDEuNWluIDEuOGluIDIuMWluIDIuNGluIDIuN2luIDMu MGluIDMuM2luIDMuNmluIDMuOWluIDQuMmluIDQuNWluIDQuOGluIDUuMWluIDUuNGluIDUuN2lu IDYuMGluIDYuM2luIDYuNmluIDYuOWluIj48Rk9OVCANCiAgc2l6ZT0zPjxGT05UIGZhY2U9IkNv dXJpZXIgTmV3Ij48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg DQogIDwvU1BBTj5wcmltYXJ5U3VtbWVkV2l0aFNlY29uZGFyeSAoMykgPG86cD48L286cD48L0ZP TlQ+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9UkZDVGV4dCANCiAgc3R5bGU9Ik1BUkdJTjogMGlu IDBpbiAwcHQ7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiAuNmluIC45aW4g MS4yaW4gMS41aW4gMS44aW4gMi4xaW4gMi40aW4gMi43aW4gMy4waW4gMy4zaW4gMy42aW4gMy45 aW4gNC4yaW4gNC41aW4gNC44aW4gNS4xaW4gNS40aW4gNS43aW4gNi4waW4gNi4zaW4gNi42aW4g Ni45aW4iPjxGT05UIA0KICBzaXplPTM+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPjxTUEFOIA0K ICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+fSAN CiAgPG86cD48L286cD48L0ZPTlQ+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIA0K ICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDZwdDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0 YWItc3RvcHM6IGxpc3QgLjVpbiI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZP TlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj5NQVgtQUNDRVNTIA0KICByZWFkLXdyaXRlPG86cD48 L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxlPSJNQVJHSU46 IDBpbiAwaW4gNnB0OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlzdCAu NWluIj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6ICdDb3Vy aWVyIE5ldyciPjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyA8L1NQQU4+U1RBVFVTPFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46 IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+Y3VycmVudDxvOnA+PC9v OnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICBzdHlsZT0iTUFSR0lOOiAw aW4gMGluIDZwdDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVp biI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnQ291cmll ciBOZXcnIj48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgDQogIDwvU1BBTj5ERVNDUklQVElPTjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4N CiAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDZwdDsgbXNv LWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PFNQQU4gDQogIHN0 eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj48U1BBTiAN CiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9T UEFOPiJXaGVuIA0KICBwa3RjU2lnRGV2VG9uZUZpcnN0VG9uZVNlY29uZGFyeU1vZGUgaXMgc2V0 IHRvPG86cD48L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxl PSJNQVJHSU46IDBpbiAwaW4gNnB0OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9w czogbGlzdCAuNWluIj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1J TFk6ICdDb3VyaWVyIE5ldyciPjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9TUEFOPnByaW1hcnlNb2R1bGF0ZWRC eVNlY29uZGFyeSwgdGhlPG86cD48L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3Jt YWwgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gNnB0OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxm bzE7IHRhYi1zdG9wczogbGlzdCAuNWluIj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJw dDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNl cnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+PFNQQU4gDQogIHN0eWxl PSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7PC9TUEFOPnBrdGNTaWdEZXZUb25lRmlyc3RUb25l U2Vjb25kYXJ5RnJlcXVlbmN5PC9TUEFOPiANCiAgPFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6 IDEycHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj5pczxvOnA+PC9vOnA+PC9TUEFOPjwv UD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDZwdDsg bXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PFNQQU4gDQog IHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj48U1BB TiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgPC9TUEFOPnVzZWQgdG8gDQogIGFtcGxpdHVkZSBtb2R1bGF0ZSB0aGU8bzpwPjwvbzpw PjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCANCiAgc3R5bGU9Ik1BUkdJTjogMGlu IDBpbiA2cHQ7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC41aW4i PjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIg TmV3JyI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+cGt0Y1NpZ0RldlRvbmVGaXJzdEZyZXF1ZW5jeS48 bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCANCiAgc3R5bGU9Ik1B UkdJTjogMGluIDBpbiA2cHQ7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBs aXN0IC41aW4iPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTog J0NvdXJpZXIgTmV3JyI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BBTj5XaGVuIA0KICBwa3RjU2lnRGV2VG9uZUZp cnN0VG9uZVNlY29uZGFyeU1vZGUgaXMgc2V0IHRvPG86cD48L286cD48L1NQQU4+PC9QPg0KICA8 UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gNnB0OyBtc28tbGlz dDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlzdCAuNWluIj48U1BBTiANCiAgc3R5bGU9 IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPjxTUEFOIA0KICBz dHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAN CiAgPC9TUEFOPnByaW1hcnlTdW1tZWRXaXRoU2Vjb25kYXJ5LCB0aGU8bzpwPjwvbzpwPjwvU1BB Tj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCANCiAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiA2 cHQ7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC41aW4iPjxTUEFO IA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+ PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IA0KICA8L1NQQU4+cGt0Y1NpZ0RldlRvbmVGaXJzdFRvbmVTZWNvbmRhcnlGcmVx dWVuY3kgaXMgDQogIHN1bW1lZDxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNv Tm9ybWFsIA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDZwdDsgbXNvLWxpc3Q6IGwwIGxldmVs MSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6 IDEycHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj48U1BBTiANCiAgc3R5bGU9Im1zby1z cGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9TUEFOPjxTUEFOIA0KICBz dHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOzwvU1BBTj53aXRoIHRoZSBwa3RjU2lnRGV2 VG9uZUZpcnN0RnJlcXVlbmN5IA0KICB3aXRob3V0IGFueTxvOnA+PC9vOnA+PC9TUEFOPjwvUD4N CiAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDZwdDsgbXNv LWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PFNQQU4gDQogIHN0 eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj48U1BBTiAN CiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9T UEFOPjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOzwvU1BBTj5tb2R1 bGF0aW9uLiBXaGVuIA0KICBwa3RjU2lnRGV2VG9uZUZpcnN0VG9uZVNlY29uZGFyeU1vZGU8bzpw PjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCANCiAgc3R5bGU9Ik1BUkdJ TjogMGluIDBpbiA2cHQ7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0 IC41aW4iPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogJ0Nv dXJpZXIgTmV3JyI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDwvU1BBTj48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVz Ij4mbmJzcDs8L1NQQU4+aXMgc2V0IHRvIG5vTW9kTm9TdW0sIA0KICB0aGU8bzpwPjwvbzpwPjwv U1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCANCiAgc3R5bGU9Ik1BUkdJTjogMGluIDBp biA2cHQ7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC41aW4iPjxT UEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3 JyI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDwvU1BBTj48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDs8 L1NQQU4+cGt0Y1NpZ0RldlRvbmVGaXJzdFRvbmVTZWNvbmRhcnlGcmVxdWVuY3kgDQogIE1VU1Qg Tk9UIGJlPG86cD48L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0 eWxlPSJNQVJHSU46IDBpbiAwaW4gNnB0OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1z dG9wczogbGlzdCAuNWluIj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1G QU1JTFk6ICdDb3VyaWVyIE5ldyciPjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJtc28tc3Bh Y2VydW46IHllcyI+Jm5ic3A7PC9TUEFOPnVzZWQuIjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAg PFAgY2xhc3M9TXNvTm9ybWFsIA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDZwdDsgbXNvLWxp c3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PFNQQU4gDQogIHN0eWxl PSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj48U1BBTiANCiAg c3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg PC9TUEFOPkRFRlZBTCB7IDEgDQogIH08bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNz PU1zb05vcm1hbCANCiAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiA2cHQ7IG1zby1saXN0OiBsMCBs ZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC41aW4iPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1T SVpFOiAxMnB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+PFNQQU4gDQogIHN0eWxlPSJt c28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+Ojo9 e3BrdGNTaWdEZXZUb25lRW50cnkgeH08bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNz PU1zb05vcm1hbCANCiAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiA2cHQ7IG1zby1saXN0OiBsMCBs ZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC41aW4iPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1T SVpFOiAxMnB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+PG86cD4mbmJzcDs8L286cD48 L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAw aW4gNnB0OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlzdCAuNWluIj48 U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5l dyciPnBrdGNTaWdEZXZUb25lRmlyc3RUb25lU2Vjb25kYXJ5QXR0cmlidXRlPG86cD48L286cD48 L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAw aW4gNnB0OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlzdCAuNWluIj48 U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5l dyciPjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA8L1NQQU4+U1lOVEFYPFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BBTj5VbnNpZ25lZDMyIA0KICAoMC4uMTAwKTxv OnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICBzdHlsZT0iTUFS R0lOOiAwaW4gMGluIDZwdDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxp c3QgLjVpbiI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAn Q291cmllciBOZXcnIj48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgPC9TUEFOPk1BWC1BQ0NFU1MgDQogIHJlYWQtd3JpdGU8bzpwPjwv bzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCANCiAgc3R5bGU9Ik1BUkdJTjog MGluIDBpbiA2cHQ7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC41 aW4iPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogJ0NvdXJp ZXIgTmV3JyI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDwvU1BBTj48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDs8 L1NQQU4+U1RBVFVTPFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+Y3VycmVudDxvOnA+PC9vOnA+PC9TUEFOPjwvUD4N CiAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDZwdDsgbXNv LWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PFNQQU4gDQogIHN0 eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj48U1BBTiAN CiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQog IDwvU1BBTj5ERVNDUklQVElPTjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9UkZD VGV4dCANCiAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQgMC4zaW47IG1zby1saXN0OiBsMCBs ZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC41aW4iPjxGT05UIA0KICBzaXplPTM+PEZPTlQg ZmFjZT0iQ291cmllciBOZXciPjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+IlRoZSBwZXJjZW50YWdlIG9mIA0KICBhbXBs aXR1ZGUgbW9kdWxhdGlvbiBhcHBsaWVkIHRvIHRoZTxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48 L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCANCiAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiA2cHQ7 IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC41aW4iPjxTUEFOIA0K ICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+PFNQ QU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IA0KICA8L1NQQU4+cGt0Y1NpZ0RldlRvbmVGaXJzdFRvbmVTZWNvbmRhcnlGcmVxdWVu Y3kuIFRoaXM8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCANCiAg c3R5bGU9Ik1BUkdJTjogMGluIDBpbiA2cHQ7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFi LXN0b3BzOiBsaXN0IC41aW4iPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05U LUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHll cyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BBTj48U1BBTiANCiAgc3R5bGU9Im1zby1z cGFjZXJ1bjogeWVzIj4mbmJzcDs8L1NQQU4+b2JqZWN0IGlzIG9ubHkgdXNlZCANCiAgaWY8bzpw PjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCANCiAgc3R5bGU9Ik1BUkdJ TjogMGluIDBpbiA2cHQ7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0 IC41aW4iPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogJ0Nv dXJpZXIgTmV3JyI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+cGt0Y1NpZ0RldlRvbmVGaXJzdFRvbmVT ZWNvbmRhcnlNb2RlIGlzPG86cD48L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1SRkNUZXh0 IA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAwLjNpbjsgbXNvLWxpc3Q6IGwwIGxldmVs MSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PEZPTlQgDQogIHNpemU9Mz48Rk9OVCBmYWNl PSJDb3VyaWVyIE5ldyI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+cHJpbWFyeU1vZHVsYXRlZEJ5U2Vj b25kYXJ5LiBBbiBhdHRlbXB0IHRvIHNldCB0aGlzIG9iamVjdCB3aGlsZSB0aGUgDQogIHZhbHVl IG9mPFNQQU4gDQogIHN0eWxlPSJtc28tYmlkaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h biciPjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29O b3JtYWwgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gNnB0OyBtc28tbGlzdDogbDAgbGV2ZWwx IGxmbzE7IHRhYi1zdG9wczogbGlzdCAuNWluIj48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1 bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgDQogIDwvU1BBTj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1G QU1JTFk6ICdDb3VyaWVyIE5ldyciPnBrdGNTaWdEZXZUb25lRmlyc3RUb25lU2Vjb25kYXJ5TW9k ZTxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9UkZDVGV4dCANCiAgc3R5bGU9Ik1B UkdJTjogMGluIDBpbiAwcHQgMC4zaW47IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0 b3BzOiBsaXN0IC41aW4iPjxGT05UIA0KICBzaXplPTM+PEZPTlQgZmFjZT0iQ291cmllciBOZXci PmlzIG5vdCBwcmltYXJ5TW9kdWxhdGVkQnlTZWNvbmRhcnkgd2lsbCByZXN1bHQgDQogIGluPFNQ QU4gDQogIHN0eWxlPSJtc28tYmlkaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbiciPjxv OnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1SRkNUZXh0IA0K ICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0 YWItc3RvcHM6IC42aW4gLjlpbiAxLjJpbiAxLjVpbiAxLjhpbiAyLjFpbiAyLjRpbiAyLjdpbiAz LjBpbiAzLjNpbiAzLjZpbiAzLjlpbiA0LjJpbiA0LjVpbiA0LjhpbiA1LjFpbiA1LjRpbiA1Ljdp biA2LjBpbiA2LjNpbiA2LjZpbiA2LjlpbiI+PEZPTlQgDQogIHNpemU9Mz48Rk9OVCBmYWNlPSJD b3VyaWVyIE5ldyI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+ YW4gaW5jb25zaXN0ZW50VmFsdWUgZXJyb3IuIjxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1A+ DQogIDxQIGNsYXNzPU1zb05vcm1hbCANCiAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiA2cHQ7IG1z by1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC41aW4iPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+PFNQQU4g DQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0K ICA8L1NQQU4+Ojo9e3BrdGNTaWdEZXZUb25lRW50cnkgeH08bzpwPjwvbzpwPjwvU1BBTj48L1A+ DQogIDxQIGNsYXNzPU1zb05vcm1hbCANCiAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiA2cHQ7IG1z by1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC41aW4iPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+PG86cD4m bmJzcDs8L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxlPSJN QVJHSU46IDBpbiAwaW4gNnB0OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9wczog bGlzdCAuNWluIj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6 ICdDb3VyaWVyIE5ldyciPkEgc2ltaWxhciBvYmplY3QgDQogIGRlZmluaXRpb24gaXMgcmVxdWly ZWQgZm9yOjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICBz dHlsZT0iTUFSR0lOOiAwaW4gMGluIDZwdDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWIt c3RvcHM6IGxpc3QgLjVpbiI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQt RkFNSUxZOiAnQ291cmllciBOZXcnIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQogIDxQ IGNsYXNzPU1zb05vcm1hbCANCiAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiA2cHQ7IG1zby1saXN0 OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC41aW4iPjxTUEFOIA0KICBzdHlsZT0i Rk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+cGt0Y1NpZ0RldlRv bmVTZWNvbmRUb25lU2Vjb25kYXJ5QXR0cmlidXRlPG86cD48L286cD48L1NQQU4+PC9QPg0KICA8 UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gNnB0OyBtc28tbGlz dDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlzdCAuNWluIj48U1BBTiANCiAgc3R5bGU9 IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPnBrdGNTaWdEZXZU b25lVGhpcmRUb25lU2Vjb25kYXJ5QXR0cmlidXRlPG86cD48L286cD48L1NQQU4+PC9QPg0KICA8 UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gNnB0OyBtc28tbGlz dDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlzdCAuNWluIj48U1BBTiANCiAgc3R5bGU9 IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPnBrdGNTaWdEZXZU b25lRm91cnRoVG9uZVNlY29uZGFyeUF0dHJpYnV0ZTxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAg PFAgY2xhc3M9TXNvTm9ybWFsIA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDZwdDsgbXNvLWxp c3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PFNQQU4gDQogIHN0eWxl PSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj5wa3RjU2lnRGV2 VG9uZUZpZnRoVG9uZVNlY29uZGFyeUF0dHJpYnV0ZTxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAg PFAgY2xhc3M9TXNvTm9ybWFsIA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDZwdDsgbXNvLWxp c3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PFNQQU4gDQogIHN0eWxl PSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj48bzpwPiZuYnNw OzwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCANCiAgc3R5bGU9Ik1BUkdJ TjogMGluIDBpbiA2cHQ7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0 IC41aW4iPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogJ0Nv dXJpZXIgTmV3JyI+cGt0Y1NpZ0RldlRvbmVGaXJzdFRvbmVSZXBlYXRDb3VudDxTUEFOIA0KICBz dHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9T UEFOPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICBzdHls ZT0iTUFSR0lOOiAwaW4gMGluIDZwdDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3Rv cHM6IGxpc3QgLjVpbiI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFN SUxZOiAnQ291cmllciBOZXcnIj48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9TUEFOPlNZTlRBWDxTUEFOIA0KICBzdHlsZT0ibXNv LXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+VW5zaWduZWQz MiANCiAgKDAuLjUwMDApPG86cD48L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3Jt YWwgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gNnB0OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxm bzE7IHRhYi1zdG9wczogbGlzdCAuNWluIj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJw dDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNl cnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+TUFYLUFDQ0VTUyANCiAg cmVhZC13cml0ZTxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIA0K ICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDZwdDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0 YWItc3RvcHM6IGxpc3QgLjVpbiI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZP TlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjog eWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9TUEFOPlNUQVRVUzxTUEFOIA0KICBzdHls ZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9TUEFO PmN1cnJlbnQ8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCANCiAg c3R5bGU9Ik1BUkdJTjogMGluIDBpbiA2cHQ7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFi LXN0b3BzOiBsaXN0IC41aW4iPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05U LUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHll cyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+REVTQ1JJUFRJT048bzpwPjwv bzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCANCiAgc3R5bGU9Ik1BUkdJTjog MGluIDBpbiA2cHQ7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC41 aW4iPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogJ0NvdXJp ZXIgTmV3JyI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDwvU1BBTj4iVGhlIHJlcGVhdCBjb3VudCANCiAgd2hpY2ggaW5kaWNhdGVz IHRoZSBudW1iZXIgb2YgdGltZXM8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1z b05vcm1hbCANCiAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiA2cHQ7IG1zby1saXN0OiBsMCBsZXZl bDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC41aW4iPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpF OiAxMnB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+PFNQQU4gDQogIHN0eWxlPSJtc28t c3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BBTj48U1BBTiANCiAg c3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDs8L1NQQU4+dG8gcmVwZWF0IHRoZSBwa3Rj U2lnRGV2VG9uZUZpcnN0VG9uZU9uIA0KICBhbmQ8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQ IGNsYXNzPVJGQ1RleHQgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0OyBtc28tbGlzdDog bDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlzdCAuNWluIj48Rk9OVCANCiAgc2l6ZT0zPjxG T05UIGZhY2U9IkNvdXJpZXIgTmV3Ij48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVz Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIDwvU1BBTj5wa3RjU2lnRGV2VG9u ZUZpcnN0VG9uZU9mZiBjYWRlbmNlIGN5Y2xlLiANCiAgU2V0dGluZzxvOnA+PC9vOnA+PC9GT05U PjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPVJGQ1RleHQgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAw aW4gMHB0OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlzdCAuNWluIj48 Rk9OVCANCiAgc2l6ZT0zPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij48U1BBTiANCiAgc3R5bGU9 Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9TUEFO PnRoaXMgb2JqZWN0IA0KICBtYXkgcmVzdWx0IGluIGEgdG9uZSBkdXJhdGlvbiBsb25nZXIgb3I8 bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1SRkNUZXh0IA0KICBzdHls ZT0iTUFSR0lOOiAwaW4gMGluIDBwdDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3Rv cHM6IGxpc3QgLjVpbiI+PEZPTlQgDQogIHNpemU9Mz48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+ PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDwvU1BBTj48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDs8L1NQ QU4+c2hvcnRlciB0aGFuIHRoZSBvdmVyYWxsIHNpZ25hbCANCiAgZHVyYXRpb24gc3BlY2lmaWVk IGJ5PG86cD48L286cD48L0ZPTlQ+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9UkZDVGV4dCANCiAg c3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQ7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFi LXN0b3BzOiBsaXN0IC41aW4iPjxGT05UIA0KICBzaXplPTM+PEZPTlQgZmFjZT0iQ291cmllciBO ZXciPjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7 PC9TUEFOPnRoZSB0aW1lIG91dCAoVE8pIG9iamVjdCBmb3IgYSANCiAgcGFydGljdWxhciBzaWdu YWwuIElmPG86cD48L286cD48L0ZPTlQ+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9UkZDVGV4dCAN CiAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQ7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsg dGFiLXN0b3BzOiBsaXN0IC41aW4iPjxGT05UIA0KICBzaXplPTM+PEZPTlQgZmFjZT0iQ291cmll ciBOZXciPjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5i c3A7PC9TUEFOPnRoZSByZXBlYXQgY291bnQgcmVzdWx0cyBpbiBhIGxvbmdlciANCiAgdG9uZSBk dXJhdGlvbjxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPVJGQ1RleHQg DQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7 IHRhYi1zdG9wczogbGlzdCAuNWluIj48Rk9OVCANCiAgc2l6ZT0zPjxGT05UIGZhY2U9IkNvdXJp ZXIgTmV3Ij48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPC9TUEFOPjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZu YnNwOzwvU1BBTj50aGFuIHRoZSBzaWduYWwgZHVyYXRpb24gc3BlY2lmaWVkIGJ5IA0KICB0aGUg VE8sIHRoZTxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPVJGQ1RleHQg DQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7 IHRhYi1zdG9wczogbGlzdCAuNWluIj48Rk9OVCANCiAgc2l6ZT0zPjxGT05UIGZhY2U9IkNvdXJp ZXIgTmV3Ij48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPC9TUEFOPjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZu YnNwOzwvU1BBTj50b25lIGR1cmF0aW9uIGRlZmluZWQgYnkgdGhlIFRPIG9iamVjdCANCiAgZm9y IGE8bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1SRkNUZXh0IA0KICBz dHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWIt c3RvcHM6IGxpc3QgLjVpbiI+PEZPTlQgDQogIHNpemU9Mz48Rk9OVCBmYWNlPSJDb3VyaWVyIE5l dyI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDwvU1BBTj48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDs8 L1NQQU4+cGFydGljdWxhciBzaWduYWwgYWx3YXlzIHJlcHJlc2VudHMgdGhlIA0KICBvdmVyYWxs PG86cD48L286cD48L0ZPTlQ+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9UkZDVGV4dCANCiAgc3R5 bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQ7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0 b3BzOiBsaXN0IC41aW4iPjxGT05UIA0KICBzaXplPTM+PEZPTlQgZmFjZT0iQ291cmllciBOZXci PjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7PC9T UEFOPnNpZ25hbCBkdXJhdGlvbiBmb3IgYSB0b25lLiBJbiB0aGlzIA0KICBjYXNlLCB0aGUgdG9u ZTxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPVJGQ1RleHQgDQogIHN0 eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1z dG9wczogbGlzdCAuNWluIj48Rk9OVCANCiAgc2l6ZT0zPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3 Ij48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgPC9TUEFOPjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOzwv U1BBTj5kdXJhdGlvbiByZXBlYXQgY291bnQgd2lsbCBub3QgYmUgZnVsbHkgDQogIGV4ZXJjaXNl ZCBhbmQ8bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1SRkNUZXh0IA0K ICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0 YWItc3RvcHM6IGxpc3QgLjVpbiI+PEZPTlQgDQogIHNpemU9Mz48Rk9OVCBmYWNlPSJDb3VyaWVy IE5ldyI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDwvU1BBTj50aGUgZGVzaXJlZCANCiAgdG9uZSBkdXJhdGlvbiB3aWxs IGJlIHRydW5jYXRlZCBwZXIgdGhlPG86cD48L286cD48L0ZPTlQ+PC9GT05UPjwvUD4NCiAgPFAg Y2xhc3M9UkZDVGV4dCANCiAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQ7IG1zby1saXN0OiBs MCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC41aW4iPjxGT05UIA0KICBzaXplPTM+PEZP TlQgZmFjZT0iQ291cmllciBOZXciPjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJtc28tc3Bh Y2VydW46IHllcyI+Jm5ic3A7PC9TUEFOPlRPIHNldHRpbmcuIElmIHRoZSByZXBlYXQgY291bnQg cmVzdWx0cyANCiAgaW4gYSBzaG9ydGVyPG86cD48L286cD48L0ZPTlQ+PC9GT05UPjwvUD4NCiAg PFAgY2xhc3M9UkZDVGV4dCANCiAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQ7IG1zby1saXN0 OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC41aW4iPjxGT05UIA0KICBzaXplPTM+ PEZPTlQgZmFjZT0iQ291cmllciBOZXciPjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5 ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJtc28t c3BhY2VydW46IHllcyI+Jm5ic3A7PC9TUEFOPnRvbmUgZHVyYXRpb24gdGhhbiB0aGUgc2lnbmFs IGR1cmF0aW9uIA0KICBzcGVjaWZpZWQgYnk8bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9QPg0K ICA8UCBjbGFzcz1SRkNUZXh0IA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdDsgbXNvLWxp c3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PEZPTlQgDQogIHNpemU9 Mz48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46 IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BBTj48U1BBTiANCiAgc3R5bGU9Im1z by1zcGFjZXJ1bjogeWVzIj4mbmJzcDs8L1NQQU4+dGhlIFRPLCB0aGUgdG9uZSBkdXJhdGlvbiBk ZWZpbmVkIGJ5IA0KICB0aGUgcmVwZWF0IGNvdW50PG86cD48L286cD48L0ZPTlQ+PC9GT05UPjwv UD4NCiAgPFAgY2xhc3M9UkZDVGV4dCANCiAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQ7IG1z by1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC41aW4iPjxGT05UIA0KICBz aXplPTM+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNl cnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+PFNQQU4gDQogIHN0eWxl PSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7PC9TUEFOPnRha2VzIHByZWNlZGVuY2Ugb3ZlciB0 aGUgVE8gYW5kIHdpbGwgDQogIGVuZCB0aGUgc2lnbmFsPG86cD48L286cD48L0ZPTlQ+PC9GT05U PjwvUD4NCiAgPFAgY2xhc3M9UkZDVGV4dCANCiAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQ7 IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC41aW4iPjxGT05UIA0K ICBzaXplPTM+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPjxTUEFOIA0KICBzdHlsZT0ibXNvLXNw YWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+PFNQQU4gDQogIHN0 eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7PC9TUEFOPmV2ZW50LiBJbiB0aGlzIGNhc2Us IHRoZSBUTyByZXByZXNlbnRzIA0KICBhIHRpbWUgbm90IHRvPG86cD48L286cD48L0ZPTlQ+PC9G T05UPjwvUD4NCiAgPFAgY2xhc3M9UkZDVGV4dCANCiAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAw cHQ7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC41aW4iPjxGT05U IA0KICBzaXplPTM+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPjxTUEFOIA0KICBzdHlsZT0ibXNv LXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+PFNQQU4gDQog IHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7PC9TUEFOPmJlIGV4Y2VlZGVkIGZvciB0 aGUgc2lnbmFsLiBJdCBpcyANCiAgcmVjb21tZW5kZWQgdG88bzpwPjwvbzpwPjwvRk9OVD48L0ZP TlQ+PC9QPg0KICA8UCBjbGFzcz1SRkNUZXh0IA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBw dDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PEZPTlQg DQogIHNpemU9Mz48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+PFNQQU4gDQogIHN0eWxlPSJtc28t c3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BBTj48U1BBTiANCiAg c3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDs8L1NQQU4+ZW5zdXJlIHByb3BlciB0ZWxl cGhvbnkgc2lnbmFsaW5nIHRoYXQgDQogIHRoZSBUTzxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48 L1A+DQogIDxQIGNsYXNzPVJGQ1RleHQgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0OyBt c28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlzdCAuNWluIj48Rk9OVCANCiAg c2l6ZT0zPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij48U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVu OiB5ZXMiPiZuYnNwOyZuYnNwOyANCiAgPC9TUEFOPjxTUEFOIHN0eWxlPSJtc28tc3BhY2VydW46 IHllcyI+Jm5ic3A7PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZu YnNwOyZuYnNwOzwvU1BBTj5kdXJhdGlvbiBzZXR0aW5nIHNob3VsZCBhbHdheXMgYmUgDQogIGxv bmdlciB0aGFuIHRoZTxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPVJG Q1RleHQgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0OyBtc28tbGlzdDogbDAgbGV2ZWwx IGxmbzE7IHRhYi1zdG9wczogMGluIC42aW4gLjlpbiAxLjJpbiAxLjVpbiAxLjhpbiAyLjFpbiAy LjRpbiAyLjdpbiAzLjBpbiAzLjNpbiAzLjZpbiAzLjlpbiA0LjJpbiA0LjVpbiA0LjhpbiA1LjFp biA1LjRpbiA1LjdpbiA2LjBpbiA2LjNpbiA2LjZpbiA2LjlpbiI+PEZPTlQgDQogIHNpemU9Mz48 Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+PFNQQU4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4m bmJzcDsgDQogIDwvU1BBTj48U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzwvU1BBTj5kZXNpcmVkIA0KICByZXBlYXQgY291bnQgdGltZSBkdXJh dGlvbi4gQSB2YWx1ZSBvZiB6ZXJvPG86cD48L286cD48L0ZPTlQ+PC9GT05UPjwvUD4NCiAgPFAg Y2xhc3M9UkZDVGV4dCANCiAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQ7IG1zby1saXN0OiBs MCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiAwaW4gLjZpbiAuOWluIDEuMmluIDEuNWluIDEuOGlu IDIuMWluIDIuNGluIDIuN2luIDMuMGluIDMuM2luIDMuNmluIDMuOWluIDQuMmluIDQuNWluIDQu OGluIDUuMWluIDUuNGluIDUuN2luIDYuMGluIDYuM2luIDYuNmluIDYuOWluIj48Rk9OVCANCiAg c2l6ZT0zPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFj ZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9TUEFOPm1lYW5zIHRo ZSB0b25lIA0KICBzZXF1ZW5jZSBpcyB0byBiZSBwbGF5ZWQgb25jZSBidXQgbm90PG86cD48L286 cD48L0ZPTlQ+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9UkZDVGV4dCANCiAgc3R5bGU9Ik1BUkdJ TjogMGluIDBpbiAwcHQ7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiAwaW4g LjZpbiAuOWluIDEuMmluIDEuNWluIDEuOGluIDIuMWluIDIuNGluIDIuN2luIDMuMGluIDMuM2lu IDMuNmluIDMuOWluIDQuMmluIDQuNWluIDQuOGluIDUuMWluIDUuNGluIDUuN2luIDYuMGluIDYu M2luIDYuNmluIDYuOWluIj48Rk9OVCANCiAgc2l6ZT0zPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3 Ij48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgDQogIDwvU1BBTj5yZXBlYXRlZC4iPG86cD48L286cD48L0ZPTlQ+PC9GT05U PjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDZw dDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PFNQQU4g DQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj48 U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgDQogIDwvU1BBTj46Oj17cGt0Y1NpZ0RldlRvbmVFbnRyeSB4fTxvOnA+PC9vOnA+PC9TUEFO PjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDZw dDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PFNQQU4g DQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj48 bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCANCiAgc3R5 bGU9Ik1BUkdJTjogMGluIDBpbiA2cHQ7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0 b3BzOiBsaXN0IC41aW4iPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZB TUlMWTogJ0NvdXJpZXIgTmV3JyI+QSBzaW1pbGFyIG9iamVjdCANCiAgZGVmaW5pdGlvbiBpcyBy ZXF1aXJlZCBmb3I6PG86cD48L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwg DQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gNnB0OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7 IHRhYi1zdG9wczogbGlzdCAuNWluIj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsg Rk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4N CiAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDZwdDsgbXNv LWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PFNQQU4gDQogIHN0 eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj5wa3RjU2ln RGV2VG9uZVNlY29uZFRvbmVSZXBlYXRDb3VudDxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVu OiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9TUEFOPjxvOnA+PC9vOnA+PC9T UEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGlu IDZwdDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjVpbiI+PFNQ QU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcn Ij5wa3RjU2lnRGV2VG9uZVRoaXJkVG9uZVJlcGVhdENvdW50PFNQQU4gDQogIHN0eWxlPSJtc28t c3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+ PG86cD48L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxlPSJN QVJHSU46IDBpbiAwaW4gNnB0OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9wczog bGlzdCAuNWluIj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6 ICdDb3VyaWVyIE5ldyciPnBrdGNTaWdEZXZUb25lRm91cnRoVG9uZVJlcGVhdENvdW50PFNQQU4g DQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0K ICA8L1NQQU4+PG86cD48L286cD48L1NQQU4+PC9QPg0KICA8RElWIGNsYXNzPU1zb05vcm1hbCAN CiAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiA2cHQ7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsg dGFiLXN0b3BzOiBsaXN0IC41aW4iPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBG T05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IFBNaW5n TGlVOyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBFTi1V UzsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj5wa3RjU2lnRGV2VG9uZUZpZnRoVG9uZVJlcGVh dENvdW50IA0KICA8L1NQQU4+PC9ESVY+DQogIDxESVYgY2xhc3M9TXNvTm9ybWFsIA0KICBzdHls ZT0iTUFSR0lOOiAwaW4gMGluIDZwdDsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3Rv cHM6IGxpc3QgLjVpbiI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFN SUxZOiAnQ291cmllciBOZXcnOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogUE1pbmdMaVU7IG1z by1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEVOLVVTOyBtc28t YmlkaS1sYW5ndWFnZTogQVItU0EiPjxTUEFOIA0KICBjbGFzcz05OTQyNjU3MTctMTIxMTIwMDQ+ DQogIDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDZwdCI+PEZPTlQg c2l6ZT0yPjxGT05UIA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjwvRk9OVD48L0ZPTlQ+Jm5i c3A7PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4g MHB0OyBtc28tbGF5b3V0LWdyaWQtYWxpZ246IG5vbmUiPjxTUEFOIA0KICBzdHlsZT0ibXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nIj48Rk9OVCANCiAgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48Rk9OVCBzaXplPTI+VGhlIGZvbGxvd2luZyBvYmplY3RzIHNob3VsZCBi ZSZuYnNwOzxTUEFOIA0KICBjbGFzcz05OTQyNjU3MTctMTIxMTIwMDQ+ZGVsZXRlZDwvU1BBTj4u IFRoZXkgYXJlIG5vIGxvbmdlciBhcHBsaWNhYmxlIGluIGxpZXUgDQogIG9mIHRoZSBhYm92ZSBj aGFuZ2VzLjxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1N c29Ob3JtYWwgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0OyBtc28tbGF5b3V0LWdyaWQt YWxpZ246IG5vbmUiPjxTUEFOIA0KICBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nIj48bzpwPjxGT05UIA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNp emU9Mj4mbmJzcDs8L0ZPTlQ+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9UkZDVGV4dCBz dHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAwLjNpbiI+cGt0Y1NpZ0RldlRvbmVGcmVxVHlwZTxT UEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQ QU4+T0JKRUNULVRZUEUgDQo8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9UkZDVGV4dCBzdHls ZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAwLjNpbiI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2Vy dW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BBTj5TWU5UQVg8U1BBTiANCiAgc3R5bGU9 Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9TUEFO PklOVEVHRVIgeyANCiAgPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPVJGQ1RleHQgc3R5bGU9 Ik1BUkdJTjogMGluIDBpbiAwcHQgMC4zaW4iPjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVu OiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9TUEFOPmFsbEZy ZXF1ZW5jaWVzICgxKSwgPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPVJGQ1RleHQgc3R5bGU9 Ik1BUkdJTjogMGluIDBpbiAwcHQgMC4zaW4iPjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVu OiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9TUEFOPnNpbmds ZUZyZXF1ZW5jeVNlcXVlbmNlICgyKSwgPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPVJGQ1Rl eHQgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQgMC4zaW4iPjxTUEFOIA0KICBzdHlsZT0ibXNv LXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9T UEFOPmR1YWxGcmVxdWVuY3lTZXF1ZW5jZSAoMyksIDxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFz cz1SRkNUZXh0IHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0IDAuM2luIj48U1BBTiANCiAgc3R5 bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg DQogIDwvU1BBTj5hbGxGcmVxdWVuY2llc01vZHVsYXRlZCAoNCkgPG86cD48L286cD48L1A+DQog IDxQIGNsYXNzPVJGQ1RleHQgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQgMC4zaW4iPjxTUEFO IA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+ fSA8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9UkZDVGV4dCBzdHlsZT0iTUFSR0lOOiAwaW4g MGluIDBwdCAwLjNpbiI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDwvU1BBTj5NQVgtQUNDRVNTPFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2Vy dW46IHllcyI+Jm5ic3A7Jm5ic3A7IDwvU1BBTj5yZWFkLXdyaXRlIDxvOnA+PC9vOnA+PC9QPg0K ICA8UCBjbGFzcz1SRkNUZXh0IHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0IDAuM2luIj48U1BB TiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsgPC9TUEFO PlNUQVRVUzxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+Y3VycmVudCANCiAgPG86cD48L286cD48L1A+ DQogIDxQIGNsYXNzPVJGQ1RleHQgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQgMC4zaW4iPjxT UEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQ QU4+REVTQ1JJUFRJT04gDQo8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9UkZDVGV4dCBzdHls ZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAwLjNpbiI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2Vy dW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8 L1NQQU4+IlRoaXMgb2JqZWN0IGRlc2NyaWJlcyBob3cgdGhlIGZyZXF1ZW5jaWVzIGFyZSBhcHBs aWVkLiA8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9UkZDVGV4dCBzdHlsZT0iTUFSR0lOOiAw aW4gMGluIDBwdCAwLjNpbiI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+ YWxsRnJlcXVlbmNpZXMgaW5kaWNhdGVzIGFsbCBmcmVxdWVuY2llcyBzcGVjaWZlZCBieTxvOnA+ PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1SRkNUZXh0IHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0 IDAuM2luIj48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIDwvU1BBTj5wa3RjU2lnRGV2 VG9uZU51bUZyZXF1ZW5jaWVzIGFyZSBtaXhlZCB0byBmb3JtIGEgc2luZ2xlPG86cD48L286cD48 L1A+DQogIDxQIGNsYXNzPVJGQ1RleHQgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQgMC4zaW4i PjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9TUEFOPnRvbmUuIFRoZSB0b25lIGlz IHRoZW4gYXBwbGllZCBpbiBzZXF1ZW5jZSB1c2luZyB0aGU8bzpwPjwvbzpwPjwvUD4NCiAgPFAg Y2xhc3M9UkZDVGV4dCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAwLjNpbiI+PFNQQU4gDQog IHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+bnVtYmVyIG9mIG9uL29mZiB0aW1lcyBzcGVj aWZpZWQgaW48bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9UkZDVGV4dCBzdHlsZT0iTUFSR0lO OiAwaW4gMGluIDBwdCAwLjNpbiI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQ QU4+cGt0Y1NpZ0RldlRvbmVOdW1Pbk9mZlRpbWVzLiBTaW5nbGVGcmVxdWVjeVNlcXVlbmNlPG86 cD48L286cD48L1A+DQogIDxQIGNsYXNzPVJGQ1RleHQgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAw cHQgMC4zaW4iPjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9TUEFOPmluZGljYXRl cyBhbGwgZnJlcXVlbmNpZXMgc3BlY2lmaWVkIGJ5PG86cD48L286cD48L1A+DQogIDxQIGNsYXNz PVJGQ1RleHQgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQgMC4zaW4iPjxTUEFOIA0KICBzdHls ZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyANCiAgPC9TUEFOPnBrdGNTaWdEZXZUb25lTnVtRnJlcXVlbmNpZXMgYXJl IGFwcGxpZWQgaW4gc2VxdWVuY2U8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9UkZDVGV4dCBz dHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAwLjNpbiI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3Bh Y2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IA0KICA8L1NQQU4+dXNpbmcgdGhlIGNvcnJlc3BvbmRpbmcgZnJlcXVlbmN5IG51bWJlciBv bi9vZmYgdGltZTxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1SRkNUZXh0IHN0eWxlPSJNQVJH SU46IDBpbiAwaW4gMHB0IDAuM2luIj48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVz Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIDwv U1BBTj4oZS5nLiwgcGt0Y1NpZ0RldlRvbmVGaXJzdEZyZXF1ZW5jeSB1c2VzPG86cD48L286cD48 L1A+DQogIDxQIGNsYXNzPVJGQ1RleHQgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQgMC4zaW4i PjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9TUEFOPnBrdGNTaWdEZXZUb25lRmly c3RUb25lT24gYW5kIA0KcGt0Y1NpZ0RldlRvbmVGaXJzdFRvbmVPZmYsPG86cD48L286cD48L1A+ DQogIDxQIGNsYXNzPVJGQ1RleHQgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQgMC4zaW4iPjxT UEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9TUEFOPnBrdGNTaWdEZXZUb25lU2Vjb25k RnJlcXVlbmN5IHVzZXM8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9UkZDVGV4dCBzdHlsZT0i TUFSR0lOOiAwaW4gMGluIDBwdCAwLjNpbiI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46 IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0K ICA8L1NQQU4+cGt0Y1NpZ0RldlRvbmVTZWNvbmRUb25lT24gYW5kPG86cD48L286cD48L1A+DQog IDxQIGNsYXNzPVJGQ1RleHQgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQgMC4zaW4iPjxTUEFO IA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9TUEFOPnBrdGNTaWdEZXZUb25lU2Vjb25kVG9u ZU9mZikuIEZvciB0aGlzIHRvbmUgdHlwZTxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1SRkNU ZXh0IHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0IDAuM2luIj48U1BBTiANCiAgc3R5bGU9Im1z by1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgDQogIDwvU1BBTj5wa3RjU2lnRGV2VG9uZU51bUZyZXF1ZW5jaWVzIE1VU1QgZXF1 YWw8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9UkZDVGV4dCBzdHlsZT0iTUFSR0lOOiAwaW4g MGluIDBwdCAwLjNpbiI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+cGt0 Y1NpZ0RldlRvbmVOdW1Pbk9mZlRpbWVzLiBEdWFsRnJlcXVlbmN5U2VxdWVuY2U8bzpwPjwvbzpw PjwvUD4NCiAgPFAgY2xhc3M9UkZDVGV4dCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAwLjNp biI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+aW5kaWNhdGVzIHR3byBw YWlycyBvZiBmcmVxdWVuY2llcyBhcmUgYWRkZWQgdG8gZm9ybSB0d288bzpwPjwvbzpwPjwvUD4N CiAgPFAgY2xhc3M9UkZDVGV4dCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAwLjNpbiI+PFNQ QU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+c2VxdWVuY2VkIHRvbmVzLiBUaGUg Zmlyc3QgYW5kIHNlY29uZCBmcmVxdWVuY3kgYXJlIA0KYWRkZWQ8bzpwPjwvbzpwPjwvUD4NCiAg PFAgY2xhc3M9UkZDVGV4dCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAwLjNpbiI+PFNQQU4g DQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+dG8gZm9ybSB0b25lIG9uZSBhbmQgYXJl IGFwcGxpZWQgdXNpbmc8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9UkZDVGV4dCBzdHlsZT0i TUFSR0lOOiAwaW4gMGluIDBwdCAwLjNpbiI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46 IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0K ICA8L1NQQU4+cGt0Y1NpZ0RldlRvbmVGaXJzdFRvbmVPbiBhbmQgDQpwa3RjU2lnRGV2VG9uZUZp cnN0VG9uZU9mZi48bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9UkZDVGV4dCBzdHlsZT0iTUFS R0lOOiAwaW4gMGluIDBwdCAwLjNpbiI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHll cyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8 L1NQQU4+VGhlIHRoaXJkIGFuZCBmb3J0aCBmcmVxdWVuY3kgYXJlIGFkZGVkIHRvIGZvcm0gdG9u ZSB0d288bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9UkZDVGV4dCBzdHlsZT0iTUFSR0lOOiAw aW4gMGluIDBwdCAwLjNpbiI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+ YW5kIGFyZSBhcHBsaWVkIHVzaW5nIHBrdGNTaWdEZXZUb25lU2Vjb25kVG9uZU9uIGFuZDxvOnA+ PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1SRkNUZXh0IHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0 IDAuM2luIj48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIDwvU1BBTj5wa3RjU2lnRGV2 VG9uZVNlY29uZFRvbmVPZmYuIEZvciB0aGlzIHRvbmUgdHlwZTxvOnA+PC9vOnA+PC9QPg0KICA8 UCBjbGFzcz1SRkNUZXh0IHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0IDAuM2luIj48U1BBTiAN CiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIDwvU1BBTj5wa3RjU2lnRGV2VG9uZU51bUZyZXF1ZW5j aWVzIE1VU1QgZXF1YWwgNCBhbmQ8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9UkZDVGV4dCBz dHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAwLjNpbiI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3Bh Y2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IA0KICA8L1NQQU4+cGt0Y1NpZ0RldlRvbmVOdW1Pbk9mZlRpbWVzIE1VU1QgZXF1YWwgMi48 bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9UkZDVGV4dCBzdHlsZT0iTUFSR0lOOiAwaW4gMGlu IDBwdCAwLjNpbiI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+YWxsRnJl cXVlbmNpZXNNb2R1bGF0ZWQgaW5kaWNhdGVzIGFsbCBmcmVxdWVuY2llczxvOnA+PC9vOnA+PC9Q Pg0KICA8UCBjbGFzcz1SRkNUZXh0IHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0IDAuM2luIj48 U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIDwvU1BBTj5zcGVjaWZpZWQgYnkgcGt0Y1Np Z0RldlRvbmVOdW1GcmVxdWVuY2llcyBhcmUgbW9kdWxhdGVkIA0KICB0bzxvOnA+PC9vOnA+PC9Q Pg0KICA8UCBjbGFzcz1SRkNUZXh0IHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0IDAuM2luIj48 U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIDwvU1BBTj5mb3JtIGEgc2luZ2xlIHRvbmUu IFRoZSB0b25lIGlzIHRoZW4gYXBwbGllZCBpbiBzZXF1ZW5jZTxvOnA+PC9vOnA+PC9QPg0KICA8 UCBjbGFzcz1SRkNUZXh0IHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0IDAuM2luIj48U1BBTiAN CiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIDwvU1BBTj51c2luZyB0aGUgbnVtYmVyIG9mIG9uL29m ZiB0aW1lcyBzcGVjaWZpZWQgaW48bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9UkZDVGV4dCBz dHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAwLjNpbiI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3Bh Y2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IA0KICA8L1NQQU4+cGt0Y1NpZ0RldlRvbmVOdW1Pbk9mZlRpbWVzLiBGb3IgDQphbGxGcmVx dWVuY2llc01vZHVsYXRlZCw8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9UkZDVGV4dCBzdHls ZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAwLjNpbiI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2Vy dW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IA0KICA8L1NQQU4+dGhlIHBrdGNTaWdEZXZUb25lTnVtRnJlcXVlbmNpZXMgTVVTVCBlcXVhbCAy LCBhbmQgdGhlPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPVJGQ1RleHQgc3R5bGU9Ik1BUkdJ TjogMGluIDBpbiAwcHQgMC4zaW4iPjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9T UEFOPmZyZXF1ZW5jeSBpbiBwa3RjU2lnRGV2VG9uZUZpcnN0RnJlcXVlbmN5IG1vZHVsYXRlcyB0 aGU8bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9UkZDVGV4dCBzdHlsZT0iTUFSR0lOOiAwaW4g MGluIDBwdCAwLjNpbiI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+ZnJl cXVlbmN5IGluIHBrdGNTaWdEZXZUb25lU2Vjb25kRnJlcXVlbmN5LiI8bzpwPjwvbzpwPjwvUD4N CiAgPFAgY2xhc3M9UkZDVGV4dCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAwLjNpbiI+PFNQ QU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BB Tj5SRUZFUkVOQ0UgPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPVJGQ1RleHQgc3R5bGU9Ik1B UkdJTjogMGluIDBpbiAwcHQgMC4zaW4iPjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5 ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9TUEFO PiJJVFUtVCBFLjE4MCIgPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPVJGQ1RleHQgc3R5bGU9 Ik1BUkdJTjogMGluIDBpbiAwcHQgMC4zaW4iPjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVu OiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+REVGVkFMIHsgYWxsRnJlcXVlbmNpZXMg fSANCiAgPG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPVJGQ1RleHQgc3R5bGU9Ik1BUkdJTjog MGluIDBpbiAwcHQgMC4zaW4iPjxTUEFOIA0KICBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZu YnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+Ojo9eyBwa3RjU2lnRGV2VG9uZUVudHJ5IDMgDQogIH0g PG86cD48L286cD48L1A+DQogIDxQIGNsYXNzPVJGQ1RleHQgc3R5bGU9Ik1BUkdJTjogMGluIDBp biAwcHQgMC4zaW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9QPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1mYXJlYXN0LWZv bnQtZmFtaWx5OiBQTWluZ0xpVTsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFz dC1sYW5ndWFnZTogRU4tVVM7IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+DQogIDxQIGNsYXNz PVJGQ1RleHQgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQgMC4zaW4iPjxGT05UIHNpemU9Mz48 Rk9OVCANCiAgZmFjZT0iQ291cmllciBOZXciPnBrdGNTaWdEZXZUb25lTnVtRnJlcXVlbmNpZXM8 U1BBTiANCiAgc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsgPC9T UEFOPk9CSkVDVC1UWVBFIA0KICA8bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9QPg0KICA8UCBj bGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0OyBtc28tbGF5b3V0 LWdyaWQtYWxpZ246IG5vbmUiPjxTUEFOIA0KICBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQogIDxQ IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDZwdCI+PFNQQU4gDQogIHN0 eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj48bzpwPjwv bzpwPjwvU1BBTj48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJ TjogMGluIDBpbiA2cHQiPjxGT05UIHNpemU9Mj48Rk9OVCANCiAgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj5FeGFtcGxlIDEgLSBNb2R1bGF0ZWQvVW5tb2R1bGF0ZWQgDQogIFRvbmU6PG86cD48L286 cD48L0ZPTlQ+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46 IDBpbiAwaW4gNnB0Ij48Rk9OVCBzaXplPTI+PEZPTlQgDQogIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+PC9GT05UPjwvRk9OVD4mbmJzcDs8L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0i TUFSR0lOOiAwaW4gMGluIDZwdCI+PEZPTlQgc2l6ZT0yPjxGT05UIA0KICBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPkphcGFuIGNhbGwgd2FpdGluZyB0b25lIHdpdGggdGhlIGZvbGxvd2luZyBkZWZp bml0aW9uIA0KICBwZXIgSVRVLVQgRS4xODA6PG86cD48L286cD48L0ZPTlQ+PC9GT05UPjwvUD4N CiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gNnB0Ij48Rk9OVCBz aXplPTI+PEZPTlQgDQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ZjEgbW9kIGYyLCB3aGVyZSBm MT00MDAgSHogQU0gbW9kdWxhdGVkIGJ5IDE2IEh6LCANCiAgZjI9NDAwIEh6IG5vdCBBTSBtb2R1 bGF0ZWQ8bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9Ik1BUkdJTjogMGluIDBpbiA2cHQiPjxGT05UIHNpemU9Mj48Rk9OVCANCiAgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj5jYWRlbmNlOjxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1A+DQog IDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDZwdCI+PEZPTlQgc2l6 ZT0yPjxGT05UIA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPmZpcnN0IHRvbmU6IDUwMG1zIE9O IHRoZW4gMCB0byA0MDBtcyANCiAgT0ZGPG86cD48L286cD48L0ZPTlQ+PC9GT05UPjwvUD4NCiAg PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gNnB0Ij48Rk9OVCBzaXpl PTI+PEZPTlQgDQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+c2Vjb25kIHRvbmU6IDUwbXMgT04g dGhlbiA0NTBtcyANCiAgT0ZGPG86cD48L286cD48L0ZPTlQ+PC9GT05UPjwvUD4NCiAgPFAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gNnB0Ij48Rk9OVCBzaXplPTI+PEZP TlQgDQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+dGhpcmQgdG9uZTogNTBtcyBPTiB0aGVuIDM0 NTBtcyANCiAgT0ZGPG86cD48L286cD48L0ZPTlQ+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gNnB0Ij48Rk9OVCBzaXplPTI+PEZPTlQgDQog IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Zm91cnRoIHRvbmU6IDUwbXMgT04gdGhlbiA0NTBtcyAN CiAgT0ZGPG86cD48L286cD48L0ZPTlQ+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gNnB0Ij48Rk9OVCBzaXplPTI+PEZPTlQgDQogIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+ZmlmdGggdG9uZTogNTBtcyBPTiB0aGVuIDM0NTAgbXMgDQogIE9G RjxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0iTUFSR0lOOiAwaW4gMGluIDZwdCI+PEZPTlQgc2l6ZT0yPjxGT05UIA0KICBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPm5vdCByZXBlYXRlZCwgbm90IGNvbnRpbnVvdXM8L0ZPTlQ+PC9GT05UPjwv UD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gNnB0Ij48Rk9O VCBzaXplPTI+PEZPTlQgDQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PC9GT05UPjwvRk9OVD4m bmJzcDs8L1A+PEZPTlQgc2l6ZT0rMD48Rk9OVCANCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4N CiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gNnB0Ij48Rk9OVCBz aXplPTI+RXhhbXBsZSAyIC0gDQogIEVtYmVkZGVkIENhZGVuY2U8U1BBTiBjbGFzcz05OTQyNjU3 MTctMTIxMTIwMDQ+OjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9Ik1BUkdJTjogMGluIDBpbiA2cHQiPjxGT05UIHNpemU9Mj48U1BBTiANCiAgY2xhc3M9OTk0 MjY1NzE3LTEyMTEyMDA0PjwvU1BBTj48U1BBTiANCiAgc3R5bGU9Im1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJyI+VGhpcyBleGFtcGxlIG9mIGFuIGVtYmVkZGVkIA0K ICBjYWRlbmNlIGlzIGJhc2VkIG9uIGFuIG9wZXJhdG9yIHZhcmlhdGlvbiBvZiBhIG5hdGlvbmFs IHN0YW5kYXJkLiBBIHNpbWlsYXIgDQogIGV4YW1wbGUgb2YgYW4gZW1iZWRkZWQgY2FkZW5jZSBj YW4gYmUgZm91bmQgaW4gPC9TUEFOPklUVS1UIHN1cHBsZW1lbnQgMiANCiAgKEUuMTgwKSBmb3Ig DQogIDxzdDE6Y291bnRyeS1yZWdpb24+PHN0MTpwbGFjZT5Sb21hbmlhPC9zdDE6cGxhY2U+PC9z dDE6Y291bnRyeS1yZWdpb24+LjxTUEFOIA0KICBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nIj48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8 UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0OyBtc28tbGF5 b3V0LWdyaWQtYWxpZ246IG5vbmUiPjxTUEFOIA0KICBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nIj48bzpwPjxGT05UIA0KICBzaXplPTI+Jm5ic3A7PC9G T05UPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCANCiAgc3R5bGU9Ik1B UkdJTjogMGluIDBpbiAwcHQ7IG1zby1sYXlvdXQtZ3JpZC1hbGlnbjogbm9uZSI+PFNQQU4gDQog IHN0eWxlPSJtc28tZmFyZWFzdC1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbiciPjxGT05U IHNpemU9Mj5GcmVxdWVuY3k6IA0KICA0MjVIejxvOnA+PC9vOnA+PC9GT05UPjwvU1BBTj48L1A+ DQogIDxQIGNsYXNzPU1zb05vcm1hbCANCiAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQ7IG1z by1sYXlvdXQtZ3JpZC1hbGlnbjogbm9uZSI+PFNQQU4gDQogIHN0eWxlPSJtc28tZmFyZWFzdC1m b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbiciPjxGT05UIA0KICBzaXplPTI+Q2FkZW5jZTo8 bzpwPjwvbzpwPjwvRk9OVD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0 eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0OyBtc28tbGF5b3V0LWdyaWQtYWxpZ246IG5vbmUiPjxT UEFOIA0KICBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n Ij48Rk9OVCBzaXplPTI+LSAxKSANCiAgdG9uOjEwMDBtc2VjLCB0b2ZmOiA0MG1zZWM8bzpwPjwv bzpwPjwvRk9OVD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxlPSJN QVJHSU46IDBpbiAwaW4gMHB0OyBtc28tbGF5b3V0LWdyaWQtYWxpZ246IG5vbmUiPjxTUEFOIA0K ICBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nIj48Rk9O VCBzaXplPTI+LSAyKSA5IHNlYyANCiAgcmVwZWF0IG9mICh0b246IDQwbWVzYywgdG9mZjogNDBt c2VjKTxvOnA+PC9vOnA+PC9GT05UPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCAN CiAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQ7IG1zby1sYXlvdXQtZ3JpZC1hbGlnbjogbm9u ZSI+PFNQQU4gDQogIHN0eWxlPSJtc28tZmFyZWFzdC1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbiciPjxGT05UIHNpemU9Mj4tIDMpIHRvbjogDQogIGNvbnRpbnVvdXM8bzpwPjwvbzpwPjwv Rk9OVD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGlu IDBpbiA2cHQiPjxvOnA+PEZPTlQgDQogIHNpemU9Mj48L0ZPTlQ+PC9vOnA+Jm5ic3A7PC9QPjxv OnA+DQogIDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDZwdCI+PEZP TlQgc2l6ZT0yPkV4YW1wbGUgMyAtIA0KICBFbWJlZGRlZCBDYWRlbmNlPFNQQU4gDQogIHN0eWxl PSJtc28tZmFyZWFzdC1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbiciPjo8bzpwPjwvbzpw PjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxlPSJNQVJH SU46IDBpbiAwaW4gMHB0OyBtc28tbGF5b3V0LWdyaWQtYWxpZ246IG5vbmUiPjxTUEFOIA0KICBz dHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nIj48Rk9OVCBz aXplPTI+VGhpcyBleGFtcGxlIA0KICBvZiBhbiBlbWJlZGRlZCBjYWRlbmNlIGlzIGJhc2VkIG9u IGFuIG9wZXJhdG9yIHZhcmlhdGlvbiBvZiBhIG5hdGlvbmFsIA0KICBzdGFuZGFyZC48bzpwPjwv bzpwPjwvRk9OVD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxlPSJN QVJHSU46IDBpbiAwaW4gMHB0OyBtc28tbGF5b3V0LWdyaWQtYWxpZ246IG5vbmUiPjxTUEFOIA0K ICBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nIj48bzpw PjxGT05UIA0KICBzaXplPTI+Jm5ic3A7PC9GT05UPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNs YXNzPU1zb05vcm1hbCANCiAgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQ7IG1zby1sYXlvdXQt Z3JpZC1hbGlnbjogbm9uZSI+PFNQQU4gDQogIHN0eWxlPSJtc28tZmFyZWFzdC1mb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbiciPjxGT05UIHNpemU9Mj5GcmVxdWVuY3k6IA0KICA0MjVIejxv OnA+PC9vOnA+PC9GT05UPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCANCiAgc3R5 bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQ7IG1zby1sYXlvdXQtZ3JpZC1hbGlnbjogbm9uZSI+PFNQ QU4gDQogIHN0eWxlPSJtc28tZmFyZWFzdC1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbici PjxGT05UIA0KICBzaXplPTI+Q2FkZW5jZTo8bzpwPjwvbzpwPjwvRk9OVD48L1NQQU4+PC9QPg0K ICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0OyBtc28t bGF5b3V0LWdyaWQtYWxpZ246IG5vbmUiPjxTUEFOIA0KICBzdHlsZT0ibXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nIj48Rk9OVCBzaXplPTI+LSAxKSB0b246IA0KICAx NjBtc2VjLCB0b2ZmOiA0MG1zZWM8bzpwPjwvbzpwPjwvRk9OVD48L1NQQU4+PC9QPg0KICA8UCBj bGFzcz1Nc29Ob3JtYWwgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0OyBtc28tbGF5b3V0 LWdyaWQtYWxpZ246IG5vbmUiPjxTUEFOIA0KICBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nIj48Rk9OVCBzaXplPTI+LSAyKSA3KiAodG9uOiANCiAgNDBt c2VjLCB0b2ZmOiA0MG1zZWMpPG86cD48L286cD48L0ZPTlQ+PC9TUEFOPjwvUD4NCiAgPFAgY2xh c3M9TXNvTm9ybWFsIA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdDsgbXNvLWxheW91dC1n cmlkLWFsaWduOiBub25lIj48U1BBTiANCiAgc3R5bGU9Im1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJyI+PEZPTlQgc2l6ZT0yPi0gMykgdG9uOiANCiAgMTYwbXNlYywg dG9mZiA0MG1zZWM8bzpwPjwvbzpwPjwvRk9OVD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29O b3JtYWwgDQogIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0OyBtc28tbGF5b3V0LWdyaWQtYWxp Z246IG5vbmUiPjxTUEFOIA0KICBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nIj48Rk9OVCBzaXplPTI+LSA0KSA3KiAodG9uOiANCiAgNDBtc2VjLCB0b2Zm OiA0MG1zZWMpPG86cD48L286cD48L0ZPTlQ+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9y bWFsIA0KICBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdDsgbXNvLWxheW91dC1ncmlkLWFsaWdu OiBub25lIj48U1BBTiANCiAgc3R5bGU9Im1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJyI+PEZPTlQgc2l6ZT0yPi0gNSkgdG9uOiANCiAgMTYwbXNlYywgdG9mZiA0MG1z ZWM8bzpwPjwvbzpwPjwvRk9OVD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgDQog IHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0OyBtc28tbGF5b3V0LWdyaWQtYWxpZ246IG5vbmUi PjxTUEFOIA0KICBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nIj48Rk9OVCBzaXplPTI+LSA2KSA3KiAodG9uOiANCiAgNDBtc2VjLCB0b2ZmOiA0MG1zZWMp PG86cD48L286cD48L0ZPTlQ+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSJNQVJHSU46IDBpbiAwaW4gNnB0Ij48Rk9OVCBmYWNlPUFyaWFsIA0KICBjb2xvcj0jMDAwMGZm PjwvRk9OVD48L286cD48L0ZPTlQ+PC9GT05UPiZuYnNwOzwvUD48L1NQQU4+PC9TUEFOPjwvU1BB Tj48L286cD48L0ZPTlQ+PC9ESVY+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= ------_=_NextPart_001_01C4F342.C5F586D0-- --===============1048304465== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============1048304465==-- From ipcdn-bounces@ietf.org Thu Jan 6 12:34:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26482 for ; Thu, 6 Jan 2005 12:34:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmbjf-0005FY-Pd for ipcdn-archive@ietf.org; Thu, 06 Jan 2005 12:47:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmbVc-00083d-Fb; Thu, 06 Jan 2005 12:33:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmbNy-0005Hz-Er for ipcdn@megatron.ietf.org; Thu, 06 Jan 2005 12:25:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25671 for ; Thu, 6 Jan 2005 12:25:19 -0500 (EST) From: andre.lejeune@Terayon.com Received: from mail.terayon.com ([63.201.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmbak-0004q9-0I for ipcdn@ietf.org; Thu, 06 Jan 2005 12:38:37 -0500 Received: from scbh01.terayon.com (scbh01.bh.terayon.com [192.168.0.23]) by mail.terayon.com (8.12.11/8.12.11) with ESMTP id j06HTvME026910; Thu, 6 Jan 2005 09:29:57 -0800 (envelope-from andre.lejeune@Terayon.com) Received: by scbh01.terayon.com with Internet Mail Service (5.5.2657.72) id ; Thu, 6 Jan 2005 09:25:08 -0800 Message-ID: To: bwijnen@lucent.com, foko@c-cor.net, jf.mule@cablelabs.com Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2 Date: Thu, 6 Jan 2005 09:24:04 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2005.1.5.42 X-Spam-Score: 0.3 (/) X-Scan-Signature: c3f828922b5ae9a0fa296d4bd5b66d71 Cc: gnakanishi@motorola.com, e.cardona@cablelabs.com, ipcdn@ietf.org, docsis-oss@cablelabs.com X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1574128356==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 12866e56e287fcb9ed724727fee710b4 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1574128356== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4F414.857BBCBE" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4F414.857BBCBE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bert, The main problem is that CableLabs require CM and CMTS vendors to = submit their equipment for a very expensive certification process using draft = MIBs as pre-requisites into these certification waves (CW) and we, the = vendors who have to pay for this certification process have very little = influence into these decisions. If these MIBs were not required until they become = RFC, then we would all be happy, except for the fact that the Cable industry wants to move faster than the time it takes to properly go through the = RFC approval processes, which is a valid desire. Those who purchase the CM = and CMTS equipment (the MSOs) will not purchase equipment that has not been previously certified by CableLabs. I concur with Fred here on most of his points. Re-rooting any of the = MIBs is a very expensive process as it costs 100s of thousands of dollars for = every vendor as they require to implement and test the change and go through certification with the changes. Multiply this by the number of vendors = and a simple re-rooting change can cost a million. Then looking into all = support equipment that depends on these MIBs and more money and efforts get = wasted. I won't argue that MIBs that were defined against the experimental root = can be re-rooted. I wish someone could find a way to avoid such re-rooting = in the future. This is the case for the Subscriber Management MIB. However, I don't agree that any of the other drafts need to be moved = from where they were assigned in the past, even if the assignment was not = done following approved processes. The draft docsBpi2MIB was placed by someone under mib-2 transmission docsIfMIB and that was the right place for it. It is a MIB that needs = to be maintained per interface, similarly to other MIBs found under the transmission tree. That person assigned the ID 6 to it, assuming it = would be the next one to be adopted. It would not serve anyone if it was placed anywhere else. The draft Event Notification MIB was placed by someone under mib-2 = docsDev and assigned the ID 2 to it. I also think this was an appropriate place = for such MIB and don't see a need to move it anywhere else. The draft Qos MIB was placed under mib-2 transmission docsIfMIB and I = also think that was an appropriate place for it, as it also needs to be maintained per interface. The person assigned ID 7 to it as it was the = next available ID. We hope that this assignment will continue to be used for = the RFC. Maybe the solution to all this is to let the the IANA assign the = numbers to wherever they want, but define requirements in the DOCSIS OSSI spec to re-root each of these RFCs to where they were first allocated. This is = ugly in terms of documentation, but it matches the reality of having two = standard bodies trying to define the same things, each with their own valid = reasons. Andr=E9 -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Thursday, January 06, 2005 6:42 AM To: Fred Oko; Jean-Francois Mule; andre.lejeune@terayon.com Cc: gnakanishi@motorola.com; Eduardo Cardona; ipcdn@ietf.org; DOCSIS = OSS Majordomo List Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB = Modules O ID assignmen ts: Assigning new RFCs under mib-2 Inline > -----Original Message----- > From: ipcdn-bounces@ietf.org=20 > [mailto:ipcdn-bounces@ietf.org]On Behalf Of > Fred Oko > Sent: Thursday, January 06, 2005 04:26 > To: Jean-Francois Mule; andre.lejeune@terayon.com > Cc: gnakanishi@motorola.com; Eduardo Cardona; ipcdn@ietf.org;=20 > DOCSIS OSS Majordomo List > Subject: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules = OID > assignmen ts: Assigning new RFCs under mib-2 >=20 >=20 > I would agree that a MIB for which the author had the=20 > foresight to root in the experimental(3) branch would be=20 > expected (both by MIB consumers and IETF) to be re-rooted for=20 > RFC transition. However, this only applies to the=20 > subscriber-mgmt MIB. I would argue that there is no value,=20 > only negative operational implications, and no impervious=20 > mandate for re-rooting any other MIB that has already seen=20 > widespread implementation and consumption. I would argue this=20 > not only for the QOS MIB, but for any draft MIB for which=20 > originally had a sub-docsIfMib or enterprise root that was=20 > mandated to be supported in any already passed CableLabs=20 > certification wave. The reasoning is that since these objects=20 > were implemented by CM/CMTS vendor and qualified, they have=20 > most certainly been also implemented against by existing OSS=20 > software, wherein lies definite operational impact of such a=20 > major change. >=20 I think the above shows where we have a BASIC problem (and we discussed this in the past as well).=20 When trying to standardize a MIB document in the IETF, then there = should be NO assumptions on where the module gets rooted. That will ONLY be = known=20 once the document has been approved by the IESG. After that approval, = it is=20 IANA who assigns the OID.=20 And that is exactly one of the reasons why we do not like that WGs = start assigning MIB modules underneath some OID branch for that = WG/technology. The reason for not wanting such early assignments (other than = experimental) is that the MIB module may change (dramatically even) during the = process in the IETF WG, IETF Last Call, MIB Doctor review, IESG review. And so if anyone implemented the MIB module based on some random revision of an Internte-Draft then that module (with assigned OID) might be completely different than the one that finally gets approved (same OID if you = followed your logic). And so that WILL result in INTEROPERABILITY problems in = the market place. See also draft-ietf-ops-mib-review-guidelines-03.txt sections 4.3 and = 4.5 > Impact points of any re-root: > 1) common to any change: CMTS and CM vendor must change code,=20 > CL must update ATP etc for qualifications, vendors must=20 > re-qualify code, and MSO's must deploy new code (granted=20 > required just for other MIB updates if not re-root) While a MIB is under development in the IETF, no one should be assuming that such a MIB module is final and so no-one should be using a pre-assigned OID for the MIB module. If anything, one could use experimental (need to request an assignment though; also see warnings about that in mib review guidleines) or your own (vendor = specific OID tree. Make sure you UNDERSTAND that the names (OIDs) should not=20 conflict with any future final OID for the MIB once approved. > 2) a decision must be made whether a CMTS or CM is=20 > backward-compatible (either as mandated by CL or discretion=20 > of vendor as advised by MSOs) and supporting two instance of=20 > a MIB has implications -- and regardless the decision of=20 > backward-compatibility on a single device, any OSS that=20 > monitors across a non-homogeneous field will of course have=20 > chance to run into new and old instances If one follows MIB guidelines/rules (and you MUST follow those to get a = MIB module or an update to a MIB module approved in IETF), then these guidelines/rules (and associated MIB doctor review in IETF) will = guarantee backward compatibility. If such needs to be compromised, then it would = only happen with serious and explicit agreement of the WG and otehr IETF = review (for example when everyone agrees that there was a BUG in an earlier = module) > a) multiple OIDs for same subidentifiers must be known=20 > by clients which may have preference to use non-fully-qualified > b) if back-compat, collection must limit itself to one=20 > of the two instances to avoid double collection thus=20 > requiring conditional logic based on probing > c) I would expect any MSO with utilities that are=20 > broken by such a re-root will demand this "bug" be fixed by=20 > the vendor thus forcing effective back-compat > d) it may be difficult for some SNMP agent=20 > implementations to support efficient backward-compatability=20 > (i.e. two OIDs mapping to same in-memory data) as such=20 > efficiency would be a must for some of the expensive MIB tables > 3) Since CL CW have continued to require very old drafts we=20 > know that implementation against the "old"/only OIDs have=20 > been in use for a while >=20 Not sure I understand all points a-b.=20 What is an MSO? What is CL CW? > No real impact points of not re-rooting anything -- simplest path: > 1) current OID assignments, while not actually assigned by=20 > IANA are guaranteed to be non-conflicting that is good. But, since they only exists in Internet-Drafts, they have not really been assigned!!!! That is the thing to understand!!! PLEASE! > 2) no re-roots have been implemented in any code -- they only=20 > exist in more recent drafts thus nullifying them is only on paper >=20 As explained above, they SHOULD NOT exist in running code!!! This is a real basic approach of how we do Iinternet-Drafts and how and why we assign OIDs AFTER an Internet-Draft has gone through the whole IETF developement and review process and has been APPROVED=20 by the IESG. > Additionally I personally see little value in the any=20 > re-roots beyond philosophical cleanliness. I do agree that=20 > all MIBs may not be semantically perfect below docsIf, but I=20 > take it as the best hierarchical umbrella we have on that=20 > road that has been traveled. If we were forced to re-root I=20 > would advocate at least leveraging hierarchy by contextually=20 > group all CL/IPCDN related objects together instead of having=20 > them assigned loosely and likely non-contiguously into the=20 > mib-2 free space. E.g. in that sense I was a fan of the=20 > enterprise clab root. >=20 I have explained to teh chairs, that a reroot is not MANDATORY. But IF you want to continue to allocate (or keep the current allocations) under docIfMib, then I would URGE you to create a document similar to RFC3737. And in the future, you would NOT let an Internet-Draft have any pre-assigned value, but instead have something aka: ::=3D { docsIfMib xx } -- xx to be assigned by IANA as per -- procedures outlined in = So you (the WG) has basically been mis-using the fact that you had a docIfMib branch and were pre-assigning values against the normal process, and with the risk of having incomp-atible versions of MIB modules in implementations! > The very nature of so many representative MIB-rooting=20 > conventions across the many CL-related MIBs (docsIf,=20 > experimental, mib-2-pending, clab) suggests if this is not=20 > exactly a contentious issue, it is definitely one still open=20 > to the author's discretion which one might tend to agree has=20 > been non-optimal. I also see a variable modification time of=20 > these drafts at some middle revision to change OID roots=20 > which indicates it was not guided by a single firm guiding=20 > consensus (but perhaps MIB doctor advice trickle effect?). I=20 > would advocate that a firm future-guiding decision be made=20 > that would apply to all as-of-yet unwritten MIBs. >=20 Totally agree. And having 4 or 5 potential places to root a new MIB mdoule aka docsIf, experimental, mib-2-pending, clab seems REALLY REALLY bad to me. > Though were these proposed re-roots to make their way=20 > unimpeded into continued-draft/RFC/ECR/cert-wave would a good=20 > time estimate to seeing such in the field be late 2006? >=20 Bert Wijnen, speaking as co-AD for the IETF OPS area. open to a good discussion on this topic and to try and document=20 the correct and agreed way for new and furture MIB dvelopement in this space. Bert NOTICE: This communication contains information which may be = proprietary, privileged or confidential. If you are not the intended recipient (or authorized to receive for the intended recipient), or believe that you = have received this communication in error, please do not print, = copy,retransmit, disseminate, disclose or otherwise use the information. Also, please indicate to the sender that you have received this communication in = error and delete the copy you received. Thank you. ------_=_NextPart_001_01C4F414.857BBCBE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules = O ID assignmen ts: Assigning new RFCs under mib-2

Bert,

The main problem is that CableLabs require CM and = CMTS vendors to submit their equipment for a very expensive = certification process using draft MIBs as pre-requisites into these = certification waves (CW) and we, the vendors who have to pay for this = certification process have very little influence into these decisions. = If these MIBs were not required until they become RFC, then we would = all be happy, except for the fact that the Cable industry wants to move = faster than the time it takes to properly go through the RFC approval = processes, which is a valid desire. Those who purchase the CM and CMTS = equipment (the MSOs) will not purchase equipment that has not been = previously certified by CableLabs.

I concur with Fred here on most of his points. = Re-rooting any of the MIBs is a very expensive process as it costs 100s = of thousands of dollars for every vendor as they require to implement = and test the change and go through certification with the changes. = Multiply this by the number of vendors and a simple re-rooting change = can cost a million. Then looking into all support equipment that = depends on these MIBs and more money and efforts get wasted.

I won't argue that MIBs that were defined against the = experimental root can be re-rooted. I wish someone could find a way to = avoid such re-rooting in the future. This is the case for the = Subscriber Management MIB.

However, I don't agree that any of the other drafts = need to be moved from where they were assigned in the past, even if the = assignment was not done following approved processes.

The draft docsBpi2MIB was placed by someone under = mib-2 transmission docsIfMIB and that was the right place for it. It is = a MIB that needs to be maintained per interface, similarly to other = MIBs found under the transmission tree. That person assigned the ID 6 = to it, assuming it would be the next one to be adopted. It would not = serve anyone if it was placed anywhere else.

The draft Event Notification MIB was placed by = someone under mib-2 docsDev and assigned the ID 2 to it. I also think = this was an appropriate place for such MIB and don't see a need to move = it anywhere else.

The draft Qos MIB was placed under mib-2 transmission = docsIfMIB and I also think that was an appropriate place for it, as it = also needs to be maintained per interface. The person assigned ID 7 to = it as it was the next available ID. We hope that this assignment will = continue to be used for the RFC.

Maybe the solution to all this is to let the the IANA = assign the numbers to wherever they want, but define requirements in = the DOCSIS OSSI spec to re-root each of these RFCs to where they were = first allocated. This is ugly in terms of documentation, but it matches = the reality of having two standard bodies trying to define the same = things, each with their own valid reasons.

Andr=E9


-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=
Sent: Thursday, January 06, 2005 6:42 AM
To: Fred Oko; Jean-Francois Mule; = andre.lejeune@terayon.com
Cc: gnakanishi@motorola.com; Eduardo Cardona; = ipcdn@ietf.org; DOCSIS OSS
Majordomo List
Subject: RE: [ipcdn] RE: IETF IPCDN proposed = standard drafts MIB Modules
O ID assignmen ts: Assigning new RFCs under = mib-2


Inline

> -----Original Message-----
> From: ipcdn-bounces@ietf.org
> [mailto:ipcdn-bounces@ietf.org= ]On Behalf Of
> Fred Oko
> Sent: Thursday, January 06, 2005 04:26
> To: Jean-Francois Mule; = andre.lejeune@terayon.com
> Cc: gnakanishi@motorola.com; Eduardo Cardona; = ipcdn@ietf.org;
>     DOCSIS OSS Majordomo = List
> Subject: [ipcdn] RE: IETF IPCDN proposed = standard drafts MIB Modules OID
> assignmen ts: Assigning new RFCs under = mib-2
>
>
> I would agree that a MIB for which the author = had the
> foresight to root in the experimental(3) branch = would be
> expected (both by MIB consumers and IETF) to be = re-rooted for
> RFC transition. However, this only applies to = the
> subscriber-mgmt MIB. I would argue that there = is no value,
> only negative operational implications, and no = impervious
> mandate for re-rooting any other MIB that has = already seen
> widespread implementation and consumption. I = would argue this
> not only for the QOS MIB, but for any draft MIB = for which
> originally had a sub-docsIfMib or enterprise = root that was
> mandated to be supported in any already passed = CableLabs
> certification wave. The reasoning is that since = these objects
> were implemented by CM/CMTS vendor and = qualified, they have
> most certainly been also implemented against by = existing OSS
> software, wherein lies definite operational = impact of such a
> major change.
>
I think the above shows where we have a BASIC = problem (and we discussed
this in the past as well).

When trying to standardize a MIB document in the = IETF, then there should
be NO assumptions on where the module gets rooted. = That will ONLY be known
once the document has been approved by the IESG. = After that approval, it is
IANA who assigns the OID.

And that is exactly one of the reasons why we do not = like that WGs start
assigning MIB modules underneath some OID branch for = that WG/technology.

The reason for not wanting such early assignments = (other than experimental)
is that the MIB module may change (dramatically = even) during the process in
the IETF WG, IETF Last Call, MIB Doctor review, IESG = review. And so if
anyone implemented the MIB module based on some = random revision
of an Internte-Draft then that module (with assigned = OID) might be completely
different than the one that finally gets approved = (same OID if you followed
your logic). And so that WILL result in = INTEROPERABILITY problems in the
market place.

See also draft-ietf-ops-mib-review-guidelines-03.txt = sections 4.3 and 4.5


> Impact points of any re-root:
> 1) common to any change: CMTS and CM vendor = must change code,
> CL must update ATP etc for qualifications, = vendors must
> re-qualify code, and MSO's must deploy new code = (granted
> required just for other MIB updates if not = re-root)

While a MIB is under development in the IETF, no one = should be assuming
that such a MIB module is final and so no-one should = be using a
pre-assigned OID for the MIB module. If anything, = one could
use experimental (need to request an assignment = though; also see
warnings about that in mib review guidleines) or = your own (vendor specific
OID tree. Make sure you UNDERSTAND that the names = (OIDs) should not
conflict with any future final OID for the MIB once = approved.

> 2) a decision must be made whether a CMTS or CM = is
> backward-compatible (either as mandated by CL = or discretion
> of vendor as advised by MSOs) and supporting = two instance of
> a MIB has implications -- and regardless the = decision of
> backward-compatibility on a single device, any = OSS that
> monitors across a non-homogeneous field will of = course have
> chance to run into new and old instances

If one follows MIB guidelines/rules (and you MUST = follow those to get a
MIB module or an update to a MIB module approved in = IETF), then these
guidelines/rules (and associated MIB doctor review = in IETF) will guarantee
backward compatibility. If such needs to be = compromised, then it would only
happen with serious and explicit agreement of the WG = and otehr IETF review
(for example when everyone agrees that there was a = BUG in an earlier module)

>       a) multiple OIDs = for same subidentifiers must be known
> by clients which may have preference to use = non-fully-qualified
>       b) if = back-compat, collection must limit itself to one
> of the two instances to avoid double collection = thus
> requiring conditional logic based on = probing
>       c) I would = expect any MSO with utilities that are
> broken by such a re-root will demand this = "bug" be fixed by
> the vendor thus forcing effective = back-compat
>       d) it may be = difficult for some SNMP agent
> implementations to support efficient = backward-compatability
> (i.e. two OIDs mapping to same in-memory data) = as such
> efficiency would be a must for some of the = expensive MIB tables
> 3) Since CL CW have continued to require very = old drafts we
> know that implementation against the = "old"/only OIDs have
> been in use for a while
>
Not sure I understand all points a-b.
What is an MSO?
What is CL CW?

> No real impact points of not re-rooting anything = -- simplest path:
> 1) current OID assignments, while not actually = assigned by
> IANA are guaranteed to be = non-conflicting

that is good.
But, since they only exists in Internet-Drafts, they = have not really
been assigned!!!! That is the thing to understand!!! = PLEASE!

> 2) no re-roots have been implemented in any code = -- they only
> exist in more recent drafts thus nullifying = them is only on paper
>
As explained above, they SHOULD NOT exist in running = code!!!
This is a real basic approach of how we do = Iinternet-Drafts and how
and why we assign OIDs AFTER an Internet-Draft has = gone through
the whole IETF developement and review process and = has been APPROVED
by the IESG.

> Additionally I personally see little value in = the any
> re-roots beyond philosophical cleanliness. I do = agree that
> all MIBs may not be semantically perfect below = docsIf, but I
> take it as the best hierarchical umbrella we = have on that
> road that has been traveled. If we were forced = to re-root I
> would advocate at least leveraging hierarchy by = contextually
> group all CL/IPCDN related objects together = instead of having
> them assigned loosely and likely = non-contiguously into the
> mib-2 free space. E.g. in that sense I was a = fan of the
> enterprise clab root.
>

I have explained to teh chairs, that a reroot is not = MANDATORY.
But IF you want to continue to allocate (or keep the = current
allocations) under docIfMib, then I would URGE you = to create
a document similar to RFC3737.

And in the future, you would NOT let an = Internet-Draft have any
pre-assigned value, but instead have something = aka:

   ::=3D { docsIfMib xx } -- xx to be = assigned by IANA as per
          &nb= sp;           &nb= sp; -- procedures outlined in <your-rfc3737-equivalent>

So you (the WG) has basically been mis-using the fact = that you
had a docIfMib branch and were pre-assigning values = against the
normal process, and with the risk of having = incomp-atible versions
of MIB modules in implementations!

> The very nature of so many representative = MIB-rooting
> conventions across the many CL-related MIBs = (docsIf,
> experimental, mib-2-pending, clab) suggests if = this is not
> exactly a contentious issue, it is definitely = one still open
> to the author's discretion which one might tend = to agree has
> been non-optimal. I also see a variable = modification time of
> these drafts at some middle revision to change = OID roots
> which indicates it was not guided by a single = firm guiding
> consensus (but perhaps MIB doctor advice = trickle effect?). I
> would advocate that a firm future-guiding = decision be made
> that would apply to all as-of-yet unwritten = MIBs.
>
Totally agree. And having 4 or 5 potential places to = root a
new MIB mdoule aka
  docsIf, experimental, mib-2-pending, = clab
seems REALLY REALLY bad to me.

> Though were these proposed re-roots to make = their way
> unimpeded into = continued-draft/RFC/ECR/cert-wave would a good
> time estimate to seeing such in the field be = late 2006?
>

Bert Wijnen,
speaking as co-AD for the IETF OPS area.
open to a good discussion on this topic and to try = and document
the correct and agreed way for new and furture MIB = dvelopement
in this space.

Bert
NOTICE: This communication contains information = which may be proprietary, privileged or confidential. If you are not = the intended recipient (or authorized to receive for the intended = recipient), or believe that you have received this communication in = error, please do not print, copy,retransmit, disseminate, disclose or = otherwise use the information. Also, please indicate to the sender that = you have received this communication in error and delete the copy you = received. Thank you.

------_=_NextPart_001_01C4F414.857BBCBE-- --===============1574128356== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============1574128356==-- From ipcdn-bounces@ietf.org Thu Jan 6 13:41:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00457 for ; Thu, 6 Jan 2005 13:41:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmcmo-0007iM-Ij for ipcdn-archive@ietf.org; Thu, 06 Jan 2005 13:55:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmcWh-0001vI-5F; Thu, 06 Jan 2005 13:38:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmcMP-0007Wm-Vb for ipcdn@megatron.ietf.org; Thu, 06 Jan 2005 13:27:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29594 for ; Thu, 6 Jan 2005 13:27:48 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmcZE-00071B-4V for ipcdn@ietf.org; Thu, 06 Jan 2005 13:41:05 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j06IR81e002876; Thu, 6 Jan 2005 11:27:09 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Jan 2005 11:27:08 -0700 Message-ID: Thread-Topic: IETF IPCDN proposed standard drafts MIB Modules OID assignmen ts: Assigning new RFCs under mib-2 Thread-Index: AcTzUaddqE3Ia/N7Q9+N1USBeX79RAAAGBKQAAkl2wAAB83tEAAhN8JA From: "Jean-Francois Mule" To: "Fred Oko" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable Cc: gnakanishi@motorola.com, Eduardo Cardona , ipcdn@ietf.org, Dan Rice , DOCSIS OSS Majordomo List Subject: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules OID assignmen ts: Assigning new RFCs under mib-2 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: quoted-printable Fred, =20 Let me be direct: your email is totally inappropriate, and actually, = misplaced. First, you responded to an email sent by Eduardo Cardona to the sole = DOCSIS OSS reflector and copy the public IETF IPCDN reflector: you are = effectively breaking the IPR policy your company signed. Worse, you = included comments sent by Andr=E9, comments that were solely sent in = response to the DOCSIS OSS email Eduardo had sent). This is = inappropriate. Note that Eduardo and I wanted to ping the CableLabs = DOCSIS OSS vendor team first by respect of the work those vendors have = done for the MIBs and continue to do by bringing implementations to = market - most of those vendors have implemented the DOCSIS MIBs we are = talking about and not all unfortunately are watching the IPCDN traffic. Second, you missed the point of my email, the email I sent to the IETF = IPCDN reflector. Note that in total transparence for the IETF process, = we (Eduardo and myself) did communicate the same points to both the = CableLabs DOCSIS OSS and IETF IPCDN reflectors. We asked internally the = DOCSIS OSS team first as the MIB module in question was designed and = evolved thanks to all the original contributions of the individuals and = vendors part of the DOCSIS OSS team. But in the end (and that is the = purpose on my email), the IETF IPCDN wg prevails and the IETF wg = consensus is the one that matters. Jean-Francois. =20 > -----Original Message----- > From: Fred Oko [mailto:foko@c-cor.net]=20 > Sent: Wednesday, January 05, 2005 8:26 PM > To: Jean-Francois Mule; andre.lejeune@terayon.com > Cc: gnakanishi@motorola.com; Eduardo Cardona; DOCSIS OSS=20 > Majordomo List; ipcdn@ietf.org > Subject: RE: IETF IPCDN proposed standard drafts MIB Modules=20 > OID assignmen ts: Assigning new RFCs under mib-2 >=20 >=20 > I would agree that a MIB for which the author had the=20 > foresight to root in the experimental(3) branch would be=20 > expected (both by MIB consumers and IETF) to be re-rooted for=20 > RFC transition. However, this only applies to the=20 > subscriber-mgmt MIB. I would argue that there is no value,=20 > only negative operational implications, and no impervious=20 > mandate for re-rooting any other MIB that has already seen=20 > widespread implementation and consumption. I would argue this=20 > not only for the QOS MIB, but for any draft MIB for which=20 > originally had a sub-docsIfMib or enterprise root that was=20 > mandated to be supported in any already passed CableLabs=20 > certification wave. The reasoning is that since these objects=20 > were implemented by CM/CMTS vendor and qualified, they have=20 > most certainly been also implemented against by existing OSS=20 > software, wherein lies definite operational impact of such a=20 > major change. >=20 > Impact points of any re-root: > 1) common to any change: CMTS and CM vendor must change code,=20 > CL must update ATP etc for qualifications, vendors must=20 > re-qualify code, and MSO's must deploy new code (granted=20 > required just for other MIB updates if not re-root) > 2) a decision must be made whether a CMTS or CM is=20 > backward-compatible (either as mandated by CL or discretion=20 > of vendor as advised by MSOs) and supporting two instance of=20 > a MIB has implications -- and regardless the decision of=20 > backward-compatibility on a single device, any OSS that=20 > monitors across a non-homogeneous field will of course have=20 > chance to run into new and old instances > a) multiple OIDs for same subidentifiers must be known=20 > by clients which may have preference to use non-fully-qualified > b) if back-compat, collection must limit itself to one=20 > of the two instances to avoid double collection thus=20 > requiring conditional logic based on probing > c) I would expect any MSO with utilities that are=20 > broken by such a re-root will demand this "bug" be fixed by=20 > the vendor thus forcing effective back-compat > d) it may be difficult for some SNMP agent=20 > implementations to support efficient backward-compatability=20 > (i.e. two OIDs mapping to same in-memory data) as such=20 > efficiency would be a must for some of the expensive MIB tables > 3) Since CL CW have continued to require very old drafts we=20 > know that implementation against the "old"/only OIDs have=20 > been in use for a while >=20 > No real impact points of not re-rooting anything -- simplest path: > 1) current OID assignments, while not actually assigned by=20 > IANA are guaranteed to be non-conflicting > 2) no re-roots have been implemented in any code -- they only=20 > exist in more recent drafts thus nullifying them is only on paper >=20 > Additionally I personally see little value in the any=20 > re-roots beyond philosophical cleanliness. I do agree that=20 > all MIBs may not be semantically perfect below docsIf, but I=20 > take it as the best hierarchical umbrella we have on that=20 > road that has been traveled. If we were forced to re-root I=20 > would advocate at least leveraging hierarchy by contextually=20 > group all CL/IPCDN related objects together instead of having=20 > them assigned loosely and likely non-contiguously into the=20 > mib-2 free space. E.g. in that sense I was a fan of the=20 > enterprise clab root. >=20 > The very nature of so many representative MIB-rooting=20 > conventions across the many CL-related MIBs (docsIf,=20 > experimental, mib-2-pending, clab) suggests if this is not=20 > exactly a contentious issue, it is definitely one still open=20 > to the author's discretion which one might tend to agree has=20 > been non-optimal. I also see a variable modification time of=20 > these drafts at some middle revision to change OID roots=20 > which indicates it was not guided by a single firm guiding=20 > consensus (but perhaps MIB doctor advice trickle effect?). I=20 > would advocate that a firm future-guiding decision be made=20 > that would apply to all as-of-yet unwritten MIBs. >=20 > Though were these proposed re-roots to make their way=20 > unimpeded into continued-draft/RFC/ECR/cert-wave would a good=20 > time estimate to seeing such in the field be late 2006? _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Jan 6 14:07:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02800 for ; Thu, 6 Jan 2005 14:07:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmdBj-0001oV-JR for ipcdn-archive@ietf.org; Thu, 06 Jan 2005 14:20:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmcwH-000156-Cm; Thu, 06 Jan 2005 14:04:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmcjh-0005uj-CE for ipcdn@megatron.ietf.org; Thu, 06 Jan 2005 13:51:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01662 for ; Thu, 6 Jan 2005 13:51:52 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmcwV-0008CQ-Qc for ipcdn@ietf.org; Thu, 06 Jan 2005 14:05:09 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j06IpIvB011842 for ; Thu, 6 Jan 2005 12:51:18 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 6 Jan 2005 19:51:17 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155061B699C@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: andre.lejeune@Terayon.com, foko@c-cor.net, jf.mule@cablelabs.com Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2 Date: Thu, 6 Jan 2005 19:51:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.6 (/) X-Scan-Signature: d2b4898a2beddf410d6e76902566f557 Cc: gnakanishi@motorola.com, e.cardona@cablelabs.com, ipcdn@ietf.org, docsis-oss@cablelabs.com X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0472057810==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 3d9377227c64d8007f9382a92e11ad5d This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0472057810== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4F420.B299AFA6" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4F420.B299AFA6 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by ihemail1.lucent.com id j06IpIvB011842 Content-Transfer-Encoding: quoted-printable Andre, =20 It sounds like we have a SERIOUS MISMATCH between CL and IETF. If CL wants to define their own stuff and mandate implementations BEFORE = IETF approves a MIB document, then that is fine... but then one should not come to IETF= and try to get IETF approval. It just does not work that way. =20 And even if you do these sort of things just within CL, even then I do se= e that you guys can easily run into interoperability problems. We are not doing this just for= the fun of it, but because there are serious risks for inetroperability problems! =20 AGAIN, as I said before. if you want to root under docsIfMIb, fine. Write= a doc similar to=20 RFC3737 and we can do it. Not that we (IETF MIB Doctors) prefer it that w= ay, but we/you (IPCDN WG) can do it that way. =20 It would still mean that you can only get the branch assigned underneath = docsIfMib AFTER IESG approval. That comes back to possible interoperability issues if you= assign it earlier. =20 Bert -----Original Message----- From: andre.lejeune@Terayon.com [mailto:andre.lejeune@Terayon.com] Sent: Thursday, January 06, 2005 18:24 To: bwijnen@lucent.com; foko@c-cor.net; jf.mule@cablelabs.com Cc: gnakanishi@motorola.com; e.cardona@cablelabs.com; ipcdn@ietf.org; doc= sis-oss@cablelabs.com Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules = O ID assignmen ts: Assigning new RFCs under mib-2 Bert,=20 The main problem is that CableLabs require CM and CMTS vendors to submit = their equipment for a very expensive certification process using draft MI= Bs as pre-requisites into these certification waves (CW) and we, the vend= ors who have to pay for this certification process have very little influ= ence into these decisions. If these MIBs were not required until they bec= ome RFC, then we would all be happy, except for the fact that the Cable i= ndustry wants to move faster than the time it takes to properly go throug= h the RFC approval processes, which is a valid desire. Those who purchase= the CM and CMTS equipment (the MSOs) will not purchase equipment that ha= s not been previously certified by CableLabs. I concur with Fred here on most of his points. Re-rooting any of the MIBs= is a very expensive process as it costs 100s of thousands of dollars for= every vendor as they require to implement and test the change and go thr= ough certification with the changes. Multiply this by the number of vendo= rs and a simple re-rooting change can cost a million. Then looking into a= ll support equipment that depends on these MIBs and more money and effort= s get wasted. I won't argue that MIBs that were defined against the experimental root c= an be re-rooted. I wish someone could find a way to avoid such re-rooting= in the future. This is the case for the Subscriber Management MIB. However, I don't agree that any of the other drafts need to be moved from= where they were assigned in the past, even if the assignment was not don= e following approved processes. The draft docsBpi2MIB was placed by someone under mib-2 transmission docs= IfMIB and that was the right place for it. It is a MIB that needs to be m= aintained per interface, similarly to other MIBs found under the transmis= sion tree. That person assigned the ID 6 to it, assuming it would be the = next one to be adopted. It would not serve anyone if it was placed anywhe= re else. The draft Event Notification MIB was placed by someone under mib-2 docsDe= v and assigned the ID 2 to it. I also think this was an appropriate place= for such MIB and don't see a need to move it anywhere else. The draft Qos MIB was placed under mib-2 transmission docsIfMIB and I als= o think that was an appropriate place for it, as it also needs to be main= tained per interface. The person assigned ID 7 to it as it was the next a= vailable ID. We hope that this assignment will continue to be used for th= e RFC. Maybe the solution to all this is to let the the IANA assign the numbers = to wherever they want, but define requirements in the DOCSIS OSSI spec to= re-root each of these RFCs to where they were first allocated. This is u= gly in terms of documentation, but it matches the reality of having two s= tandard bodies trying to define the same things, each with their own vali= d reasons. Andr=E9=20 -----Original Message-----=20 From: Wijnen, Bert (Bert) [ mailto:bwijnen@lucent.com ]=20 Sent: Thursday, January 06, 2005 6:42 AM=20 To: Fred Oko; Jean-Francois Mule; andre.lejeune@terayon.com=20 Cc: gnakanishi@motorola.com; Eduardo Cardona; ipcdn@ietf.org; DOCSIS OSS=20 Majordomo List=20 Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules=20 O ID assignmen ts: Assigning new RFCs under mib-2=20 Inline=20 > -----Original Message-----=20 > From: ipcdn-bounces@ietf.org=20 > [ mailto:ipcdn-bounces@ietf.org ]On Beh= alf Of=20 > Fred Oko=20 > Sent: Thursday, January 06, 2005 04:26=20 > To: Jean-Francois Mule; andre.lejeune@terayon.com=20 > Cc: gnakanishi@motorola.com; Eduardo Cardona; ipcdn@ietf.org;=20 > DOCSIS OSS Majordomo List=20 > Subject: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules OI= D=20 > assignmen ts: Assigning new RFCs under mib-2=20 >=20 >=20 > I would agree that a MIB for which the author had the=20 > foresight to root in the experimental(3) branch would be=20 > expected (both by MIB consumers and IETF) to be re-rooted for=20 > RFC transition. However, this only applies to the=20 > subscriber-mgmt MIB. I would argue that there is no value,=20 > only negative operational implications, and no impervious=20 > mandate for re-rooting any other MIB that has already seen=20 > widespread implementation and consumption. I would argue this=20 > not only for the QOS MIB, but for any draft MIB for which=20 > originally had a sub-docsIfMib or enterprise root that was=20 > mandated to be supported in any already passed CableLabs=20 > certification wave. The reasoning is that since these objects=20 > were implemented by CM/CMTS vendor and qualified, they have=20 > most certainly been also implemented against by existing OSS=20 > software, wherein lies definite operational impact of such a=20 > major change.=20 >=20 I think the above shows where we have a BASIC problem (and we discussed=20 this in the past as well).=20 When trying to standardize a MIB document in the IETF, then there should=20 be NO assumptions on where the module gets rooted. That will ONLY be know= n=20 once the document has been approved by the IESG. After that approval, it = is=20 IANA who assigns the OID.=20 And that is exactly one of the reasons why we do not like that WGs start=20 assigning MIB modules underneath some OID branch for that WG/technology.=20 The reason for not wanting such early assignments (other than experimenta= l)=20 is that the MIB module may change (dramatically even) during the process = in=20 the IETF WG, IETF Last Call, MIB Doctor review, IESG review. And so if=20 anyone implemented the MIB module based on some random revision=20 of an Internte-Draft then that module (with assigned OID) might be comple= tely=20 different than the one that finally gets approved (same OID if you follow= ed=20 your logic). And so that WILL result in INTEROPERABILITY problems in the=20 market place.=20 See also draft-ietf-ops-mib-review-guidelines-03.txt sections 4.3 and 4.5= =20 > Impact points of any re-root:=20 > 1) common to any change: CMTS and CM vendor must change code,=20 > CL must update ATP etc for qualifications, vendors must=20 > re-qualify code, and MSO's must deploy new code (granted=20 > required just for other MIB updates if not re-root)=20 While a MIB is under development in the IETF, no one should be assuming=20 that such a MIB module is final and so no-one should be using a=20 pre-assigned OID for the MIB module. If anything, one could=20 use experimental (need to request an assignment though; also see=20 warnings about that in mib review guidleines) or your own (vendor specifi= c=20 OID tree. Make sure you UNDERSTAND that the names (OIDs) should not=20 conflict with any future final OID for the MIB once approved.=20 > 2) a decision must be made whether a CMTS or CM is=20 > backward-compatible (either as mandated by CL or discretion=20 > of vendor as advised by MSOs) and supporting two instance of=20 > a MIB has implications -- and regardless the decision of=20 > backward-compatibility on a single device, any OSS that=20 > monitors across a non-homogeneous field will of course have=20 > chance to run into new and old instances=20 If one follows MIB guidelines/rules (and you MUST follow those to get a=20 MIB module or an update to a MIB module approved in IETF), then these=20 guidelines/rules (and associated MIB doctor review in IETF) will guarante= e=20 backward compatibility. If such needs to be compromised, then it would on= ly=20 happen with serious and explicit agreement of the WG and otehr IETF revie= w=20 (for example when everyone agrees that there was a BUG in an earlier modu= le)=20 > a) multiple OIDs for same subidentifiers must be known=20 > by clients which may have preference to use non-fully-qualified=20 > b) if back-compat, collection must limit itself to one=20 > of the two instances to avoid double collection thus=20 > requiring conditional logic based on probing=20 > c) I would expect any MSO with utilities that are=20 > broken by such a re-root will demand this "bug" be fixed by=20 > the vendor thus forcing effective back-compat=20 > d) it may be difficult for some SNMP agent=20 > implementations to support efficient backward-compatability=20 > (i.e. two OIDs mapping to same in-memory data) as such=20 > efficiency would be a must for some of the expensive MIB tables=20 > 3) Since CL CW have continued to require very old drafts we=20 > know that implementation against the "old"/only OIDs have=20 > been in use for a while=20 >=20 Not sure I understand all points a-b.=20 What is an MSO?=20 What is CL CW?=20 > No real impact points of not re-rooting anything -- simplest path:=20 > 1) current OID assignments, while not actually assigned by=20 > IANA are guaranteed to be non-conflicting=20 that is good.=20 But, since they only exists in Internet-Drafts, they have not really=20 been assigned!!!! That is the thing to understand!!! PLEASE!=20 > 2) no re-roots have been implemented in any code -- they only=20 > exist in more recent drafts thus nullifying them is only on paper=20 >=20 As explained above, they SHOULD NOT exist in running code!!!=20 This is a real basic approach of how we do Iinternet-Drafts and how=20 and why we assign OIDs AFTER an Internet-Draft has gone through=20 the whole IETF developement and review process and has been APPROVED=20 by the IESG.=20 > Additionally I personally see little value in the any=20 > re-roots beyond philosophical cleanliness. I do agree that=20 > all MIBs may not be semantically perfect below docsIf, but I=20 > take it as the best hierarchical umbrella we have on that=20 > road that has been traveled. If we were forced to re-root I=20 > would advocate at least leveraging hierarchy by contextually=20 > group all CL/IPCDN related objects together instead of having=20 > them assigned loosely and likely non-contiguously into the=20 > mib-2 free space. E.g. in that sense I was a fan of the=20 > enterprise clab root.=20 >=20 I have explained to teh chairs, that a reroot is not MANDATORY.=20 But IF you want to continue to allocate (or keep the current=20 allocations) under docIfMib, then I would URGE you to create=20 a document similar to RFC3737.=20 And in the future, you would NOT let an Internet-Draft have any=20 pre-assigned value, but instead have something aka:=20 ::=3D { docsIfMib xx } -- xx to be assigned by IANA as per=20 -- procedures outlined in =20 So you (the WG) has basically been mis-using the fact that you=20 had a docIfMib branch and were pre-assigning values against the=20 normal process, and with the risk of having incomp-atible versions=20 of MIB modules in implementations!=20 > The very nature of so many representative MIB-rooting=20 > conventions across the many CL-related MIBs (docsIf,=20 > experimental, mib-2-pending, clab) suggests if this is not=20 > exactly a contentious issue, it is definitely one still open=20 > to the author's discretion which one might tend to agree has=20 > been non-optimal. I also see a variable modification time of=20 > these drafts at some middle revision to change OID roots=20 > which indicates it was not guided by a single firm guiding=20 > consensus (but perhaps MIB doctor advice trickle effect?). I=20 > would advocate that a firm future-guiding decision be made=20 > that would apply to all as-of-yet unwritten MIBs.=20 >=20 Totally agree. And having 4 or 5 potential places to root a=20 new MIB mdoule aka=20 docsIf, experimental, mib-2-pending, clab=20 seems REALLY REALLY bad to me.=20 > Though were these proposed re-roots to make their way=20 > unimpeded into continued-draft/RFC/ECR/cert-wave would a good=20 > time estimate to seeing such in the field be late 2006?=20 >=20 Bert Wijnen,=20 speaking as co-AD for the IETF OPS area.=20 open to a good discussion on this topic and to try and document=20 the correct and agreed way for new and furture MIB dvelopement=20 in this space.=20 Bert=20 NOTICE: This communication contains information which may be proprietary,= privileged or confidential. If you are not the intended recipient (or au= thorized to receive for the intended recipient), or believe that you have= received this communication in error, please do not print, copy,retransm= it, disseminate, disclose or otherwise use the information. Also, please = indicate to the sender that you have received this communication in error= and delete the copy you received. Thank you. ------_=_NextPart_001_01C4F420.B299AFA6 Content-Type: text/html; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by ihemail1.lucent.com id j06IpIvB011842 Content-Transfer-Encoding: quoted-printable RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O = ID assignmen ts: Assigning new RFCs under mib-2
Andre,
 
It=20 sounds like we have a SERIOUS MISMATCH between CL and IETF.=
If CL=20 wants to define their own stuff and mandate implementations BEFORE IETF=20 approves
a MIB=20 document, then that is fine... but then one should not come to IETF and t= ry to=20 get
IETF=20 approval. It just does not work that way.
 
And=20 even if you do these sort of things just within CL, even then I do see th= at you=20 guys can
easily=20 run into interoperability problems. We are not doing this just for the fu= n of=20 it, but because
there=20 are serious risks for inetroperability problems!
 
AGAIN,=20 as I said before. if you want to root under docsIfMIb, fine. Write a doc = similar=20 to
RFC3737 and we can do it. Not that we (IETF MIB Doctors) prefer = it that=20 way, but we/you (IPCDN WG)
can do=20 it that way.
 
It=20 would still mean that you can only get the branch assigned underneat= h=20 docsIfMib AFTER
IESG=20 approval. That comes back to possible interoperability issues if you assi= gn it=20 earlier.
 
Bert
-----Original Message-----
From: andre.lejeune@Teray= on.com=20 [mailto:andre.lejeune@Terayon.com]
Sent: Thursday, January 06= , 2005=20 18:24
To: bwijnen@lucent.com; foko@c-cor.net;=20 jf.mule@cablelabs.com
Cc: gnakanishi@motorola.com;=20 e.cardona@cablelabs.com; ipcdn@ietf.org;=20 docsis-oss@cablelabs.com
Subject: RE: [ipcdn] RE: IETF IPCDN=20 proposed standard drafts MIB Modules O ID assignmen ts: Assigning new R= FCs=20 under mib-2

Bert,

The main problem is that CableLabs require CM and CMT= S vendors=20 to submit their equipment for a very expensive certification process us= ing=20 draft MIBs as pre-requisites into these certification waves (CW) and we= , the=20 vendors who have to pay for this certification process have very little= =20 influence into these decisions. If these MIBs were not required until t= hey=20 become RFC, then we would all be happy, except for the fact that the Ca= ble=20 industry wants to move faster than the time it takes to properly go thr= ough=20 the RFC approval processes, which is a valid desire. Those who purchase= the CM=20 and CMTS equipment (the MSOs) will not purchase equipment that has not = been=20 previously certified by CableLabs.

I concur with Fred here on most of his points. Re-roo= ting any=20 of the MIBs is a very expensive process as it costs 100s of thousands o= f=20 dollars for every vendor as they require to implement and test the chan= ge and=20 go through certification with the changes. Multiply this by the number = of=20 vendors and a simple re-rooting change can cost a million. Then looking= into=20 all support equipment that depends on these MIBs and more money and eff= orts=20 get wasted.

I won't argue that MIBs that were defined against the= =20 experimental root can be re-rooted. I wish someone could find a way to = avoid=20 such re-rooting in the future. This is the case for the Subscriber Mana= gement=20 MIB.

However, I don't agree that any of the other drafts n= eed to be=20 moved from where they were assigned in the past, even if the assignment= was=20 not done following approved processes.

The draft docsBpi2MIB was placed by someone under mib= -2=20 transmission docsIfMIB and that was the right place for it. It is a MIB= that=20 needs to be maintained per interface, similarly to other MIBs found und= er the=20 transmission tree. That person assigned the ID 6 to it, assuming it wou= ld be=20 the next one to be adopted. It would not serve anyone if it was placed=20 anywhere else.

The draft Event Notification MIB was placed by someon= e under=20 mib-2 docsDev and assigned the ID 2 to it. I also think this was an=20 appropriate place for such MIB and don't see a need to move it anywhere= =20 else.

The draft Qos MIB was placed under mib-2 transmission= =20 docsIfMIB and I also think that was an appropriate place for it, as it = also=20 needs to be maintained per interface. The person assigned ID 7 to it as= it was=20 the next available ID. We hope that this assignment will continue to be= used=20 for the RFC.

Maybe the solution to all this is to let the the IANA= assign=20 the numbers to wherever they want, but define requirements in the DOCSI= S OSSI=20 spec to re-root each of these RFCs to where they were first allocated. = This is=20 ugly in terms of documentation, but it matches the reality of having tw= o=20 standard bodies trying to define the same things, each with their own v= alid=20 reasons.

Andr=E9


-----Original Message-----
= From:=20 Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20
Sent: Thursday, January 06, 2005 6:42 AM
= To: Fred Oko; Jean-Francois Mule; andre.lejeune@terayon.com=20
Cc: gnakanishi@motorola.com; Eduardo Cardona; ipcdn@= ietf.org;=20 DOCSIS OSS
Majordomo List
Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts M= IB=20 Modules
O ID assignmen ts: Assigning new RFCs= under=20 mib-2


Inline

> -----Original Message-----
>=20 From: ipcdn-bounces@ietf.org
> [mailto:ipcdn-bounces@ietf.org]On=20 Behalf Of
> Fred Oko
>=20 Sent: Thursday, January 06, 2005 04:26
> T= o:=20 Jean-Francois Mule; andre.lejeune@terayon.com
> Cc:=20 gnakanishi@motorola.com; Eduardo Cardona; ipcdn@ietf.org;
>     DOCSIS OSS Majordomo List =
> Subject: [ipcdn] RE: IETF IPCDN proposed standard drafts = MIB=20 Modules OID
> assignmen ts: Assigning new = RFCs=20 under mib-2
>
&g= t;=20
> I would agree that a MIB for which the a= uthor had=20 the
> foresight to root in the experimenta= l(3)=20 branch would be
> expected (both by MIB co= nsumers=20 and IETF) to be re-rooted for
> RFC transi= tion.=20 However, this only applies to the
> subscr= iber-mgmt=20 MIB. I would argue that there is no value,
&g= t; only=20 negative operational implications, and no impervious
> mandate for re-rooting any other MIB that has already see= n=20
> widespread implementation and consumptio= n. I=20 would argue this
> not only for the QOS MI= B, but=20 for any draft MIB for which
> originally h= ad a=20 sub-docsIfMib or enterprise root that was
>= ;=20 mandated to be supported in any already passed CableLabs
> certification wave. The reasoning is that since these obj= ects=20
> were implemented by CM/CMTS vendor and q= ualified,=20 they have
> most certainly been also imple= mented=20 against by existing OSS
> software, wherei= n lies=20 definite operational impact of such a
> ma= jor=20 change.
>
I thin= k the above=20 shows where we have a BASIC problem (and we discussed
this in the past as well).

When trying to standardize a MIB document in the IETF= , then=20 there should
be NO assumptions on where the m= odule=20 gets rooted. That will ONLY be known
once the= document=20 has been approved by the IESG. After that approval, it is
IANA who assigns the OID.

And that is exactly one of the reasons why we do not = like that=20 WGs start
assigning MIB modules underneath so= me OID=20 branch for that WG/technology.

The reason for not wanting such early assignments (ot= her than=20 experimental)
is that the MIB module may chan= ge=20 (dramatically even) during the process in
the= IETF WG,=20 IETF Last Call, MIB Doctor review, IESG review. And so if
anyone implemented the MIB module based on some random revisio= n=20
of an Internte-Draft then that module (with assigned= OID)=20 might be completely
different than the one th= at=20 finally gets approved (same OID if you followed
your=20 logic). And so that WILL result in INTEROPERABILITY problems in the=20
market place.

See also draft-ietf-ops-mib-review-guidelines-03.txt = sections=20 4.3 and 4.5


> Impact points of any re-root:
> 1) common to any change: CMTS and CM vendor must change c= ode,=20
> CL must update ATP etc for qualification= s,=20 vendors must
> re-qualify code, and MSO's = must=20 deploy new code (granted
> required just f= or other=20 MIB updates if not re-root)

While a MIB is under development in the IETF, no one = should be=20 assuming
that such a MIB module is final and = so no-one=20 should be using a
pre-assigned OID for the MI= B module.=20 If anything, one could
use experimental (need= to=20 request an assignment though; also see
warnin= gs about=20 that in mib review guidleines) or your own (vendor specific
= OID tree. Make sure you UNDERSTAND that the names (OIDs) shoul= d not=20
conflict with any future final OID for the MI= B once=20 approved.

> 2) a decision must be made whether a CMTS or CM = is=20
> backward-compatible (either as mandated = by CL or=20 discretion
> of vendor as advised by MSOs)= and=20 supporting two instance of
> a MIB has imp= lications=20 -- and regardless the decision of
>=20 backward-compatibility on a single device, any OSS that
> monitors across a non-homogeneous field will of course ha= ve=20
> chance to run into new and old instances= =20

If one follows MIB guidelines/rules (and you MUST fol= low those=20 to get a
MIB module or an update to a MIB mod= ule=20 approved in IETF), then these
guidelines/rule= s (and=20 associated MIB doctor review in IETF) will guarantee
backward compatibility. If such needs to be compromised, then = it would=20 only
happen with serious and explicit agreeme= nt of the=20 WG and otehr IETF review
(for example when ev= eryone=20 agrees that there was a BUG in an earlier module)

>       a) multiple OIDs = for same=20 subidentifiers must be known
> by clients = which may=20 have preference to use non-fully-qualified
&g= t;=20       b) if back-compat, collection must limit= itself=20 to one
> of the two instances to avoid dou= ble=20 collection thus
> requiring conditional lo= gic based=20 on probing
>      = ; c) I=20 would expect any MSO with utilities that are
= >=20 broken by such a re-root will demand this "bug" be fixed by
= > the vendor thus forcing effective back-compat
= >       d) it may be difficult for= some=20 SNMP agent
> implementations to support ef= ficient=20 backward-compatability
> (i.e. two OIDs ma= pping to=20 same in-memory data) as such
> efficiency = would be=20 a must for some of the expensive MIB tables
&= gt; 3)=20 Since CL CW have continued to require very old drafts we
> know that implementation against the "old"/only OIDs have= =20
> been in use for a while
>
Not sure I understand all point= s a-b.=20
What is an MSO?
Wha= t is CL=20 CW?

> No real impact points of not re-rooting anything= --=20 simplest path:
> 1) current OID assignment= s, while=20 not actually assigned by
> IANA are guaran= teed to=20 be non-conflicting

that is good.
But, since th= ey only=20 exists in Internet-Drafts, they have not really
been=20 assigned!!!! That is the thing to understand!!! PLEASE!

> 2) no re-roots have been implemented in any code= -- they=20 only
> exist in more recent drafts thus nu= llifying=20 them is only on paper
>
As=20 explained above, they SHOULD NOT exist in running code!!!
This is a real basic approach of how we do Iinternet-Drafts an= d=20 how
and why we assign OIDs AFTER an Internet-= Draft has=20 gone through
the whole IETF developement and = review=20 process and has been APPROVED
by the IESG.

> Additionally I personally see little value in th= e any=20
> re-roots beyond philosophical cleanlines= s. I do=20 agree that
> all MIBs may not be semantica= lly=20 perfect below docsIf, but I
> take it as t= he best=20 hierarchical umbrella we have on that
> ro= ad that=20 has been traveled. If we were forced to re-root I
>=20 would advocate at least leveraging hierarchy by contextually > group all CL/IPCDN related objects together instead of ha= ving=20
> them assigned loosely and likely non-con= tiguously=20 into the
> mib-2 free space. E.g. in that = sense I=20 was a fan of the
> enterprise clab root.=20
>

I have explained to teh chairs, that a reroot is not=20 MANDATORY.
But IF you want to continue to all= ocate (or=20 keep the current
allocations) under docIfMib,= then I=20 would URGE you to create
a document similar t= o=20 RFC3737.

And in the future, you would NOT let an Internet-Draf= t have=20 any
pre-assigned value, but instead have some= thing=20 aka:

   ::=3D { docsIfMib xx } -- xx to be assig= ned by IANA=20 as per
          &n= bsp;           &nb= sp;=20 -- procedures outlined in <your-rfc3737-equivalent>

So you (the WG) has basically been mis-using the fact= that=20 you
had a docIfMib branch and were pre-assign= ing=20 values against the
normal process, and with t= he risk=20 of having incomp-atible versions
of MIB modul= es in=20 implementations!

> The very nature of so many representative MIB-ro= oting=20
> conventions across the many CL-related M= IBs=20 (docsIf,
> experimental, mib-2-pending, cl= ab)=20 suggests if this is not
> exactly a conten= tious=20 issue, it is definitely one still open
> t= o the=20 author's discretion which one might tend to agree has
> been non-optimal. I also see a variable modification time= of=20
> these drafts at some middle revision to = change=20 OID roots
> which indicates it was not gui= ded by a=20 single firm guiding
> consensus (but perha= ps MIB=20 doctor advice trickle effect?). I
> would = advocate=20 that a firm future-guiding decision be made
&= gt; that=20 would apply to all as-of-yet unwritten MIBs.
= >=20
Totally agree. And having 4 or 5 potential pl= aces to=20 root a
new MIB mdoule aka
  docsIf, experimental, mib-2-pending, clab
seems REALLY REALLY bad to me.

> Though were these proposed re-roots to make thei= r way=20
> unimpeded into continued-draft/RFC/ECR/c= ert-wave=20 would a good
> time estimate to seeing suc= h in the=20 field be late 2006?
>

Bert Wijnen,
speaking as co= -AD for the=20 IETF OPS area.
open to a good discussion on t= his topic=20 and to try and document
the correct and agree= d way for=20 new and furture MIB dvelopement
in this space= .=20

Bert
NOTICE: This communica= tion=20 contains information which may be proprietary, privileged or confidenti= al. If=20 you are not the intended recipient (or authorized to receive for the in= tended=20 recipient), or believe that you have received this communication in err= or,=20 please do not print, copy,retransmit, disseminate, disclose or otherwis= e use=20 the information. Also, please indicate to the sender that you have rece= ived=20 this communication in error and delete the copy you received. Thank=20 you.

------_=_NextPart_001_01C4F420.B299AFA6-- --===============0472057810== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============0472057810==-- From ipcdn-bounces@ietf.org Thu Jan 6 14:14:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03584 for ; Thu, 6 Jan 2005 14:14:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmdIC-0002gL-O4 for ipcdn-archive@ietf.org; Thu, 06 Jan 2005 14:27:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmd0Y-0002RD-L2; Thu, 06 Jan 2005 14:09:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmcwV-00019Z-8Q for ipcdn@megatron.ietf.org; Thu, 06 Jan 2005 14:05:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02622 for ; Thu, 6 Jan 2005 14:05:06 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmd9J-0001CZ-JC for ipcdn@ietf.org; Thu, 06 Jan 2005 14:18:23 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j06J4Q1e010671; Thu, 6 Jan 2005 12:04:26 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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, 6 Jan 2005 12:04:26 -0700 Message-ID: Thread-Topic: IETF IPCDN proposed standard drafts MIB Modules OID assignmen ts: Assigning new RFCs under mib-2 Thread-Index: AcTzUaddqE3Ia/N7Q9+N1USBeX79RAAAGBKQAAkl2wAAB83tEAAh4vIQ From: "Jean-Francois Mule" To: "Fred Oko" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: quoted-printable Cc: DOCSIS OSS Majordomo List , ipcdn@ietf.org, Dan Rice Subject: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules OID assignmen ts: Assigning new RFCs under mib-2 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Content-Transfer-Encoding: quoted-printable See inline for the technical response. > -----Original Message----- > From: Fred Oko [mailto:foko@c-cor.net]=20 > Sent: Wednesday, January 05, 2005 8:26 PM > To: Jean-Francois Mule; andre.lejeune@terayon.com > Cc: gnakanishi@motorola.com; Eduardo Cardona; DOCSIS OSS=20 > Majordomo List; ipcdn@ietf.org > Subject: RE: IETF IPCDN proposed standard drafts MIB Modules=20 > OID assignmen ts: Assigning new RFCs under mib-2 >=20 >=20 > I would agree that a MIB for which the author had the=20 > foresight to root in the experimental(3) branch would be=20 > expected (both by MIB consumers and IETF) to be re-rooted for=20 > RFC transition.=20 Per my email, there is one MIB module to be discussed here:=20 http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib-10.txt I do not see the rooting to the experimental branch in the above referenced document. > However, this only applies to the=20 > subscriber-mgmt MIB.=20 The IETF IPCDN subs mgmt MIB will be routed under ..mib-2. > I would argue that there is no value,=20 > only negative operational implications, and no impervious=20 > mandate for re-rooting any other MIB that has already seen=20 > widespread implementation and consumption.=20 The point of this IETF email discussion is not to discuss what the product requirements should be moving forward for CableLabs once the RFC is published (this is totally inappropriate). The point is to get the MIB to a stable RFC status and your technical input was requested just for that. > I would argue this=20 > not only for the QOS MIB, but for any draft MIB for which=20 > originally had a sub-docsIfMib or enterprise root that was=20 > mandated to be supported in any already passed CableLabs=20 > certification wave. The reasoning is that since these objects=20 > were implemented by CM/CMTS vendor and qualified, they have=20 > most certainly been also implemented against by existing OSS=20 > software, wherein lies definite operational impact of such a=20 > major change. A couple of points: - the IETF process follows its course and not only will the OID root change but the MIB modules themselves - the one being worked on in IPCDN have changed. And changed drastically sometimes (QoS mib in particular), based on the expert advice from MIB doctors and the IETF community. They have mostly changed for the better: for e.g., we are not mucking anymore with the ECN bits when touching the DSCP code fields - I see those kinds of changes as very important to improve the quality of our specs. - the requirements imposed by CableLabs for product qualification are decided by its cable operator members as you are aware - this is not the place to discuss this, sorry. > Impact points of any re-root: This is not a discussion for the IETF ID. This *potential* impact is actually to be analyzed by the cable operators and CableLabs when the time comes that we have all the DOCSIS MIBs to RFC status. My first goal is to get those RFCs. > 1) common to any change: CMTS and CM vendor must change code,=20 > CL must update ATP etc for qualifications, vendors must=20 > re-qualify code, and MSO's must deploy new code (granted=20 > required just for other MIB updates if not re-root) > 2) a decision must be made whether a CMTS or CM is=20 > backward-compatible (either as mandated by CL or discretion=20 > of vendor as advised by MSOs) and supporting two instance of=20 > a MIB has implications -- and regardless the decision of=20 > backward-compatibility on a single device, any OSS that=20 > monitors across a non-homogeneous field will of course have=20 > chance to run into new and old instances > a) multiple OIDs for same subidentifiers must be known=20 > by clients which may have preference to use non-fully-qualified > b) if back-compat, collection must limit itself to one=20 > of the two instances to avoid double collection thus=20 > requiring conditional logic based on probing > c) I would expect any MSO with utilities that are=20 > broken by such a re-root will demand this "bug" be fixed by=20 > the vendor thus forcing effective back-compat > d) it may be difficult for some SNMP agent=20 > implementations to support efficient backward-compatability=20 ^^^^^^^^^^^^^^^^^^^^^^^ Have you followed the work of IPCDN?=20 this backward compatibility question has been raised and bottom line, it is not possible. Some MIB modules have changed in a way that is totally incompatible: renumbering of object OID entries in some tables for e.g., change of object syntax that is incompatible on the wire, etc. But more importantly, backward compatibility is not our focus: the IETF IPCDN wg and the IETF in general is not a rubber stamping organization. If something needs to be changed in an Internet-Draft, it is changed. More importantly, this is not specific to IPCDN or MIBs. Some vendors implement internet drafts and have to change their implementations when the RFCs are published. And we have yet to mandate any change since there are no RFCs. > (i.e. two OIDs mapping to same in-memory data) as such=20 > efficiency would be a must for some of the expensive MIB tables > 3) Since CL CW have continued to require very old drafts we=20 > know that implementation against the "old"/only OIDs have=20 > been in use for a while >=20 > No real impact points of not re-rooting anything -- simplest path: > 1) current OID assignments, while not actually assigned by=20 > IANA are guaranteed to be non-conflicting /wg chair hat on I totally disagree. Read the mib drafts and analyze the syntax and semantic changes in the MIB modules. Wg chair hat off/ > 2) no re-roots have been implemented in any code -- they only=20 > exist in more recent drafts thus nullifying them is only on paper =20 you are missing the point: code/implementation changes go far beyond OID re-root if you want to take this path.=20 "thus nullifying them is only on paper"=20 ^^^^^^^^^^ I won't go there... And stop here. > Additionally I personally see little value in the any=20 > re-roots beyond philosophical cleanliness. I do agree that=20 > all MIBs may not be semantically perfect below docsIf, but I=20 > take it as the best hierarchical umbrella we have on that=20 > road that has been traveled.=20 I see no technical comment in the above paragraph. > If we were forced to re-root I=20 > would advocate at least leveraging hierarchy by contextually=20 > group all CL/IPCDN related objects together instead of having=20 ^^^^=20 no. > them assigned loosely and likely non-contiguously into the=20 > mib-2 free space. E.g. in that sense I was a fan of the=20 > enterprise clab root. > The very nature of so many representative MIB-rooting=20 > conventions across the many CL-related MIBs (docsIf,=20 ^^ what CableLabs has done is done.=20 > experimental, mib-2-pending, clab) suggests if this is not=20 > exactly a contentious issue, it is definitely one still open=20 > to the author's discretion which one might tend to agree has=20 ^^^^^^^^^^^^^^^^^^^ Not in IETF IPCDN > been non-optimal. I also see a variable modification time of=20 > these drafts at some middle revision to change OID roots=20 > which indicates it was not guided by a single firm guiding=20 > consensus (but perhaps MIB doctor advice trickle effect?). I=20 > would advocate that a firm future-guiding decision be made=20 > that would apply to all as-of-yet unwritten MIBs. > Though were these proposed re-roots to make their way=20 > unimpeded into continued-draft/RFC/ECR/cert-wave would a good=20 > time estimate to seeing such in the field be late 2006? _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Jan 6 14:45:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08624 for ; Thu, 6 Jan 2005 14:45:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmdmP-00062l-9l for ipcdn-archive@ietf.org; Thu, 06 Jan 2005 14:58:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmdUR-0000Ug-LJ; Thu, 06 Jan 2005 14:40:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmdRs-0007fw-BR for ipcdn@megatron.ietf.org; Thu, 06 Jan 2005 14:37:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07701 for ; Thu, 6 Jan 2005 14:37:30 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmdef-0005Jx-2Q for ipcdn@ietf.org; Thu, 06 Jan 2005 14:50:48 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j06Jam1e016642; Thu, 6 Jan 2005 12:36:48 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules OID assignmen ts: Assigning new RFCs under mib-2 Date: Thu, 6 Jan 2005 12:36:48 -0700 Message-ID: Thread-Topic: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules OID assignmen ts: Assigning new RFCs under mib-2 Thread-Index: AcTz5MitGAHdpg+BS2iclDu3TZ+0fAAPdo8g From: "Jean-Francois Mule" To: "Wijnen, Bert (Bert)" , "Fred Oko" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Content-Transfer-Encoding: quoted-printable Cc: gnakanishi@motorola.com, Eduardo Cardona , ipcdn@ietf.org, DOCSIS OSS Majordomo List X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 Content-Transfer-Encoding: quoted-printable inline > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 > Sent: Thursday, January 06, 2005 4:42 AM > To: Fred Oko; Jean-Francois Mule; andre.lejeune@terayon.com > Cc: gnakanishi@motorola.com; Eduardo Cardona; ipcdn@ietf.org;=20 > DOCSIS OSS Majordomo List > Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts=20 > MIB Modules OID assignmen ts: Assigning new RFCs under mib-2 >=20 >=20 > Inline >=20 > > -----Original Message----- > > From: ipcdn-bounces@ietf.org > > [mailto:ipcdn-bounces@ietf.org]On Behalf Of > > Fred Oko > > Sent: Thursday, January 06, 2005 04:26 > > To: Jean-Francois Mule; andre.lejeune@terayon.com > > Cc: gnakanishi@motorola.com; Eduardo Cardona; ipcdn@ietf.org;=20 > > DOCSIS OSS Majordomo List > > Subject: [ipcdn] RE: IETF IPCDN proposed standard drafts=20 > MIB Modules OID > > assignmen ts: Assigning new RFCs under mib-2 > >=20 > >=20 > > I would agree that a MIB for which the author had the > > foresight to root in the experimental(3) branch would be=20 > > expected (both by MIB consumers and IETF) to be re-rooted for=20 > > RFC transition. However, this only applies to the=20 > > subscriber-mgmt MIB. I would argue that there is no value,=20 > > only negative operational implications, and no impervious=20 > > mandate for re-rooting any other MIB that has already seen=20 > > widespread implementation and consumption. I would argue this=20 > > not only for the QOS MIB, but for any draft MIB for which=20 > > originally had a sub-docsIfMib or enterprise root that was=20 > > mandated to be supported in any already passed CableLabs=20 > > certification wave. The reasoning is that since these objects=20 > > were implemented by CM/CMTS vendor and qualified, they have=20 > > most certainly been also implemented against by existing OSS=20 > > software, wherein lies definite operational impact of such a=20 > > major change. > >=20 > I think the above shows where we have a BASIC problem (and we=20 > discussed this in the past as well).=20 We are all aware of the problem as it exists and will continue to exist: we have implementations of Internet-Drafts. This basic problem exists in many places and companies deal with it. As a co-author of the SIP MIB, I can tell you that back in 2000, 2 companies had implementations of the SIP MIB draft 01. We are now almost done, and the to-be-published sip mib draft09 has incompatibility changes with draft 2... > When trying to standardize a MIB document in the IETF, then=20 > there should be NO assumptions on where the module gets=20 > rooted. That will ONLY be known=20 > once the document has been approved by the IESG. After that=20 > approval, it is=20 > IANA who assigns the OID.=20 >=20 > And that is exactly one of the reasons why we do not like=20 > that WGs start assigning MIB modules underneath some OID=20 > branch for that WG/technology. And we have not in the IETF IPCDN wg. More importantly, CableLabs has learned from this: DOCSIS is what it is, we cannot change it but for other projects like PacketCable and CableHome, the MIBs we originated with the help of vendors and our service operator members like the MTA MIB have been routed under the CableLabs private OID. > The reason for not wanting such early assignments (other than=20 > experimental) is that the MIB module may change (dramatically=20 > even) during the process in the IETF WG, IETF Last Call, MIB=20 > Doctor review, IESG review. And so if anyone implemented the=20 > MIB module based on some random revision of an Internte-Draft=20 > then that module (with assigned OID) might be completely=20 > different than the one that finally gets approved (same OID=20 > if you followed your logic). And so that WILL result in=20 > INTEROPERABILITY problems in the market place. I agree and our goal in IPCDN has been to follow the IETF process. > See also draft-ietf-ops-mib-review-guidelines-03.txt sections=20 > 4.3 and 4.5 >=20 >=20 > > Impact points of any re-root: > > 1) common to any change: CMTS and CM vendor must change code, > > CL must update ATP etc for qualifications, vendors must=20 > > re-qualify code, and MSO's must deploy new code (granted=20 > > required just for other MIB updates if not re-root) >=20 > While a MIB is under development in the IETF, no one should=20 > be assuming that such a MIB module is final and so no-one=20 > should be using a pre-assigned OID for the MIB module. If=20 > anything, one could use experimental (need to request an=20 > assignment though; also see warnings about that in mib review=20 > guidleines) or your own (vendor specific OID tree. Make sure=20 > you UNDERSTAND that the names (OIDs) should not=20 > conflict with any future final OID for the MIB once approved. >=20 > > 2) a decision must be made whether a CMTS or CM is > > backward-compatible (either as mandated by CL or discretion=20 > > of vendor as advised by MSOs) and supporting two instance of=20 > > a MIB has implications -- and regardless the decision of=20 > > backward-compatibility on a single device, any OSS that=20 > > monitors across a non-homogeneous field will of course have=20 > > chance to run into new and old instances >=20 > If one follows MIB guidelines/rules (and you MUST follow=20 > those to get a=20 > MIB module or an update to a MIB module approved in IETF),=20 > then these guidelines/rules (and associated MIB doctor review=20 > in IETF) will guarantee backward compatibility. If such needs=20 > to be compromised, then it would only happen with serious and=20 > explicit agreement of the WG and otehr IETF review (for=20 > example when everyone agrees that there was a BUG in an=20 > earlier module) >=20 > > a) multiple OIDs for same subidentifiers must be known > > by clients which may have preference to use non-fully-qualified > > b) if back-compat, collection must limit itself to one=20 > > of the two instances to avoid double collection thus=20 > > requiring conditional logic based on probing > > c) I would expect any MSO with utilities that are=20 > > broken by such a re-root will demand this "bug" be fixed by=20 > > the vendor thus forcing effective back-compat > > d) it may be difficult for some SNMP agent=20 > > implementations to support efficient backward-compatability=20 > > (i.e. two OIDs mapping to same in-memory data) as such=20 > > efficiency would be a must for some of the expensive MIB tables > > 3) Since CL CW have continued to require very old drafts we=20 > > know that implementation against the "old"/only OIDs have=20 > > been in use for a while > >=20 > Not sure I understand all points a-b.=20 > What is an MSO? Multi Service Operator a.k.a. cable operator > What is CL CW? CableLabs Certification Wave This has nothing to do with this discussion BTW > > No real impact points of not re-rooting anything -- simplest path: > > 1) current OID assignments, while not actually assigned by > > IANA are guaranteed to be non-conflicting >=20 > that is good. > But, since they only exists in Internet-Drafts, they have not=20 > really been assigned!!!! That is the thing to understand!!! PLEASE! Exactly. =20 > > 2) no re-roots have been implemented in any code -- they only > > exist in more recent drafts thus nullifying them is only on paper > >=20 > As explained above, they SHOULD NOT exist in running code!!!=20 > This is a real basic approach of how we do Iinternet-Drafts=20 > and how and why we assign OIDs AFTER an Internet-Draft has=20 > gone through the whole IETF developement and review process=20 > and has been APPROVED=20 > by the IESG. >=20 > > Additionally I personally see little value in the any > > re-roots beyond philosophical cleanliness. I do agree that=20 > > all MIBs may not be semantically perfect below docsIf, but I=20 > > take it as the best hierarchical umbrella we have on that=20 > > road that has been traveled. If we were forced to re-root I=20 > > would advocate at least leveraging hierarchy by contextually=20 > > group all CL/IPCDN related objects together instead of having=20 > > them assigned loosely and likely non-contiguously into the=20 > > mib-2 free space. E.g. in that sense I was a fan of the=20 > > enterprise clab root. > >=20 >=20 > I have explained to teh chairs, that a reroot is not MANDATORY. And if you read my post from yesterday, I stated: > The alternative is that we document the=20 > motivations and rationale for continuing to assign MIBs under=20 > ..mib-2(1) transmission(10) > docsIfMib(127)) - I am willing to do this if the wg feels=20 > strongly about it. > But IF you want to continue to allocate (or keep the current > allocations) under docIfMib, then I would URGE you to create > a document similar to RFC3737. I think we are on the same page. But since we (as individual contributors) did not see much impact for the IETF IPCDN mibs given the technical changes of the mib modules anyway, we decided to poll the interested folks to see if we could put it under mib-2. =20 > And in the future, you would NOT let an Internet-Draft have any > pre-assigned value, but instead have something aka: >=20 > ::=3D { docsIfMib xx } -- xx to be assigned by IANA as per > -- procedures outlined in=20 > >=20 > So you (the WG) has basically been mis-using the fact that you > had a docIfMib branch and were pre-assigning values against the > normal process, and with the risk of having incomp-atible versions > of MIB modules in implementations! Point taken. Trying to correct it... > > The very nature of so many representative MIB-rooting=20 > > conventions across the many CL-related MIBs (docsIf,=20 > > experimental, mib-2-pending, clab) suggests if this is not=20 > > exactly a contentious issue, it is definitely one still open=20 > > to the author's discretion which one might tend to agree has=20 > > been non-optimal. I also see a variable modification time of=20 > > these drafts at some middle revision to change OID roots=20 > > which indicates it was not guided by a single firm guiding=20 > > consensus (but perhaps MIB doctor advice trickle effect?). I=20 > > would advocate that a firm future-guiding decision be made=20 > > that would apply to all as-of-yet unwritten MIBs. > >=20 > Totally agree. And having 4 or 5 potential places to root a > new MIB mdoule aka > docsIf, experimental, mib-2-pending, clab > seems REALLY REALLY bad to me. Let me respectfully disagree with Fred's comment you quote but agree with you when you say: > And having 4 or 5 potential places to root a > new MIB mdoule aka > docsIf, experimental, mib-2-pending, clab > seems REALLY REALLY bad to me. Here is why I disagree with Fred's comment. Fred wrote: > > these drafts at some middle revision to change OID roots=20 Internet-drafts are not assigned any roots per Bert's earlier comment. So the point is moot. > > which indicates it was not guided by a single firm guiding=20 > > consensus (but perhaps MIB doctor advice trickle effect?).=20 Who has raised this OID rooting issue in the past in the wg before the draft went to mib doctor or AD reviews? I am willing to accept those kinds of comments about "single firm guiding consensus".=20 We learn as we go, all together, no single point. We guide when we know. Note that this area of MIB authoring is so complex to comprehend and do well that we go to "mib doctors" and have to follow the MIB authoring guidelines. We all learn by doing it, right? > > Though were these proposed re-roots to make their way=20 > > unimpeded into continued-draft/RFC/ECR/cert-wave would a good=20 > > time estimate to seeing such in the field be late 2006? > >=20 >=20 > Bert Wijnen, > speaking as co-AD for the IETF OPS area. > open to a good discussion on this topic and to try and document=20 > the correct and agreed way for new and furture MIB dvelopement > in this space. >=20 > Bert >=20 >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Jan 6 15:48:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15101 for ; Thu, 6 Jan 2005 15:48:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmeld-0008SJ-0j for ipcdn-archive@ietf.org; Thu, 06 Jan 2005 16:02:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmeWP-0007Ij-KF; Thu, 06 Jan 2005 15:46:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmeKG-0007rJ-Ci for ipcdn@megatron.ietf.org; Thu, 06 Jan 2005 15:33:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13790 for ; Thu, 6 Jan 2005 15:33:42 -0500 (EST) Received: from pop-a065d05.pas.sa.earthlink.net ([207.217.121.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmeX7-0007sJ-1T for ipcdn@ietf.org; Thu, 06 Jan 2005 15:47:01 -0500 Received: from h-69-3-25-164.snvacaid.dynamic.covad.net ([69.3.25.164] helo=oemcomputer) by pop-a065d05.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CmeKF-0001ie-00 for ipcdn@ietf.org; Thu, 06 Jan 2005 12:33:43 -0800 Message-ID: <00b801c4f42f$1b51c340$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn \(E-mail\)" References: Subject: Re: [ipcdn] IETF NCS Sig MIB Tone Table Date: Thu, 6 Jan 2005 12:34:22 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Hi - > From: "Beacham Gordon-CGB005" > To: ; > Sent: Wednesday, January 05, 2005 8:22 AM > Subject: [ipcdn] IETF NCS Sig MIB Tone Table ... > PktcSigDevToneEntry ::= SEQUENCE { ... This really should be TWO tables. One would control properties that apply to the whole sequence, and a second with an additional index to permit individual entries for each of the tones in a sequence. This would reduce the number of object definitions in the MIB module, make the scope of applicability of the attributes clearer, and generally make it easier to understand what's going on. When I see > pktcSigDevToneFirstFrequency Unsigned32, .... > pktcSigDevToneSecondFrequency Unsigned32, ... > pktcSigDevToneThirdFrequency Unsigned32, ... > pktcSigDevToneFourthFrequency Unsigned32, ... > pktcSigDevToneFifthFrequency Unsigned32, I get the feeling that the model needs to be re-factored, both in light of the need to support these more complex sequences and from a simple data modeling perspective. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Jan 6 15:50:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15192 for ; Thu, 6 Jan 2005 15:50:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmenK-0008U4-Mt for ipcdn-archive@ietf.org; Thu, 06 Jan 2005 16:03:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmeWT-0007MD-9I; Thu, 06 Jan 2005 15:46:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmeMQ-00011M-2g for ipcdn@megatron.ietf.org; Thu, 06 Jan 2005 15:35:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14002 for ; Thu, 6 Jan 2005 15:35:56 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmeZD-0007wW-EC for ipcdn@ietf.org; Thu, 06 Jan 2005 15:49:14 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j06KZD1g001266; Thu, 6 Jan 2005 13:35:15 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2 Date: Thu, 6 Jan 2005 13:35:13 -0700 Message-ID: Thread-Topic: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2 Thread-Index: AcT0FMkUPfSwC+/1TZqy2hk6nmOipAAFJK7A From: "Jean-Francois Mule" To: , , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: quoted-printable Cc: gnakanishi@motorola.com, Eduardo Cardona , ipcdn@ietf.org, DOCSIS OSS Majordomo List X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Content-Transfer-Encoding: quoted-printable Andr=E9 et al., Please let us stick to the engineering issues and technical questions = at stake. I'm trying hard to keep this thread focused on technical = issues and keep it under control, please help me... I will only respond to the technical points. See inline. Jean-Francois=20 > -----Original Message----- > From: andre.lejeune@Terayon.com [mailto:andre.lejeune@Terayon.com]=20 > Sent: Thursday, January 06, 2005 10:24 AM > To: bwijnen@lucent.com; foko@c-cor.net; Jean-Francois Mule > Cc: gnakanishi@motorola.com; Eduardo Cardona; ipcdn@ietf.org;=20 > DOCSIS OSS Majordomo List > Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts=20 > MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2 >=20 >=20 > Bert,=20 > The main problem is that CableLabs require CM and CMTS=20 > vendors to submit their equipment for=20 [snip, stripped non technical comments, irrelevant to the thread] > certification process using draft MIBs as pre-requisites into=20 > these certification waves (CW)=20 A clarification is required: - the comment on MIB requirements pointing to IETF ID is only = applicable to DOCSIS. We have learned from it and if you take the = PacketCable MIB requirements for example, the MIB modules are rooted = under the CableLabs private OID branch. =20 [snip, stripped non technical comments, irrelevant to the thread] < If these MIBs were not=20 > required until they become RFC, then we would all be happy,=20 This is the case for CableLabs projects like PacketCable and Cablehome = and it has been our approach since 2002 for any new MIB in any project = (including DOCSIS, the eDOCSIS SLED mib is a good example of it). The precedent has been set for DOCSIS and there is not much we can do = about it other than work towards completing the RFCs to then analyze the = gap between what we have been requiring and using in the field for = years, and what the standard-track RFCs require. This is the only = rationale process I can recommend, otherwise, we keep arguing about = drafts that are moving targets, making suppositions about what will be = required by CableLabs - this wg is not the right place for that. Ultimately, we are all servicing the same clients, our cable operators, = the service providers that deploy these MIBs and manage the network = elements with it. > except for the fact that the Cable industry wants to move=20 > faster than the time it takes to properly go through the RFC=20 > approval processes, which is a valid desire.=20 Consider this: if we had put the original DOCSIS MIB modules under the = CableLabs private tree to start with, this entire discussion would be = moot. We would have private CableLabs MIBs and IETF RFCs. The migration = path would still need to be analyzed and code changes made to support = the RFCs. This is no different than what some vendors do with other wg = MIB ID: they need mib objects to go to market with, put them under their = private branch until the IETF is done, then make code and tool changes = to move to the RFCs. [snip, stripped non technical comments, irrelevant to the thread] > I concur with Fred here on most of his points.=20 > Re-rooting any of the MIBs is a very expensive process as it=20 > costs 100s of thousands of dollars for every vendor as they=20 > require to implement and test the change and go through=20 > certification with the changes.=20 I will only respond to the technical part of this comment. Read my response to Fred's email. The re-rooting is actually not the = hardest piece here, it is the actual syntax and semantic changes that = went into those MIBs that would cause the bulk of the work, on both the = CM/CMTS network elements and the mgmt applications that use those mibs. This about how we had been using Counter32 objects for e.g. and how we = have come along... Same goes for many technical changes. [snip, stripped non technical comments, irrelevant to the thread] > be re-rooted. I wish someone could find a way to avoid such=20 > re-rooting in the future.=20 Tell me if what we have been doing since 2002 in other CableLabs = projects helps.=20 The solution to date has been: the private CableLabs MIBs should be = defined under the CableLabs private OID. You, vendors with requirements from operators contribute to design MIB = modules in the CableLabs project. We define them under the CableLabs = private OID branches to go to market with. As we go through the standard = process, we make some changes (look at the many PacketCable Engineering = Changes that were introduced in our private MIBs based on the learning = we went through due to the IETF process - simple things like changing = ipAddress to the RFC 3291 textual conventions to just correcting plain = wrong SMI syntax issues). We also submit the original MIB and changes to = the IETF process when it is appropriate. Once we reach RFC status, an = analysis of the gaps between the RFC and what is being implemented by = vendors can be done with all kinds of considerations (costs, benefits, = etc.). Ultimately, the cable operators make those important decisions on = the product requirements. > The draft docsBpi2MIB was placed by someone under=20 > mib-2 transmission docsIfMIB and that was the right place for=20 > it.=20 No. The IETF IPCDN ID for the DOCSIS BPI+ MIB, defining the docsBpi2MIB = module, = ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-bpiplus-mib-15.txt, = is requesting an assignment under mib-2. > It is a MIB that needs to be maintained per interface,=20 > similarly to other MIBs found under the transmission tree.=20 > That person assigned the ID 6 to it, assuming it would be the=20 > next one to be adopted.=20 /wg chair hat on This assignment was WRONG, and should NEVER have been done. Let's not = use the bad examples of the past to justify what we should do now!!! We should have moved this set of MIB requirements under the CableLabs = branch before it even became an ID, freeze those requiremetns as we = like, then pursue the IETF standardization process as we have. wg chair hat off/ > It would not serve anyone if it was=20 > placed anywhere else.=20 See above, I disagree. The OID assignment in that branch is the sole authoritative = responsibility of IANA and noone else should make any assignment in the = IANA controlled namespace.=20 > The draft Event Notification MIB was=20 > placed by someone under mib-2 docsDev and assigned the ID 2=20 > to it.=20 Same comment as above. > I also think this was an appropriate place for such=20 I disagree, see above. > MIB and don't see a need to move it anywhere else. The draft=20 > Qos MIB was placed under mib-2 transmission docsIfMIB and I=20 > also think that was an appropriate place for it, as it also=20 > needs to be maintained per interface. The person assigned ID=20 > 7 to it as it was the next available ID. We hope that this=20 > assignment will continue to be used for the RFC. Maybe the=20 > solution to all this is to let the the IANA assign the=20 > numbers to wherever they want, but define requirements in the=20 > DOCSIS OSSI spec to re-root each of these RFCs to where they=20 > were first allocated. This is ugly in terms of documentation,=20 > but it matches the reality of having two standard bodies=20 > trying to define the same things, each with their own valid=20 > reasons. Andr=E9=20 Jean-Fran=E7ois _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Jan 6 16:51:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27068 for ; Thu, 6 Jan 2005 16:51:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmfkh-0004F1-M7 for ipcdn-archive@ietf.org; Thu, 06 Jan 2005 17:05:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmfFx-0000GS-UF; Thu, 06 Jan 2005 16:33:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmeef-0004Z2-FQ for ipcdn@megatron.ietf.org; Thu, 06 Jan 2005 15:54:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15494 for ; Thu, 6 Jan 2005 15:54:47 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmerW-00008X-7T for ipcdn@ietf.org; Thu, 06 Jan 2005 16:08:06 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j06Ks91e006894; Thu, 6 Jan 2005 13:54:09 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2 Date: Thu, 6 Jan 2005 13:54:09 -0700 Message-ID: Thread-Topic: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2 Thread-Index: AcT0INDyyESEQ8rpTuaeZ/frXsiddgADnHvw From: "Jean-Francois Mule" To: "Wijnen, Bert (Bert)" , , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable Cc: gnakanishi@motorola.com, Eduardo Cardona , ipcdn@ietf.org, DOCSIS OSS Majordomo List X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Bert, We have discussed this set of issues for DOCSIS with Thomas Narten, = yourself and Rich many times since 2002. Since then, I do not believe we = have a mismatch. What was done was done, there is not much we CableLabs, = the vendors or anyone can do about it. Let me be clear that we have worked hard to change the way we do = things with MIBs and other IETF Internet-Drafts for that matter. My = earlier emails on what we have done in PacketCable should provide = detailed examples. Let me give you another example: in the SIP/SIPPING = working groups, with the help of several vendors, we initiated the SIP = DCS proxy-to-proxy draft and we worked with the wg chairs and Allison to = get the draft to RFC. We then changed our SIP-based spec (PacketCable = CMSS) to reference this RFC. Same for RFC 3495 on DHCP option 122 (which = replaced an experimental DHCP option 177 assignment and that transition = has gone well in the specs and in the field). See inline for additional comments. Jean-Fran=E7ois > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 > Sent: Thursday, January 06, 2005 11:51 AM > To: andre.lejeune@Terayon.com; foko@c-cor.net; Jean-Francois Mule > Cc: gnakanishi@motorola.com; Eduardo Cardona; ipcdn@ietf.org;=20 > DOCSIS OSS Majordomo List > Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts=20 > MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2 >=20 >=20 > Andre, >=20 > It sounds like we have a SERIOUS MISMATCH between CL and=20 > IETF.=20 As I said above, I don't think we have any serious mismatch. =20 > If CL wants to define their own stuff and mandate=20 > implementations BEFORE IETF approves a MIB document, then=20 > that is fine...=20 > but then one should not come to IETF and try=20 > to get IETF approval. It just does not work that way. With the time some of us put in the IETF work in various working = groups, and my wg chair stance on IPCDN MIB issues when folks invoked = "existing implementation" reasons in order not to address the comment, I = hope you believe that we bring some contributions in the full spirit of = IETF and that we benefit from expert advice and simple good engineering = practices. > And even if you do these sort of things just within CL, even=20 > then I do see that you guys can easily run into=20 > interoperability problems.=20 You bet. > We are not doing this just for the=20 > fun of it, but because there are serious risks for=20 > inetroperability problems! >=20 > AGAIN, as I said before. if you want to root under docsIfMIb,=20 > fine. Write a doc similar to=20 > RFC3737 and we can do it. Not that we (IETF MIB Doctors)=20 > prefer it that way, but we/you (IPCDN WG) can do it that way. Back to the original question, I have yet to see any good reason for = not changing the OID assignment to mib-2 for the IETF IPCDN DOCSIS QoS = MIB. Did I miss anything? =20 > It would still mean that you can only get the branch assigned=20 > underneath docsIfMib AFTER IESG approval. That comes back to=20 > possible interoperability issues if you assign it earlier. >=20 > Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Jan 6 16:53:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27248 for ; Thu, 6 Jan 2005 16:53:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmflx-0004IZ-01 for ipcdn-archive@ietf.org; Thu, 06 Jan 2005 17:06:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmfJD-0005Ga-Lk; Thu, 06 Jan 2005 16:36:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmeyE-00021r-Bb for ipcdn@megatron.ietf.org; Thu, 06 Jan 2005 16:15:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19065 for ; Thu, 6 Jan 2005 16:15:00 -0500 (EST) From: andre.lejeune@Terayon.com Received: from mail.terayon.com ([63.201.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmfB4-0001PM-6v for ipcdn@ietf.org; Thu, 06 Jan 2005 16:28:19 -0500 Received: from scbh01.terayon.com (scbh01.bh.terayon.com [192.168.0.23]) by mail.terayon.com (8.12.11/8.12.11) with ESMTP id j06LJfjM008027; Thu, 6 Jan 2005 13:19:41 -0800 (envelope-from andre.lejeune@Terayon.com) Received: by scbh01.terayon.com with Internet Mail Service (5.5.2657.72) id ; Thu, 6 Jan 2005 13:14:51 -0800 Message-ID: To: jf.mule@cablelabs.com Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2 Date: Thu, 6 Jan 2005 13:13:48 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2005.1.6.25 X-Spam-Score: 0.3 (/) X-Scan-Signature: dd887a8966a4c4c217a52303814d0b5f Cc: e.cardona@cablelabs.com, ipcdn@ietf.org, docsis-oss@cablelabs.com, gnakanishi@motorola.com, bwijnen@lucent.com X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0109329541==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0109329541== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4F434.9D41D7D2" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4F434.9D41D7D2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jean-Francois, What are the attributes that a MIB has to have, in your opinion, for = being added to the transmission OID under mib-2, as opposed to only be added = to mib-2? I presented my opinion regarding this, which was that a MIB that would only be applicable to a certain type of interface would be better placed under the associated transmission type rather than being placed = at the mib-2 level. I have not seen any justification for not doing this = with the QoS MIB and BPI+ MIBs, other than the fact that the latest drafts = of the BPI+ MIB is requesting them under mib-2, which is not a sufficient justification in my opinion. Andr=E9 -----Original Message----- From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] Sent: Thursday, January 06, 2005 3:54 PM To: Wijnen, Bert (Bert); andre.lejeune@Terayon.com; foko@c-cor.net Cc: gnakanishi@motorola.com; Eduardo Cardona; ipcdn@ietf.org; DOCSIS = OSS Majordomo List Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB = Modules O ID assignmen ts: Assigning new RFCs under mib-2 Bert, We have discussed this set of issues for DOCSIS with Thomas Narten, yourself and Rich many times since 2002. Since then, I do not believe = we have a mismatch. What was done was done, there is not much we = CableLabs, the vendors or anyone can do about it. Let me be clear that we have worked hard to change the way we do = things with MIBs and other IETF Internet-Drafts for that matter. My earlier = emails on what we have done in PacketCable should provide detailed examples. = Let me give you another example: in the SIP/SIPPING working groups, with the = help of several vendors, we initiated the SIP DCS proxy-to-proxy draft and = we worked with the wg chairs and Allison to get the draft to RFC. We then changed our SIP-based spec (PacketCable CMSS) to reference this RFC. = Same for RFC 3495 on DHCP option 122 (which replaced an experimental DHCP = option 177 assignment and that transition has gone well in the specs and in = the field). See inline for additional comments. Jean-Fran=E7ois > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 > Sent: Thursday, January 06, 2005 11:51 AM > To: andre.lejeune@Terayon.com; foko@c-cor.net; Jean-Francois Mule > Cc: gnakanishi@motorola.com; Eduardo Cardona; ipcdn@ietf.org;=20 > DOCSIS OSS Majordomo List > Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts=20 > MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2 >=20 >=20 > Andre, >=20 > It sounds like we have a SERIOUS MISMATCH between CL and=20 > IETF.=20 As I said above, I don't think we have any serious mismatch. =20 > If CL wants to define their own stuff and mandate=20 > implementations BEFORE IETF approves a MIB document, then=20 > that is fine...=20 > but then one should not come to IETF and try=20 > to get IETF approval. It just does not work that way. With the time some of us put in the IETF work in various working = groups, and my wg chair stance on IPCDN MIB issues when folks invoked "existing implementation" reasons in order not to address the comment, I hope you believe that we bring some contributions in the full spirit of IETF and = that we benefit from expert advice and simple good engineering practices. > And even if you do these sort of things just within CL, even=20 > then I do see that you guys can easily run into=20 > interoperability problems.=20 You bet. > We are not doing this just for the=20 > fun of it, but because there are serious risks for=20 > inetroperability problems! >=20 > AGAIN, as I said before. if you want to root under docsIfMIb,=20 > fine. Write a doc similar to=20 > RFC3737 and we can do it. Not that we (IETF MIB Doctors)=20 > prefer it that way, but we/you (IPCDN WG) can do it that way. Back to the original question, I have yet to see any good reason for = not changing the OID assignment to mib-2 for the IETF IPCDN DOCSIS QoS MIB. = Did I miss anything? =20 > It would still mean that you can only get the branch assigned=20 > underneath docsIfMib AFTER IESG approval. That comes back to=20 > possible interoperability issues if you assign it earlier. >=20 > Bert NOTICE: This communication contains information which may be = proprietary, privileged or confidential. If you are not the intended recipient (or authorized to receive for the intended recipient), or believe that you = have received this communication in error, please do not print, = copy,retransmit, disseminate, disclose or otherwise use the information. Also, please indicate to the sender that you have received this communication in = error and delete the copy you received. Thank you. ------_=_NextPart_001_01C4F434.9D41D7D2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules = O ID assignmen ts: Assigning new RFCs under mib-2

Jean-Francois,

What are the attributes that a MIB has to have, in = your opinion, for being added to the transmission OID under mib-2, as = opposed to only be added to mib-2? I presented my opinion regarding = this, which was that a MIB that would only be applicable to a certain = type of interface would be better placed under the associated = transmission type rather than being placed at the mib-2 level. I have = not seen any justification for not doing this with the QoS MIB and BPI+ = MIBs, other than the fact that the latest drafts of the BPI+ MIB is = requesting them under mib-2, which is not a sufficient justification in = my opinion.

Andr=E9

-----Original Message-----
From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]<= /FONT>
Sent: Thursday, January 06, 2005 3:54 PM
To: Wijnen, Bert (Bert); andre.lejeune@Terayon.com; = foko@c-cor.net
Cc: gnakanishi@motorola.com; Eduardo Cardona; = ipcdn@ietf.org; DOCSIS OSS
Majordomo List
Subject: RE: [ipcdn] RE: IETF IPCDN proposed = standard drafts MIB Modules
O ID assignmen ts: Assigning new RFCs under = mib-2


Bert,

  We have discussed this set of issues for = DOCSIS with Thomas Narten, yourself and Rich many times since 2002. = Since then, I do not believe we have a mismatch. What was done was = done, there is not much we CableLabs, the vendors or anyone can do = about it.

  Let me be clear that we have worked hard to = change the way we do things with MIBs and other IETF Internet-Drafts = for that matter. My earlier emails on what we have done in PacketCable = should provide detailed examples. Let me give you another example: in = the SIP/SIPPING working groups, with the help of several vendors, we = initiated the SIP DCS proxy-to-proxy draft and we worked with the wg = chairs and Allison to get the draft to RFC. We then changed our = SIP-based spec (PacketCable CMSS) to reference this RFC. Same for RFC = 3495 on DHCP option 122 (which replaced an experimental DHCP option 177 = assignment and that transition has gone well in the specs and in the = field).

 See inline for additional comments.

Jean-Fran=E7ois

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] =
> Sent: Thursday, January 06, 2005 11:51 = AM
> To: andre.lejeune@Terayon.com; foko@c-cor.net; = Jean-Francois Mule
> Cc: gnakanishi@motorola.com; Eduardo Cardona; = ipcdn@ietf.org;
> DOCSIS OSS Majordomo List
> Subject: RE: [ipcdn] RE: IETF IPCDN proposed = standard drafts
> MIB Modules O ID assignmen ts: Assigning new = RFCs under mib-2
>
>
> Andre,
>
> It sounds like we have a SERIOUS MISMATCH = between CL and
> IETF.
  As I said above, I don't think we have any = serious mismatch. 

> If CL wants to define their own stuff and = mandate
> implementations BEFORE IETF approves a MIB = document, then
> that is fine...
> but then one should not come to IETF and try =
> to get IETF approval. It just does not work = that way.

  With the time some of us put in the IETF work = in various working groups, and my wg chair stance on IPCDN MIB issues = when folks invoked "existing implementation" reasons in order = not to address the comment, I hope you believe that we bring some = contributions in the full spirit of IETF and that we benefit from = expert advice and simple good engineering practices.


> And even if you do these sort of things just = within CL, even
> then I do see that you guys can easily run into =
> interoperability problems.
  You bet.

> We are not doing this just for the
> fun of it, but because there are serious risks = for
> inetroperability problems!
>
> AGAIN, as I said before. if you want to root = under docsIfMIb,
> fine. Write a doc similar to
> RFC3737 and we can do it. Not that we (IETF MIB = Doctors)
> prefer it that way, but we/you (IPCDN WG) can = do it that way.


  Back to the original question, I have yet to = see any good reason for not changing the OID assignment to mib-2 for = the IETF IPCDN DOCSIS QoS MIB. Did I miss anything?

 
> It would still mean that you can only get the = branch assigned
> underneath docsIfMib AFTER IESG approval. That = comes back to
> possible interoperability issues if you assign = it earlier.
>
> Bert
NOTICE: This communication contains information = which may be proprietary, privileged or confidential. If you are not = the intended recipient (or authorized to receive for the intended = recipient), or believe that you have received this communication in = error, please do not print, copy,retransmit, disseminate, disclose or = otherwise use the information. Also, please indicate to the sender that = you have received this communication in error and delete the copy you = received. Thank you.

------_=_NextPart_001_01C4F434.9D41D7D2-- --===============0109329541== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============0109329541==-- From ipcdn-bounces@ietf.org Thu Jan 6 17:06:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29331 for ; Thu, 6 Jan 2005 17:06:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmfzG-00055R-Ia for ipcdn-archive@ietf.org; Thu, 06 Jan 2005 17:20:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmfbq-0002eY-Vg; Thu, 06 Jan 2005 16:55:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmfVk-0006Lc-5l for ipcdn@megatron.ietf.org; Thu, 06 Jan 2005 16:49:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26812 for ; Thu, 6 Jan 2005 16:49:37 -0500 (EST) Received: from pacdcoavas10.cable.comcast.com ([208.17.33.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmfiV-00048U-Uz for ipcdn@ietf.org; Thu, 06 Jan 2005 17:02:57 -0500 Message-ID: From: "Woundy, Richard" To: "'andre.lejeune@terayon.com'" , jf.mule@cablelabs.com Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2 Date: Thu, 6 Jan 2005 16:48:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.6 (/) X-Scan-Signature: 4c463dcf97e2b913ab242796279c24d2 Cc: e.cardona@cablelabs.com, ipcdn@ietf.org, docsis-oss@cablelabs.com, gnakanishi@motorola.com, bwijnen@lucent.com X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1141908513==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 213cf0777a99c4ccdd94bb20659dd28c This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1141908513== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4F439.680E909C" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4F439.680E909C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Here is what the current MIB guidelines ( http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines= -03. txt, section 4.5)have to say: =20 - The value assigned to the MODULE-IDENTITY descriptor MUST be = unique and (for IETF standards-track MIB modules) SHOULD reside under the mgmt subtree [RFC2578]. Most often it will be an IANA-assigned value directly under mib-2 [RFC2578], although for media-specific MIB modules that extend the IF-MIB [RFC2863] it is customary to = use an IANA-assigned value under transmission [RFC2578]. In the past some IETF working groups have made their own assignments from subtrees delegated to them by IANA, but that practice has proven problematic and is NOT RECOMMENDED. =20 -- Rich -----Original Message----- From: owner-docsis-oss@cablelabs.com = [mailto:owner-docsis-oss@cablelabs.com] On Behalf Of andre.lejeune@terayon.com Sent: Thursday, January 06, 2005 4:14 PM To: jf.mule@cablelabs.com Cc: gnakanishi@motorola.com; e.cardona@cablelabs.com; ipcdn@ietf.org; docsis-oss@cablelabs.com; bwijnen@lucent.com; foko@c-cor.net Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB = Modules O ID assignmen ts: Assigning new RFCs under mib-2 Jean-Francois,=20 What are the attributes that a MIB has to have, in your opinion, for = being added to the transmission OID under mib-2, as opposed to only be added = to mib-2? I presented my opinion regarding this, which was that a MIB that would only be applicable to a certain type of interface would be better placed under the associated transmission type rather than being placed = at the mib-2 level. I have not seen any justification for not doing this = with the QoS MIB and BPI+ MIBs, other than the fact that the latest drafts = of the BPI+ MIB is requesting them under mib-2, which is not a sufficient justification in my opinion. Andr=E9=20 -----Original Message-----=20 From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com ]=20 Sent: Thursday, January 06, 2005 3:54 PM=20 To: Wijnen, Bert (Bert); andre.lejeune@Terayon.com; foko@c-cor.net=20 Cc: gnakanishi@motorola.com; Eduardo Cardona; ipcdn@ietf.org; DOCSIS = OSS=20 Majordomo List=20 Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB = Modules=20 O ID assignmen ts: Assigning new RFCs under mib-2=20 Bert,=20 We have discussed this set of issues for DOCSIS with Thomas Narten, yourself and Rich many times since 2002. Since then, I do not believe = we have a mismatch. What was done was done, there is not much we = CableLabs, the vendors or anyone can do about it. Let me be clear that we have worked hard to change the way we do = things with MIBs and other IETF Internet-Drafts for that matter. My earlier = emails on what we have done in PacketCable should provide detailed examples. = Let me give you another example: in the SIP/SIPPING working groups, with the = help of several vendors, we initiated the SIP DCS proxy-to-proxy draft and = we worked with the wg chairs and Allison to get the draft to RFC. We then changed our SIP-based spec (PacketCable CMSS) to reference this RFC. = Same for RFC 3495 on DHCP option 122 (which replaced an experimental DHCP = option 177 assignment and that transition has gone well in the specs and in = the field). See inline for additional comments.=20 Jean-Fran=E7ois=20 > -----Original Message-----=20 > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com ]=20 > Sent: Thursday, January 06, 2005 11:51 AM=20 > To: andre.lejeune@Terayon.com; foko@c-cor.net; Jean-Francois Mule=20 > Cc: gnakanishi@motorola.com; Eduardo Cardona; ipcdn@ietf.org;=20 > DOCSIS OSS Majordomo List=20 > Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts=20 > MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2=20 >=20 >=20 > Andre,=20 >=20 > It sounds like we have a SERIOUS MISMATCH between CL and=20 > IETF.=20 As I said above, I don't think we have any serious mismatch. =20 > If CL wants to define their own stuff and mandate=20 > implementations BEFORE IETF approves a MIB document, then=20 > that is fine...=20 > but then one should not come to IETF and try=20 > to get IETF approval. It just does not work that way.=20 With the time some of us put in the IETF work in various working = groups, and my wg chair stance on IPCDN MIB issues when folks invoked "existing implementation" reasons in order not to address the comment, I hope you believe that we bring some contributions in the full spirit of IETF and = that we benefit from expert advice and simple good engineering practices. > And even if you do these sort of things just within CL, even=20 > then I do see that you guys can easily run into=20 > interoperability problems.=20 You bet.=20 > We are not doing this just for the=20 > fun of it, but because there are serious risks for=20 > inetroperability problems!=20 >=20 > AGAIN, as I said before. if you want to root under docsIfMIb,=20 > fine. Write a doc similar to=20 > RFC3737 and we can do it. Not that we (IETF MIB Doctors)=20 > prefer it that way, but we/you (IPCDN WG) can do it that way.=20 Back to the original question, I have yet to see any good reason for = not changing the OID assignment to mib-2 for the IETF IPCDN DOCSIS QoS MIB. = Did I miss anything? > It would still mean that you can only get the branch assigned=20 > underneath docsIfMib AFTER IESG approval. That comes back to=20 > possible interoperability issues if you assign it earlier.=20 >=20 > Bert=20 NOTICE: This communication contains information which may be = proprietary, privileged or confidential. If you are not the intended recipient (or authorized to receive for the intended recipient), or believe that you = have received this communication in error, please do not print, = copy,retransmit, disseminate, disclose or otherwise use the information. Also, please indicate to the sender that you have received this communication in = error and delete the copy you received. Thank you. ------_=_NextPart_001_01C4F439.680E909C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Here=20 is what the current MIB guidelines (http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-g= uidelines-03.txt, section 4.5)have to=20 say:
 
   - The value assigned to the MODULE-IDENTITY = descriptor MUST=20 be unique
     and (for IETF standards-track MIB = modules)=20 SHOULD reside under the
     mgmt subtree=20 [RFC2578].  Most often it will be an=20 IANA-assigned
     value directly under mib-2 = [RFC2578],=20 although for media-specific
     MIB modules = that extend=20 the IF-MIB [RFC2863] it is customary to use
     = an=20 IANA-assigned value under transmission [RFC2578].  In the=20 past
     some IETF working groups have made = their own=20 assignments from
     subtrees delegated to them = by IANA,=20 but that practice has proven
     problematic = and is NOT=20 RECOMMENDED.
 
--=20 Rich
-----Original Message-----
From:=20 owner-docsis-oss@cablelabs.com = [mailto:owner-docsis-oss@cablelabs.com] On=20 Behalf Of andre.lejeune@terayon.com
Sent: Thursday, = January 06,=20 2005 4:14 PM
To: jf.mule@cablelabs.com
Cc:=20 gnakanishi@motorola.com; e.cardona@cablelabs.com; ipcdn@ietf.org;=20 docsis-oss@cablelabs.com; bwijnen@lucent.com;=20 foko@c-cor.net
Subject: RE: [ipcdn] RE: IETF IPCDN proposed = standard=20 drafts MIB Modules O ID assignmen ts: Assigning new RFCs under=20 mib-2

Jean-Francois,

What are the attributes that a MIB has to have, in = your=20 opinion, for being added to the transmission OID under mib-2, as = opposed to=20 only be added to mib-2? I presented my opinion regarding this, which = was that=20 a MIB that would only be applicable to a certain type of interface = would be=20 better placed under the associated transmission type rather than = being placed=20 at the mib-2 level. I have not seen any justification for not doing = this with=20 the QoS MIB and BPI+ MIBs, other than the fact that the latest drafts = of the=20 BPI+ MIB is requesting them under mib-2, which is not a sufficient=20 justification in my opinion.

Andr=E9

-----Original Message-----
From:=20 Jean-Francois Mule [mailto:jf.mule@cablelabs.com]<= /FONT>=20
Sent: Thursday, January 06, 2005 3:54 PM =
To: Wijnen, Bert (Bert); andre.lejeune@Terayon.com;=20 foko@c-cor.net
Cc: gnakanishi@motorola.com; = Eduardo=20 Cardona; ipcdn@ietf.org; DOCSIS OSS
Majordomo=20 List
Subject: RE: [ipcdn] RE: IETF IPCDN = proposed=20 standard drafts MIB Modules
O ID assignmen = ts:=20 Assigning new RFCs under mib-2


Bert,

  We have discussed this set of issues for = DOCSIS with=20 Thomas Narten, yourself and Rich many times since 2002. Since then, I = do not=20 believe we have a mismatch. What was done was done, there is not much = we=20 CableLabs, the vendors or anyone can do about it.

  Let me be clear that we have worked hard to = change the=20 way we do things with MIBs and other IETF Internet-Drafts for that = matter. My=20 earlier emails on what we have done in PacketCable should provide = detailed=20 examples. Let me give you another example: in the SIP/SIPPING working = groups,=20 with the help of several vendors, we initiated the SIP DCS = proxy-to-proxy=20 draft and we worked with the wg chairs and Allison to get the draft = to RFC. We=20 then changed our SIP-based spec (PacketCable CMSS) to reference this = RFC. Same=20 for RFC 3495 on DHCP option 122 (which replaced an experimental DHCP = option=20 177 assignment and that transition has gone well in the specs and in = the=20 field).

 See inline for additional comments. =

Jean-Fran=E7ois

> -----Original Message-----
>=20 From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20
> Sent: Thursday, January 06, 2005 11:51 = AM=20
> To: andre.lejeune@Terayon.com; = foko@c-cor.net;=20 Jean-Francois Mule
> Cc: = gnakanishi@motorola.com;=20 Eduardo Cardona; ipcdn@ietf.org;
> = DOCSIS OSS=20 Majordomo List
> Subject: RE: [ipcdn] = RE: IETF=20 IPCDN proposed standard drafts
> MIB = Modules O ID=20 assignmen ts: Assigning new RFCs under mib-2
>=20
>
> = Andre,=20
>
> It sounds like = we have a=20 SERIOUS MISMATCH between CL and
> IETF.=20
  As I said above, I don't think we = have any=20 serious mismatch. 

> If CL wants to define their own stuff and = mandate=20
> implementations BEFORE IETF approves a = MIB=20 document, then
> that is fine... =
> but then one should not come to IETF and try =
> to get IETF approval. It just does not work that = way.

  With the time some of us put in the IETF = work in=20 various working groups, and my wg chair stance on IPCDN MIB issues = when folks=20 invoked "existing implementation" reasons in order not to address the = comment,=20 I hope you believe that we bring some contributions in the full = spirit of IETF=20 and that we benefit from expert advice and simple good engineering=20 practices.


> And even if you do these sort of things just = within CL,=20 even
> then I do see that you guys can = easily run=20 into
> interoperability problems. =
  You bet.

> We are not doing this just for the =
> fun of it, but because there are serious risks for=20
> inetroperability problems! =
>
> AGAIN, as I said before. = if you want=20 to root under docsIfMIb,
> fine. Write a = doc=20 similar to
> RFC3737 and we can do it. = Not that we=20 (IETF MIB Doctors)
> prefer it that way, = but we/you=20 (IPCDN WG) can do it that way.


  Back to the original question, I have yet to = see any=20 good reason for not changing the OID assignment to mib-2 for the IETF = IPCDN=20 DOCSIS QoS MIB. Did I miss anything?


> It would still mean = that you can=20 only get the branch assigned
> = underneath docsIfMib=20 AFTER IESG approval. That comes back to
> possible=20 interoperability issues if you assign it earlier.
>=20
> Bert
NOTICE: = This=20 communication contains information which may be proprietary, = privileged or=20 confidential. If you are not the intended recipient (or authorized to = receive=20 for the intended recipient), or believe that you have received this=20 communication in error, please do not print, copy,retransmit, = disseminate,=20 disclose or otherwise use the information. Also, please indicate to = the sender=20 that you have received this communication in error and delete the = copy you=20 received. Thank you.

------_=_NextPart_001_01C4F439.680E909C-- --===============1141908513== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============1141908513==-- From ipcdn-bounces@ietf.org Thu Jan 6 17:43:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02060 for ; Thu, 6 Jan 2005 17:43:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmgZA-0005yW-HU for ipcdn-archive@ietf.org; Thu, 06 Jan 2005 17:57:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmgK7-0005AI-Sj; Thu, 06 Jan 2005 17:41:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmgIn-0004MR-Ti for ipcdn@megatron.ietf.org; Thu, 06 Jan 2005 17:40:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01851 for ; Thu, 6 Jan 2005 17:40:19 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmgVf-0005rn-5W for ipcdn@ietf.org; Thu, 06 Jan 2005 17:53:39 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j06Mdf1e000422; Thu, 6 Jan 2005 15:39:42 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2 Date: Thu, 6 Jan 2005 15:39:41 -0700 Message-ID: Thread-Topic: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2 Thread-Index: AcT0NNqC/WZWk+3LSrSzttC2xuJ8awABJBIw From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable Cc: Eduardo Cardona , ipcdn@ietf.org, DOCSIS OSS Majordomo List , gnakanishi@motorola.com, bwijnen@lucent.com X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: quoted-printable All right, back to good technical discussions. Andre wrote: > Jean-Francois,=20 > What are the attributes that a MIB has to have, in your=20 > opinion, for being added to the transmission OID under mib-2,=20 > as opposed to only be added to mib-2?=20 I believe some rough and vague guidelines can be found in the old MIB-II (RFC 1213 section 3.12) - now transmission is normatively defined by rfc2578 I think (SNMPv2-SMI). And that section 3.12 is the section I considered before I sent the email yesterday. Here is an outdated dump of the first assignments under the transmission branch: Prefix: iso.org.dod.internet.mgmt.mib-2.transmission (1.3.6.1.2.1.10) Decimal Name Description ------- ---- ----------- 5 x25 X.25 [RFC1382] 7 IEEE802.3 CSMACD--like Objects [RFC1650] 8 IEEE802.4 Token Bus-like Objects =20 -- [RFC1230,RFC1239] 9 dot5 Token Ring-like Objects [RFC1743] 15 FDDI FDDI Objects [RFC1285,JDC20] 16 lapb LAP B [RFC1381] 18 ds1 T1 Carrier Objects [RFC1406] 19 e1 E1 Carrier Objects [RFC1406] 23 ppp Point-to-Point Protocol [RFC1471] 30 ds3 DS3/E3 Interface Objects [RFC1407] 31 sip SMDS Interface Objects [RFC1694] 32 frame-relay Frame Relay Objects [RFC1315,CXB] 33 RS-232 RS-232 Objects [RFC1659] 34 Parallel Parallel Printer Objects [RFC1660] 35 arcnet ARC network =20 36 arcnet-plus ARC network plus 37 atm ATM 38 MIOX25 MIOX25 [RFC1461] 39 sonetMIB SONET MIB [RFC1595] 44 frnetservMIB Frame Relay Service MIB for DCE [RFC1596] ... 127 docsIfMib DOCSIS RFI MIB [RFC2670] The DOCSIS RFI mib clearly defined a new type of transmission media (docsis mac layer which fits somewhat well within the above table). The key question is: why should the QoS MIB stay under transmission 127?=20 One could argue that it defines interface extensions (the docsQosPktClassTable relies on ifIndex being an ifType of 127) - hence the justification. And this is fine by me: as my earlier post, I stated, we could document those kinds of motivations in a document (Bert added in an RFC3737-like document).=20 My earlier email asked the question: do *we* in IPCDN see any real impact of changing the assignment of the IETF IPCDN *Internet-Draft* from *unassigned_by_IANA_under_docsIfMib* to *unassigned_by_IANA_under_mib-2*? There, I could not find any good reasons as I started in the email. That said, I would raise the following considerations: - because of the mal practices of assigning DOCSIS MIBs under docsIfMib (by CableLabs), I would argue that the best thing we can do is break the current OID given the syntactic and semantic MIB changes; that means either request that IANA assigns a random OID under docsIfMib that does *not* match the one that has been allocated, or, request that IANA assigned an OID under MIB-2; I think this is one of the points where I fundamentally disagree with your argumentation. Since the MIB module has changed so much, the best thing we can do to avoid OID namespace conflict and nightmares is to make sure the IETF IPCDN RFC root is different from the one used (or more correctly wrongfully used). - Mike Heard's MIB authoring guidelines (http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guideline s-03.txt) do state something about uniqueness of the OIDs, and this is a key point to me. Hence my earlier email: - if IANA were to assign this QoS MIB under a mib-2 root, I do not see any real implications. It is more a MIB tree management issue that the IETF ops area and mib doctors should worry about that I guess. I personally do not like the multiplication of branches (I tend to like more leaves rather than branches ;) - If IANA were to assign it under a docsIfMib root, there are no real implications from an IETF point of view but there might be some tough times in implementations and potential migrations --- if and when the CableLabs requirements change which again is an argument that does not belong here. I hope this answers your question. Let me add something you stated earlier which I strongly oppose: You wrote: > Maybe the solution to all this is to let the the IANA assign=20 > the numbers to wherever they want, but define requirements in=20 > the DOCSIS OSSI spec to re-root each of these RFCs to where=20 > they were first allocated. No. Do you realize that the latest QoS MIB internet-drafts have changed some object syntax? DSCP for e.g. Do you want an OID to map to 2 different, imcompatible object definitions? Because that is what I think you end up with if you follow what you say. > This is ugly in terms of=20 > documentation, but it matches the reality of having two=20 > standard bodies trying to define the same things, each with=20 > their own valid reasons. Dr. Richard Green, CableLabs CEO continue to say that CableLabs is not a standard body, period. We work with other SDOs to get our specifications to standardization level, like SCTE, ANSI, ETSI in Europe. Dr. Richard Green is also the chairman of ITU-T SG9 where DOCSIS is an international standard approved as an ITU-T recommendation. And this is just not the way we have worked within IETF to date: the IETF IPCDN mibs contain sometimes drastic changes to our original submission (see the use of the diffserv mib objects in the subs mgmt mib, section 3.3 of http://www.ipcdn.org/drafts/draft-ietf-ipcdn-subscriber-mib-16.txt). Our goal is to get those MIBs to stable RFC status with all the changes that were brought through this process. Jean-Francois. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Jan 7 03:14:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24332 for ; Fri, 7 Jan 2005 03:14:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmpTm-00081o-JU for ipcdn-archive@ietf.org; Fri, 07 Jan 2005 03:28:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmpBA-0005mk-O0; Fri, 07 Jan 2005 03:09:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmp77-000423-J7 for ipcdn@megatron.ietf.org; Fri, 07 Jan 2005 03:04:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23883 for ; Fri, 7 Jan 2005 03:04:52 -0500 (EST) Received: from mail.stargus.com ([65.193.169.166] helo=xchange.stargus.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CmpK0-0007S2-JC for ipcdn@ietf.org; Fri, 07 Jan 2005 03:18:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2 Date: Fri, 7 Jan 2005 03:04:39 -0500 Message-ID: <6FEBB4954538C7408210BEDBE4843642311E3E@xchange.stargus.com> Thread-Topic: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2 Thread-Index: AcT0OZFhW1QjYRLRSLCQawhklgmNXAASnMcg From: "Fred Oko" To: "Woundy, Richard" , , X-Spam-Score: 0.6 (/) X-Scan-Signature: 8970a17ea8642e1e9e9a967e2088f88d Cc: gnakanishi@motorola.com, e.cardona@cablelabs.com, ipcdn@ietf.org, bwijnen@lucent.com, docsis-oss@cablelabs.com X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1740332203==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 0489daa2bca46f53f2cc9214d1b54371 This is a multi-part message in MIME format. --===============1740332203== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4F48F.8996275A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4F48F.8996275A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would be interested seeing best practices that have been learned by = readers of this reflector contributed to the 04 version of the noted = draft-ietf-ops-mib-review-guidelines-03.txt. In particular, as an = expansion upon the advise against using experimental for anything that = would see field deployment (as is the case for all IPCDN drafts and the = like) the advice of the possibly cleaner direction of using enterprise = space (e.g. CableLabs enterprise clabProj* of noted path being taken by = IPCDN) with notes for the possible necessities of re-rooting. =20 =20 4.3. Naming Hierarchy Experience has shown that it is impractical to move objects from one subtree to another once those objects have seen large-scale use in an operational environment. Hence any object that is targeted for deployment in an operational environment MUST NOT be registered under the experimental subtree, irrespective of the standardization status of that object. The experimental subtree should be used only for objects that are intended for limited experimental deployment. Such objects typically are defined in Experimental RFCs. =20 =20 -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]=20 Sent: Thursday, January 06, 2005 4:48 PM To: 'andre.lejeune@terayon.com'; jf.mule@cablelabs.com Cc: gnakanishi@motorola.com; e.cardona@cablelabs.com; ipcdn@ietf.org; = docsis-oss@cablelabs.com; bwijnen@lucent.com; Fred Oko Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules = O ID assignmen ts: Assigning new RFCs under mib-2 =20 Here is what the current MIB guidelines = (http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines= -03.txt = , section 4.5)have to say: =20 - The value assigned to the MODULE-IDENTITY descriptor MUST be unique and (for IETF standards-track MIB modules) SHOULD reside under the mgmt subtree [RFC2578]. Most often it will be an IANA-assigned value directly under mib-2 [RFC2578], although for media-specific MIB modules that extend the IF-MIB [RFC2863] it is customary to use an IANA-assigned value under transmission [RFC2578]. In the past some IETF working groups have made their own assignments from subtrees delegated to them by IANA, but that practice has proven problematic and is NOT RECOMMENDED. =20 -- Rich -----Original Message----- From: owner-docsis-oss@cablelabs.com = [mailto:owner-docsis-oss@cablelabs.com] On Behalf Of = andre.lejeune@terayon.com Sent: Thursday, January 06, 2005 4:14 PM To: jf.mule@cablelabs.com Cc: gnakanishi@motorola.com; e.cardona@cablelabs.com; ipcdn@ietf.org; = docsis-oss@cablelabs.com; bwijnen@lucent.com; foko@c-cor.net Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB = Modules O ID assignmen ts: Assigning new RFCs under mib-2 Jean-Francois,=20 What are the attributes that a MIB has to have, in your opinion, for = being added to the transmission OID under mib-2, as opposed to only be = added to mib-2? I presented my opinion regarding this, which was that a = MIB that would only be applicable to a certain type of interface would = be better placed under the associated transmission type rather than = being placed at the mib-2 level. I have not seen any justification for = not doing this with the QoS MIB and BPI+ MIBs, other than the fact that = the latest drafts of the BPI+ MIB is requesting them under mib-2, which = is not a sufficient justification in my opinion. Andr=E9=20 -----Original Message-----=20 From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 Sent: Thursday, January 06, 2005 3:54 PM=20 To: Wijnen, Bert (Bert); andre.lejeune@Terayon.com; foko@c-cor.net=20 Cc: gnakanishi@motorola.com; Eduardo Cardona; ipcdn@ietf.org; DOCSIS = OSS=20 Majordomo List=20 Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB = Modules=20 O ID assignmen ts: Assigning new RFCs under mib-2=20 =20 Bert,=20 We have discussed this set of issues for DOCSIS with Thomas Narten, = yourself and Rich many times since 2002. Since then, I do not believe we = have a mismatch. What was done was done, there is not much we CableLabs, = the vendors or anyone can do about it. Let me be clear that we have worked hard to change the way we do = things with MIBs and other IETF Internet-Drafts for that matter. My = earlier emails on what we have done in PacketCable should provide = detailed examples. Let me give you another example: in the SIP/SIPPING = working groups, with the help of several vendors, we initiated the SIP = DCS proxy-to-proxy draft and we worked with the wg chairs and Allison to = get the draft to RFC. We then changed our SIP-based spec (PacketCable = CMSS) to reference this RFC. Same for RFC 3495 on DHCP option 122 (which = replaced an experimental DHCP option 177 assignment and that transition = has gone well in the specs and in the field). See inline for additional comments.=20 Jean-Fran=E7ois=20 > -----Original Message-----=20 > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 > Sent: Thursday, January 06, 2005 11:51 AM=20 > To: andre.lejeune@Terayon.com; foko@c-cor.net; Jean-Francois Mule=20 > Cc: gnakanishi@motorola.com; Eduardo Cardona; ipcdn@ietf.org;=20 > DOCSIS OSS Majordomo List=20 > Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts=20 > MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2=20 >=20 >=20 > Andre,=20 >=20 > It sounds like we have a SERIOUS MISMATCH between CL and=20 > IETF.=20 As I said above, I don't think we have any serious mismatch. =20 > If CL wants to define their own stuff and mandate=20 > implementations BEFORE IETF approves a MIB document, then=20 > that is fine...=20 > but then one should not come to IETF and try=20 > to get IETF approval. It just does not work that way.=20 With the time some of us put in the IETF work in various working = groups, and my wg chair stance on IPCDN MIB issues when folks invoked = "existing implementation" reasons in order not to address the comment, I = hope you believe that we bring some contributions in the full spirit of = IETF and that we benefit from expert advice and simple good engineering = practices. =20 > And even if you do these sort of things just within CL, even=20 > then I do see that you guys can easily run into=20 > interoperability problems.=20 You bet.=20 > We are not doing this just for the=20 > fun of it, but because there are serious risks for=20 > inetroperability problems!=20 >=20 > AGAIN, as I said before. if you want to root under docsIfMIb,=20 > fine. Write a doc similar to=20 > RFC3737 and we can do it. Not that we (IETF MIB Doctors)=20 > prefer it that way, but we/you (IPCDN WG) can do it that way.=20 =20 Back to the original question, I have yet to see any good reason for = not changing the OID assignment to mib-2 for the IETF IPCDN DOCSIS QoS = MIB. Did I miss anything? =09 > It would still mean that you can only get the branch assigned=20 > underneath docsIfMib AFTER IESG approval. That comes back to=20 > possible interoperability issues if you assign it earlier.=20 >=20 > Bert=20 NOTICE: This communication contains information which may be = proprietary, privileged or confidential. If you are not the intended = recipient (or authorized to receive for the intended recipient), or = believe that you have received this communication in error, please do = not print, copy,retransmit, disseminate, disclose or otherwise use the = information. Also, please indicate to the sender that you have received = this communication in error and delete the copy you received. Thank you. ------_=_NextPart_001_01C4F48F.8996275A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message

I would be interested seeing best practices that have been learned by readers of this reflector = contributed to the 04 version of the noted draft-ietf-ops-mib-review-guidelines-03.txt. = In particular, as an expansion upon the advise against using experimental for anything = that would see field deployment (as is the case for all IPCDN drafts and the = like) the advice of the possibly cleaner direction of using enterprise space = (e.g. CableLabs enterprise clabProj* of noted path being taken by IPCDN) with notes for the possible necessities = of re-rooting.

 

 

4.3.=A0 Naming = Hierarchy

=A0=A0 Experience has shown that it is impractical to move objects from = one

=A0=A0 subtree to another once = those objects have seen large-scale use in an

=A0=A0 operational environment.=A0 Hence any object that is targeted = for

=A0=A0 deployment in an operational environment MUST NOT = be registered under

=A0=A0 the experimental subtree, irrespective of the standardization status

=A0=A0 of that object.=A0 = The experimental subtree should be used only = for

=A0=A0 objects that are intended for limited experimental deployment.=A0 = Such

=A0=A0 objects typically are defined in Experimental RFCs.

 

 

-----Original = Message-----
From: Woundy, Richard = [mailto:Richard_Woundy@cable.comcast.com]
Sent: Thursday, January = 06, 2005 4:48 PM
To: = 'andre.lejeune@terayon.com'; jf.mule@cablelabs.com
Cc: = gnakanishi@motorola.com; e.cardona@cablelabs.com; ipcdn@ietf.org; docsis-oss@cablelabs.com; bwijnen@lucent.com; Fred Oko
Subject: RE: [ipcdn] RE: = IETF IPCDN proposed standard drafts MIB Modules O ID assignmen ts: Assigning = new RFCs under mib-2

 

Here is what the = current MIB guidelines (http://www.ietf.org/internet= -drafts/draft-ietf-ops-mib-review-guidelines-03.txt, section 4.5)have to say:

 

   - = The value assigned to the MODULE-IDENTITY descriptor MUST be unique
     and (for IETF standards-track MIB modules) = SHOULD reside under the
     mgmt subtree [RFC2578].  Most often it = will be an IANA-assigned
     value directly under mib-2 [RFC2578], although = for media-specific
     MIB modules that extend the IF-MIB [RFC2863] it = is customary to use
     an IANA-assigned value under transmission [RFC2578].  In the past
     some IETF working groups have made their own assignments from
     subtrees delegated to them by IANA, but that = practice has proven
     problematic and is NOT = RECOMMENDED.

 

-- = Rich

-----Original Message-----
From: owner-docsis-oss@cablelabs.com [mailto:owner-docsis-oss@cablelabs.com] = On Behalf Of = andre.lejeune@terayon.com
Sent: Thursday, January = 06, 2005 4:14 PM
To: = jf.mule@cablelabs.com
Cc: = gnakanishi@motorola.com; e.cardona@cablelabs.com; ipcdn@ietf.org; docsis-oss@cablelabs.com; bwijnen@lucent.com; foko@c-cor.net
Subject: RE: [ipcdn] RE: = IETF IPCDN proposed standard drafts MIB Modules O ID assignmen ts: Assigning = new RFCs under mib-2

Jean-Francois,

What are the attributes that a MIB has to = have, in your opinion, for being added to the transmission OID under mib-2, as = opposed to only be added to mib-2? I presented my opinion regarding this, which = was that a MIB that would only be applicable to a certain type of interface = would be better placed under the associated transmission type rather than = being placed at the mib-2 level. I have not seen any justification for not = doing this with the QoS MIB and BPI+ MIBs, other than the fact that the latest = drafts of the BPI+ MIB is requesting them under mib-2, which is not a sufficient justification in my opinion.

Andr=E9

-----Original Message-----
From: Jean-Francois Mule = [mailto:jf.mule@cablelabs.com]
Sent: Thursday, January = 06, 2005 3:54 PM
To: Wijnen, Bert (Bert); andre.lejeune@Terayon.com; foko@c-cor.net
Cc: = gnakanishi@motorola.com; Eduardo Cardona; ipcdn@ietf.org; DOCSIS OSS
Majordomo = List
Subject: RE: [ipcdn] RE: = IETF IPCDN proposed standard drafts MIB Modules
O ID assignmen ts: = Assigning new RFCs under mib-2

 

Bert,

  We have discussed this set of issues = for DOCSIS with Thomas Narten, yourself and Rich many times since 2002. Since then, = I do not believe we have a mismatch. What was done was done, there is not = much we CableLabs, the vendors or anyone can do about = it.

  Let me be clear that we have worked = hard to change the way we do things with MIBs and other IETF Internet-Drafts for = that matter. My earlier emails on what we have done in PacketCable should = provide detailed examples. Let me give you another example: in the SIP/SIPPING = working groups, with the help of several vendors, we initiated the SIP DCS proxy-to-proxy draft and we worked with the wg chairs and Allison to get = the draft to RFC. We then changed our SIP-based spec (PacketCable CMSS) to reference this RFC. Same for RFC 3495 on DHCP option 122 (which replaced = an experimental DHCP option 177 assignment and that transition has gone = well in the specs and in the field).

 See inline for additional = comments.

Jean-Fran=E7ois

> -----Original Message----- =
> From: Wijnen, Bert = (Bert) [mailto:bwijnen@lucent.com] =
> Sent: Thursday, = January 06, 2005 11:51 AM
> To: = andre.lejeune@Terayon.com; foko@c-cor.net; Jean-Francois Mule
> Cc: = gnakanishi@motorola.com; Eduardo Cardona; ipcdn@ietf.org;
> DOCSIS OSS = Majordomo List
> Subject: RE: = [ipcdn] RE: IETF IPCDN proposed standard drafts
> MIB Modules O ID = assignmen ts: Assigning new RFCs under mib-2
>
>
> = Andre,
>
> It sounds like we = have a SERIOUS MISMATCH between CL and
> IETF. =
  As I said above, = I don't think we have any serious mismatch. 

> If CL wants to define their own stuff = and mandate
> implementations = BEFORE IETF approves a MIB document, then
> that is fine... =
> but then one should = not come to IETF and try
> to get IETF = approval. It just does not work that way.

  With the time some of us put in the = IETF work in various working groups, and my wg chair stance on IPCDN MIB issues = when folks invoked "existing implementation" reasons in order not = to address the comment, I hope you believe that we bring some contributions = in the full spirit of IETF and that we benefit from expert advice and simple = good engineering practices.

 

> And even if you do these sort of things = just within CL, even
> then I do see that = you guys can easily run into
> interoperability = problems.
  You = bet.

> We are not doing this just for the =
> fun of it, but = because there are serious risks for
> inetroperability = problems!
>
> AGAIN, as I said = before. if you want to root under docsIfMIb,
> fine. Write a doc = similar to
> RFC3737 and we can = do it. Not that we (IETF MIB Doctors)
> prefer it that way, = but we/you (IPCDN WG) can do it that way.

 

  Back to the original question, I have = yet to see any good reason for not changing the OID assignment to mib-2 for the = IETF IPCDN DOCSIS QoS MIB. Did I miss anything?


> It = would still mean that you can only get the branch assigned
> underneath = docsIfMib AFTER IESG approval. That comes back to
> possible = interoperability issues if you assign it earlier.
>
> Bert =
NOTICE: This = communication contains information which may be proprietary, privileged or confidential. If you = are not the intended recipient (or authorized to receive for the intended recipient), or believe that you have received this communication in = error, please do not print, copy,retransmit, disseminate, disclose or otherwise = use the information. Also, please indicate to the sender that you have = received this communication in error and delete the copy you received. Thank = you.

=00 ------_=_NextPart_001_01C4F48F.8996275A-- --===============1740332203== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============1740332203==-- From ipcdn-bounces@ietf.org Fri Jan 7 03:14:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24350 for ; Fri, 7 Jan 2005 03:14:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmpTm-00081m-GU for ipcdn-archive@ietf.org; Fri, 07 Jan 2005 03:28:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmpAx-0005c4-GD; Fri, 07 Jan 2005 03:08:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmp73-0003yh-HI for ipcdn@megatron.ietf.org; Fri, 07 Jan 2005 03:04:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23880 for ; Fri, 7 Jan 2005 03:04:48 -0500 (EST) Received: from mail.stargus.com ([65.193.169.166] helo=xchange.stargus.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CmpJx-0007S2-LO for ipcdn@ietf.org; Fri, 07 Jan 2005 03:18:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Jan 2005 03:04:30 -0500 Message-ID: <6FEBB4954538C7408210BEDBE4843642311E3F@xchange.stargus.com> Thread-Topic: IETF IPCDN proposed standard drafts MIB Modules OID assignmen ts: Assigning new RFCs under mib-2 Thread-Index: AcTzUaddqE3Ia/N7Q9+N1USBeX79RAAAGBKQAAkl2wAAB83tEAAhN8JAABvxiJA= From: "Fred Oko" To: "Jean-Francois Mule" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Content-Transfer-Encoding: quoted-printable Cc: gnakanishi@motorola.com, Eduardo Cardona , ipcdn@ietf.org, Dan Rice , DOCSIS OSS Majordomo List Subject: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules OID assignmen ts: Assigning new RFCs under mib-2 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Content-Transfer-Encoding: quoted-printable OK, sorry if I have transgressed. In part my cross-posting was something = I questioned and took guidance from seeing some previous cross-posting = (being the most efficient distribution) on the reflectors but will be = careful to avoid such in the future. As a theme of this thread I = embrace, we learn by doing. In part I was under the impression that the draft period was a time not = only for forward evolution but that time would also be given to examine = the operational impact imposed upon MIB implementers and consumers so as = to not run into a brick wall once the RFC is cast in stone/shipped -- we = could later call it foresight. But as you say some of the drafts have = taken directions that no longer support backward-compatibility and would = in fact mandate a re-root to prevent OID<->object conflicts etc. As I = was not tracking this at the time I can only assume that this was the = only (/optimal by consensus) path and no longer open to review e.g. REVISION "200302010000Z" -- February 1, 2003 DESCRIPTION "Published as draft-ietf-ipcdn-qos-mib-07.txt. Changes from qos-mib-06 include: - Re-routed the docQosMib because of compilation errors. - Removed obsolete and deprecated objects. - Renumbered existing objects after removal of obsolete and deprecated objects. and the subsequent renaming to DOCS-IETF-QOS-MIB from DOCS-QOS-MIB.=20 But note that my original references to backward-compatibility were not = referring to the desired intra-MIB backward-compatibility (to the = version mandated to be implemented) we have lost but instead of the = likely necessity of the CMTS to support (post-reroot) = backward-compatability at the SNMP agent application layer by = concurrently exposing both the already-implemented draft MIB in addition = to the RFCed version (i.e. transition period). The only other field = deployment precedent to such a case yet faced by CableLabs MIBs was the = noted docsDev experimental and RFC versions at the CM level. But there = the two versions were interchangeable but for OID root while here there = could be a mandate to support two, as you note, quite different versions = of what in some cases can be expensive MIBs to manage resource-wise. I would think the experiences of the respondents on this thread would = cry out for a better scheme for handling such version incompatibilities = if this is truly such a common occurrence with internet drafts in = industries that demand rapid deployment. I would expect this to be one = trait to consider in evaluating possible technology replacements for = SNMP in DOCSIS3.0 such that it is easier to support versioning through = handshake or views. =20 -----Original Message----- From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 Sent: Thursday, January 06, 2005 1:27 PM To: Fred Oko; andre.lejeune@terayon.com Cc: gnakanishi@motorola.com; Eduardo Cardona; DOCSIS OSS Majordomo List; = ipcdn@ietf.org; Dan Rice Subject: RE: IETF IPCDN proposed standard drafts MIB Modules OID = assignmen ts: Assigning new RFCs under mib-2 Fred, =20 Let me be direct: your email is totally inappropriate, and actually, = misplaced. First, you responded to an email sent by Eduardo Cardona to the sole = DOCSIS OSS reflector and copy the public IETF IPCDN reflector: you are = effectively breaking the IPR policy your company signed. Worse, you = included comments sent by Andr=E9, comments that were solely sent in = response to the DOCSIS OSS email Eduardo had sent). This is = inappropriate. Note that Eduardo and I wanted to ping the CableLabs = DOCSIS OSS vendor team first by respect of the work those vendors have = done for the MIBs and continue to do by bringing implementations to = market - most of those vendors have implemented the DOCSIS MIBs we are = talking about and not all unfortunately are watching the IPCDN traffic. Second, you missed the point of my email, the email I sent to the IETF = IPCDN reflector. Note that in total transparence for the IETF process, = we (Eduardo and myself) did communicate the same points to both the = CableLabs DOCSIS OSS and IETF IPCDN reflectors. We asked internally the = DOCSIS OSS team first as the MIB module in question was designed and = evolved thanks to all the original contributions of the individuals and = vendors part of the DOCSIS OSS team. But in the end (and that is the = purpose on my email), the IETF IPCDN wg prevails and the IETF wg = consensus is the one that matters. Jean-Francois. =20 > -----Original Message----- > From: Fred Oko [mailto:foko@c-cor.net]=20 > Sent: Wednesday, January 05, 2005 8:26 PM > To: Jean-Francois Mule; andre.lejeune@terayon.com > Cc: gnakanishi@motorola.com; Eduardo Cardona; DOCSIS OSS=20 > Majordomo List; ipcdn@ietf.org > Subject: RE: IETF IPCDN proposed standard drafts MIB Modules=20 > OID assignmen ts: Assigning new RFCs under mib-2 >=20 >=20 > I would agree that a MIB for which the author had the=20 > foresight to root in the experimental(3) branch would be=20 > expected (both by MIB consumers and IETF) to be re-rooted for=20 > RFC transition. However, this only applies to the=20 > subscriber-mgmt MIB. I would argue that there is no value,=20 > only negative operational implications, and no impervious=20 > mandate for re-rooting any other MIB that has already seen=20 > widespread implementation and consumption. I would argue this=20 > not only for the QOS MIB, but for any draft MIB for which=20 > originally had a sub-docsIfMib or enterprise root that was=20 > mandated to be supported in any already passed CableLabs=20 > certification wave. The reasoning is that since these objects=20 > were implemented by CM/CMTS vendor and qualified, they have=20 > most certainly been also implemented against by existing OSS=20 > software, wherein lies definite operational impact of such a=20 > major change. >=20 > Impact points of any re-root: > 1) common to any change: CMTS and CM vendor must change code,=20 > CL must update ATP etc for qualifications, vendors must=20 > re-qualify code, and MSO's must deploy new code (granted=20 > required just for other MIB updates if not re-root) > 2) a decision must be made whether a CMTS or CM is=20 > backward-compatible (either as mandated by CL or discretion=20 > of vendor as advised by MSOs) and supporting two instance of=20 > a MIB has implications -- and regardless the decision of=20 > backward-compatibility on a single device, any OSS that=20 > monitors across a non-homogeneous field will of course have=20 > chance to run into new and old instances > a) multiple OIDs for same subidentifiers must be known=20 > by clients which may have preference to use non-fully-qualified > b) if back-compat, collection must limit itself to one=20 > of the two instances to avoid double collection thus=20 > requiring conditional logic based on probing > c) I would expect any MSO with utilities that are=20 > broken by such a re-root will demand this "bug" be fixed by=20 > the vendor thus forcing effective back-compat > d) it may be difficult for some SNMP agent=20 > implementations to support efficient backward-compatability=20 > (i.e. two OIDs mapping to same in-memory data) as such=20 > efficiency would be a must for some of the expensive MIB tables > 3) Since CL CW have continued to require very old drafts we=20 > know that implementation against the "old"/only OIDs have=20 > been in use for a while >=20 > No real impact points of not re-rooting anything -- simplest path: > 1) current OID assignments, while not actually assigned by=20 > IANA are guaranteed to be non-conflicting > 2) no re-roots have been implemented in any code -- they only=20 > exist in more recent drafts thus nullifying them is only on paper >=20 > Additionally I personally see little value in the any=20 > re-roots beyond philosophical cleanliness. I do agree that=20 > all MIBs may not be semantically perfect below docsIf, but I=20 > take it as the best hierarchical umbrella we have on that=20 > road that has been traveled. If we were forced to re-root I=20 > would advocate at least leveraging hierarchy by contextually=20 > group all CL/IPCDN related objects together instead of having=20 > them assigned loosely and likely non-contiguously into the=20 > mib-2 free space. E.g. in that sense I was a fan of the=20 > enterprise clab root. >=20 > The very nature of so many representative MIB-rooting=20 > conventions across the many CL-related MIBs (docsIf,=20 > experimental, mib-2-pending, clab) suggests if this is not=20 > exactly a contentious issue, it is definitely one still open=20 > to the author's discretion which one might tend to agree has=20 > been non-optimal. I also see a variable modification time of=20 > these drafts at some middle revision to change OID roots=20 > which indicates it was not guided by a single firm guiding=20 > consensus (but perhaps MIB doctor advice trickle effect?). I=20 > would advocate that a firm future-guiding decision be made=20 > that would apply to all as-of-yet unwritten MIBs. >=20 > Though were these proposed re-roots to make their way=20 > unimpeded into continued-draft/RFC/ECR/cert-wave would a good=20 > time estimate to seeing such in the field be late 2006? _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Jan 7 10:49:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22125 for ; Fri, 7 Jan 2005 10:49:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmwZQ-0000cP-6s for ipcdn-archive@ietf.org; Fri, 07 Jan 2005 11:02:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmwKv-0005Pt-0m; Fri, 07 Jan 2005 10:47:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmwDx-0003SO-RX for ipcdn@megatron.ietf.org; Fri, 07 Jan 2005 10:40:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21725 for ; Fri, 7 Jan 2005 10:40:23 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmwQu-00085b-U7 for ipcdn@ietf.org; Fri, 07 Jan 2005 10:53:52 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j07Fdf1e006862; Fri, 7 Jan 2005 08:39:41 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Jan 2005 08:39:41 -0700 Message-ID: <5259D0D7419C6149B347837A2E64F46F06A4AB@srvxchg.cablelabs.com> Thread-Topic: IETF IPCDN proposed standard drafts MIB Modules OID assignmen ts: Assigning new RFCs under mib-2 Thread-Index: AcTzUaddqE3Ia/N7Q9+N1USBeX79RAAAGBKQAAkl2wAAB83tEAAhN8JAABvxiJAAD1CWIA== From: "Eduardo Cardona" To: "Fred Oko" , "Jean-Francois Mule" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Content-Transfer-Encoding: quoted-printable Cc: gnakanishi@motorola.com, DOCSIS OSS Majordomo List , ipcdn@ietf.org, Dan Rice Subject: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules OID assignmen ts: Assigning new RFCs under mib-2 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Content-Transfer-Encoding: quoted-printable few comments inline -----Original Message----- From: Fred Oko [mailto:foko@c-cor.net]=20 Sent: Friday, January 07, 2005 1:05 AM To: Jean-Francois Mule; andre.lejeune@terayon.com Cc: gnakanishi@motorola.com; Eduardo Cardona; DOCSIS OSS Majordomo List; = ipcdn@ietf.org; Dan Rice Subject: RE: IETF IPCDN proposed standard drafts MIB Modules OID = assignmen ts: Assigning new RFCs under mib-2 OK, sorry if I have transgressed. In part my cross-posting was something = I questioned and took guidance from seeing some previous cross-posting = (being the most efficient distribution) on the reflectors but will be = careful to avoid such in the future. As a theme of this thread I = embrace, we learn by doing. In part I was under the impression that the draft period was a time not = only for forward evolution but that time would also be given to examine = the operational impact imposed upon MIB implementers and consumers so as = to not run into a brick wall once the RFC is cast in stone/shipped -- we = could later call it foresight. But as you say some of the drafts have = taken directions that no longer support backward-compatibility and would = in fact mandate a re-root to prevent OID<->object conflicts etc. As I = was not tracking this at the time I can only assume that this was the = only (/optimal by consensus) path and no longer open to review e.g. REVISION "200302010000Z" -- February 1, 2003 DESCRIPTION "Published as draft-ietf-ipcdn-qos-mib-07.txt. Changes from qos-mib-06 include: - Re-routed the docQosMib because of compilation errors. - Removed obsolete and deprecated objects. - Renumbered existing objects after removal of obsolete and deprecated objects. and the subsequent renaming to DOCS-IETF-QOS-MIB from DOCS-QOS-MIB.=20 But note that my original references to backward-compatibility were not = referring to the desired intra-MIB backward-compatibility (to the = version mandated to be implemented) we have lost but instead of the = likely necessity of the CMTS to support (post-reroot) = backward-compatability at the SNMP agent application layer by = concurrently exposing both the already-implemented draft MIB in addition = to the RFCed version (i.e. transition period). The only other field = deployment precedent to such a case yet faced by CableLabs MIBs was the = noted docsDev experimental and RFC versions at the CM level. But there = the two versions were interchangeable but for OID root while here there = could be a mandate to support two, as you note, quite different versions = of what in some cases can be expensive MIBs to manage resource-wise. I would think the experiences of the respondents on this thread would = cry out for a better scheme for handling such version incompatibilities = if this is truly such a common occurrence with internet drafts in = industries that demand rapid deployment. I would expect this to be one = trait to consider in evaluating possible technology replacements for = SNMP in DOCSIS3.0 such that it is easier to support versioning through = handshake or views. =20 SNMP semantics is believed to be rich enough to have a solution for = transitions,=20 If in the past docsis required the dual implementation of CD MIB in = experimental as well as RFC 2669, we always take take the exercise of = evaluate those consiredations for backward compatible analysis as the = specs evolve Specially on those days (DOCSIS 1.0) it was a matter of one MIB module = for CMs with reduced number of instances per MIB structures such tables. = In the current case (anyway outside of the topic discussion) we are also = covering CMTS which is a different situation Thanks for pointing out those elements that certainly are critical in = deciding where to shift the transition cost ( device or Management = system). =20 - The history told us that DOCSIS 1.0 put the load in the CM,=20 DOCSIS 1.1 removed that "dual" MIB requirement so we have 4 years of = DOCSIS 1.1 requirements that hopefully are pusshing the NMS applications = to the next level In particular, as well as SNMPv3 stack normaly automatically does Engine = ID discovery, I believe it is expected for the NMS to do Mib modules per = device registeration by querying sysOrTable and dynamically swap MIB = modules and or Management routines and scripts. (Agree reads simple but = could be complex, but what application on todays days is dump simple?) That's not such difference on already products ready to switch from IP = MIB RFC 2011 to the upcoming RFC 2011 updates for IPv6. as an example: ipNetToPhysicalTable replaces ipNetToMedia - Changes of Object names - Changes of Index structure ( INETAddress requirements) It means total applications rewrite In our case "in the eventuality of updates" to new RFCs - Majority of the objects keep the same name ( different MODULE name) - A discovery process as indicated above will do most of the work - Potentially Apps can stay quite the same, just the OID engine need to = be smarter Again, not saying that is easy, cost implications etc. other forums or = discussions will decide that. In summary, The Cable transition from one root to another, Is necessary, = not an isolated case, (not exclusive for "rapid deployment" industries). = All IETF faces those paradigms, and the solutions for backward = compatibility, and old devices support should (wish) come from all IETF = parties.=20 Your DOCSIS 3.0 comments Based on your inertia of cross-pointing lists, please note that there is = also a DOCSIS 3.0 Majordomo list, which I verified you are already = subscribed. =20 =20 -----Original Message----- From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 Sent: Thursday, January 06, 2005 1:27 PM To: Fred Oko; andre.lejeune@terayon.com Cc: gnakanishi@motorola.com; Eduardo Cardona; DOCSIS OSS Majordomo List; = ipcdn@ietf.org; Dan Rice Subject: RE: IETF IPCDN proposed standard drafts MIB Modules OID = assignmen ts: Assigning new RFCs under mib-2 Fred, =20 Let me be direct: your email is totally inappropriate, and actually, = misplaced. First, you responded to an email sent by Eduardo Cardona to the sole = DOCSIS OSS reflector and copy the public IETF IPCDN reflector: you are = effectively breaking the IPR policy your company signed. Worse, you = included comments sent by Andr=E9, comments that were solely sent in = response to the DOCSIS OSS email Eduardo had sent). This is = inappropriate. Note that Eduardo and I wanted to ping the CableLabs = DOCSIS OSS vendor team first by respect of the work those vendors have = done for the MIBs and continue to do by bringing implementations to = market - most of those vendors have implemented the DOCSIS MIBs we are = talking about and not all unfortunately are watching the IPCDN traffic. Second, you missed the point of my email, the email I sent to the IETF = IPCDN reflector. Note that in total transparence for the IETF process, = we (Eduardo and myself) did communicate the same points to both the = CableLabs DOCSIS OSS and IETF IPCDN reflectors. We asked internally the = DOCSIS OSS team first as the MIB module in question was designed and = evolved thanks to all the original contributions of the individuals and = vendors part of the DOCSIS OSS team. But in the end (and that is the = purpose on my email), the IETF IPCDN wg prevails and the IETF wg = consensus is the one that matters. Jean-Francois. =20 > -----Original Message----- > From: Fred Oko [mailto:foko@c-cor.net] > Sent: Wednesday, January 05, 2005 8:26 PM > To: Jean-Francois Mule; andre.lejeune@terayon.com > Cc: gnakanishi@motorola.com; Eduardo Cardona; DOCSIS OSS=20 > Majordomo List; ipcdn@ietf.org > Subject: RE: IETF IPCDN proposed standard drafts MIB Modules=20 > OID assignmen ts: Assigning new RFCs under mib-2 >=20 >=20 > I would agree that a MIB for which the author had the > foresight to root in the experimental(3) branch would be=20 > expected (both by MIB consumers and IETF) to be re-rooted for=20 > RFC transition. However, this only applies to the=20 > subscriber-mgmt MIB. I would argue that there is no value,=20 > only negative operational implications, and no impervious=20 > mandate for re-rooting any other MIB that has already seen=20 > widespread implementation and consumption. I would argue this=20 > not only for the QOS MIB, but for any draft MIB for which=20 > originally had a sub-docsIfMib or enterprise root that was=20 > mandated to be supported in any already passed CableLabs=20 > certification wave. The reasoning is that since these objects=20 > were implemented by CM/CMTS vendor and qualified, they have=20 > most certainly been also implemented against by existing OSS=20 > software, wherein lies definite operational impact of such a=20 > major change. >=20 > Impact points of any re-root: > 1) common to any change: CMTS and CM vendor must change code, > CL must update ATP etc for qualifications, vendors must=20 > re-qualify code, and MSO's must deploy new code (granted=20 > required just for other MIB updates if not re-root) > 2) a decision must be made whether a CMTS or CM is=20 > backward-compatible (either as mandated by CL or discretion=20 > of vendor as advised by MSOs) and supporting two instance of=20 > a MIB has implications -- and regardless the decision of=20 > backward-compatibility on a single device, any OSS that=20 > monitors across a non-homogeneous field will of course have=20 > chance to run into new and old instances > a) multiple OIDs for same subidentifiers must be known=20 > by clients which may have preference to use non-fully-qualified > b) if back-compat, collection must limit itself to one=20 > of the two instances to avoid double collection thus=20 > requiring conditional logic based on probing > c) I would expect any MSO with utilities that are=20 > broken by such a re-root will demand this "bug" be fixed by=20 > the vendor thus forcing effective back-compat > d) it may be difficult for some SNMP agent=20 > implementations to support efficient backward-compatability=20 > (i.e. two OIDs mapping to same in-memory data) as such=20 > efficiency would be a must for some of the expensive MIB tables > 3) Since CL CW have continued to require very old drafts we=20 > know that implementation against the "old"/only OIDs have=20 > been in use for a while >=20 > No real impact points of not re-rooting anything -- simplest path: > 1) current OID assignments, while not actually assigned by > IANA are guaranteed to be non-conflicting > 2) no re-roots have been implemented in any code -- they only=20 > exist in more recent drafts thus nullifying them is only on paper >=20 > Additionally I personally see little value in the any > re-roots beyond philosophical cleanliness. I do agree that=20 > all MIBs may not be semantically perfect below docsIf, but I=20 > take it as the best hierarchical umbrella we have on that=20 > road that has been traveled. If we were forced to re-root I=20 > would advocate at least leveraging hierarchy by contextually=20 > group all CL/IPCDN related objects together instead of having=20 > them assigned loosely and likely non-contiguously into the=20 > mib-2 free space. E.g. in that sense I was a fan of the=20 > enterprise clab root. >=20 > The very nature of so many representative MIB-rooting > conventions across the many CL-related MIBs (docsIf,=20 > experimental, mib-2-pending, clab) suggests if this is not=20 > exactly a contentious issue, it is definitely one still open=20 > to the author's discretion which one might tend to agree has=20 > been non-optimal. I also see a variable modification time of=20 > these drafts at some middle revision to change OID roots=20 > which indicates it was not guided by a single firm guiding=20 > consensus (but perhaps MIB doctor advice trickle effect?). I=20 > would advocate that a firm future-guiding decision be made=20 > that would apply to all as-of-yet unwritten MIBs. >=20 > Though were these proposed re-roots to make their way > unimpeded into continued-draft/RFC/ECR/cert-wave would a good=20 > time estimate to seeing such in the field be late 2006? _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Jan 7 14:45:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08261 for ; Fri, 7 Jan 2005 14:45:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn0GA-0002BW-1u for ipcdn-archive@ietf.org; Fri, 07 Jan 2005 14:58:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn01Z-00055N-BH; Fri, 07 Jan 2005 14:43:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmzwg-0003qf-Cq for ipcdn@megatron.ietf.org; Fri, 07 Jan 2005 14:38:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07834 for ; Fri, 7 Jan 2005 14:38:49 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn09j-0001Q8-9F for ipcdn@ietf.org; Fri, 07 Jan 2005 14:52:19 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j07JcA1e029453; Fri, 7 Jan 2005 12:38:10 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Jan 2005 12:38:10 -0700 Message-ID: Thread-Topic: IETF IPCDN proposed standard drafts MIB Modules OID assignmen ts: Assigning new RFCs under mib-2 Thread-Index: AcTzUaddqE3Ia/N7Q9+N1USBeX79RAAAGBKQAAkl2wAAB83tEAAhN8JAABvxiJAAGQEWoA== From: "Jean-Francois Mule" To: "Fred Oko" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Cc: gnakanishi@motorola.com, Eduardo Cardona , ipcdn@ietf.org, Dan Rice , DOCSIS OSS Majordomo List Subject: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules OID assignmen ts: Assigning new RFCs under mib-2 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Fred Oko wrote: > OK, sorry if I have transgressed. In part my cross-posting=20 > was something I questioned and took guidance from seeing some=20 > previous cross-posting (being the most efficient=20 > distribution) on the reflectors but will be careful to avoid=20 > such in the future. As a theme of this thread I embrace, we=20 > learn by doing. No problem. Sorry if my email response was perceived as harsh, it was = not intended. [snip] Fred Oko wrote: > But as you say some of the drafts have=20 > taken directions that no longer support=20 > backward-compatibility and would in fact mandate a re-root to=20 > prevent OID<->object conflicts etc.=20 So does this mean you are ok with the IETF IPCDN QoS MIB Internet-Draft = 10 being changed to request an OID assignment under ..mib-2(1)? I would = like to get wg consensus on this: we have to move this draft along to = get it on the IESG agenda asap. > As I was not tracking=20 > this at the time I can only assume that this was the only=20 > (/optimal by consensus) path and no longer open to review e.g. >=20 > REVISION "200302010000Z" -- February 1, 2003 > DESCRIPTION > "Published as draft-ietf-ipcdn-qos-mib-07.txt. >=20 > Changes from qos-mib-06 include: >=20 > - Re-routed the docQosMib because of compilation errors. > - Removed obsolete and deprecated objects. > - Renumbered existing objects after removal of > obsolete and deprecated objects. >=20 > and the subsequent renaming to DOCS-IETF-QOS-MIB from DOCS-QOS-MIB. Yes. For reference, this is well documented. On 2/13/03, during the interim IPCDN wg meeting held at CableLabs = chaired by Rich Woundy and myself, Bert Wijnen had strongly recommended = this approach when reviewing the BPI+ mib draft 06. We as a wg approved = to re-route the DOCSIS BPI+ then under mib-2, and we also agreed to = change all IPCDN MIB module identity names. See http://www.ipcdn.org/meetings.html, Feb 13 2003 meeting, and the notes recorded in the IETF proceedings at: http://www.ietf.org/proceedings/03mar/slides/ipcdn-1/index.html =20 > But note that my original references to=20 > backward-compatibility were not referring to the desired=20 > intra-MIB backward-compatibility (to the version mandated to=20 > be implemented) we have lost but instead of the likely=20 > necessity of the CMTS to support (post-reroot)=20 > backward-compatability at the SNMP agent application layer by=20 > concurrently exposing both the already-implemented draft MIB=20 > in addition to the RFCed version (i.e. transition period).=20 Ok. The latter is always what I meant. Note that, as I pointed out, = the decision to mandate the "likely necessity of the CMTS to support" is = something that will be done by cable operators. Be assured that we will = deal with this extremely carefully and communicate with the vendors as = part of the CableLabs process (this is btw not a topic for discussion in = IETF). > I would think the experiences of the respondents on this=20 > thread would cry out for a better scheme for handling such=20 > version incompatibilities if this is truly such a common=20 > occurrence with internet drafts in industries that demand=20 > rapid deployment.=20 Isnt' the way we have dealt with those issues in the CableLabs = PacketCable and Cablehome projects answering your request for a better = scheme? Jean-Fran=E7ois=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Jan 7 15:48:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23371 for ; Fri, 7 Jan 2005 15:48:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn1FT-00086Z-IS for ipcdn-archive@ietf.org; Fri, 07 Jan 2005 16:02:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn0vG-0004Ut-A8; Fri, 07 Jan 2005 15:41:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn0t2-0003Hf-GU; Fri, 07 Jan 2005 15:39:08 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20905; Fri, 7 Jan 2005 15:39:06 -0500 (EST) Message-Id: <200501072039.PAA20905@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 07 Jan 2005 15:39:04 -0500 Cc: ipcdn@ietf.org Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-docsisevent-mib-05.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Event Notification Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems Author(s) : A. Ahmad, G. Nakanishi Filename : draft-ietf-ipcdn-docsisevent-mib-05.txt Pages : 41 Date : 2005-1-7 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP- based event notification management of DOCSIS compliant Cable Modems and Cable Modem Termination Systems. This MIB is defined as an extension to the DOCSIS Cable Device MIB. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docsisevent-mib-05.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-ietf-ipcdn-docsisevent-mib-05.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-ietf-ipcdn-docsisevent-mib-05.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: <2005-1-7152154.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-docsisevent-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-docsisevent-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-7152154.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --NextPart-- From ipcdn-bounces@ietf.org Fri Jan 7 18:41:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08409 for ; Fri, 7 Jan 2005 18:41:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn3wH-0005mU-4M for ipcdn-archive@ietf.org; Fri, 07 Jan 2005 18:54:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn3hk-0002qe-IB; Fri, 07 Jan 2005 18:39:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn3hP-0002g2-Nc for ipcdn@megatron.ietf.org; Fri, 07 Jan 2005 18:39:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08321 for ; Fri, 7 Jan 2005 18:39:16 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn3uT-0005Xj-UT for ipcdn@ietf.org; Fri, 07 Jan 2005 18:52:50 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j07Nci1e019452; Fri, 7 Jan 2005 16:38:45 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] New editor for IETF IPCDN DOCSIS cable device MIB v2 ID Date: Fri, 7 Jan 2005 16:38:44 -0700 Message-ID: Thread-Topic: [ipcdn] New editor for IETF IPCDN DOCSIS cable device MIB v2 ID Thread-Index: AcSGETA7YL1c/WVvTxWNSmZECb/jPRR90GvQBUBib2ACAALYUA== From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: quoted-printable Cc: DOCSIS OSS Majordomo List , Kevin.Marez@motorola.com, "Richard Woundy @ Comcast" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: quoted-printable All, I am pleased to announce that Kevin Marez of Motorola has agreed to = be the new editor of the IETF IPCDN Cable Device MIB v2. We should soon = have a plan for the next draft with a target date, the list of = open/closed issues, etc. Thank you for all of those who had expressed interest (I talked to = all of you directly, thanks for your time).=20 Thank you again Kevin. Jean-Francois. > -----Original Message----- > From: Jean-Francois Mule=20 > Sent: Tuesday, December 28, 2004 11:47 AM > To: ipcdn@ietf.org > Cc: DOCSIS OSS Majordomo List; Richard Woundy @ Comcast > Subject: [ipcdn] Update on finding a new editor for IETF=20 > IPCDN DOCSIS cable device MIB v2 ID >=20 >=20 > Folks, >=20 > Just a quick update on my action item to find a new=20 > editor for IETF IPCDN DOCSIS cable device MIB v2. In short, I=20 > have been slow and we only have a couple of volunteers. To=20 > date, we have 4 people on the list (2 have directly responded=20 > to my call for volunteers=20 > html>) and 2 additional names were suggested to me after I=20 > followed up with some folks.=20 > I have contacted all the volunteers, and hopefully soon,=20 > we'll have a new editor. If you are now interested, let me know asap. >=20 >=20 > Below is what I believe should be done to advance the ID: > + take over the expired draft06 > =20 > http://www.ipcdn.org/drafts/draft-ietf-ipcdn-device-mibv2-06.txt=20 >=20 > + take over the list of known issues, sum it up and=20 > publish it as of today with a current status (some issues=20 > raised by mib doctors on draft06 have been addressed by Rich=20 > and others, some are still pending) Here are the MIB doctor=20 > comments/concerns applicable to this ID:=20 > > > (resolved by > =20 > ) > > > (resolved by > =20 > ) >=20 > + nail down the open or pending issues in 2 or 3 weeks=20 > by either putting them to bed forever or addressing them in=20 > consultation with the IETF and DOCSIS OSS teams (all emails=20 > must be sent to the IETF list and resolution must get ipcdn=20 > wg consensus).=20 >=20 > + release draft07 addressing all the issues that needed=20 > to be addressed >=20 > It is imperative that the editor understands the DOCSIS specs=20 > and the CM/CMTS function managed in the MIB objects in=20 > question. It is also imperative that the IETF process be=20 > understood at a high level, and, in particular, that the=20 > candidate be willing to read and consider: > - ID guidelines http://www.ietf.org/ietf/1id-guidelines.txt > - The XML document format for ID editing since the source of=20 > the Internet-draft has now been converted to XML by Rich=20 > using RFC2629 http://xml.resource.org/;=20 > - the IDnits and ID Checklist > http://www.ietf.org/ID-Checklist.html > - the Guidelines for Authors and Reviewers of MIB Documents=20 http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-= 03.txt - and all the other minor things to make the draft compliant with the = laws of the mib doctor kingdom. Did I miss something important? Jean-Francois. > -----Original Message----- > From: Jean-Francois Mule > Sent: Wednesday, November 03, 2004 12:26 PM > To: ipcdn@ietf.org > Subject: [ipcdn] Call for volunteer to be the editor of RFC 2669bis >=20 >=20 > Folks, >=20 > We are hitting a roadblock on the cable dev mib and need a new ID > editor. > =20 > http://www.ipcdn.org/drafts/draft-ietf-ipcdn-device-mibv2-06.t xt is expired. The current status is that numerous comments were received from mib = doctors and a new draft is needed. While some comments have been = addressed in an alpha version of draft 07, we need someone who can take = over the draft and complete the work. While Rich and I can offer = support, we cannot commit to being draft editors anymore on this one. = Rich and I can give more technical details on what's left to address in = draft 07 if needed. Anyone interested? Please let us know via email, or, if you are not = sure yet and want to chat live, ping us and we can organize a call or = chat live at the IETF meeting in Washington DC next week. Thanks, -- Rich and Jean-Fran=E7ois _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Jan 7 18:59:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09351 for ; Fri, 7 Jan 2005 18:59:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn4Dz-0007LB-G5 for ipcdn-archive@ietf.org; Fri, 07 Jan 2005 19:12:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn3yG-0000gV-S6; Fri, 07 Jan 2005 18:56:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn3vq-0008SQ-IE for ipcdn@megatron.ietf.org; Fri, 07 Jan 2005 18:54:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08946 for ; Fri, 7 Jan 2005 18:53:41 -0500 (EST) Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn48H-0006o1-K7 for ipcdn@ietf.org; Fri, 07 Jan 2005 19:07:16 -0500 Received: from [192.168.1.100] (pcp893423pcs.csouth01.va.comcast.net[68.57.128.251]) by comcast.net (rwcrmhc13) with ESMTP id <2005010723522101500oc57qe>; Fri, 7 Jan 2005 23:52:22 +0000 Message-ID: <41DF2090.60809@comcast.net> Date: Fri, 07 Jan 2005 18:51:44 -0500 From: Joshua Brady User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jean-Francois Mule Subject: Re: [ipcdn] New editor for IETF IPCDN DOCSIS cable device MIB v2 ID References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA08946 Cc: DOCSIS OSS Majordomo List , ipcdn@ietf.org, "Richard Woundy @ Comcast" , Kevin.Marez@motorola.com X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Content-Transfer-Encoding: quoted-printable Jean-Francois Mule wrote: > All, >=20 > I am pleased to announce that Kevin Marez of Motorola has agreed to = be the new editor of the IETF IPCDN Cable Device MIB v2. We should soon h= ave a plan for the next draft with a target date, the list of open/closed= issues, etc. >=20 > Thank you for all of those who had expressed interest (I talked to a= ll of you directly, thanks for your time).=20 > Thank you again Kevin. >=20 Thank you Kevin for stepping up to the job! > Jean-Francois. >=20 >=20 >>-----Original Message----- >>From: Jean-Francois Mule=20 >>Sent: Tuesday, December 28, 2004 11:47 AM >>To: ipcdn@ietf.org >>Cc: DOCSIS OSS Majordomo List; Richard Woundy @ Comcast >>Subject: [ipcdn] Update on finding a new editor for IETF=20 >>IPCDN DOCSIS cable device MIB v2 ID >> >> >>Folks, >> >> Just a quick update on my action item to find a new=20 >>editor for IETF IPCDN DOCSIS cable device MIB v2. In short, I=20 >>have been slow and we only have a couple of volunteers. To=20 >>date, we have 4 people on the list (2 have directly responded=20 >>to my call for volunteers=20 >>>html>) and 2 additional names were suggested to me after I=20 >>followed up with some folks.=20 >> I have contacted all the volunteers, and hopefully soon,=20 >>we'll have a new editor. If you are now interested, let me know asap. >> >> >> Below is what I believe should be done to advance the ID: >> + take over the expired draft06 >> =20 >>http://www.ipcdn.org/drafts/draft-ietf-ipcdn-device-mibv2-06.txt=20 >> >> + take over the list of known issues, sum it up and=20 >>publish it as of today with a current status (some issues=20 >>raised by mib doctors on draft06 have been addressed by Rich=20 >>and others, some are still pending) Here are the MIB doctor=20 >>comments/concerns applicable to this ID:=20 >> >> >> (resolved by >> =20 >>) >> >> >> (resolved by >> =20 >>) >> >> + nail down the open or pending issues in 2 or 3 weeks=20 >>by either putting them to bed forever or addressing them in=20 >>consultation with the IETF and DOCSIS OSS teams (all emails=20 >>must be sent to the IETF list and resolution must get ipcdn=20 >>wg consensus).=20 >> >> + release draft07 addressing all the issues that needed=20 >>to be addressed >> >>It is imperative that the editor understands the DOCSIS specs=20 >>and the CM/CMTS function managed in the MIB objects in=20 >>question. It is also imperative that the IETF process be=20 >>understood at a high level, and, in particular, that the=20 >>candidate be willing to read and consider: >>- ID guidelines http://www.ietf.org/ietf/1id-guidelines.txt >>- The XML document format for ID editing since the source of=20 >>the Internet-draft has now been converted to XML by Rich=20 >>using RFC2629 http://xml.resource.org/;=20 >>- the IDnits and ID Checklist >> http://www.ietf.org/ID-Checklist.html >>- the Guidelines for Authors and Reviewers of MIB Documents=20 >=20 > http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guideline= s-03.txt > - and all the other minor things to make the draft compliant with the l= aws of the mib doctor kingdom. >=20 > Did I miss something important? > Jean-Francois. >=20 >=20 >>-----Original Message----- >>From: Jean-Francois Mule >>Sent: Wednesday, November 03, 2004 12:26 PM >>To: ipcdn@ietf.org >>Subject: [ipcdn] Call for volunteer to be the editor of RFC 2669bis >> >> >>Folks, >> >> We are hitting a roadblock on the cable dev mib and need a new ID >>editor. >> =20 >>http://www.ipcdn.org/drafts/draft-ietf-ipcdn-device-mibv2-06.t >=20 > xt is expired. >=20 > The current status is that numerous comments were received from mib d= octors and a new draft is needed. While some comments have been addressed= in an alpha version of draft 07, we need someone who can take over the d= raft and complete the work. While Rich and I can offer support, we canno= t commit to being draft editors anymore on this one. Rich and I can give = more technical details on what's left to address in draft 07 if needed. >=20 > Anyone interested? Please let us know via email, or, if you are not s= ure yet and want to chat live, ping us and we can organize a call or chat= live at the IETF meeting in Washington DC next week. >=20 > Thanks, > -- Rich and Jean-Fran=E7ois >=20 > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn >=20 >=20 > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Jan 10 09:38:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22350 for ; Mon, 10 Jan 2005 09:38:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co0uF-00039p-He for ipcdn-archive@ietf.org; Mon, 10 Jan 2005 09:52:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co0ce-0008JB-9D; Mon, 10 Jan 2005 09:34:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co0Xl-0007Z8-6C for ipcdn@megatron.ietf.org; Mon, 10 Jan 2005 09:29:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21723 for ; Mon, 10 Jan 2005 09:29:14 -0500 (EST) Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co0lJ-0002gV-Uq for ipcdn@ietf.org; Mon, 10 Jan 2005 09:43:21 -0500 Received: from ([172.16.57.92]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.8547373; Fri, 07 Jan 2005 18:09:05 -0500 Received: by oakexsmtp03.cable.comcast.com with Internet Mail Service (5.5.2657.72) id ; Fri, 7 Jan 2005 18:10:01 -0500 Message-ID: From: "Woundy, Richard" To: "'Fred Oko'" , andre.lejeune@terayon.com, jf.mule@cablelabs.com Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2 Date: Fri, 7 Jan 2005 18:09:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.7 (/) X-Scan-Signature: cb256aa41b5300a7da304d7294799ef5 Cc: gnakanishi@motorola.com, e.cardona@cablelabs.com, ipcdn@ietf.org, bwijnen@lucent.com, docsis-oss@cablelabs.com X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0790814840==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: 5f02d6646f83ade536724b616ceb2e16 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0790814840== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4F50D.E02C5F0D" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4F50D.E02C5F0D Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA21723 Content-Transfer-Encoding: quoted-printable >I would be interested seeing best practices that have been learned by readers of this reflector contributed to the 04 version of the noted draft-ietf-ops-mib-review-guidelines-03.txt. =20 OK, if you would like to make comments on these MIB guidelines, you shoul= d bring those comments to the proper forum in the IETF. The draft itself do= es point out the best forum for these comments: =20 Comments on this memo should be submitted to the mailing list. To subscribe to this mailing list send an e-mail message to with the word "subscribe" in the message body. =20 -- Rich -----Original Message----- From: Fred Oko [mailto:foko@c-cor.net]=20 Sent: Friday, January 07, 2005 3:05 AM To: Woundy, Richard; andre.lejeune@terayon.com; jf.mule@cablelabs.com Cc: gnakanishi@motorola.com; e.cardona@cablelabs.com; ipcdn@ietf.org; docsis-oss@cablelabs.com; bwijnen@lucent.com Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules = O ID assignmen ts: Assigning new RFCs under mib-2 I would be interested seeing best practices that have been learned by readers of this reflector contributed to the 04 version of the noted draft-ietf-ops-mib-review-guidelines-03.txt. In particular, as an expansi= on upon the advise against using experimental for anything that would see fi= eld deployment (as is the case for all IPCDN drafts and the like) the advice = of the possibly cleaner direction of using enterprise space (e.g. CableLabs enterprise clabProj* of noted path being taken by IPCDN) with notes for t= he possible necessities of re-rooting. =20 =20 4.3. Naming Hierarchy Experience has shown that it is impractical to move objects from one subtree to another once those objects have seen large-scale use in an operational environment. Hence any object that is targeted for deployment in an operational environment MUST NOT be registered under the experimental subtree, irrespective of the standardization status of that object. The experimental subtree should be used only for objects that are intended for limited experimental deployment. Such objects typically are defined in Experimental RFCs. =20 =20 -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]=20 Sent: Thursday, January 06, 2005 4:48 PM To: 'andre.lejeune@terayon.com'; jf.mule@cablelabs.com Cc: gnakanishi@motorola.com; e.cardona@cablelabs.com; ipcdn@ietf.org; docsis-oss@cablelabs.com; bwijnen@lucent.com; Fred Oko Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules = O ID assignmen ts: Assigning new RFCs under mib-2 =20 Here is what the current MIB guidelines ( http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-= 03. txt, section 4.5)have to say: =20 - The value assigned to the MODULE-IDENTITY descriptor MUST be unique and (for IETF standards-track MIB modules) SHOULD reside under the mgmt subtree [RFC2578]. Most often it will be an IANA-assigned value directly under mib-2 [RFC2578], although for media-specific MIB modules that extend the IF-MIB [RFC2863] it is customary to use an IANA-assigned value under transmission [RFC2578]. In the past some IETF working groups have made their own assignments from subtrees delegated to them by IANA, but that practice has proven problematic and is NOT RECOMMENDED. =20 -- Rich -----Original Message----- From: owner-docsis-oss@cablelabs.com [mailto:owner-docsis-oss@cablelabs.c= om] On Behalf Of andre.lejeune@terayon.com Sent: Thursday, January 06, 2005 4:14 PM To: jf.mule@cablelabs.com Cc: gnakanishi@motorola.com; e.cardona@cablelabs.com; ipcdn@ietf.org; docsis-oss@cablelabs.com; bwijnen@lucent.com; foko@c-cor.net Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules = O ID assignmen ts: Assigning new RFCs under mib-2 Jean-Francois,=20 What are the attributes that a MIB has to have, in your opinion, for bein= g added to the transmission OID under mib-2, as opposed to only be added to mib-2? I presented my opinion regarding this, which was that a MIB that would only be applicable to a certain type of interface would be better placed under the associated transmission type rather than being placed at the mib-2 level. I have not seen any justification for not doing this wit= h the QoS MIB and BPI+ MIBs, other than the fact that the latest drafts of = the BPI+ MIB is requesting them under mib-2, which is not a sufficient justification in my opinion. Andr=E9=20 -----Original Message-----=20 From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com ]=20 Sent: Thursday, January 06, 2005 3:54 PM=20 To: Wijnen, Bert (Bert); andre.lejeune@Terayon.com; foko@c-cor.net=20 Cc: gnakanishi@motorola.com; Eduardo Cardona; ipcdn@ietf.org; DOCSIS OSS=20 Majordomo List=20 Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules=20 O ID assignmen ts: Assigning new RFCs under mib-2=20 =20 Bert,=20 We have discussed this set of issues for DOCSIS with Thomas Narten, yourself and Rich many times since 2002. Since then, I do not believe we have a mismatch. What was done was done, there is not much we CableLabs, = the vendors or anyone can do about it. Let me be clear that we have worked hard to change the way we do things with MIBs and other IETF Internet-Drafts for that matter. My earlier emai= ls on what we have done in PacketCable should provide detailed examples. Let= me give you another example: in the SIP/SIPPING working groups, with the hel= p of several vendors, we initiated the SIP DCS proxy-to-proxy draft and we worked with the wg chairs and Allison to get the draft to RFC. We then changed our SIP-based spec (PacketCable CMSS) to reference this RFC. Same for RFC 3495 on DHCP option 122 (which replaced an experimental DHCP opti= on 177 assignment and that transition has gone well in the specs and in the field). See inline for additional comments.=20 Jean-Fran=E7ois=20 > -----Original Message-----=20 > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com ]=20 > Sent: Thursday, January 06, 2005 11:51 AM=20 > To: andre.lejeune@Terayon.com; foko@c-cor.net; Jean-Francois Mule=20 > Cc: gnakanishi@motorola.com; Eduardo Cardona; ipcdn@ietf.org;=20 > DOCSIS OSS Majordomo List=20 > Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts=20 > MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2=20 >=20 >=20 > Andre,=20 >=20 > It sounds like we have a SERIOUS MISMATCH between CL and=20 > IETF.=20 As I said above, I don't think we have any serious mismatch. =20 > If CL wants to define their own stuff and mandate=20 > implementations BEFORE IETF approves a MIB document, then=20 > that is fine...=20 > but then one should not come to IETF and try=20 > to get IETF approval. It just does not work that way.=20 With the time some of us put in the IETF work in various working groups= , and my wg chair stance on IPCDN MIB issues when folks invoked "existing implementation" reasons in order not to address the comment, I hope you believe that we bring some contributions in the full spirit of IETF and t= hat we benefit from expert advice and simple good engineering practices. =20 > And even if you do these sort of things just within CL, even=20 > then I do see that you guys can easily run into=20 > interoperability problems.=20 You bet.=20 > We are not doing this just for the=20 > fun of it, but because there are serious risks for=20 > inetroperability problems!=20 >=20 > AGAIN, as I said before. if you want to root under docsIfMIb,=20 > fine. Write a doc similar to=20 > RFC3737 and we can do it. Not that we (IETF MIB Doctors)=20 > prefer it that way, but we/you (IPCDN WG) can do it that way.=20 =20 Back to the original question, I have yet to see any good reason for no= t changing the OID assignment to mib-2 for the IETF IPCDN DOCSIS QoS MIB. D= id I miss anything? > It would still mean that you can only get the branch assigned=20 > underneath docsIfMib AFTER IESG approval. That comes back to=20 > possible interoperability issues if you assign it earlier.=20 >=20 > Bert=20 NOTICE: This communication contains information which may be proprietary, privileged or confidential. If you are not the intended recipient (or authorized to receive for the intended recipient), or believe that you ha= ve received this communication in error, please do not print, copy,retransmi= t, disseminate, disclose or otherwise use the information. Also, please indicate to the sender that you have received this communication in error and delete the copy you received. Thank you. ------_=_NextPart_001_01C4F50D.E02C5F0D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
>I would be = interested=20 seeing best practices that have been learned by readers of this = reflector=20 contributed to the 04 version of the noted=20 draft-ietf-ops-mib-review-guidelines-03.txt.=
 
OK, if=20 you would like to make comments on these MIB guidelines, you should = bring those=20 comments to the proper forum in the IETF. The draft itself=20 does point out the best forum for these comments:
 
   Comments on this memo should be submitted to=20 the
   <ietfmibs@ops.ietf.org> mailing list.  = To=20 subscribe to this mailing
   list send an e-mail message = to=20 <ietfmibs-request@ops.ietf.org> with
   the word = "subscribe"=20 in the message body.
 
--=20 Rich
-----Original Message-----
From: = Fred Oko=20 [mailto:foko@c-cor.net]
Sent: Friday, January 07, 2005 = 3:05=20 AM
To: Woundy, Richard; andre.lejeune@terayon.com;=20 jf.mule@cablelabs.com
Cc: gnakanishi@motorola.com;=20 e.cardona@cablelabs.com; ipcdn@ietf.org; docsis-oss@cablelabs.com;=20 bwijnen@lucent.com
Subject: RE: [ipcdn] RE: IETF IPCDN = proposed=20 standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs = under=20 mib-2

I would be = interested=20 seeing best practices that have been learned by readers of this = reflector=20 contributed to the 04 version of the noted=20 draft-ietf-ops-mib-review-guidelines-03.txt. In particular, as an = expansion=20 upon the advise against using experimental for anything that would = see field=20 deployment (as is the case for all IPCDN drafts and the like) the = advice of=20 the possibly cleaner direction of using enterprise space (e.g. CableLabs enterprise clabProj*=20 of noted path being taken by IPCDN) with notes for the possible = necessities of=20 re-rooting.

 

 

4.3.  = Naming=20 Hierarchy

   Experience has shown = that it is=20 impractical to move objects from one

   subtree to another once those objects = have seen=20 large-scale use in an

   operational environment.  Hence any object that is = targeted=20 for

   deployment in an operational environment MUST = NOT be=20 registered under

   the=20 experimental subtree, irrespective of the = standardization status

   of that=20 object.  The = experimental subtree should be used only=20 for

   objects=20 that are intended for limited experimental deployment.  = Such

   objects=20 typically are defined in Experimental RFCs.

 

 

-----Original=20 Message-----
From: = Woundy,=20 Richard [mailto:Richard_Woundy@cable.comcast.com]
Sent: Thursday, January 06, = 2005 4:48=20 PM
To:=20 'andre.lejeune@terayon.com'; jf.mule@cablelabs.com
Cc: gnakanishi@motorola.com;=20 e.cardona@cablelabs.com; ipcdn@ietf.org; docsis-oss@cablelabs.com;=20 bwijnen@lucent.com; Fred Oko
Subject: RE: [ipcdn] RE: IETF = IPCDN=20 proposed standard drafts MIB Modules O ID assignmen ts: Assigning new = RFCs=20 under mib-2

 

Here is=20 what the current MIB guidelines (http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-gui= delines-03.txt,=20 section 4.5)have to say:

 

   - The=20 value assigned to the MODULE-IDENTITY descriptor MUST be=20 unique
     and (for IETF standards-track MIB = modules)=20 SHOULD reside under the
     mgmt subtree=20 [RFC2578].  Most often it will be an=20 IANA-assigned
     value directly under mib-2=20 [RFC2578], although for media-specific
     = MIB modules=20 that extend the IF-MIB [RFC2863] it is customary to=20 use
     an IANA-assigned value under = transmission=20 [RFC2578].  In the past
     some IETF = working=20 groups have made their own assignments = from
    =20 subtrees delegated to them by IANA, but that practice has=20 proven
     problematic and is NOT=20 RECOMMENDED.

 

--=20 Rich

-----Original=20 Message-----
From:=20 owner-docsis-oss@cablelabs.com = [mailto:owner-docsis-oss@cablelabs.com]=20 On Behalf Of=20 andre.lejeune@terayon.com
Sent: Thursday, January 06, = 2005 4:14=20 PM
To:=20 jf.mule@cablelabs.com
Cc:=20 gnakanishi@motorola.com; e.cardona@cablelabs.com; ipcdn@ietf.org;=20 docsis-oss@cablelabs.com; bwijnen@lucent.com; = foko@c-cor.net
Subject: RE: [ipcdn] RE: = IETF IPCDN=20 proposed standard drafts MIB Modules O ID assignmen ts: Assigning = new RFCs=20 under mib-2

Jean-Francois, =

What are the attributes that a MIB has to = have, in=20 your opinion, for being added to the transmission OID under mib-2, = as=20 opposed to only be added to mib-2? I presented my opinion regarding = this,=20 which was that a MIB that would only be applicable to a certain = type of=20 interface would be better placed under the associated transmission = type=20 rather than being placed at the mib-2 level. I have not seen any=20 justification for not doing this with the QoS MIB and BPI+ MIBs, = other than=20 the fact that the latest drafts of the BPI+ MIB is requesting them = under=20 mib-2, which is not a sufficient justification in my=20 opinion.

Andr=E9

-----Original Message----- =
From: Jean-Francois Mule = [mailto:jf.mule@cablelabs.com]<= /SPAN>=20
Sent: Thursday, = January 06,=20 2005 3:54 PM
To: Wijnen, Bert (Bert); = andre.lejeune@Terayon.com;=20 foko@c-cor.net
Cc: gnakanishi@motorola.com; Eduardo = Cardona;=20 ipcdn@ietf.org; DOCSIS OSS
Majordomo List
Subject: RE: [ipcdn] RE: IETF IPCDN = proposed=20 standard drafts MIB Modules
O ID assignmen ts: Assigning new RFCs = under=20 mib-2

 

Bert,

  We have discussed this set of = issues for=20 DOCSIS with Thomas Narten, yourself and Rich many times since 2002. = Since=20 then, I do not believe we have a mismatch. What was done was done, = there is=20 not much we CableLabs, the vendors or anyone can do about=20 it.

  Let me be clear that we have = worked hard to=20 change the way we do things with MIBs and other IETF = Internet-Drafts for=20 that matter. My earlier emails on what we have done in PacketCable = should=20 provide detailed examples. Let me give you another example: in the=20 SIP/SIPPING working groups, with the help of several vendors, we = initiated=20 the SIP DCS proxy-to-proxy draft and we worked with the wg chairs = and=20 Allison to get the draft to RFC. We then changed our SIP-based spec = (PacketCable CMSS) to reference this RFC. Same for RFC 3495 on DHCP = option=20 122 (which replaced an experimental DHCP option 177 assignment and = that=20 transition has gone well in the specs and in the=20 field).

 See inline for additional=20 comments.

Jean-Fran=E7ois =

> -----Original = Message-----=20
> From: = Wijnen, Bert=20 (Bert) [mailto:bwijnen@lucent.com]=20
> Sent:=20 Thursday, January 06, 2005 11:51 AM
> To: andre.lejeune@Terayon.com; = foko@c-cor.net;=20 Jean-Francois Mule
> Cc: gnakanishi@motorola.com; Eduardo = Cardona;=20 ipcdn@ietf.org;
> DOCSIS OSS Majordomo = List=20
> Subject: = RE: [ipcdn] RE:=20 IETF IPCDN proposed standard drafts
> MIB Modules O ID assignmen ts: = Assigning new=20 RFCs under mib-2
>
>
> Andre,
>
> It sounds like we have a SERIOUS = MISMATCH=20 between CL and
> IETF.
  As I said above, I don't think we = have any=20 serious mismatch. 

> If CL wants to define their own = stuff and=20 mandate
>=20 implementations BEFORE IETF approves a MIB document, then=20
> that is=20 fine...
>=20 but then one should not come to IETF and try =
> to get IETF approval. = It just does=20 not work that way.

  With the time some of us put in = the IETF work=20 in various working groups, and my wg chair stance on IPCDN MIB = issues when=20 folks invoked "existing implementation" reasons in order not to = address the=20 comment, I hope you believe that we bring some contributions in the = full=20 spirit of IETF and that we benefit from expert advice and simple = good=20 engineering practices.

 

> And even if you do these sort of = things just=20 within CL, even
> then I do see that you guys can = easily run into=20
>=20 interoperability problems.
  You bet. =

> We are not doing this just for the=20
> fun of it,=20 but because there are serious risks for
> inetroperability = problems!=20
> =
> AGAIN, as I said = before. if you=20 want to root under docsIfMIb,
> fine. Write a doc similar to=20
> RFC3737=20 and we can do it. Not that we (IETF MIB Doctors) =
> prefer it that way, = but we/you=20 (IPCDN WG) can do it that way.

 

  Back to the original question, I = have yet to=20 see any good reason for not changing the OID assignment to mib-2 = for the=20 IETF IPCDN DOCSIS QoS MIB. Did I miss = anything?


> It would still mean that you can = only get the=20 branch assigned
> underneath docsIfMib AFTER IESG = approval. That=20 comes back to
> possible interoperability issues if = you assign=20 it earlier.
>
> Bert
NOTICE: This communication contains = information=20 which may be proprietary, privileged or confidential. If you are = not the=20 intended recipient (or authorized to receive for the intended = recipient), or=20 believe that you have received this communication in error, please = do not=20 print, copy,retransmit, disseminate, disclose or otherwise use the=20 information. Also, please indicate to the sender that you have = received this=20 communication in error and delete the copy you received. Thank=20 = you.

= ------_=_NextPart_001_01C4F50D.E02C5F0D-- --===============0790814840== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============0790814840==-- From ipcdn-bounces@ietf.org Mon Jan 10 12:25:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07040 for ; Mon, 10 Jan 2005 12:25:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co3VX-0001eX-8U for ipcdn-archive@ietf.org; Mon, 10 Jan 2005 12:39:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co3Bx-0007zM-6v; Mon, 10 Jan 2005 12:18:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co356-00059n-ML for ipcdn@megatron.ietf.org; Mon, 10 Jan 2005 12:11:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06193 for ; Mon, 10 Jan 2005 12:11:49 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co3Ij-0001CO-Nt for ipcdn@ietf.org; Mon, 10 Jan 2005 12:25:58 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j0AHBDVG002135 for ; Mon, 10 Jan 2005 11:11:14 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 10 Jan 2005 18:11:12 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155061B70B8@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Woundy, Richard" , "'Fred Oko'" , andre.lejeune@terayon.com, jf.mule@cablelabs.com Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2 Date: Mon, 10 Jan 2005 18:11:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.7 (/) X-Scan-Signature: 5ad972b4f487a18b25712571c4a63592 Cc: gnakanishi@motorola.com, e.cardona@cablelabs.com, ipcdn@ietf.org, docsis-oss@cablelabs.com X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0376403309==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: 1d8165457635e4ae587bbb513f69669b This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0376403309== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4F737.61E8B880" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4F737.61E8B880 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by ihemail1.lucent.com id j0AHBDVG002135 Content-Transfer-Encoding: quoted-printable Let me point out that the author is (right now as we speak) working on a = revision fo draft-ietf-ops-mib-review-guidelines-03.txt., so now is a really good = time to comment! =20 Bert -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Saturday, January 08, 2005 00:09 To: 'Fred Oko'; andre.lejeune@terayon.com; jf.mule@cablelabs.com Cc: gnakanishi@motorola.com; e.cardona@cablelabs.com; ipcdn@ietf.org; doc= sis-oss@cablelabs.com; bwijnen@lucent.com Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules = O ID assignmen ts: Assigning new RFCs under mib-2 >I would be interested seeing best practices that have been learned by re= aders of this reflector contributed to the 04 version of the noted draft-= ietf-ops-mib-review-guidelines-03.txt. =20 OK, if you would like to make comments on these MIB guidelines, you shoul= d bring those comments to the proper forum in the IETF. The draft itself = does point out the best forum for these comments: =20 Comments on this memo should be submitted to the mailing list. To subscribe to this mailing list send an e-mail message to with the word "subscribe" in the message body. =20 -- Rich -----Original Message----- From: Fred Oko [mailto:foko@c-cor.net]=20 Sent: Friday, January 07, 2005 3:05 AM To: Woundy, Richard; andre.lejeune@terayon.com; jf.mule@cablelabs.com Cc: gnakanishi@motorola.com; e.cardona@cablelabs.com; ipcdn@ietf.org; doc= sis-oss@cablelabs.com; bwijnen@lucent.com Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules = O ID assignmen ts: Assigning new RFCs under mib-2 I would be interested seeing best practices that have been learned by rea= ders of this reflector contributed to the 04 version of the noted draft-i= etf-ops-mib-review-guidelines-03.txt. In particular, as an expansion upon= the advise against using experimental for anything that would see field = deployment (as is the case for all IPCDN drafts and the like) the advice = of the possibly cleaner direction of using enterprise space (e.g. CableLa= bs enterprise clabProj* of noted path being taken by IPCDN) with notes fo= r the possible necessities of re-rooting. =20 =20 4.3. Naming Hierarchy Experience has shown that it is impractical to move objects from one subtree to another once those objects have seen large-scale use in an operational environment. Hence any object that is targeted for deployment in an operational environment MUST NOT be registered under the experimental subtree, irrespective of the standardization status of that object. The experimental subtree should be used only for objects that are intended for limited experimental deployment. Such objects typically are defined in Experimental RFCs. =20 =20 -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]=20 Sent: Thursday, January 06, 2005 4:48 PM To: 'andre.lejeune@terayon.com'; jf.mule@cablelabs.com Cc: gnakanishi@motorola.com; e.cardona@cablelabs.com; ipcdn@ietf.org; doc= sis-oss@cablelabs.com; bwijnen@lucent.com; Fred Oko Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules = O ID assignmen ts: Assigning new RFCs under mib-2 =20 Here is what the current MIB guidelines ( http://www.ietf.org/i= nternet-drafts/draft-ietf-ops-mib-review-guidelines-03.txt, section 4.5)h= ave to say: =20 - The value assigned to the MODULE-IDENTITY descriptor MUST be unique and (for IETF standards-track MIB modules) SHOULD reside under the mgmt subtree [RFC2578]. Most often it will be an IANA-assigned value directly under mib-2 [RFC2578], although for media-specific MIB modules that extend the IF-MIB [RFC2863] it is customary to use an IANA-assigned value under transmission [RFC2578]. In the past some IETF working groups have made their own assignments from subtrees delegated to them by IANA, but that practice has proven problematic and is NOT RECOMMENDED. =20 -- Rich -----Original Message----- From: owner-docsis-oss@cablelabs.com [mailto:owner-docsis-oss@cablelabs.c= om] On Behalf Of andre.lejeune@terayon.com Sent: Thursday, January 06, 2005 4:14 PM To: jf.mule@cablelabs.com Cc: gnakanishi@motorola.com; e.cardona@cablelabs.com; ipcdn@ietf.org; doc= sis-oss@cablelabs.com; bwijnen@lucent.com; foko@c-cor.net Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules = O ID assignmen ts: Assigning new RFCs under mib-2 Jean-Francois,=20 What are the attributes that a MIB has to have, in your opinion, for bein= g added to the transmission OID under mib-2, as opposed to only be added = to mib-2? I presented my opinion regarding this, which was that a MIB tha= t would only be applicable to a certain type of interface would be better= placed under the associated transmission type rather than being placed a= t the mib-2 level. I have not seen any justification for not doing this w= ith the QoS MIB and BPI+ MIBs, other than the fact that the latest drafts= of the BPI+ MIB is requesting them under mib-2, which is not a sufficien= t justification in my opinion. Andr=E9=20 -----Original Message-----=20 From: Jean-Francois Mule [ mailto:jf.mule@cablelabs.com ]=20 Sent: Thursday, January 06, 2005 3:54 PM=20 To: Wijnen, Bert (Bert); andre.lejeune@Terayon.com; foko@c-cor.net=20 Cc: gnakanishi@motorola.com; Eduardo Cardona; ipcdn@ietf.org; DOCSIS OSS=20 Majordomo List=20 Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules=20 O ID assignmen ts: Assigning new RFCs under mib-2=20 =20 Bert,=20 We have discussed this set of issues for DOCSIS with Thomas Narten, you= rself and Rich many times since 2002. Since then, I do not believe we hav= e a mismatch. What was done was done, there is not much we CableLabs, the= vendors or anyone can do about it. Let me be clear that we have worked hard to change the way we do things= with MIBs and other IETF Internet-Drafts for that matter. My earlier ema= ils on what we have done in PacketCable should provide detailed examples.= Let me give you another example: in the SIP/SIPPING working groups, with= the help of several vendors, we initiated the SIP DCS proxy-to-proxy dra= ft and we worked with the wg chairs and Allison to get the draft to RFC. = We then changed our SIP-based spec (PacketCable CMSS) to reference this R= FC. Same for RFC 3495 on DHCP option 122 (which replaced an experimental = DHCP option 177 assignment and that transition has gone well in the specs= and in the field). See inline for additional comments.=20 Jean-Fran=E7ois=20 > -----Original Message-----=20 > From: Wijnen, Bert (Bert) [ mailto:bwijnen@lucent.com ]=20 > Sent: Thursday, January 06, 2005 11:51 AM=20 > To: andre.lejeune@Terayon.com; foko@c-cor.net; Jean-Francois Mule=20 > Cc: gnakanishi@motorola.com; Eduardo Cardona; ipcdn@ietf.org;=20 > DOCSIS OSS Majordomo List=20 > Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts=20 > MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2=20 >=20 >=20 > Andre,=20 >=20 > It sounds like we have a SERIOUS MISMATCH between CL and=20 > IETF.=20 As I said above, I don't think we have any serious mismatch. =20 > If CL wants to define their own stuff and mandate=20 > implementations BEFORE IETF approves a MIB document, then=20 > that is fine...=20 > but then one should not come to IETF and try=20 > to get IETF approval. It just does not work that way.=20 With the time some of us put in the IETF work in various working groups= , and my wg chair stance on IPCDN MIB issues when folks invoked "existing= implementation" reasons in order not to address the comment, I hope you = believe that we bring some contributions in the full spirit of IETF and t= hat we benefit from expert advice and simple good engineering practices. =20 > And even if you do these sort of things just within CL, even=20 > then I do see that you guys can easily run into=20 > interoperability problems.=20 You bet.=20 > We are not doing this just for the=20 > fun of it, but because there are serious risks for=20 > inetroperability problems!=20 >=20 > AGAIN, as I said before. if you want to root under docsIfMIb,=20 > fine. Write a doc similar to=20 > RFC3737 and we can do it. Not that we (IETF MIB Doctors)=20 > prefer it that way, but we/you (IPCDN WG) can do it that way.=20 =20 Back to the original question, I have yet to see any good reason for no= t changing the OID assignment to mib-2 for the IETF IPCDN DOCSIS QoS MIB.= Did I miss anything? > It would still mean that you can only get the branch assigned=20 > underneath docsIfMib AFTER IESG approval. That comes back to=20 > possible interoperability issues if you assign it earlier.=20 >=20 > Bert=20 NOTICE: This communication contains information which may be proprietary,= privileged or confidential. If you are not the intended recipient (or au= thorized to receive for the intended recipient), or believe that you have= received this communication in error, please do not print, copy,retransm= it, disseminate, disclose or otherwise use the information. Also, please = indicate to the sender that you have received this communication in error= and delete the copy you received. Thank you. ------_=_NextPart_001_01C4F737.61E8B880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Let me=20 point out that the author is (right now as we speak) working on a=20 revision
fo=20 draft-ietf-ops-mib-review-guidelines-03.txt., so = now=20 is a really good time to comment!
 
Bert
-----Original Message-----
From: Woundy, Richard=20 [mailto:Richard_Woundy@cable.comcast.com]
Sent: Saturday, = January=20 08, 2005 00:09
To: 'Fred Oko'; andre.lejeune@terayon.com;=20 jf.mule@cablelabs.com
Cc: gnakanishi@motorola.com;=20 e.cardona@cablelabs.com; ipcdn@ietf.org; docsis-oss@cablelabs.com;=20 bwijnen@lucent.com
Subject: RE: [ipcdn] RE: IETF IPCDN = proposed=20 standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs = under=20 mib-2

>I would be = interested=20 seeing best practices that have been learned by readers of this = reflector=20 contributed to the 04 version of the noted=20 = draft-ietf-ops-mib-review-guidelines-03.txt.=
 
OK,=20 if you would like to make comments on these MIB guidelines, you = should bring=20 those comments to the proper forum in the IETF. The draft=20 itself does point out the best forum for these = comments:
 
   Comments on this memo should be submitted to=20 the
   <ietfmibs@ops.ietf.org> mailing list.  = To=20 subscribe to this mailing
   list send an e-mail message = to=20 <ietfmibs-request@ops.ietf.org> with
   the word=20 "subscribe" in the message body.
 
--=20 Rich
-----Original Message-----
From: = Fred Oko=20 [mailto:foko@c-cor.net]
Sent: Friday, January 07, 2005 = 3:05=20 AM
To: Woundy, Richard; andre.lejeune@terayon.com;=20 jf.mule@cablelabs.com
Cc: gnakanishi@motorola.com;=20 e.cardona@cablelabs.com; ipcdn@ietf.org; docsis-oss@cablelabs.com;=20 bwijnen@lucent.com
Subject: RE: [ipcdn] RE: IETF IPCDN = proposed=20 standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs = under=20 mib-2

I would = be=20 interested seeing best practices that have been learned by readers = of this=20 reflector contributed to the 04 version of the noted=20 draft-ietf-ops-mib-review-guidelines-03.txt. In particular, as an = expansion=20 upon the advise against using experimental for anything that would = see field=20 deployment (as is the case for all IPCDN drafts and the like) the = advice of=20 the possibly cleaner direction of using enterprise space (e.g. = CableLabs enterprise clabProj*=20 of noted path being taken by IPCDN) with notes for the possible = necessities=20 of re-rooting.

 

 

4.3.  = Naming=20 Hierarchy

   Experience has = shown that it=20 is impractical to move objects from = one

   subtree to another once those objects = have seen=20 large-scale use in an

   operational environment.  Hence any object that is = targeted=20 for

   deployment in an operational environment MUST = NOT be=20 registered under

   the=20 experimental subtree, irrespective of = the=20 standardization status

   of=20 that object.  The = experimental=20 subtree should be used only=20 for

   objects that are intended for limited = experimental=20 deployment. =20 Such

   objects typically are defined in Experimental = RFCs.

 

 

-----Original=20 Message-----
From: Woundy,=20 Richard [mailto:Richard_Woundy@cable.comcast.com]
Sent: Thursday, January 06, = 2005 4:48=20 PM
To:=20 'andre.lejeune@terayon.com'; jf.mule@cablelabs.com
Cc: gnakanishi@motorola.com; = e.cardona@cablelabs.com; ipcdn@ietf.org; docsis-oss@cablelabs.com;=20 bwijnen@lucent.com; Fred Oko
Subject: RE: [ipcdn] RE: = IETF IPCDN=20 proposed standard drafts MIB Modules O ID assignmen ts: Assigning = new RFCs=20 under mib-2

 

Here=20 is what the current MIB guidelines (http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-gui= delines-03.txt,=20 section 4.5)have to say:

 

   - The=20 value assigned to the MODULE-IDENTITY descriptor MUST be=20 unique
     and (for IETF standards-track = MIB=20 modules) SHOULD reside under the
     mgmt = subtree=20 [RFC2578].  Most often it will be an=20 IANA-assigned
     value directly under = mib-2=20 [RFC2578], although for media-specific
     = MIB=20 modules that extend the IF-MIB [RFC2863] it is customary to=20 use
     an IANA-assigned value under = transmission=20 [RFC2578].  In the past
     some IETF = working=20 groups have made their own assignments = from
    =20 subtrees delegated to them by IANA, but that practice has=20 proven
     problematic and is NOT=20 RECOMMENDED.

 

--=20 Rich

-----Original=20 Message-----
From:=20 owner-docsis-oss@cablelabs.com = [mailto:owner-docsis-oss@cablelabs.com]=20 On Behalf Of=20 andre.lejeune@terayon.com
Sent: Thursday, January = 06, 2005 4:14=20 PM
To:=20 jf.mule@cablelabs.com
Cc:=20 gnakanishi@motorola.com; e.cardona@cablelabs.com; ipcdn@ietf.org; = docsis-oss@cablelabs.com; bwijnen@lucent.com; = foko@c-cor.net
Subject: RE: [ipcdn] RE: = IETF IPCDN=20 proposed standard drafts MIB Modules O ID assignmen ts: Assigning = new RFCs=20 under mib-2

Jean-Francois, =

What are the attributes that a MIB has = to have, in=20 your opinion, for being added to the transmission OID under = mib-2, as=20 opposed to only be added to mib-2? I presented my opinion = regarding this,=20 which was that a MIB that would only be applicable to a certain = type of=20 interface would be better placed under the associated = transmission type=20 rather than being placed at the mib-2 level. I have not seen any=20 justification for not doing this with the QoS MIB and BPI+ MIBs, = other=20 than the fact that the latest drafts of the BPI+ MIB is = requesting them=20 under mib-2, which is not a sufficient justification in my=20 opinion.

Andr=E9

-----Original = Message-----
From: Jean-Francois Mule = [mailto:jf.mule@cablelabs.com]<= /SPAN>=20
Sent: = Thursday, January 06,=20 2005 3:54 PM
To: Wijnen, Bert (Bert);=20 andre.lejeune@Terayon.com; foko@c-cor.net
Cc: = gnakanishi@motorola.com; Eduardo=20 Cardona; ipcdn@ietf.org; DOCSIS OSS
Majordomo List
Subject: RE: [ipcdn] RE: = IETF IPCDN=20 proposed standard drafts MIB Modules
O ID assignmen ts: Assigning new RFCs = under=20 mib-2

 

Bert,

  We have discussed this set of = issues for=20 DOCSIS with Thomas Narten, yourself and Rich many times since = 2002. Since=20 then, I do not believe we have a mismatch. What was done was = done, there=20 is not much we CableLabs, the vendors or anyone can do about=20 it.

  Let me be clear that we have = worked hard to=20 change the way we do things with MIBs and other IETF = Internet-Drafts for=20 that matter. My earlier emails on what we have done in = PacketCable should=20 provide detailed examples. Let me give you another example: in = the=20 SIP/SIPPING working groups, with the help of several vendors, we = initiated=20 the SIP DCS proxy-to-proxy draft and we worked with the wg chairs = and=20 Allison to get the draft to RFC. We then changed our SIP-based = spec=20 (PacketCable CMSS) to reference this RFC. Same for RFC 3495 on = DHCP option=20 122 (which replaced an experimental DHCP option 177 assignment = and that=20 transition has gone well in the specs and in the=20 field).

 See inline for additional=20 comments.

Jean-Fran=E7ois =

> -----Original = Message-----=20
> From: = Wijnen, Bert=20 (Bert) [mailto:bwijnen@lucent.com]=20
> Sent:=20 Thursday, January 06, 2005 11:51 AM
> To: andre.lejeune@Terayon.com;=20 foko@c-cor.net; Jean-Francois Mule
> Cc: gnakanishi@motorola.com; = Eduardo Cardona;=20 ipcdn@ietf.org;
> DOCSIS OSS Majordomo = List=20
> Subject: = RE: [ipcdn]=20 RE: IETF IPCDN proposed standard drafts
> MIB Modules O ID = assignmen ts:=20 Assigning new RFCs under mib-2
>
>
> Andre,
>
> It sounds like we have a SERIOUS = MISMATCH=20 between CL and
> IETF.
  As I said above, I don't think = we have any=20 serious mismatch. 

> If CL wants to define their own = stuff and=20 mandate
>=20 implementations BEFORE IETF approves a MIB document, then=20
> that is=20 fine...
>=20 but then one should not come to IETF and try =
> to get IETF = approval. It just=20 does not work that way.

  With the time some of us put in = the IETF=20 work in various working groups, and my wg chair stance on IPCDN = MIB issues=20 when folks invoked "existing implementation" reasons in order not = to=20 address the comment, I hope you believe that we bring some = contributions=20 in the full spirit of IETF and that we benefit from expert advice = and=20 simple good engineering practices.

 

> And even if you do these sort of = things just=20 within CL, even
> then I do see that you guys can = easily run=20 into
>=20 interoperability problems.
  You bet. =

> We are not doing this just for the =
> fun of=20 it, but because there are serious risks for =
> inetroperability=20 problems!
>
> AGAIN, as I said before. if you = want to root=20 under docsIfMIb,
> fine. Write a doc similar to=20
> RFC3737=20 and we can do it. Not that we (IETF MIB Doctors) =
> prefer it that way, = but we/you=20 (IPCDN WG) can do it that way.

 

  Back to the original question, I = have yet=20 to see any good reason for not changing the OID assignment to = mib-2 for=20 the IETF IPCDN DOCSIS QoS MIB. Did I miss=20 anything?


> It would still mean that you can = only get the=20 branch assigned
> underneath docsIfMib AFTER IESG = approval.=20 That comes back to
> possible interoperability issues = if you=20 assign it earlier.
>
> Bert
NOTICE: This communication contains = information=20 which may be proprietary, privileged or confidential. If you are = not the=20 intended recipient (or authorized to receive for the intended = recipient),=20 or believe that you have received this communication in error, = please do=20 not print, copy,retransmit, disseminate, disclose or otherwise = use the=20 information. Also, please indicate to the sender that you have = received=20 this communication in error and delete the copy you received. = Thank=20 = you.

------_=_NextPart_001_01C4F737.61E8B880-- --===============0376403309== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============0376403309==-- From ipcdn-bounces@ietf.org Mon Jan 10 14:31:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15415 for ; Mon, 10 Jan 2005 14:31:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co5U0-0005OO-62 for ipcdn-archive@ietf.org; Mon, 10 Jan 2005 14:45:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co58j-0003Ie-IQ; Mon, 10 Jan 2005 14:23:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co584-0003AN-VM for ipcdn@megatron.ietf.org; Mon, 10 Jan 2005 14:23:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14976 for ; Mon, 10 Jan 2005 14:23:03 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co5Lh-00058g-7F for ipcdn@ietf.org; Mon, 10 Jan 2005 14:37:12 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j0AJMwad005066 for ; Mon, 10 Jan 2005 13:22:59 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 10 Jan 2005 20:22:57 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155061B70D4@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Jean-Francois Mule Date: Mon, 10 Jan 2005 20:22:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by hoemail1.lucent.com id j0AJMwad005066 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: quoted-printable Cc: gnakanishi@motorola.com, RWoundy@broadband.att.com, "Richard Woundy @ Comcast" , "Ipcdn \(E-mail\)" , azlina@protegonetworks.com Subject: [ipcdn] RE: New Version Notification - draft-ietf-ipcdn-docsisevent-mib-0 5.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Content-Transfer-Encoding: quoted-printable I get: !! Missing citation for Normative reference: P039 L042: [10] SCTE Data Standards Subcommittee, "Data-Over-Cable = Service I could fix theat with an RFC-Editor note if you tell me where to insert = the citation. On page 37: It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Causes: !! Missing Reference for citation: [RFC3410] P038 L017: provided by the SNMPv3 framework (see [RFC3410], section = 8), I could fix that with an RFC-Editor note. It makes me wonder if all references are in sync with the citations. Someone, please check and send a positive acknowledgement that you HAVE c= hecked them all and that they are OK. But I still see: docsDevCmNotifCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for CM Notifications and Control" MODULE --docsDevNotif --mandatory groups GROUP docsDevCmNotifControlGroup DESCRIPTION "Mandatory in CM." GROUP docsDevCmNotificationGroup DESCRIPTION "Mandatory in CM." ::=3D { docsDevNotifCompliances 1 } And I thought we had agreed that you would change it to: docsDevCmNotifCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for CM Notifications and Control" MODULE --docsDevNotif MANDATORY-GROUPS { docsDevCmNotifControlGroup, docsDevCmNotificationGroup } ::=3D { docsDevNotifCompliances 1 } What am I missing? And also: docsDevCmtsNotifCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for DOCSIS CM and CMTS." MODULE --docsDevNotif --mandatory groups GROUP docsDevCmtsNotifControlGroup DESCRIPTION "Mandatory in CMTS." GROUP docsDevCmtsNotificationGroup DESCRIPTION "Mandatory in CMTS." ::=3D { docsDevNotifCompliances 2 } should be (possibly) be (but see my questions): docsDevCmtsNotifCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for DOCSIS CM and CMTS." bw asks: is it really for CM and CMTS or only for CMTS? MODULE --docsDevNotif MANDATORY-GROUPS { docsDevCmtsNotifControlGroup, docsDevCmtsNotificationGroup } ::=3D { docsDevNotifCompliances 2 } if it is both for CM and CMTS, then you seem to be telling me that it is optional for CM. So maybe this one should be just for CMTS (with just=20 mandatory groups) and then the first MODULE-COMPLIANCE should have these 2 groups added as optional groups!? If this is just for CMTS, then the DESCRIPTION clause should say so and t= hen my=20 suggested change is the proper way to specify it. You have put this=20 Note that notifications are also under the control of the MIB modules defined in RFC 3413 [17]. In the security COnsiderations section. That is not a secuurity concern (= I think). Rather it is something to describe (I think) in the DESCRIPTION clauses o= f docsDevCmNotifControl and docsDevCmtsNotifControl. W.r.t. Persistency of the writable objects you have added: If the device is rebooted, the value of this object should revert to the default value. which meets my concern.=20 It is something however that you and the WG chairs may want to make sure = that the WG agrees with. Bert > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: Friday, January 07, 2005 19:19 > To: bwijnen@lucent.com > Cc: Richard Woundy @ Comcast; RWoundy@broadband.att.com; > azlina@protegonetworks.com; gnakanishi@motorola.com > Subject: RE: New Version Notification - > draft-ietf-ipcdn-docsisevent-mib-05.txt >=20 >=20 > Bert, >=20 > Let us know what the next step is on this ID. >=20 > Thanks, > Jean-Fran=E7ois=20 >=20 > > -----Original Message----- > > From: ID Tracker [mailto:internet-drafts-reply@ietf.org]=20 > > Sent: Friday, January 07, 2005 11:46 AM > > To: Richard Woundy @ Comcast; RWoundy@broadband.att.com;=20 > > Jean-Francois Mule; azlina@protegonetworks.com;=20 > > gnakanishi@motorola.com; bwijnen@lucent.com > > Subject: New Version Notification -=20 > > draft-ietf-ipcdn-docsisevent-mib-05.txt > >=20 > >=20 > >=20 > > New version (-05) has been submitted for=20 > > draft-ietf-ipcdn-docsisevent-mib-05.txt. > > http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docsiseve > nt-mib-05.txt >=20 >=20 >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Jan 11 09:19:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25998 for ; Tue, 11 Jan 2005 09:19:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoN5k-0006Nx-9a for ipcdn-archive@ietf.org; Tue, 11 Jan 2005 09:33:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoMqh-0006DN-9M; Tue, 11 Jan 2005 09:18:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoMjW-0004mz-S6 for ipcdn@megatron.ietf.org; Tue, 11 Jan 2005 09:10:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25200 for ; Tue, 11 Jan 2005 09:10:53 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoMxJ-0006AZ-6N for ipcdn@ietf.org; Tue, 11 Jan 2005 09:25:12 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j0BEAm2i022678 for ; Tue, 11 Jan 2005 08:10:49 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 11 Jan 2005 15:10:47 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155061B72F2@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Nakanishi Greg-MGI8179 , Jean-Francois Mule Date: Tue, 11 Jan 2005 15:10:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by hoemail1.lucent.com id j0BEAm2i022678 X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Content-Transfer-Encoding: quoted-printable Cc: RWoundy@broadband.att.com, "Richard Woundy @ Comcast" , "Ipcdn \(E-mail\)" , azlina@protegonetworks.com Subject: [ipcdn] RE: New Version Notification - draft-ietf-ipcdn-docsisevent-mib-0 5.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Content-Transfer-Encoding: quoted-printable I still seee docsDevCmNotifControlGroup OBJECT-GROUP OBJECTS { docsDevCmNotifControl } STATUS current DESCRIPTION "CM must support docsDevCmNotifControl." ::=3D { docsDevNotifGroups 1 } The "CM must support" is something that is normally not put in a OBJECT-G= ROUP=20 statement. This statement is used to just "group" objects together that l= ogically=20 belong together. The "CM must..." is part of the "MANDATORY GROUPS" claus= e of the MODULE-COMPLIANCE statement. So a better text for above would be: docsDevCmNotifControlGroup OBJECT-GROUP OBJECTS { docsDevCmNotifControl } STATUS current DESCRIPTION "This group represents objects to allow control over CM Notifi= cations." ::=3D { docsDevNotifGroups 1 } Same for: docsDevCmtsNotifControlGroup Other then that it looks fine to me.=20 Bert > -----Original Message----- > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > Sent: Tuesday, January 11, 2005 01:00 > To: 'Wijnen, Bert (Bert)'; Jean-Francois Mule > Cc: Richard Woundy @ Comcast; RWoundy@broadband.att.com; > azlina@protegonetworks.com; Ipcdn (E-mail) > Subject: RE: New Version Notification - > draft-ietf-ipcdn-docsisevent-mib-0 5.txt >=20 >=20 > Burt, >=20 > Thanks for the review. >=20 > 1) I cross-checked all the citations with the references and=20 > they are in synch now. > 2) Compliance statement - My apologies. You provided me with=20 > this comment before the holidays and I neglected to=20 > incorporate it. It is in now. > 3) I moved the text regarding RFC3413 from the Security=20 > Considerations section to the appropriate MIB description clauses. > 4) Regarding the persistency comment... OK, I will post a=20 > message to the WG and solicit feedback. >=20 > I've attached an update. >=20 > Thanks, greg >=20 > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 > Sent: Monday, January 10, 2005 11:23 AM > To: Jean-Francois Mule > Cc: Richard Woundy @ Comcast; RWoundy@broadband.att.com;=20 > azlina@protegonetworks.com; Nakanishi Greg-MGI8179; Ipcdn (E-mail) > Subject: RE: New Version Notification -=20 > draft-ietf-ipcdn-docsisevent-mib-0 5.txt >=20 >=20 > I get: > !! Missing citation for Normative reference: > P039 L042: [10] SCTE Data Standards Subcommittee,=20 > "Data-Over-Cable Service >=20 > I could fix theat with an RFC-Editor note if you tell me=20 > where to insert the citation. >=20 > On page 37: > It is RECOMMENDED that implementers consider the security=20 > features as > provided by the SNMPv3 framework (see [RFC3410], section 8), > including full support for the SNMPv3 cryptographic mechanisms (for > authentication and privacy). > Causes: > !! Missing Reference for citation: [RFC3410] > P038 L017: provided by the SNMPv3 framework (see=20 > [RFC3410], section 8), >=20 > I could fix that with an RFC-Editor note. >=20 > It makes me wonder if all references are in sync with the=20 > citations. Someone, please check and send a positive=20 > acknowledgement that you HAVE checked them all and that they are OK. >=20 > But I still see: > docsDevCmNotifCompliance MODULE-COMPLIANCE > STATUS current >=20 > DESCRIPTION > "The compliance statement for CM Notifications and Control" >=20 > MODULE --docsDevNotif > --mandatory groups >=20 > GROUP docsDevCmNotifControlGroup > DESCRIPTION > "Mandatory in CM." >=20 > GROUP docsDevCmNotificationGroup > DESCRIPTION > "Mandatory in CM." >=20 > ::=3D { docsDevNotifCompliances 1 } >=20 > And I thought we had agreed that you would change it to: >=20 > docsDevCmNotifCompliance MODULE-COMPLIANCE > STATUS current >=20 > DESCRIPTION > "The compliance statement for CM Notifications and Control" >=20 > MODULE --docsDevNotif > MANDATORY-GROUPS { > docsDevCmNotifControlGroup, > docsDevCmNotificationGroup > } > ::=3D { docsDevNotifCompliances 1 } >=20 > What am I missing? >=20 > And also: > docsDevCmtsNotifCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "The compliance statement for DOCSIS CM and CMTS." > MODULE --docsDevNotif > --mandatory groups >=20 > GROUP docsDevCmtsNotifControlGroup > DESCRIPTION > "Mandatory in CMTS." >=20 > GROUP docsDevCmtsNotificationGroup > DESCRIPTION > "Mandatory in CMTS." >=20 > ::=3D { docsDevNotifCompliances 2 } >=20 > should be (possibly) be (but see my questions): >=20 > docsDevCmtsNotifCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "The compliance statement for DOCSIS CM and CMTS." >=20 > bw asks: is it really for CM and CMTS or only for CMTS? >=20 > MODULE --docsDevNotif > MANDATORY-GROUPS { > docsDevCmtsNotifControlGroup, > docsDevCmtsNotificationGroup > } > ::=3D { docsDevNotifCompliances 2 } >=20 > if it is both for CM and CMTS, then you seem to be telling me=20 > that it is optional for CM. So maybe this one should be just=20 > for CMTS (with just=20 > mandatory groups) and then the first MODULE-COMPLIANCE should=20 > have these 2 groups added as optional groups!? >=20 > If this is just for CMTS, then the DESCRIPTION clause should=20 > say so and then my=20 > suggested change is the proper way to specify it. >=20 > You have put this=20 > Note that notifications are also under the control of the=20 > MIB modules > defined in RFC 3413 [17]. > In the security COnsiderations section. That is not a=20 > secuurity concern (I think). Rather it is something to=20 > describe (I think) in the DESCRIPTION clauses of=20 > docsDevCmNotifControl and docsDevCmtsNotifControl. >=20 > W.r.t. Persistency of the writable objects you have added: > If the device is rebooted, the value of this object=20 > should revert > to the default value. > which meets my concern.=20 > It is something however that you and the WG chairs may want=20 > to make sure that the WG agrees with. >=20 > Bert > > -----Original Message----- > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > Sent: Friday, January 07, 2005 19:19 > > To: bwijnen@lucent.com > > Cc: Richard Woundy @ Comcast; RWoundy@broadband.att.com;=20 > > azlina@protegonetworks.com; gnakanishi@motorola.com > > Subject: RE: New Version Notification -=20 > > draft-ietf-ipcdn-docsisevent-mib-05.txt > >=20 > >=20 > > Bert, > >=20 > > Let us know what the next step is on this ID. > >=20 > > Thanks, > > Jean-Fran=E7ois > >=20 > > > -----Original Message----- > > > From: ID Tracker [mailto:internet-drafts-reply@ietf.org] > > > Sent: Friday, January 07, 2005 11:46 AM > > > To: Richard Woundy @ Comcast; RWoundy@broadband.att.com;=20 > > > Jean-Francois Mule; azlina@protegonetworks.com;=20 > > > gnakanishi@motorola.com; bwijnen@lucent.com > > > Subject: New Version Notification -=20 > > > draft-ietf-ipcdn-docsisevent-mib-05.txt > > >=20 > > >=20 > > >=20 > > > New version (-05) has been submitted for > > > draft-ietf-ipcdn-docsisevent-mib-05.txt. > > > http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docsiseve > > nt-mib-05.txt > >=20 > >=20 > >=20 >=20 >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Jan 11 10:04:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28884 for ; Tue, 11 Jan 2005 10:04:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoNmw-0007G0-5I for ipcdn-archive@ietf.org; Tue, 11 Jan 2005 10:18:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoNUY-00034Z-5e; Tue, 11 Jan 2005 09:59:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoNQI-0002fO-RY; Tue, 11 Jan 2005 09:55:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28336; Tue, 11 Jan 2005 09:55:05 -0500 (EST) Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CoNe6-00075k-0k; Tue, 11 Jan 2005 10:09:25 -0500 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm1741e4603b; Tue, 11 Jan 2005 22:57:14 +0800 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmd41df2af8; Sat, 08 Jan 2005 04:56:46 +0800 Received: from megatron.ietf.org([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm1041df648a; Sat, 08 Jan 2005 04:56:45 +0800 Received: from megatron.ietf.org([132.151.6.71]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Sat, 08 Jan 2005 04:56:45 +0800 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn0vJ-0004Uy-4Q; Fri, 07 Jan 2005 15:41:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn0t2-0003Hf-GU; Fri, 07 Jan 2005 15:39:08 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20905; Fri, 7 Jan 2005 15:39:06 -0500 (EST) Message-Id: <200501072039.PAA20905@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 07 Jan 2005 15:39:04 -0500 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 0.4 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: ipcdn@ietf.org Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-docsisevent-mib-05.txt X-BeenThere: ipcdn@ietf.org Reply-To: internet-drafts@ietf.org List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Event Notification Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems Author(s) : A. Ahmad, G. Nakanishi Filename : draft-ietf-ipcdn-docsisevent-mib-05.txt Pages : 41 Date : 2005-1-7 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP- based event notification management of DOCSIS compliant Cable Modems and Cable Modem Termination Systems. This MIB is defined as an extension to the DOCSIS Cable Device MIB. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docsisevent-mib-05.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-ietf-ipcdn-docsisevent-mib-05.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-ietf-ipcdn-docsisevent-mib-05.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: <2005-1-7152154.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-docsisevent-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-docsisevent-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-7152154.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --NextPart-- From ipcdn-bounces@ietf.org Tue Jan 11 12:20:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10207 for ; Tue, 11 Jan 2005 12:20:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoPv0-0001ti-2a for ipcdn-archive@ietf.org; Tue, 11 Jan 2005 12:35:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoPes-0000am-K9; Tue, 11 Jan 2005 12:18:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoPb4-0007Fq-M3 for ipcdn@megatron.ietf.org; Tue, 11 Jan 2005 12:14:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09727 for ; Tue, 11 Jan 2005 12:14:20 -0500 (EST) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoPol-0001lU-UH for ipcdn@ietf.org; Tue, 11 Jan 2005 12:28:39 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id j0BHJv2P028065 for ; Tue, 11 Jan 2005 10:19:57 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id j0BHBDea021132 for ; Tue, 11 Jan 2005 11:11:13 -0600 Received: by ca25exm01 with Internet Mail Service (5.5.2657.72) id ; Tue, 11 Jan 2005 09:14:09 -0800 Message-ID: From: Nakanishi Greg-MGI8179 To: "'Wijnen, Bert (Bert)'" , Jean-Francois Mule Date: Tue, 11 Jan 2005 09:14:07 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by motgate3.mot.com id j0BHJv2P028065 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Content-Transfer-Encoding: quoted-printable Cc: "Ipcdn \(E-mail\)" , "Richard Woundy @ Comcast" , azlina@protegonetworks.com Subject: [ipcdn] RE: New Version Notification - draft-ietf-ipcdn-docsisevent-mib-0 5.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Content-Transfer-Encoding: quoted-printable OK, will update. Thanks, greg -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Tuesday, January 11, 2005 6:11 AM To: Nakanishi Greg-MGI8179; Jean-Francois Mule Cc: Richard Woundy @ Comcast; RWoundy@broadband.att.com; azlina@protegone= tworks.com; Ipcdn (E-mail) Subject: RE: New Version Notification - draft-ietf-ipcdn-docsisevent-mib-= 0 5.txt I still seee docsDevCmNotifControlGroup OBJECT-GROUP OBJECTS { docsDevCmNotifControl } STATUS current DESCRIPTION "CM must support docsDevCmNotifControl." ::=3D { docsDevNotifGroups 1 } The "CM must support" is something that is normally not put in a OBJECT-G= ROUP=20 statement. This statement is used to just "group" objects together that l= ogically=20 belong together. The "CM must..." is part of the "MANDATORY GROUPS" claus= e of the MODULE-COMPLIANCE statement. So a better text for above would be= : docsDevCmNotifControlGroup OBJECT-GROUP OBJECTS { docsDevCmNotifControl } STATUS current DESCRIPTION "This group represents objects to allow control over CM Notifi= cations." ::=3D { docsDevNotifGroups 1 } Same for: docsDevCmtsNotifControlGroup Other then that it looks fine to me.=20 Bert > -----Original Message----- > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > Sent: Tuesday, January 11, 2005 01:00 > To: 'Wijnen, Bert (Bert)'; Jean-Francois Mule > Cc: Richard Woundy @ Comcast; RWoundy@broadband.att.com;=20 > azlina@protegonetworks.com; Ipcdn (E-mail) > Subject: RE: New Version Notification -=20 > draft-ietf-ipcdn-docsisevent-mib-0 5.txt >=20 >=20 > Burt, >=20 > Thanks for the review. >=20 > 1) I cross-checked all the citations with the references and > they are in synch now. > 2) Compliance statement - My apologies. You provided me with=20 > this comment before the holidays and I neglected to=20 > incorporate it. It is in now. > 3) I moved the text regarding RFC3413 from the Security=20 > Considerations section to the appropriate MIB description clauses. > 4) Regarding the persistency comment... OK, I will post a=20 > message to the WG and solicit feedback. >=20 > I've attached an update. >=20 > Thanks, greg >=20 > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Monday, January 10, 2005 11:23 AM > To: Jean-Francois Mule > Cc: Richard Woundy @ Comcast; RWoundy@broadband.att.com;=20 > azlina@protegonetworks.com; Nakanishi Greg-MGI8179; Ipcdn (E-mail) > Subject: RE: New Version Notification -=20 > draft-ietf-ipcdn-docsisevent-mib-0 5.txt >=20 >=20 > I get: > !! Missing citation for Normative reference: > P039 L042: [10] SCTE Data Standards Subcommittee,=20 > "Data-Over-Cable Service >=20 > I could fix theat with an RFC-Editor note if you tell me > where to insert the citation. >=20 > On page 37: > It is RECOMMENDED that implementers consider the security > features as > provided by the SNMPv3 framework (see [RFC3410], section 8), > including full support for the SNMPv3 cryptographic mechanisms (for > authentication and privacy). > Causes: > !! Missing Reference for citation: [RFC3410] > P038 L017: provided by the SNMPv3 framework (see=20 > [RFC3410], section 8), >=20 > I could fix that with an RFC-Editor note. >=20 > It makes me wonder if all references are in sync with the > citations. Someone, please check and send a positive=20 > acknowledgement that you HAVE checked them all and that they are OK. >=20 > But I still see: > docsDevCmNotifCompliance MODULE-COMPLIANCE > STATUS current >=20 > DESCRIPTION > "The compliance statement for CM Notifications and Control" >=20 > MODULE --docsDevNotif > --mandatory groups >=20 > GROUP docsDevCmNotifControlGroup > DESCRIPTION > "Mandatory in CM." >=20 > GROUP docsDevCmNotificationGroup > DESCRIPTION > "Mandatory in CM." >=20 > ::=3D { docsDevNotifCompliances 1 } >=20 > And I thought we had agreed that you would change it to: >=20 > docsDevCmNotifCompliance MODULE-COMPLIANCE > STATUS current >=20 > DESCRIPTION > "The compliance statement for CM Notifications and Control" >=20 > MODULE --docsDevNotif > MANDATORY-GROUPS { > docsDevCmNotifControlGroup, > docsDevCmNotificationGroup > } > ::=3D { docsDevNotifCompliances 1 } >=20 > What am I missing? >=20 > And also: > docsDevCmtsNotifCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "The compliance statement for DOCSIS CM and CMTS." > MODULE --docsDevNotif > --mandatory groups >=20 > GROUP docsDevCmtsNotifControlGroup > DESCRIPTION > "Mandatory in CMTS." >=20 > GROUP docsDevCmtsNotificationGroup > DESCRIPTION > "Mandatory in CMTS." >=20 > ::=3D { docsDevNotifCompliances 2 } >=20 > should be (possibly) be (but see my questions): >=20 > docsDevCmtsNotifCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "The compliance statement for DOCSIS CM and CMTS." >=20 > bw asks: is it really for CM and CMTS or only for CMTS? >=20 > MODULE --docsDevNotif > MANDATORY-GROUPS { > docsDevCmtsNotifControlGroup, > docsDevCmtsNotificationGroup > } > ::=3D { docsDevNotifCompliances 2 } >=20 > if it is both for CM and CMTS, then you seem to be telling me > that it is optional for CM. So maybe this one should be just=20 > for CMTS (with just=20 > mandatory groups) and then the first MODULE-COMPLIANCE should=20 > have these 2 groups added as optional groups!? >=20 > If this is just for CMTS, then the DESCRIPTION clause should > say so and then my=20 > suggested change is the proper way to specify it. >=20 > You have put this=20 > Note that notifications are also under the control of the > MIB modules > defined in RFC 3413 [17]. > In the security COnsiderations section. That is not a=20 > secuurity concern (I think). Rather it is something to=20 > describe (I think) in the DESCRIPTION clauses of=20 > docsDevCmNotifControl and docsDevCmtsNotifControl. >=20 > W.r.t. Persistency of the writable objects you have added: > If the device is rebooted, the value of this object > should revert > to the default value. > which meets my concern.=20 > It is something however that you and the WG chairs may want=20 > to make sure that the WG agrees with. >=20 > Bert > > -----Original Message----- > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > Sent: Friday, January 07, 2005 19:19 > > To: bwijnen@lucent.com > > Cc: Richard Woundy @ Comcast; RWoundy@broadband.att.com; > > azlina@protegonetworks.com; gnakanishi@motorola.com > > Subject: RE: New Version Notification -=20 > > draft-ietf-ipcdn-docsisevent-mib-05.txt > >=20 > >=20 > > Bert, > >=20 > > Let us know what the next step is on this ID. > >=20 > > Thanks, > > Jean-Fran=E7ois > >=20 > > > -----Original Message----- > > > From: ID Tracker [mailto:internet-drafts-reply@ietf.org] > > > Sent: Friday, January 07, 2005 11:46 AM > > > To: Richard Woundy @ Comcast; RWoundy@broadband.att.com; > > > Jean-Francois Mule; azlina@protegonetworks.com;=20 > > > gnakanishi@motorola.com; bwijnen@lucent.com > > > Subject: New Version Notification -=20 > > > draft-ietf-ipcdn-docsisevent-mib-05.txt > > >=20 > > >=20 > > >=20 > > > New version (-05) has been submitted for=20 > > > draft-ietf-ipcdn-docsisevent-mib-05.txt. > > > http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docsiseve > > nt-mib-05.txt > >=20 > >=20 > >=20 >=20 >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Jan 11 12:25:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10491 for ; Tue, 11 Jan 2005 12:25:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoPzM-0001zV-G2 for ipcdn-archive@ietf.org; Tue, 11 Jan 2005 12:39:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoPkM-0002KE-Tr; Tue, 11 Jan 2005 12:23:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoPjg-0002BD-9U for ipcdn@megatron.ietf.org; Tue, 11 Jan 2005 12:23:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10411 for ; Tue, 11 Jan 2005 12:23:13 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoPxU-0001xb-Ll for ipcdn@ietf.org; Tue, 11 Jan 2005 12:37:36 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j0BHP3JD019459 for ; Tue, 11 Jan 2005 10:25:04 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id j0BHLrNv012837 for ; Tue, 11 Jan 2005 11:21:54 -0600 Received: by ca25exm01 with Internet Mail Service (5.5.2657.72) id ; Tue, 11 Jan 2005 09:23:10 -0800 Message-ID: From: Nakanishi Greg-MGI8179 To: "Ipcdn (E-mail)" Date: Tue, 11 Jan 2005 09:23:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [ipcdn] Persistency description for docsDevCmNotifControl and docsDevCmts NotifControl X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 I received a comment that there should be a description of persistency of the docsDevCmNotifControl and docsDevCmtsNotifControl objects in the Event Notification MIB. I added the following sentence to the description of both objects: "If the device is rebooted,the value of this object should revert to the default value." I'd like to solicit feedback on this, particularly if anyone disagrees with the sentence. Thanks, greg _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Jan 11 16:56:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08139 for ; Tue, 11 Jan 2005 16:56:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoUEP-0002FS-NG for ipcdn-archive@ietf.org; Tue, 11 Jan 2005 17:11:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoTqj-00081Y-T0; Tue, 11 Jan 2005 16:46:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoTWS-0003nc-Ot for ipcdn@megatron.ietf.org; Tue, 11 Jan 2005 16:25:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02975 for ; Tue, 11 Jan 2005 16:25:50 -0500 (EST) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoTkJ-0000Wa-QB for ipcdn@ietf.org; Tue, 11 Jan 2005 16:40:14 -0500 Received: from h-69-3-25-179.snvacaid.dynamic.covad.net ([69.3.25.179] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CoTWC-00066o-00 for ipcdn@ietf.org; Tue, 11 Jan 2005 13:25:36 -0800 Message-ID: <004601c4f824$3636f920$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn \(E-mail\)" References: Subject: Re: [ipcdn] Persistency description for docsDevCmNotifControl anddocsDevCmts NotifControl Date: Tue, 11 Jan 2005 13:26:27 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Hi - > From: "Nakanishi Greg-MGI8179" > To: "Ipcdn (E-mail)" > Sent: Tuesday, January 11, 2005 9:23 AM > Subject: [ipcdn] Persistency description for docsDevCmNotifControl anddocsDevCmts NotifControl > > I received a comment that there should be a description of persistency of the docsDevCmNotifControl > and docsDevCmtsNotifControl objects in the Event Notification MIB. > > I added the following sentence to the description of both objects: > > "If the device is rebooted,the value of this object should revert to the default value." > > I'd like to solicit feedback on this, particularly if anyone disagrees with the sentence. ... 1) is the "should" meant as a "SHOULD"? 2) is the intent really to weakly prohibit persistence? (I don't have a position, I'm just trying to understand.) Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Jan 11 18:48:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17406 for ; Tue, 11 Jan 2005 18:48:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoVyO-0004jB-RX for ipcdn-archive@ietf.org; Tue, 11 Jan 2005 19:02:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoVfZ-0002pm-Rt; Tue, 11 Jan 2005 18:43:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoVY5-0001SL-VP for ipcdn@megatron.ietf.org; Tue, 11 Jan 2005 18:35:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16710 for ; Tue, 11 Jan 2005 18:35:39 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoVlx-0004TY-3z for ipcdn@ietf.org; Tue, 11 Jan 2005 18:50:04 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j0BNYr1e008128; Tue, 11 Jan 2005 16:34:53 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of questions Date: Tue, 11 Jan 2005 16:34:53 -0700 Message-ID: Thread-Topic: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of questions Thread-Index: AcQHvN926xVuYmLvRFuX5nS5/On1/wD5ERZwAAG0zlABimPhABuwhhFwAALJl5AABA/rAAAHRsZsHdoI4fA= From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: quoted-printable Cc: enechamkin@broadcom.com, PacketCable Provisioning and OSS Majordomo List , Leandro Rzezak , Dave Thaler X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Content-Transfer-Encoding: quoted-printable All, Eugene and I are updating the IETF IPCDN MTA MIB draft 06.=20 We'd like to close one of the open items that did not get address in = the draft05 released in October: pktcMtaDevErrorOidsTable and what MTA = behavior should be when the number of errors exceeds the table size = limit of 1024. Based on the input received, we'd like to propose the following: 1. keep 1024 as a reasonable number of errors in a single config file=20 2. if more than 1024 I had ping the list, >/dev/null": the MTA should = forget about any subsequent errors i.e. any error after 1024 does not = get stored in the table, and the last entry (1024th)'s is populated with = a reason indicating that there are more errors per the suggestions = received by Leandro and Sumanth on the list. Proposed text changes: pktcMtaDevErrorOidIndex OBJECT-TYPE =20 SYNTAX Unsigned32 (1..1024) MAX-ACCESS not-accessible STATUS current DESCRIPTION=20 " This object is the index of the MTA configuration error=20 table. It is an integer value which starts at value '1' and is incremented for each encountered configuration=20 file error or warning. If the number of configuration errors exceeds 1024, all errors beyond the 1024th one must be ignored - these=20 subsequent errors are not reflected in the pktcMtaDevErrorOidsTable. In this case, the value of the pktcMtaDevErrorOid, pktcMtaDevErrorValue, and=20 pktcMtaDevErrorReason objects for the 1024-th table entry must all be equal to 'TOO MANY ERRORS IN THE CONFIGURATION FILE'." ::=3D {pktcMtaDevErrorOidsEntry 1} Let us know if this change is acceptable or else, feel free to propose = text improvements or suggestions. Thanks, Jean-Fran=E7ois=20 > -----Original Message----- > From: Sumanth Channabasappa [mailto:SChanna@alopa.com]=20 > Sent: Thursday, August 12, 2004 6:32 PM > To: Leandro Rzezak; Jean-Francois Mule; ipcdn@ietf.org;=20 > PacketCable Provisioning and OSS Majordomo List > Cc: enechamkin@broadcom.com; Dave Thaler > Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a=20 > number of questions >=20 >=20 > Hi, >=20 > I am unaware of any specific reason for the range when it was=20 > proposed. (I guess it was assumed that 1024 errors would=20 > exceed any errors in a single configuration file!). >=20 > I would agree on the /dev/null (but indicating in the 1024th=20 > entry there were more errors!).=20 >=20 > Sumanth >=20 > . >=20 > -----Original Message-----=20 > From: ipcdn-bounces@ietf.org on behalf of Leandro Rzezak=20 > Sent: Thu 8/12/2004 3:00 PM=20 > To: 'Jean-Francois Mule'; ipcdn@ietf.org; 'PacketCable=20 > Provisioning and OSS Majordomo List'=20 > Cc: enechamkin@broadcom.com; 'Dave Thaler'=20 > Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a=20 > number of questions >=20 >=20 > About the 2nd issue, perhaps going with the ">/dev/null" mode=20 > but overwriting the 1024th error with a warning... >=20 > Regards, >=20 > Leandro Rzezak > Intraway Corp. > http://www.intraway.com >=20 > -----Original Message----- > From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org]=20 > On Behalf Of Jean-Francois Mule > Sent: Thursday, August 12, 2004 5:11 PM > To: ipcdn@ietf.org; PacketCable Provisioning and OSS Majordomo List > Cc: enechamkin@broadcom.com; Dave Thaler > Subject: [ipcdn] [pkt-prov] MTA MIB Error OID table - a=20 > number of questions >=20 > Folks, >=20 > We received one comment from Dave Thaler during the IETF=20 > mib doctor review on the MTA MIB ErrorOID table for which I=20 > would like to request some input from the lists (comment #11=20 > from Dave). >=20 > 1. Max range of the index object: > pktcMtaDevErrorOidIndex OBJECT-TYPE=20 > SYNTAX Unsigned32 (1..1024) > ^^^^ > Is there any reason why we are limiting the size of this=20 > object? From an implementation point of view on the snmp mib=20 > agent, is this limitation buying much? >=20 >=20 > 2. What happens if more than 1024 errors are encountered?=20 > Hopefully this does not happen often since the operators=20 > manage the config files and it is extremely rare to have=20 > config files with over 1024 entries or with a smaller number=20 > of entries causing 1024 errors. That said, if we keep the=20 > range as-is, per Dave's recommendation, we should define=20 > properly what happens after the value 1024 is reached so that=20 > all MTA vendors do it consistently and so that SNMP mgers can=20 > act accordingly in those cases. >=20 > Assuming we keep the range as is (1..1024), there are a=20 > couple of options for MTAs to populate the table when a=20 > 1025th error is encountered: > - ">/dev/null": forget about it, any error after 1024 does=20 > not get stored, only the first 1024 errors are present in the table, > - "wrap": overwrite entries starting with entry 1, so 1025=20 > -> 1, 1026 -> 2, etc. > - "tail": just overwrite the last entry (1..1023 remain=20 > stable, 1024 is updated with the latest error: 1025 -> 1024,=20 > 1026 -> 1024, etc.) >=20 > The "wrap" mode is not a good option in my opinion for 2 reasons: > - by analogy with compilation errors we sometimes encounter with > C++/C/SMI, an error early on in the file being parsed can=20 > cause numerous > subsequent errors which are not very relevant; > - in this particular case of config files with TLV=20 > tuples, if something goes wrong on the MTA misinterpreting=20 > the length of a TLV for e.g., all subsequent TLV parsing will=20 > be affected. =3D> "wrap" won't help troubleshoot the primary errors. >=20 > My preference would be ">/dev/null". It is simpler for MTAs=20 > and if there are 1024 errors, who cares about the remaining=20 > ones (based on the above). The "tail" mode is misleading in=20 > my opinion and is not very relevant as intermediate entries=20 > (1025..max_errors-1) will be missed. >=20 > Are there any other/better options if we keep the range? Any=20 > comments on the above? >=20 > Jean-Fran=E7ois _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Jan 11 19:08:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18507 for ; Tue, 11 Jan 2005 19:08:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoWHS-00055o-W6 for ipcdn-archive@ietf.org; Tue, 11 Jan 2005 19:22:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoVyO-00064H-8v; Tue, 11 Jan 2005 19:02:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoVjh-0003bf-T4 for ipcdn@megatron.ietf.org; Tue, 11 Jan 2005 18:47:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17358 for ; Tue, 11 Jan 2005 18:47:38 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoVxb-0004hu-V2 for ipcdn@ietf.org; Tue, 11 Jan 2005 19:02:04 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j0BNl61e010894; Tue, 11 Jan 2005 16:47:07 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Jan 2005 16:47:06 -0700 Message-ID: Thread-Topic: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt Thread-Index: AcR6thTZfq+7VKivT3+3uhPKgFAc5B9gDNXg From: "Jean-Francois Mule" To: "Dave Thaler" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Content-Transfer-Encoding: quoted-printable Cc: randy_presuhn@mindspring.com, "Wijnen, Bert \(Bert\)" , enechamkin@broadcom.com, "C. M. Heard" Subject: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Content-Transfer-Encoding: quoted-printable To close on one additional comment: Dave wrote: > 12) pktcMtaDevErrorOid, pktcMtaDevErrorValue, etc: > why are OIDs of type SnmpAdminString rather than an=20 > OBJECT IDENTIFIER > type/subtype? As is, the management station cannot do=20 > simple things > like expanding the OID into the defined string tokens in the MIB. We discussed this point during the IETF IPCDN meeting #61, see = proceedings at: The meeting minutes recorded: In the WG meeting, we had consensus that since the OID and its value is provided in the MTA config file by an operator in the form of a character string, it is better to leave the syntax as SnmpAdminString rather than OBJECT IDENTIFIER. It was also requested that the above explanation be mentioned in the doc. So, the resolution is: - no object syntax change - change the description of the pktcMtaDevErrorOid to indicate the = following: "Note that the syntax of this object is SnmpAdminString rather OBJECT IDENTIFIER because the object value is provided by an operator in the MTA configuration file in the form of a character string." - after more review of the pktcMtaDevErrorValue object, we do not = believe the above text should be added to its description as this = pktcMtaDevErrorValue object may contain all kinds of object values in = the case where the MTA can recognize the OID but cannot interpret the = given value. Proposed text changes: pktcMtaDevErrorOid OBJECT-TYPE =20 SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION=20 " This object contains a human readable representation (character string) of the OID corresponding to the configuration file parameter that caused the particular error. For example, if the value of the pktcMtaDevEnabled object in the configuration file caused an error, then this object instance will contain the human readable string of '.1.3.6.1.2.1.XXX.1.1.6.0'. ************************************************************ * NOTES TO RFC Editor (to be removed prior to publication) * * Please replace XXX with the IANA-assigned number under * * mib-2. * ************************************************************ If the MTA generated an error because it was not able=20 to recognize a particular OID, then this object=20 instance would contain an empty value (zero-length string). For example, if the value of an OID in the configuration=20 file was interpreted by the MTA as being .1.2.3.4.5, and=20 the MTA was not able to recognize this OID as a valid one, this object instance will contain a zero-length string. Note that the syntax of this object is SnmpAdminString rather OBJECT IDENTIFIER because the object value is provided by an operator in the MTA configuration file in the form of a character string." ::=3D {pktcMtaDevErrorOidsEntry 2} Let us know if this change is acceptable or else, feel free to propose = text improvements or suggestions. Thanks, Jean-Fran=E7ois=20 > -----Original Message----- > From: Dave Thaler [mailto:dthaler@windows.microsoft.com]=20 > Sent: Thursday, August 05, 2004 12:33 AM > To: enechamkin@broadcom.com; Jean-Francois Mule > Cc: ipcdn@ietf.org; Wijnen, Bert (Bert);=20 > randy_presuhn@mindspring.com; C. M. Heard > Subject: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt >=20 >=20 > Here's my MIB Doctor review of this document and what I=20 > believe MUST/SHOULD/MAY be fixed. >=20 > MUST fix > -------- > 1) There is no IANA Considerations section, and this is now=20 > required in the > new guidelines. The draft needs something like (based on=20 > the template=20 > in the guidelines): >=20 > 9. IANA Considerations >=20 > The MIB module in this document uses the following=20 > IANA-assigned > OBJECT IDENTIFIER values recorded in the SMI Numbers registry: >=20 > Descriptor OBJECT IDENTIFIER value > ---------- ----------------------- > pktcMtaMib { mib-2 XXX } >=20 > Editor's Note (to be removed prior to publication): =20 > the IANA is > requested to assign a value for "XXX" under the 'mib-2' > subtree and to record the assignment in the SMI=20 > Numbers registry. > When the assignment has been made, the RFC Editor is asked to > replace "XXX" (here and in the MIB module) with the assigned > value and to remove this note. >=20 > 2) The page header on pages 2-51 says July 2002 >=20 > 3) MIB Guidelines say > If the module was developed by an IETF working group, then the > ORGANIZATION clause MUST provide the full name of the=20 > working group > ^^^^^^^^^ >=20 > The draft just uses the WG acronym: > ORGANIZATION "IETF IPCDN Working Group " >=20 > 4) The LAST-UPDATED date predates the REVISION date: > LAST-UPDATED "200406160000Z" -- June 16, 2004 > REVISION "200407160000Z" > ^ >=20 > 5) pktcMtaBasicSmtaCompliance contains > MODULE DOCS-CABLE-DEVICE-MIB > MANDATORY-GROUPS { > docsDevSoftwareGroupV2 > } > but RFC2669 is not referenced as a normative reference > and docsDevSoftwareGroupV2 isn't in there anyway, only > docsDevSoftwareGroup. Is this blocked on the progression=20 > of another > document containing this? Looks like this used to be in > draft-ietf-ipcdn-device-mibv2-*.txt which has now expired. >=20 > 6) SEQUENCE element #4 `pktcMtaDevCmsSolicitedKeyTimeout'=20 > does not match >=20 > order of columnar objects under `pktcMtaDevCmsEntry'. > Should swap the following two lines: > pktcMtaDevCmsSolicitedKeyTimeout Unsigned32, > pktcMtaDevCmsMaxClockSkew Unsigned32, >=20 > 7) pktcMtaDevProvisioningState has 'passWithWarning' (singular) in the > enum, but 'passWithWarnings' (plural) twice in the DESCRIPTION. > Also has 'failOtherReason' in the enum but 'failureOtherReason'=20 > in the DESCRIPTION. >=20 > 8) The comment on page 29 refers to=20 > draft-ietf-ipcdn-pktc-signaling-02.txt > This should be added to the references section of the doc. > Also grammar error "Upper case must be use to" > ^^^ >=20 > 9) Typo in DESCRIPTION of pktcMtaDevCmsKerbRealmName: > realm table (pktcMtaDevRealmtable)." > ^ capitalize >=20 > 10) The DESCRIPTION of pktcMtaDevRealmTgsGracePeriod has=20 > weird indentation, > and includes weird characters (as do several other objects). >=20 > SHOULD fix > ---------- > 11) pktcMtaDevErrorOidIndex: say what happens after the value 1024 is=20 > reached >=20 > 12) pktcMtaDevErrorOid, pktcMtaDevErrorValue, etc: > why are OIDs of type SnmpAdminString rather than an=20 > OBJECT IDENTIFIER > type/subtype? As is, the management station cannot do=20 > simple things > like expanding the OID into the defined string tokens in the MIB. >=20 > 13) pktcMtaDevServerDhcp1, pktcMtaDevServerDns1, etc: the=20 > DESCRIPTION of >=20 > these objects is worded as if the type is a string rather than an > InetAddress (the "dotted" IP address, etc). Technically,=20 > there's no > dots in the value, only in the displayed version of it. >=20 > 14) pktcMtaDevServerAddressType: what does it mean for this=20 > to be read-write > but the dependent InetAddress fields to be read-only? I.e., what=20 > happens to the latter immediately after the former is set? >=20 > MAY fix > ------- > 15) Consider defining a TC for kerberos realm names, since=20 > this is used by=20 > multiple objects (pktcMtaDevProvKerbRealmName,=20 > pktcMtaDevRealmName, > and pktcMtaDevCmsKerbRealmName) and has special syntax=20 > restrictions=20 > (1..255 upper case ASCII chars)=20 >=20 > 16) The current conformance statements require read-write in=20 > implementations > to be compliant. Is this intended? Since it currently=20 > only supports > ipv4, it doesn't seem useful to require read-write access to the > InetAddressType objects. >=20 > 17) pktcMtaDevSwCurrentVers is redundant with sysDescr, so=20 > why is this=20 > needed? The draft says: > The data presented in this object MUST be > identical to the software version information contained > in the 'sysDescr' MIB object of the MTA. >=20 > 18) The MIB guidelines suggest using { pktcMtaMib 0 } for the=20 > notification prefix. The draft currently requires two=20 > definitions: >=20 > pktcMtaNotificationPrefix OBJECT IDENTIFIER ::=3D { pktcMtaMib 2 } > pktcMtaNotification OBJECT IDENTIFIER ::=3D { > pktcMtaNotificationPrefix 0 } >=20 > Is there a good reason for this? (e.g. already deployed > implementations?) >=20 > 19) What is the expected behavior when reading=20 > pktcMtaDevRealmName and=20 > pktcMtaDevRealmOrgName when the row is first created and they are=20 > not set? (There's no DEFVAL, and the MIB doesn't say=20 > they have to=20 > be set in the initial createAndWait set.) >=20 > 20) draft-ietf-ipcdn-bpiplus-mib-12.txt is referenced, and is now > draft-ietf-ipcdn-bpiplus-mib-13.txt >=20 > 21) The wording in section 8 varies marginally from the template. >=20 > Template: > > Some of the readable objects in this MIB module (i.e.,=20 > objects with a > > MAX-ACCESS other than not-accessible) may be considered=20 > sensitive or > =20 > Actual: > > Some of the readable objects in this MIB module may be=20 > considered > > sensitive or [...] >=20 >=20 >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Jan 11 19:30:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20423 for ; Tue, 11 Jan 2005 19:30:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoWdC-0005eD-IE for ipcdn-archive@ietf.org; Tue, 11 Jan 2005 19:45:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoWDR-0001IS-Ow; Tue, 11 Jan 2005 19:18:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoW2u-0007Ba-NY for ipcdn@megatron.ietf.org; Tue, 11 Jan 2005 19:07:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18428 for ; Tue, 11 Jan 2005 19:07:29 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoWGo-00052l-7S for ipcdn@ietf.org; Tue, 11 Jan 2005 19:21:55 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j0C06u1e016019; Tue, 11 Jan 2005 17:06:56 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Jan 2005 17:06:56 -0700 Message-ID: Thread-Topic: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt Thread-Index: AcR6thTZfq+7VKivT3+3uhPKgFAc5B9gt0cw From: "Jean-Francois Mule" To: "Dave Thaler" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: randy_presuhn@mindspring.com, "Wijnen, Bert \(Bert\)" , ipcdn@ietf.org, "C. M. Heard" Subject: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Dave Thaler wrote: > SHOULD fix > ---------- [snip] > 13) pktcMtaDevServerDhcp1, pktcMtaDevServerDns1, etc: the=20 > DESCRIPTION of >=20 > these objects is worded as if the type is a string rather than an > InetAddress (the "dotted" IP address, etc). Technically,=20 > there's no > dots in the value, only in the displayed version of it. Good point and yes, this may be confusing. Here's a proposed rewording for all the affected object description = clauses (it's a bit of a convoluted rewording but that's the best I = could come up with): Replace: < If this object is of value '0.0.0.0', the MTA MUST stop=20 < all provisioning attempts as well as all other activities. < If this object is of value '255.255.255.255', it means there was no preference given for the primary DHCP=20 server, and, the MTA must follow the logic of RFC2131, and =20 the value of DHCP option 122 sub-option 2 must be=20 ignored." with: > If this object is of an InetAddress value equivalent to=20 > '0.0.0.0', the MTA MUST stop all provisioning attempts=20 > as well as all other activities. > If this object is of an InetAddress value equivalent to > '255.255.255.255', it means there was no preference given for the primary DHCP=20 server, and, the MTA must follow the logic of RFC2131, and =20 the value of DHCP option 122 sub-option 2 must be=20 ignored." Ok? Jean-Fran=E7ois=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Jan 11 19:31:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20477 for ; Tue, 11 Jan 2005 19:31:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoWdn-0005eu-On for ipcdn-archive@ietf.org; Tue, 11 Jan 2005 19:45:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoWDR-0001Ia-W2; Tue, 11 Jan 2005 19:18:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoW31-0007Cb-9M for ipcdn@megatron.ietf.org; Tue, 11 Jan 2005 19:07:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18446 for ; Tue, 11 Jan 2005 19:07:36 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoWGt-000544-M3 for ipcdn@ietf.org; Tue, 11 Jan 2005 19:22:02 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j0C09OJD006346 for ; Tue, 11 Jan 2005 17:09:24 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id j0C068xd002636 for ; Tue, 11 Jan 2005 18:06:08 -0600 Received: by ca25exm01 with Internet Mail Service (5.5.2657.72) id ; Tue, 11 Jan 2005 16:07:31 -0800 Message-ID: From: Nakanishi Greg-MGI8179 To: "'Randy Presuhn'" , "Ipcdn \\(E-mail\\)" Subject: RE: [ipcdn] Persistency description for docsDevCmNotifControl and docsDevCmts NotifControl Date: Tue, 11 Jan 2005 16:07:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Hi Randy, Yes, I think "SHOULD", rather then "should", would be appropriate. The intent was to recommend that these objects not be persistent, but not prohibit it. greg -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Randy Presuhn Sent: Tuesday, January 11, 2005 1:26 PM To: Ipcdn \(E-mail\) Subject: Re: [ipcdn] Persistency description for docsDevCmNotifControl anddocsDevCmts NotifControl Hi - > From: "Nakanishi Greg-MGI8179" > To: "Ipcdn (E-mail)" > Sent: Tuesday, January 11, 2005 9:23 AM > Subject: [ipcdn] Persistency description for docsDevCmNotifControl > anddocsDevCmts NotifControl > > I received a comment that there should be a description of persistency > of the docsDevCmNotifControl and docsDevCmtsNotifControl objects in > the Event Notification MIB. > > I added the following sentence to the description of both objects: > > "If the device is rebooted,the value of this object should revert to > the default value." > > I'd like to solicit feedback on this, particularly if anyone disagrees > with the sentence. ... 1) is the "should" meant as a "SHOULD"? 2) is the intent really to weakly prohibit persistence? (I don't have a position, I'm just trying to understand.) Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Jan 11 19:37:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20782 for ; Tue, 11 Jan 2005 19:37:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoWjU-0005mS-Cg for ipcdn-archive@ietf.org; Tue, 11 Jan 2005 19:51:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoWOX-0004Ah-Lf; Tue, 11 Jan 2005 19:29:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoWAx-0000KD-4R for ipcdn@megatron.ietf.org; Tue, 11 Jan 2005 19:15:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18981 for ; Tue, 11 Jan 2005 19:15:47 -0500 (EST) Received: from mms-nat.broadcom.com ([63.70.210.58] helo=mms1.broadcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoWOr-0005Eq-J8 for ipcdn@ietf.org; Tue, 11 Jan 2005 19:30:14 -0500 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Tue, 11 Jan 2005 16:14:59 -0800 X-Server-Uuid: 97B92932-364A-4474-92D6-5CFE9C59AD14 Received: from nt-irva-0740.brcm.ad.broadcom.com ( nt-irva-0740.brcm.ad.broadcom.com [10.8.194.53]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id QAA08407; Tue, 11 Jan 2005 16:14:59 -0800 (PST) Received: from nt-rmna-0740.brcm.ad.broadcom.com ([10.136.192.33]) by nt-irva-0740.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Jan 2005 16:14:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 11 Jan 2005 16:14:56 -0800 Message-ID: <24CDBA67F085904999751B3C4F9E8C0B01E76C70@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt Thread-Index: AcR6thTZfq+7VKivT3+3uhPKgFAc5B9gt0cwAACrS5A= From: "Eugene Nechamkin" To: "Jean-Francois Mule" , "Dave Thaler" X-OriginalArrivalTime: 12 Jan 2005 00:14:59.0323 (UTC) FILETIME=[C0B78CB0:01C4F83B] X-WSS-ID: 6DFAB3891FC8383688-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Cc: randy_presuhn@mindspring.com, "Wijnen, Bert \(Bert\)" , ipcdn@ietf.org, "C. M. Heard" Subject: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Looks good to me. Eugene. -----Original Message----- From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 Sent: Tuesday, January 11, 2005 4:07 PM To: Dave Thaler; Eugene Nechamkin Cc: ipcdn@ietf.org; Wijnen, Bert (Bert); randy_presuhn@mindspring.com; = C. M. Heard Subject: RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt Dave Thaler wrote: > SHOULD fix > ---------- [snip] > 13) pktcMtaDevServerDhcp1, pktcMtaDevServerDns1, etc: the DESCRIPTION=20 > of >=20 > these objects is worded as if the type is a string rather than an > InetAddress (the "dotted" IP address, etc). Technically, there's=20 > no > dots in the value, only in the displayed version of it. Good point and yes, this may be confusing. Here's a proposed rewording for all the affected object description = clauses (it's a bit of a convoluted rewording but that's the best I = could come up with): Replace: < If this object is of value '0.0.0.0', the MTA MUST stop=20 < all provisioning attempts as well as all other activities. < If this object is of value '255.255.255.255', it means there was no preference given for the primary DHCP=20 server, and, the MTA must follow the logic of RFC2131, and =20 the value of DHCP option 122 sub-option 2 must be=20 ignored." with: > If this object is of an InetAddress value equivalent to=20 > '0.0.0.0', the MTA MUST stop all provisioning attempts=20 > as well as all other activities. > If this object is of an InetAddress value equivalent to > '255.255.255.255', it means there was no preference given for the primary DHCP=20 server, and, the MTA must follow the logic of RFC2131, and =20 the value of DHCP option 122 sub-option 2 must be=20 ignored." Ok? Jean-Fran=E7ois=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Jan 12 06:46:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04235 for ; Wed, 12 Jan 2005 06:46:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CohBi-0002vH-3F for ipcdn-archive@ietf.org; Wed, 12 Jan 2005 07:01:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoguG-0002wN-4e; Wed, 12 Jan 2005 06:43:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cogs8-0002Ne-5H for ipcdn@megatron.ietf.org; Wed, 12 Jan 2005 06:41:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03969 for ; Wed, 12 Jan 2005 06:41:05 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Coh66-0002mZ-Mp for ipcdn@ietf.org; Wed, 12 Jan 2005 06:55:37 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j0CBeWi0028573 for ; Wed, 12 Jan 2005 05:40:33 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 12 Jan 2005 12:40:32 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155062BE42F@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Dave Thaler , Jean-Francois Mule , ipcdn@ietf.org Date: Wed, 12 Jan 2005 12:40:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: randy_presuhn@mindspring.com, "C. M. Heard" , enechamkin@broadcom.com Subject: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Look fine to me too Bert > -----Original Message----- > From: Dave Thaler [mailto:dthaler@windows.microsoft.com] > Sent: Wednesday, January 12, 2005 03:39 > To: Jean-Francois Mule; ipcdn@ietf.org > Cc: Wijnen, Bert (Bert); randy_presuhn@mindspring.com; C. M. Heard; > enechamkin@broadcom.com > Subject: RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt > > > Jean-Francois Mule writes: > > To close on one additional comment: > > Dave wrote: > > > 12) pktcMtaDevErrorOid, pktcMtaDevErrorValue, etc: > > > why are OIDs of type SnmpAdminString rather than an > > > OBJECT IDENTIFIER > > > type/subtype? As is, the management station cannot do > > > simple things > > > like expanding the OID into the defined string tokens in the > MIB. > [...] > > So, the resolution is: > > - no object syntax change > > - change the description of the pktcMtaDevErrorOid to > indicate the > > following: > > "Note that the syntax of this object is SnmpAdminString > > rather OBJECT IDENTIFIER because the object value is > > provided by an operator in the MTA configuration file > > in the form of a character string." > > - after more review of the pktcMtaDevErrorValue object, > we do not > > believe the above text should be added to its description as this > > pktcMtaDevErrorValue object may contain all kinds of object > values in > the > > case where the MTA can recognize the OID but cannot interpret the > given > > value. > [...] > > This resolution looks fine to me. > > -Dave > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Jan 12 09:24:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15960 for ; Wed, 12 Jan 2005 09:24:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cojdw-0006vP-77 for ipcdn-archive@ietf.org; Wed, 12 Jan 2005 09:38:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CojJt-0008QM-Bg; Wed, 12 Jan 2005 09:17:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoXvL-0006fd-OA for ipcdn@megatron.ietf.org; Tue, 11 Jan 2005 21:07:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27181 for ; Tue, 11 Jan 2005 21:07:49 -0500 (EST) Received: from mms-nat.broadcom.com ([63.70.210.58] helo=mms3.broadcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoY9F-0007jP-Dq for ipcdn@ietf.org; Tue, 11 Jan 2005 21:22:15 -0500 Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Tue, 11 Jan 2005 18:07:03 -0800 X-Server-Uuid: 062D48FB-9769-4139-967C-478C67B5F9C9 Received: from nt-irva-0740.brcm.ad.broadcom.com ( nt-irva-0740.brcm.ad.broadcom.com [10.8.194.53]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id SAA05925; Tue, 11 Jan 2005 18:07:03 -0800 (PST) Received: from nt-rmna-0740.brcm.ad.broadcom.com ([10.136.192.33]) by nt-irva-0740.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Jan 2005 18:07:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] IETF NCS Sig MIB Tone Table Date: Tue, 11 Jan 2005 18:07:01 -0800 Message-ID: <24CDBA67F085904999751B3C4F9E8C0B01E76C7D@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] IETF NCS Sig MIB Tone Table Thread-Index: AcT0B3lvN1wUAD69QZ6D480F9gtxqgEQpUBw From: "Eugene Nechamkin" To: "Beacham Gordon-CGB005" , sumanth@cablelabs.com X-OriginalArrivalTime: 12 Jan 2005 02:07:02.0865 (UTC) FILETIME=[6842A410:01C4F84B] X-WSS-ID: 6DFA59CD2349298918-01-01 X-Spam-Score: 3.7 (+++) X-Scan-Signature: ba143a8ed18dc7be9da38313352319a1 X-Mailman-Approved-At: Wed, 12 Jan 2005 09:17:52 -0500 Cc: ipcdn@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0372959035==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 3.7 (+++) X-Scan-Signature: 1e681f1d9089d699fa07ea1655f6d87c This is a multi-part message in MIME format. --===============0372959035== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4F84B.673BFA31" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4F84B.673BFA31 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable =20 We believe the tone generation capabilities are getting overly complicated for the added benefit they are providing. Operators need to be able to easily fill these out and we may be getting into a situation where we create more problems than solutions. =20 In addition, we believe the interpretation of E.180 below in the examples may not be correct. (In the Japan case, f1 is not modulated by f2, it is modulated by 16Hz). =20 This needs to be reconsidered further to find an alternative which provides the necessary functionality in a less complicated way. As the solution does not seem to be obvious, some time for further dicussions is needed to come up with the reasonable approach.=20 =20 Eugene. ________________________________ From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Beacham Gordon-CGB005 Sent: Wednesday, January 05, 2005 8:23 AM To: 'ipcdn@ietf.org'; 'sumanth@cablelabs.com' Subject: [ipcdn] IETF NCS Sig MIB Tone Table ITU-T supplement 2 (E.180) identifies several tone definitions that cannot be currently satisfied by the IETF NCS Sig MIB tone table definition. It is important for the IETF NCS Sig MIB to support E.180 tone definitions for: 1. embedded tone cadences (i.e., Romania number unobtainable tone, etc) [2 examples shown below]=20 2. amplitude modulation (i.e., Japan call waiting tone) [1 example shown below] To address these issues, the following changes are recommended: PktcSigDevToneEntry ::=3D SEQUENCE {=20 pktcSigDevToneType INTEGER,=20 pktcSigDevToneDbLevel TenthdBm,=20 pktcSigDevToneFreqType INTEGER,=20 pktcSigDevToneNumFrequencies Unsigned32,=20 pktcSigDevToneFirstFrequency Unsigned32,=20 pktcSigDevToneFirstToneSecondaryFrequency Unsigned32,=20 pktcSigDevToneFirstToneSecondaryMode Unsigned32,=20 pktcSigDevToneFirstToneSecondaryAttribute Unsigned32,=20 pktcSigDevToneSecondFrequency Unsigned32,=20 pktcSigDevToneSecondToneSecondaryFrequency Unsigned32,=20 pktcSigDevToneSecondToneSecondaryMode Unsigned32,=20 pktcSigDevToneSecondToneSecondaryAttribute Unsigned32,=20 pktcSigDevToneThirdFrequency Unsigned32,=20 pktcSigDevToneThirdToneSecondaryFrequency Unsigned32,=20 pktcSigDevToneThirdToneSecondaryMode Unsigned32,=20 pktcSigDevToneThirdToneSecondaryAttribute Unsigned32,=20 pktcSigDevToneFourthFrequency Unsigned32,=20 pktcSigDevToneFourthToneSecondaryFrequency Unsigned32,=20 pktcSigDevToneFourthToneSecondaryMode Unsigned32,=20 pktcSigDevToneFourthToneSecondaryAttribute Unsigned32,=20 pktcSigDevToneFifthFrequency Unsigned32,=20 pktcSigDevToneFifthToneSecondaryFrequency Unsigned32,=20 pktcSigDevToneFifthToneSecondaryMode Unsigned32,=20 pktcSigDevToneFifthToneSecondaryAttribute Unsigned32,=20 pktcSigDevToneNumOnOffTimes Unsigned32,=20 pktcSigDevToneFirstToneOn Unsigned32,=20 pktcSigDevToneFirstToneOff Unsigned32,=20 pktcSigDevToneFirstToneRepeatCount Unsigned32,=20 pktcSigDevToneSecondToneOn Unsigned32,=20 pktcSigDevToneSecondToneOff Unsigned32,=20 pktcSigDevToneSecondToneRepeatCount Unsigned32,=20 pktcSigDevToneThirdToneOn Unsigned32,=20 pktcSigDevToneThirdToneOff Unsigned32,=20 pktcSigDevToneThirdToneRepeatCount Unsigned32,=20 pktcSigDevToneFourthToneOn Unsigned32,=20 pktcSigDevToneFourthToneOff Unsigned32,=20 pktcSigDevToneFourthToneRepeatCount Unsigned32,=20 pktcSigDevToneFifthToneOn Unsigned32,=20 pktcSigDevToneFifthToneOff Unsigned32,=20 pktcSigDevToneFifthToneRepeatCount Unsigned32,=20 pktcSigDevToneWholeToneRepeatCount Unsigned32,=20 pktcSigDevToneSteady TruthValue=20 }=20 =20 pktcSigDevToneFirstToneSecondaryFrequency SYNTAX Unsigned32 (0..4000) MAX-ACCESS read-write STATUS current DESCRIPTION "The secondary frequency used to amplitude modulate or which is summed with the pktcSigDevToneFirstFrequency depending on the setting of pktcSigDevToneFirstToneSecondaryMode." ::=3D{pktcSigDevToneEntry x} =20 A similar object definition is required for: =20 pktcSigDevToneSecondToneSecondaryFrequency pktcSigDevToneThirdToneSecondaryFrequency pktcSigDevToneFourthToneSecondaryFrequency pktcSigDevToneFifthToneSecondaryFrequency =20 pktcSigDevToneFirstToneSecondaryMode SYNTAX INTEGER {=20 noModNoSum (1), primaryModulatedBySecondary (2),=20 primarySummedWithSecondary (3)=20 }=20 MAX-ACCESS read-write STATUS current DESCRIPTION "When pktcSigDevToneFirstToneSecondaryMode is set to primaryModulatedBySecondary, the pktcSigDevToneFirstToneSecondaryFrequency is used to amplitude modulate the pktcSigDevToneFirstFrequency. When pktcSigDevToneFirstToneSecondaryMode is set to primarySummedWithSecondary, the pktcSigDevToneFirstToneSecondaryFrequency is summed with the pktcSigDevToneFirstFrequency without any modulation. When pktcSigDevToneFirstToneSecondaryMode is set to noModNoSum, the pktcSigDevToneFirstToneSecondaryFrequency MUST NOT be used." DEFVAL { 1 } ::=3D{pktcSigDevToneEntry x} =20 pktcSigDevToneFirstToneSecondaryAttribute SYNTAX Unsigned32 (0..100) MAX-ACCESS read-write STATUS current DESCRIPTION "The percentage of amplitude modulation applied to the pktcSigDevToneFirstToneSecondaryFrequency. This object is only used if pktcSigDevToneFirstToneSecondaryMode is primaryModulatedBySecondary. An attempt to set this object while the value of pktcSigDevToneFirstToneSecondaryMode is not primaryModulatedBySecondary will result in an inconsistentValue error." ::=3D{pktcSigDevToneEntry x} =20 A similar object definition is required for: =20 pktcSigDevToneSecondToneSecondaryAttribute pktcSigDevToneThirdToneSecondaryAttribute pktcSigDevToneFourthToneSecondaryAttribute pktcSigDevToneFifthToneSecondaryAttribute =20 pktcSigDevToneFirstToneRepeatCount =20 SYNTAX Unsigned32 (0..5000) MAX-ACCESS read-write STATUS current DESCRIPTION "The repeat count which indicates the number of times to repeat the pktcSigDevToneFirstToneOn and pktcSigDevToneFirstToneOff cadence cycle. Setting this object may result in a tone duration longer or shorter than the overall signal duration specified by the time out (TO) object for a particular signal. If the repeat count results in a longer tone duration than the signal duration specified by the TO, the tone duration defined by the TO object for a particular signal always represents the overall signal duration for a tone. In this case, the tone duration repeat count will not be fully exercised and the desired tone duration will be truncated per the TO setting. If the repeat count results in a shorter tone duration than the signal duration specified by the TO, the tone duration defined by the repeat count takes precedence over the TO and will end the signal event. In this case, the TO represents a time not to be exceeded for the signal. It is recommended to ensure proper telephony signaling that the TO duration setting should always be longer than the desired repeat count time duration. A value of zero means the tone sequence is to be played once but not repeated." ::=3D{pktcSigDevToneEntry x} =20 A similar object definition is required for: =20 pktcSigDevToneSecondToneRepeatCount =20 pktcSigDevToneThirdToneRepeatCount =20 pktcSigDevToneFourthToneRepeatCount =20 pktcSigDevToneFifthToneRepeatCount=20 =20 The following objects should be deleted. They are no longer applicable in lieu of the above changes. =20 pktcSigDevToneFreqType OBJECT-TYPE=20 SYNTAX INTEGER {=20 allFrequencies (1),=20 singleFrequencySequence (2),=20 dualFrequencySequence (3),=20 allFrequenciesModulated (4)=20 }=20 MAX-ACCESS read-write=20 STATUS current=20 DESCRIPTION=20 "This object describes how the frequencies are applied.=20 allFrequencies indicates all frequencies specifed by pktcSigDevToneNumFrequencies are mixed to form a single tone. The tone is then applied in sequence using the number of on/off times specified in pktcSigDevToneNumOnOffTimes. SingleFrequecySequence indicates all frequencies specified by pktcSigDevToneNumFrequencies are applied in sequence using the corresponding frequency number on/off time (e.g., pktcSigDevToneFirstFrequency uses pktcSigDevToneFirstToneOn and pktcSigDevToneFirstToneOff, pktcSigDevToneSecondFrequency uses pktcSigDevToneSecondToneOn and pktcSigDevToneSecondToneOff). For this tone type pktcSigDevToneNumFrequencies MUST equal pktcSigDevToneNumOnOffTimes. DualFrequencySequence indicates two pairs of frequencies are added to form two sequenced tones. The first and second frequency are added to form tone one and are applied using pktcSigDevToneFirstToneOn and pktcSigDevToneFirstToneOff. The third and forth frequency are added to form tone two and are applied using pktcSigDevToneSecondToneOn and pktcSigDevToneSecondToneOff. For this tone type pktcSigDevToneNumFrequencies MUST equal 4 and pktcSigDevToneNumOnOffTimes MUST equal 2. allFrequenciesModulated indicates all frequencies specified by pktcSigDevToneNumFrequencies are modulated to form a single tone. The tone is then applied in sequence using the number of on/off times specified in pktcSigDevToneNumOnOffTimes. For allFrequenciesModulated, the pktcSigDevToneNumFrequencies MUST equal 2, and the frequency in pktcSigDevToneFirstFrequency modulates the frequency in pktcSigDevToneSecondFrequency." REFERENCE=20 "ITU-T E.180"=20 DEFVAL { allFrequencies }=20 ::=3D{ pktcSigDevToneEntry 3 }=20 =20 pktcSigDevToneNumFrequencies OBJECT-TYPE=20 =20 =09 Example 1 - Modulated/Unmodulated Tone: =20 Japan call waiting tone with the following definition per ITU-T E.180: f1 mod f2, where f1=3D400 Hz AM modulated by 16 Hz, f2=3D400 Hz not AM modulated cadence: first tone: 500ms ON then 0 to 400ms OFF second tone: 50ms ON then 450ms OFF third tone: 50ms ON then 3450ms OFF fourth tone: 50ms ON then 450ms OFF fifth tone: 50ms ON then 3450 ms OFF not repeated, not continuous =20 Example 2 - Embedded Cadence: This example of an embedded cadence is based on an operator variation of a national standard. A similar example of an embedded cadence can be found in ITU-T supplement 2 (E.180) for Romania. =20 Frequency: 425Hz Cadence: - 1) ton:1000msec, toff: 40msec - 2) 9 sec repeat of (ton: 40mesc, toff: 40msec) - 3) ton: continuous =20 Example 3 - Embedded Cadence: This example of an embedded cadence is based on an operator variation of a national standard. =20 Frequency: 425Hz Cadence: - 1) ton: 160msec, toff: 40msec - 2) 7* (ton: 40msec, toff: 40msec) - 3) ton: 160msec, toff 40msec - 4) 7* (ton: 40msec, toff: 40msec) - 5) ton: 160msec, toff 40msec - 6) 7* (ton: 40msec, toff: 40msec) =20 ------_=_NextPart_001_01C4F84B.673BFA31 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message=
 
We believe the tone generation capabilities are = getting=20 overly complicated for the added benefit they are providing. Operators = need to=20 be able to easily fill these out and we may be getting into a situation = where we=20 create more problems than solutions.
 
In addition, we believe the interpretation of = E.180 below=20 in the examples may not be correct. (In the Japan case, f1 is not = modulated by=20 f2, it is modulated by 16Hz).
 
This needs to be reconsidered = further to find an alternative which provides the necessary = functionality in a=20 less complicated way. As the solution does not seem to be obvious, = some time=20 for further dicussions is needed to come up with = the reasonable=20 approach.
 
Eugene.

From: ipcdn-bounces@ietf.org=20 [mailto:ipcdn-bounces@ietf.org] On Behalf Of Beacham=20 Gordon-CGB005
Sent: Wednesday, January 05, 2005 8:23 = AM
To:=20 'ipcdn@ietf.org'; 'sumanth@cablelabs.com'
Subject: [ipcdn] = IETF NCS=20 Sig MIB Tone Table

ITU-T supplement 2 (E.180) identifies several tone = definitions=20 that cannot be currently satisfied by the IETF NCS Sig MIB tone table=20 definition. It is important for = the=20 IETF NCS Sig MIB to support = E.180 tone=20 definitions for:
  1. embedded tone cadences (i.e.,=20 = Romania=20 number unobtainable tone, etc) [2 examples shown = below]=20
  2. amplitude modulation (i.e.,=20 = Japan = call=20 waiting tone) [1 example shown=20 below]
To address these = issues, the=20 following changes are recommended:

PktcSigDevToneEntry ::=3D SEQUENCE = {=20

    = pktcSigDevToneType           &n= bsp;         =20 INTEGER,

    = pktcSigDevToneDbLevel           &n= bsp;      =20 TenthdBm,

   =20 pktcSigDevToneFreqType           &n= bsp;     =20 INTEGER,

   =20 pktcSigDevToneNumFrequencies           =20 Unsigned32,

   =20 pktcSigDevToneFirstFrequency           =20 Unsigned32,

   =20 pktcSigDevToneFirstToneSecondaryFrequency Unsigned32,=20

   =20 pktcSigDevToneFirstToneSecondaryMode      = Unsigned32,=20

   =20 pktcSigDevToneFirstToneSecondaryAttribute Unsigned32,=20

   =20 pktcSigDevToneSecondFrequency          =20 Unsigned32,

   =20 pktcSigDevToneSecondToneSecondaryFrequency Unsigned32,=20

   =20 pktcSigDevToneSecondToneSecondaryMode      = Unsigned32,=20

   =20 pktcSigDevToneSecondToneSecondaryAttribute Unsigned32,=20

   =20 pktcSigDevToneThirdFrequency           =20 Unsigned32,

   =20 pktcSigDevToneThirdToneSecondaryFrequency Unsigned32,=20

   =20 pktcSigDevToneThirdToneSecondaryMode      = Unsigned32,=20

   =20 pktcSigDevToneThirdToneSecondaryAttribute Unsigned32,=20

   =20 pktcSigDevToneFourthFrequency           Unsigned32,=20

   =20 pktcSigDevToneFourthToneSecondaryFrequency Unsigned32,=20

   =20 pktcSigDevToneFourthToneSecondaryMode      = Unsigned32,=20

   =20 pktcSigDevToneFourthToneSecondaryAttribute Unsigned32,=20

   =20 pktcSigDevToneFifthFrequency           =20 Unsigned32,

   =20 pktcSigDevToneFifthToneSecondaryFrequency Unsigned32,=20

   =20 pktcSigDevToneFifthToneSecondaryMode      = Unsigned32,=20

   =20 pktcSigDevToneFifthToneSecondaryAttribute Unsigned32,=20

   =20 pktcSigDevToneNumOnOffTimes           &n= bsp;=20 Unsigned32,

   =20 pktcSigDevToneFirstToneOn           &n= bsp;  =20 Unsigned32,

   =20 pktcSigDevToneFirstToneOff           &n= bsp; =20 Unsigned32,

   =20 pktcSigDevToneFirstToneRepeatCount      = Unsigned32,=20

   =20 pktcSigDevToneSecondToneOn           &n= bsp; =20 Unsigned32,

   =20 pktcSigDevToneSecondToneOff           &n= bsp;=20 Unsigned32,

   =20 pktcSigDevToneSecondToneRepeatCount     = Unsigned32,=20

   =20 pktcSigDevToneThirdToneOn           &n= bsp;  =20 Unsigned32,

   =20 pktcSigDevToneThirdToneOff           &n= bsp; =20 Unsigned32,

   =20 pktcSigDevToneThirdToneRepeatCount      = Unsigned32,=20

   =20 pktcSigDevToneFourthToneOn           &n= bsp; =20 Unsigned32,

   =20 pktcSigDevToneFourthToneOff           &n= bsp;=20 Unsigned32,

   =20 pktcSigDevToneFourthToneRepeatCount     = Unsigned32,=20

   =20 pktcSigDevToneFifthToneOn          =20     Unsigned32,=20

   =20 pktcSigDevToneFifthToneOff          =20    Unsigned32,=20

   =20 pktcSigDevToneFifthToneRepeatCount      Unsigned32,=20

   =20 pktcSigDevToneWholeToneRepeatCount      = Unsigned32,=20

    = pktcSigDevToneSteady           &n= bsp;       =20 TruthValue

    }=20

 

pktcSigDevToneFirstToneSecondaryFrequency

     = SYNTAX     Unsigned32 = (0..4000)

     MAX-ACCESS = read-write

     = STATUS    =20 current

     DESCRIPTION

     "The secondary frequency used = to=20 amplitude modulate or

      = which is=20 summed with the pktcSigDevToneFirstFrequency

      depending on the setting=20 of

      pktcSigDevToneFirstToneSecondaryMode."

     ::=3D{pktcSigDevToneEntry=20 x}

 

A similar object = definition is required for:

 

pktcSigDevToneSecondToneSecondaryFrequency

pktcSigDevToneThirdToneSecondaryFrequency

pktcSigDevToneFourthToneSecondaryFrequency

pktcSigDevToneFifthToneSecondaryFrequency

 

pktcSigDevToneFirstToneSecondaryMode

    SYNTAX       = INTEGER=20 {

           =20 noModNoSum (1),

           =20 primaryModulatedBySecondary (2),

           =20 primarySummedWithSecondary (3)

    }=20

MAX-ACCESS=20 read-write

     = STATUS    =20 current

    =20 DESCRIPTION

     "When=20 pktcSigDevToneFirstToneSecondaryMode is set to

     =20 primaryModulatedBySecondary, the

      pktcSigDevToneFirstToneSecondaryFrequency=20 is

      used = to=20 amplitude modulate the

     =20 pktcSigDevToneFirstFrequency.

      When = pktcSigDevToneFirstToneSecondaryMode is set to

     =20 primarySummedWithSecondary, the

     =20 pktcSigDevToneFirstToneSecondaryFrequency is=20 summed

      with the = pktcSigDevToneFirstFrequency=20 without any

      modulation. When=20 pktcSigDevToneFirstToneSecondaryMode

      is set to noModNoSum,=20 the

      pktcSigDevToneFirstToneSecondaryFrequency=20 MUST NOT be

      used."

      = DEFVAL { 1=20 }

    =20 ::=3D{pktcSigDevToneEntry x}

 

pktcSigDevToneFirstToneSecondaryAttribute

     = SYNTAX     Unsigned32 = (0..100)

     MAX-ACCESS = read-write

     STATUS    =20 current

    =20 DESCRIPTION

     "The = percentage of=20 amplitude modulation applied to the

     =20 pktcSigDevToneFirstToneSecondaryFrequency. = This

      object is only used=20 if

     =20 pktcSigDevToneFirstToneSecondaryMode is

     =20 primaryModulatedBySecondary. An attempt to set this object = while the=20 value of

         =20 pktcSigDevToneFirstToneSecondaryMode

is not primaryModulatedBySecondary = will result=20 in

         =20 an inconsistentValue error."

    =20 ::=3D{pktcSigDevToneEntry x}

 

A similar object = definition is required for:

 

pktcSigDevToneSecondToneSecondaryAttribute

pktcSigDevToneThirdToneSecondaryAttribute

pktcSigDevToneFourthToneSecondaryAttribute

pktcSigDevToneFifthToneSecondaryAttribute

 

pktcSigDevToneFirstToneRepeatCount    =20

     = SYNTAX     Unsigned32 = (0..5000)

     MAX-ACCESS = read-write

     = STATUS    =20 current

    =20 DESCRIPTION

     "The = repeat count=20 which indicates the number of times

      to repeat the = pktcSigDevToneFirstToneOn=20 and

     =20 pktcSigDevToneFirstToneOff cadence cycle.=20 Setting

      this = object=20 may result in a tone duration longer or

      shorter than the overall = signal=20 duration specified by

      the time out (TO) object for = a=20 particular signal. If

      the repeat count results in a = longer=20 tone duration

      than the signal duration = specified by=20 the TO, the

      tone duration defined by the = TO object=20 for a

      particular signal always = represents the=20 overall

      signal duration for a tone. = In this=20 case, the tone

      duration repeat count will = not be fully=20 exercised and

      the = desired=20 tone duration will be truncated per the

      TO setting. If the repeat = count results=20 in a shorter

      tone duration than the signal = duration=20 specified by

      the TO, the tone duration = defined by=20 the repeat count

      takes precedence over the TO = and will=20 end the signal

      event. In this case, the TO = represents=20 a time not to

      be exceeded for the signal. = It is=20 recommended to

      ensure proper telephony = signaling that=20 the TO

  =20    duration setting should = always be=20 longer than the

 =20     desired=20 repeat count time duration. A value of = zero

      = means the tone=20 sequence is to be played once but not

     =20 repeated."

    =20 ::=3D{pktcSigDevToneEntry x}

 

A similar object = definition is required for:

 

pktcSigDevToneSecondToneRepeatCount    =20

pktcSigDevToneThirdToneRepeatCount     =20

pktcSigDevToneFourthToneRepeatCount    =20

pktcSigDevToneFifthToneRepeatCount=20

 

The following objects should = be deleted. They are no longer = applicable in lieu=20 of the above changes.

 

pktcSigDevToneFreqType    OBJECT-TYPE=20

    SYNTAX      = INTEGER {=20

           &n= bsp;   =20 allFrequencies (1),

           &n= bsp;   =20 singleFrequencySequence (2),

           &n= bsp;   =20 dualFrequencySequence (3),

           &n= bsp;   =20 allFrequenciesModulated (4)

    } =

    MAX-ACCESS   read-write =

    STATUS       = current=20

    DESCRIPTION=20

        = "This object describes how the frequencies are applied. =

        =20 allFrequencies indicates all frequencies specifed = by

        =20 pktcSigDevToneNumFrequencies are mixed to form a = single

        =20 tone. The tone is then applied in sequence using = the

        =20 number of on/off times specified in

        =20 pktcSigDevToneNumOnOffTimes. = SingleFrequecySequence

        =20 indicates all frequencies specified by

        =20 pktcSigDevToneNumFrequencies are applied in = sequence

        =20 using the corresponding frequency number on/off = time

        =20 (e.g., pktcSigDevToneFirstFrequency uses

        =20 pktcSigDevToneFirstToneOn and=20 pktcSigDevToneFirstToneOff,

        =20 pktcSigDevToneSecondFrequency uses

        =20 pktcSigDevToneSecondToneOn and

        =20 pktcSigDevToneSecondToneOff). For this tone type

        =20 pktcSigDevToneNumFrequencies MUST equal

        =20 pktcSigDevToneNumOnOffTimes. = DualFrequencySequence

        =20 indicates two pairs of frequencies are added to form = two

        =20 sequenced tones. The first and second frequency are=20 added

        =20 to form tone one and are applied using

        =20 pktcSigDevToneFirstToneOn and=20 pktcSigDevToneFirstToneOff.

        =20 The third and forth frequency are added to form tone = two

        =20 and are applied using pktcSigDevToneSecondToneOn = and

        =20 pktcSigDevToneSecondToneOff. For this tone type

        =20 pktcSigDevToneNumFrequencies MUST equal 4 and

        =20 pktcSigDevToneNumOnOffTimes MUST equal 2.

        =20 allFrequenciesModulated indicates all = frequencies

        =20 specified by pktcSigDevToneNumFrequencies are modulated=20 to

        =20 form a single tone. The tone is then applied in = sequence

        =20 using the number of on/off times specified in

        =20 pktcSigDevToneNumOnOffTimes. For=20 allFrequenciesModulated,

        =20 the pktcSigDevToneNumFrequencies MUST equal 2, and = the

        =20 frequency in pktcSigDevToneFirstFrequency modulates = the

        =20 frequency in pktcSigDevToneSecondFrequency."

    REFERENCE =

        = "ITU-T E.180"

    DEFVAL { = allFrequencies }=20

    ::=3D{ = pktcSigDevToneEntry 3=20 }

 

pktcSigDevToneNumFrequencies    OBJECT-TYPE=20

 

Example 1 - Modulated/Unmodulated=20 Tone:

 

Japan call waiting tone with the following = definition=20 per ITU-T E.180:

f1 mod f2, where f1=3D400 Hz AM modulated by = 16 Hz,=20 f2=3D400 Hz not AM modulated

cadence:

first tone: 500ms ON then 0 to 400ms=20 OFF

second tone: 50ms ON then 450ms=20 OFF

third tone: 50ms ON then 3450ms=20 OFF

fourth tone: 50ms ON then 450ms=20 OFF

fifth tone: 50ms ON then 3450 ms=20 OFF

not repeated, not = continuous

 

Example 2 -=20 Embedded Cadence:

This example of = an embedded=20 cadence is based on an operator variation of a national standard. A = similar=20 example of an embedded cadence can be found in ITU-T supplement = 2=20 (E.180) for=20 = Romania.<= SPAN=20 style=3D"mso-fareast-font-family: 'Times New = Roman'">

 

Frequency:=20 425Hz

Cadence:

- = 1)=20 ton:1000msec, toff: 40msec

- = 2) 9 sec=20 repeat of (ton: 40mesc, toff: 40msec)

- = 3) ton:=20 continuous

 

Example 3 -=20 Embedded Cadence:

This example=20 of an embedded cadence is based on an operator variation of a national = standard.

 

Frequency:=20 425Hz

Cadence:

- = 1) ton:=20 160msec, toff: 40msec

- = 2) 7* (ton:=20 40msec, toff: 40msec)

- = 3) ton:=20 160msec, toff 40msec

- = 4) 7* (ton:=20 40msec, toff: 40msec)

- = 5) ton:=20 160msec, toff 40msec

- = 6) 7* (ton:=20 40msec, toff: 40msec)

 

------_=_NextPart_001_01C4F84B.673BFA31-- --===============0372959035== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============0372959035==-- From ipcdn-bounces@ietf.org Wed Jan 12 09:24:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15989 for ; Wed, 12 Jan 2005 09:24:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CojeG-0006vi-N4 for ipcdn-archive@ietf.org; Wed, 12 Jan 2005 09:39:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CojJt-0008QR-Ra; Wed, 12 Jan 2005 09:17:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoYMI-00045b-6j for ipcdn@megatron.ietf.org; Tue, 11 Jan 2005 21:35:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28653 for ; Tue, 11 Jan 2005 21:35:39 -0500 (EST) Received: from mms-nat.broadcom.com ([63.70.210.58] helo=mms1.broadcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoYaC-0008IG-1X for ipcdn@ietf.org; Tue, 11 Jan 2005 21:50:05 -0500 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Tue, 11 Jan 2005 18:34:53 -0800 X-Server-Uuid: 97B92932-364A-4474-92D6-5CFE9C59AD14 Received: from nt-irva-0740.brcm.ad.broadcom.com ( nt-irva-0740.brcm.ad.broadcom.com [10.8.194.53]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id SAA11636; Tue, 11 Jan 2005 18:34:53 -0800 (PST) Received: from nt-rmna-0740.brcm.ad.broadcom.com ([10.136.192.33]) by nt-irva-0740.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Jan 2005 18:34:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] IETF NCS Sig MIB Tone Table Date: Tue, 11 Jan 2005 18:34:50 -0800 Message-ID: <24CDBA67F085904999751B3C4F9E8C0B01E76C7E@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] IETF NCS Sig MIB Tone Table Thread-Index: AcT0B3lvN1wUAD69QZ6D480F9gtxqgEQpUBwAAE2C0A= From: "Eugene Nechamkin" To: "Beacham Gordon-CGB005" , sumanth@cablelabs.com X-OriginalArrivalTime: 12 Jan 2005 02:34:52.0835 (UTC) FILETIME=[4BA3D730:01C4F84F] X-WSS-ID: 6DFA53471FC8414849-01-01 X-Spam-Score: 3.7 (+++) X-Scan-Signature: f25395c61ce97c691771e8bd63d587fc X-Mailman-Approved-At: Wed, 12 Jan 2005 09:17:52 -0500 Cc: ipcdn@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1500396239==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 3.7 (+++) X-Scan-Signature: 193515d63a2b1bb1b708157174fe8e5e This is a multi-part message in MIME format. --===============1500396239== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4F84F.4A51793A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4F84F.4A51793A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable =20 Resending my previous message as it bounced off of the reflector ("Message body is too big: 86122 bytes with a limit of 70 KB" which is obviously not the case for my message). ________________________________ From: Eugene Nechamkin=20 Sent: Tuesday, January 11, 2005 6:07 PM To: 'Beacham Gordon-CGB005'; 'sumanth@cablelabs.com' Cc: 'ipcdn@ietf.org' Subject: RE: [ipcdn] IETF NCS Sig MIB Tone Table =20 We believe the tone generation capabilities are getting overly complicated for the added benefit they are providing. Operators need to be able to easily fill these out and we may be getting into a situation where we create more problems than solutions. =20 In addition, we believe the interpretation of E.180 below in the examples may not be correct. (In the Japan case, f1 is not modulated by f2, it is modulated by 16Hz). =20 This needs to be reconsidered further to find an alternative which provides the necessary functionality in a less complicated way. As the solution does not seem to be obvious, some time for further dicussions is needed to come up with the reasonable approach.=20 =20 Eugene. ________________________________ From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Beacham Gordon-CGB005 Sent: Wednesday, January 05, 2005 8:23 AM To: 'ipcdn@ietf.org'; 'sumanth@cablelabs.com' Subject: [ipcdn] IETF NCS Sig MIB Tone Table ITU-T supplement 2 (E.180) identifies several tone definitions that cannot be currently satisfied by the IETF NCS Sig MIB tone table definition. It is important for the IETF NCS Sig MIB to support E.180 tone definitions for: 1. embedded tone cadences (i.e., Romania number unobtainable tone, etc) [2 examples shown below]=20 2. amplitude modulation (i.e., Japan call waiting tone) [1 example shown below] To address these issues, the following changes are recommended: PktcSigDevToneEntry ::=3D SEQUENCE {=20 pktcSigDevToneType INTEGER,=20 pktcSigDevToneDbLevel TenthdBm,=20 pktcSigDevToneFreqType INTEGER,=20 pktcSigDevToneNumFrequencies Unsigned32,=20 pktcSigDevToneFirstFrequency Unsigned32,=20 pktcSigDevToneFirstToneSecondaryFrequency Unsigned32,=20 pktcSigDevToneFirstToneSecondaryMode Unsigned32,=20 pktcSigDevToneFirstToneSecondaryAttribute Unsigned32,=20 pktcSigDevToneSecondFrequency Unsigned32,=20 pktcSigDevToneSecondToneSecondaryFrequency Unsigned32,=20 pktcSigDevToneSecondToneSecondaryMode Unsigned32,=20 pktcSigDevToneSecondToneSecondaryAttribute Unsigned32,=20 pktcSigDevToneThirdFrequency Unsigned32,=20 pktcSigDevToneThirdToneSecondaryFrequency Unsigned32,=20 pktcSigDevToneThirdToneSecondaryMode Unsigned32,=20 pktcSigDevToneThirdToneSecondaryAttribute Unsigned32,=20 pktcSigDevToneFourthFrequency Unsigned32,=20 pktcSigDevToneFourthToneSecondaryFrequency Unsigned32,=20 pktcSigDevToneFourthToneSecondaryMode Unsigned32,=20 pktcSigDevToneFourthToneSecondaryAttribute Unsigned32,=20 pktcSigDevToneFifthFrequency Unsigned32,=20 pktcSigDevToneFifthToneSecondaryFrequency Unsigned32,=20 pktcSigDevToneFifthToneSecondaryMode Unsigned32,=20 pktcSigDevToneFifthToneSecondaryAttribute Unsigned32,=20 pktcSigDevToneNumOnOffTimes Unsigned32,=20 pktcSigDevToneFirstToneOn Unsigned32,=20 pktcSigDevToneFirstToneOff Unsigned32,=20 pktcSigDevToneFirstToneRepeatCount Unsigned32,=20 pktcSigDevToneSecondToneOn Unsigned32,=20 pktcSigDevToneSecondToneOff Unsigned32,=20 pktcSigDevToneSecondToneRepeatCount Unsigned32,=20 pktcSigDevToneThirdToneOn Unsigned32,=20 pktcSigDevToneThirdToneOff Unsigned32,=20 pktcSigDevToneThirdToneRepeatCount Unsigned32,=20 pktcSigDevToneFourthToneOn Unsigned32,=20 pktcSigDevToneFourthToneOff Unsigned32,=20 pktcSigDevToneFourthToneRepeatCount Unsigned32,=20 pktcSigDevToneFifthToneOn Unsigned32,=20 pktcSigDevToneFifthToneOff Unsigned32,=20 pktcSigDevToneFifthToneRepeatCount Unsigned32,=20 pktcSigDevToneWholeToneRepeatCount Unsigned32,=20 pktcSigDevToneSteady TruthValue=20 }=20 =20 pktcSigDevToneFirstToneSecondaryFrequency SYNTAX Unsigned32 (0..4000) MAX-ACCESS read-write STATUS current DESCRIPTION "The secondary frequency used to amplitude modulate or which is summed with the pktcSigDevToneFirstFrequency depending on the setting of pktcSigDevToneFirstToneSecondaryMode." ::=3D{pktcSigDevToneEntry x} =20 A similar object definition is required for: =20 pktcSigDevToneSecondToneSecondaryFrequency pktcSigDevToneThirdToneSecondaryFrequency pktcSigDevToneFourthToneSecondaryFrequency pktcSigDevToneFifthToneSecondaryFrequency =20 pktcSigDevToneFirstToneSecondaryMode SYNTAX INTEGER {=20 noModNoSum (1), primaryModulatedBySecondary (2),=20 primarySummedWithSecondary (3)=20 }=20 MAX-ACCESS read-write STATUS current DESCRIPTION "When pktcSigDevToneFirstToneSecondaryMode is set to primaryModulatedBySecondary, the pktcSigDevToneFirstToneSecondaryFrequency is used to amplitude modulate the pktcSigDevToneFirstFrequency. When pktcSigDevToneFirstToneSecondaryMode is set to primarySummedWithSecondary, the pktcSigDevToneFirstToneSecondaryFrequency is summed with the pktcSigDevToneFirstFrequency without any modulation. When pktcSigDevToneFirstToneSecondaryMode is set to noModNoSum, the pktcSigDevToneFirstToneSecondaryFrequency MUST NOT be used." DEFVAL { 1 } ::=3D{pktcSigDevToneEntry x} =20 pktcSigDevToneFirstToneSecondaryAttribute SYNTAX Unsigned32 (0..100) MAX-ACCESS read-write STATUS current DESCRIPTION "The percentage of amplitude modulation applied to the pktcSigDevToneFirstToneSecondaryFrequency. This object is only used if pktcSigDevToneFirstToneSecondaryMode is primaryModulatedBySecondary. An attempt to set this object while the value of pktcSigDevToneFirstToneSecondaryMode is not primaryModulatedBySecondary will result in an inconsistentValue error." ::=3D{pktcSigDevToneEntry x} =20 A similar object definition is required for: =20 pktcSigDevToneSecondToneSecondaryAttribute pktcSigDevToneThirdToneSecondaryAttribute pktcSigDevToneFourthToneSecondaryAttribute pktcSigDevToneFifthToneSecondaryAttribute =20 pktcSigDevToneFirstToneRepeatCount =20 SYNTAX Unsigned32 (0..5000) MAX-ACCESS read-write STATUS current DESCRIPTION "The repeat count which indicates the number of times to repeat the pktcSigDevToneFirstToneOn and pktcSigDevToneFirstToneOff cadence cycle. Setting this object may result in a tone duration longer or shorter than the overall signal duration specified by the time out (TO) object for a particular signal. If the repeat count results in a longer tone duration than the signal duration specified by the TO, the tone duration defined by the TO object for a particular signal always represents the overall signal duration for a tone. In this case, the tone duration repeat count will not be fully exercised and the desired tone duration will be truncated per the TO setting. If the repeat count results in a shorter tone duration than the signal duration specified by the TO, the tone duration defined by the repeat count takes precedence over the TO and will end the signal event. In this case, the TO represents a time not to be exceeded for the signal. It is recommended to ensure proper telephony signaling that the TO duration setting should always be longer than the desired repeat count time duration. A value of zero means the tone sequence is to be played once but not repeated." ::=3D{pktcSigDevToneEntry x} =20 A similar object definition is required for: =20 pktcSigDevToneSecondToneRepeatCount =20 pktcSigDevToneThirdToneRepeatCount =20 pktcSigDevToneFourthToneRepeatCount =20 pktcSigDevToneFifthToneRepeatCount=20 =20 The following objects should be deleted. They are no longer applicable in lieu of the above changes. =20 pktcSigDevToneFreqType OBJECT-TYPE=20 SYNTAX INTEGER {=20 allFrequencies (1),=20 singleFrequencySequence (2),=20 dualFrequencySequence (3),=20 allFrequenciesModulated (4)=20 }=20 MAX-ACCESS read-write=20 STATUS current=20 DESCRIPTION=20 "This object describes how the frequencies are applied.=20 allFrequencies indicates all frequencies specifed by pktcSigDevToneNumFrequencies are mixed to form a single tone. The tone is then applied in sequence using the number of on/off times specified in pktcSigDevToneNumOnOffTimes. SingleFrequecySequence indicates all frequencies specified by pktcSigDevToneNumFrequencies are applied in sequence using the corresponding frequency number on/off time (e.g., pktcSigDevToneFirstFrequency uses pktcSigDevToneFirstToneOn and pktcSigDevToneFirstToneOff, pktcSigDevToneSecondFrequency uses pktcSigDevToneSecondToneOn and pktcSigDevToneSecondToneOff). For this tone type pktcSigDevToneNumFrequencies MUST equal pktcSigDevToneNumOnOffTimes. DualFrequencySequence indicates two pairs of frequencies are added to form two sequenced tones. The first and second frequency are added to form tone one and are applied using pktcSigDevToneFirstToneOn and pktcSigDevToneFirstToneOff. The third and forth frequency are added to form tone two and are applied using pktcSigDevToneSecondToneOn and pktcSigDevToneSecondToneOff. For this tone type pktcSigDevToneNumFrequencies MUST equal 4 and pktcSigDevToneNumOnOffTimes MUST equal 2. allFrequenciesModulated indicates all frequencies specified by pktcSigDevToneNumFrequencies are modulated to form a single tone. The tone is then applied in sequence using the number of on/off times specified in pktcSigDevToneNumOnOffTimes. For allFrequenciesModulated, the pktcSigDevToneNumFrequencies MUST equal 2, and the frequency in pktcSigDevToneFirstFrequency modulates the frequency in pktcSigDevToneSecondFrequency." REFERENCE=20 "ITU-T E.180"=20 DEFVAL { allFrequencies }=20 ::=3D{ pktcSigDevToneEntry 3 }=20 =20 pktcSigDevToneNumFrequencies OBJECT-TYPE=20 =20 =09 Example 1 - Modulated/Unmodulated Tone: =20 Japan call waiting tone with the following definition per ITU-T E.180: f1 mod f2, where f1=3D400 Hz AM modulated by 16 Hz, f2=3D400 Hz not AM modulated cadence: first tone: 500ms ON then 0 to 400ms OFF second tone: 50ms ON then 450ms OFF third tone: 50ms ON then 3450ms OFF fourth tone: 50ms ON then 450ms OFF fifth tone: 50ms ON then 3450 ms OFF not repeated, not continuous =20 Example 2 - Embedded Cadence: This example of an embedded cadence is based on an operator variation of a national standard. A similar example of an embedded cadence can be found in ITU-T supplement 2 (E.180) for Romania. =20 Frequency: 425Hz Cadence: - 1) ton:1000msec, toff: 40msec - 2) 9 sec repeat of (ton: 40mesc, toff: 40msec) - 3) ton: continuous =20 Example 3 - Embedded Cadence: This example of an embedded cadence is based on an operator variation of a national standard. =20 Frequency: 425Hz Cadence: - 1) ton: 160msec, toff: 40msec - 2) 7* (ton: 40msec, toff: 40msec) - 3) ton: 160msec, toff 40msec - 4) 7* (ton: 40msec, toff: 40msec) - 5) ton: 160msec, toff 40msec - 6) 7* (ton: 40msec, toff: 40msec) =20 ------_=_NextPart_001_01C4F84F.4A51793A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message=
 
Resending my previous message as it bounced = off of the=20 reflector ("Message body is too big: 86122 bytes with a = limit of 70=20 KB" which is obviously not the case for my=20 message).

From: Eugene Nechamkin =
Sent: Tuesday,=20 January 11, 2005 6:07 PM
To: 'Beacham Gordon-CGB005';=20 'sumanth@cablelabs.com'
Cc: = 'ipcdn@ietf.org'
Subject: RE:=20 [ipcdn] IETF NCS Sig MIB Tone Table

 
We believe the tone generation capabilities are = getting=20 overly complicated for the added benefit they are providing. Operators = need to=20 be able to easily fill these out and we may be getting into a situation = where we=20 create more problems than solutions.
 
In addition, we believe the interpretation of = E.180 below=20 in the examples may not be correct. (In the Japan case, f1 is not = modulated by=20 f2, it is modulated by 16Hz).
 
This needs to be reconsidered = further to find an alternative which provides the necessary = functionality in a=20 less complicated way. As the solution does not seem to be obvious, = some time=20 for further dicussions is needed to come up with = the reasonable=20 approach.
 
Eugene.

From: ipcdn-bounces@ietf.org=20 [mailto:ipcdn-bounces@ietf.org] On Behalf Of Beacham=20 Gordon-CGB005
Sent: Wednesday, January 05, 2005 8:23 = AM
To:=20 'ipcdn@ietf.org'; 'sumanth@cablelabs.com'
Subject: [ipcdn] = IETF NCS=20 Sig MIB Tone Table

ITU-T supplement 2 (E.180) identifies several tone = definitions=20 that cannot be currently satisfied by the IETF NCS Sig MIB tone table=20 definition. It is important for = the=20 IETF NCS Sig MIB to support = E.180 tone=20 definitions for:
  1. embedded tone cadences (i.e.,=20 = Romania=20 number unobtainable tone, etc) [2 examples shown = below]=20
  2. amplitude modulation (i.e.,=20 = Japan = call=20 waiting tone) [1 example shown=20 below]
To address these = issues, the=20 following changes are recommended:

PktcSigDevToneEntry ::=3D SEQUENCE = {=20

    = pktcSigDevToneType           &n= bsp;         =20 INTEGER,

    = pktcSigDevToneDbLevel           &n= bsp;      =20 TenthdBm,

   =20 pktcSigDevToneFreqType           &n= bsp;     =20 INTEGER,

   =20 pktcSigDevToneNumFrequencies           =20 Unsigned32,

   =20 pktcSigDevToneFirstFrequency           =20 Unsigned32,

   =20 pktcSigDevToneFirstToneSecondaryFrequency Unsigned32,=20

   =20 pktcSigDevToneFirstToneSecondaryMode      = Unsigned32,=20

   =20 pktcSigDevToneFirstToneSecondaryAttribute Unsigned32,=20

   =20 pktcSigDevToneSecondFrequency          =20 Unsigned32,

   =20 pktcSigDevToneSecondToneSecondaryFrequency Unsigned32,=20

   =20 pktcSigDevToneSecondToneSecondaryMode      = Unsigned32,=20

   =20 pktcSigDevToneSecondToneSecondaryAttribute Unsigned32,=20

   =20 pktcSigDevToneThirdFrequency           =20 Unsigned32,

   =20 pktcSigDevToneThirdToneSecondaryFrequency Unsigned32,=20

   =20 pktcSigDevToneThirdToneSecondaryMode      = Unsigned32,=20

   =20 pktcSigDevToneThirdToneSecondaryAttribute Unsigned32,=20

   =20 pktcSigDevToneFourthFrequency           Unsigned32,=20

   =20 pktcSigDevToneFourthToneSecondaryFrequency Unsigned32,=20

   =20 pktcSigDevToneFourthToneSecondaryMode      = Unsigned32,=20

   =20 pktcSigDevToneFourthToneSecondaryAttribute Unsigned32,=20

   =20 pktcSigDevToneFifthFrequency           =20 Unsigned32,

   =20 pktcSigDevToneFifthToneSecondaryFrequency Unsigned32,=20

   =20 pktcSigDevToneFifthToneSecondaryMode      = Unsigned32,=20

   =20 pktcSigDevToneFifthToneSecondaryAttribute Unsigned32,=20

   =20 pktcSigDevToneNumOnOffTimes           &n= bsp;=20 Unsigned32,

   =20 pktcSigDevToneFirstToneOn           &n= bsp;  =20 Unsigned32,

   =20 pktcSigDevToneFirstToneOff           &n= bsp; =20 Unsigned32,

   =20 pktcSigDevToneFirstToneRepeatCount      = Unsigned32,=20

   =20 pktcSigDevToneSecondToneOn           &n= bsp; =20 Unsigned32,

   =20 pktcSigDevToneSecondToneOff           &n= bsp;=20 Unsigned32,

   =20 pktcSigDevToneSecondToneRepeatCount     = Unsigned32,=20

   =20 pktcSigDevToneThirdToneOn           &n= bsp;  =20 Unsigned32,

   =20 pktcSigDevToneThirdToneOff           &n= bsp; =20 Unsigned32,

   =20 pktcSigDevToneThirdToneRepeatCount      = Unsigned32,=20

   =20 pktcSigDevToneFourthToneOn           &n= bsp; =20 Unsigned32,

   =20 pktcSigDevToneFourthToneOff           &n= bsp;=20 Unsigned32,

   =20 pktcSigDevToneFourthToneRepeatCount     = Unsigned32,=20

   =20 pktcSigDevToneFifthToneOn          =20     Unsigned32,=20

   =20 pktcSigDevToneFifthToneOff          =20    Unsigned32,=20

   =20 pktcSigDevToneFifthToneRepeatCount      Unsigned32,=20

   =20 pktcSigDevToneWholeToneRepeatCount      = Unsigned32,=20

    = pktcSigDevToneSteady           &n= bsp;       =20 TruthValue

    }=20

 

pktcSigDevToneFirstToneSecondaryFrequency

     = SYNTAX     Unsigned32 = (0..4000)

     MAX-ACCESS = read-write

     = STATUS    =20 current

     DESCRIPTION

     "The secondary frequency used = to=20 amplitude modulate or

      = which is=20 summed with the pktcSigDevToneFirstFrequency

      depending on the setting=20 of

      pktcSigDevToneFirstToneSecondaryMode."

     ::=3D{pktcSigDevToneEntry=20 x}

 

A similar object = definition is required for:

 

pktcSigDevToneSecondToneSecondaryFrequency

pktcSigDevToneThirdToneSecondaryFrequency

pktcSigDevToneFourthToneSecondaryFrequency

pktcSigDevToneFifthToneSecondaryFrequency

 

pktcSigDevToneFirstToneSecondaryMode

    SYNTAX       = INTEGER=20 {

           =20 noModNoSum (1),

           =20 primaryModulatedBySecondary (2),

           =20 primarySummedWithSecondary (3)

    }=20

MAX-ACCESS=20 read-write

     = STATUS    =20 current

    =20 DESCRIPTION

     "When=20 pktcSigDevToneFirstToneSecondaryMode is set to

     =20 primaryModulatedBySecondary, the

      pktcSigDevToneFirstToneSecondaryFrequency=20 is

      used = to=20 amplitude modulate the

     =20 pktcSigDevToneFirstFrequency.

      When = pktcSigDevToneFirstToneSecondaryMode is set to

     =20 primarySummedWithSecondary, the

     =20 pktcSigDevToneFirstToneSecondaryFrequency is=20 summed

      with the = pktcSigDevToneFirstFrequency=20 without any

      modulation. When=20 pktcSigDevToneFirstToneSecondaryMode

      is set to noModNoSum,=20 the

      pktcSigDevToneFirstToneSecondaryFrequency=20 MUST NOT be

      used."

      = DEFVAL { 1=20 }

    =20 ::=3D{pktcSigDevToneEntry x}

 

pktcSigDevToneFirstToneSecondaryAttribute

     = SYNTAX     Unsigned32 = (0..100)

     MAX-ACCESS = read-write

     STATUS    =20 current

    =20 DESCRIPTION

     "The = percentage of=20 amplitude modulation applied to the

     =20 pktcSigDevToneFirstToneSecondaryFrequency. = This

      object is only used=20 if

     =20 pktcSigDevToneFirstToneSecondaryMode is

     =20 primaryModulatedBySecondary. An attempt to set this object = while the=20 value of

         =20 pktcSigDevToneFirstToneSecondaryMode

is not primaryModulatedBySecondary = will result=20 in

         =20 an inconsistentValue error."

    =20 ::=3D{pktcSigDevToneEntry x}

 

A similar object = definition is required for:

 

pktcSigDevToneSecondToneSecondaryAttribute

pktcSigDevToneThirdToneSecondaryAttribute

pktcSigDevToneFourthToneSecondaryAttribute

pktcSigDevToneFifthToneSecondaryAttribute

 

pktcSigDevToneFirstToneRepeatCount    =20

     = SYNTAX     Unsigned32 = (0..5000)

     MAX-ACCESS = read-write

     = STATUS    =20 current

    =20 DESCRIPTION

     "The = repeat count=20 which indicates the number of times

      to repeat the = pktcSigDevToneFirstToneOn=20 and

     =20 pktcSigDevToneFirstToneOff cadence cycle.=20 Setting

      this = object=20 may result in a tone duration longer or

      shorter than the overall = signal=20 duration specified by

      the time out (TO) object for = a=20 particular signal. If

      the repeat count results in a = longer=20 tone duration

      than the signal duration = specified by=20 the TO, the

      tone duration defined by the = TO object=20 for a

      particular signal always = represents the=20 overall

      signal duration for a tone. = In this=20 case, the tone

      duration repeat count will = not be fully=20 exercised and

      the = desired=20 tone duration will be truncated per the

      TO setting. If the repeat = count results=20 in a shorter

      tone duration than the signal = duration=20 specified by

      the TO, the tone duration = defined by=20 the repeat count

      takes precedence over the TO = and will=20 end the signal

      event. In this case, the TO = represents=20 a time not to

      be exceeded for the signal. = It is=20 recommended to

      ensure proper telephony = signaling that=20 the TO

  =20    duration setting should = always be=20 longer than the

 =20     desired=20 repeat count time duration. A value of = zero

      = means the tone=20 sequence is to be played once but not

     =20 repeated."

    =20 ::=3D{pktcSigDevToneEntry x}

 

A similar object = definition is required for:

 

pktcSigDevToneSecondToneRepeatCount    =20

pktcSigDevToneThirdToneRepeatCount     =20

pktcSigDevToneFourthToneRepeatCount    =20

pktcSigDevToneFifthToneRepeatCount=20

 

The following objects should = be deleted. They are no longer = applicable in lieu=20 of the above changes.

 

pktcSigDevToneFreqType    OBJECT-TYPE=20

    SYNTAX      = INTEGER {=20

           &n= bsp;   =20 allFrequencies (1),

           &n= bsp;   =20 singleFrequencySequence (2),

           &n= bsp;   =20 dualFrequencySequence (3),

           &n= bsp;   =20 allFrequenciesModulated (4)

    } =

    MAX-ACCESS   read-write =

    STATUS       = current=20

    DESCRIPTION=20

        = "This object describes how the frequencies are applied. =

        =20 allFrequencies indicates all frequencies specifed = by

        =20 pktcSigDevToneNumFrequencies are mixed to form a = single

        =20 tone. The tone is then applied in sequence using = the

        =20 number of on/off times specified in

        =20 pktcSigDevToneNumOnOffTimes. = SingleFrequecySequence

        =20 indicates all frequencies specified by

        =20 pktcSigDevToneNumFrequencies are applied in = sequence

        =20 using the corresponding frequency number on/off = time

        =20 (e.g., pktcSigDevToneFirstFrequency uses

        =20 pktcSigDevToneFirstToneOn and=20 pktcSigDevToneFirstToneOff,

        =20 pktcSigDevToneSecondFrequency uses

        =20 pktcSigDevToneSecondToneOn and

        =20 pktcSigDevToneSecondToneOff). For this tone type

        =20 pktcSigDevToneNumFrequencies MUST equal

        =20 pktcSigDevToneNumOnOffTimes. = DualFrequencySequence

        =20 indicates two pairs of frequencies are added to form = two

        =20 sequenced tones. The first and second frequency are=20 added

        =20 to form tone one and are applied using

        =20 pktcSigDevToneFirstToneOn and=20 pktcSigDevToneFirstToneOff.

        =20 The third and forth frequency are added to form tone = two

        =20 and are applied using pktcSigDevToneSecondToneOn = and

        =20 pktcSigDevToneSecondToneOff. For this tone type

        =20 pktcSigDevToneNumFrequencies MUST equal 4 and

        =20 pktcSigDevToneNumOnOffTimes MUST equal 2.

        =20 allFrequenciesModulated indicates all = frequencies

        =20 specified by pktcSigDevToneNumFrequencies are modulated=20 to

        =20 form a single tone. The tone is then applied in = sequence

        =20 using the number of on/off times specified in

        =20 pktcSigDevToneNumOnOffTimes. For=20 allFrequenciesModulated,

        =20 the pktcSigDevToneNumFrequencies MUST equal 2, and = the

        =20 frequency in pktcSigDevToneFirstFrequency modulates = the

        =20 frequency in pktcSigDevToneSecondFrequency."

    REFERENCE =

        = "ITU-T E.180"

    DEFVAL { = allFrequencies }=20

    ::=3D{ = pktcSigDevToneEntry 3=20 }

 

pktcSigDevToneNumFrequencies    OBJECT-TYPE=20

 

Example 1 - Modulated/Unmodulated=20 Tone:

 

Japan call waiting tone with the following = definition=20 per ITU-T E.180:

f1 mod f2, where f1=3D400 Hz AM modulated by = 16 Hz,=20 f2=3D400 Hz not AM modulated

cadence:

first tone: 500ms ON then 0 to 400ms=20 OFF

second tone: 50ms ON then 450ms=20 OFF

third tone: 50ms ON then 3450ms=20 OFF

fourth tone: 50ms ON then 450ms=20 OFF

fifth tone: 50ms ON then 3450 ms=20 OFF

not repeated, not = continuous

 

Example 2 -=20 Embedded Cadence:

This example of = an embedded=20 cadence is based on an operator variation of a national standard. A = similar=20 example of an embedded cadence can be found in ITU-T supplement = 2=20 (E.180) for=20 = Romania.<= SPAN=20 style=3D"mso-fareast-font-family: 'Times New = Roman'">

 

Frequency:=20 425Hz

Cadence:

- = 1)=20 ton:1000msec, toff: 40msec

- = 2) 9 sec=20 repeat of (ton: 40mesc, toff: 40msec)

- = 3) ton:=20 continuous

 

Example 3 -=20 Embedded Cadence:

This example=20 of an embedded cadence is based on an operator variation of a national = standard.

 

Frequency:=20 425Hz

Cadence:

- = 1) ton:=20 160msec, toff: 40msec

- = 2) 7* (ton:=20 40msec, toff: 40msec)

- = 3) ton:=20 160msec, toff 40msec

- = 4) 7* (ton:=20 40msec, toff: 40msec)

- = 5) ton:=20 160msec, toff 40msec

- = 6) 7* (ton:=20 40msec, toff: 40msec)

 

------_=_NextPart_001_01C4F84F.4A51793A-- --===============1500396239== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============1500396239==-- From ipcdn-bounces@ietf.org Wed Jan 12 09:26:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16141 for ; Wed, 12 Jan 2005 09:26:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cojfu-0006z3-WC for ipcdn-archive@ietf.org; Wed, 12 Jan 2005 09:40:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CojJv-0008Qx-0t; Wed, 12 Jan 2005 09:17:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoYPl-0004MN-0v for ipcdn@megatron.ietf.org; Tue, 11 Jan 2005 21:39:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28825 for ; Tue, 11 Jan 2005 21:39:15 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoYdg-0008Mi-ST for ipcdn@ietf.org; Tue, 11 Jan 2005 21:53:41 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Tue, 11 Jan 2005 18:38:46 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Jan 2005 18:38:44 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Tue, 11 Jan 2005 18:38:44 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Tue, 11 Jan 2005 18:38:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Jan 2005 18:38:42 -0800 Message-ID: Thread-Topic: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt Thread-Index: AcR6thTZfq+7VKivT3+3uhPKgFAc5B9gt0cwAAHmZ4A= From: "Dave Thaler" To: "Jean-Francois Mule" , X-OriginalArrivalTime: 12 Jan 2005 02:38:43.0986 (UTC) FILETIME=[D56AAF20:01C4F84F] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 12 Jan 2005 09:17:52 -0500 Cc: randy_presuhn@mindspring.com, "Wijnen, Bert \(Bert\)" , ipcdn@ietf.org, "C. M. Heard" Subject: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: Tuesday, January 11, 2005 4:07 PM > To: Dave Thaler; enechamkin@broadcom.com > Cc: ipcdn@ietf.org; Wijnen, Bert (Bert); randy_presuhn@mindspring.com; = C. > M. Heard > Subject: RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt >=20 > Dave Thaler wrote: > > SHOULD fix > > ---------- > [snip] > > 13) pktcMtaDevServerDhcp1, pktcMtaDevServerDns1, etc: the > > DESCRIPTION of > > > > these objects is worded as if the type is a string rather than = an > > InetAddress (the "dotted" IP address, etc). Technically, > > there's no > > dots in the value, only in the displayed version of it. >=20 > Good point and yes, this may be confusing. > Here's a proposed rewording for all the affected object description > clauses (it's a bit of a convoluted rewording but that's the best I = could > come up with): > Replace: > < If this object is of value '0.0.0.0', the MTA MUST stop > < all provisioning attempts as well as all other activities. > < If this object is of value '255.255.255.255', it means > there was no preference given for the primary DHCP > server, and, the MTA must follow the logic of RFC2131, and > the value of DHCP option 122 sub-option 2 must be > ignored." >=20 > with: > > If this object is of an InetAddress value equivalent to > > '0.0.0.0', the MTA MUST stop all provisioning attempts > > as well as all other activities. > > If this object is of an InetAddress value equivalent to > > '255.255.255.255', it means > there was no preference given for the primary DHCP > server, and, the MTA must follow the logic of RFC2131, and > the value of DHCP option 122 sub-option 2 must be > ignored." >=20 > Ok? > Jean-Fran=E7ois My original comment was specifically in response to the use of the word = "dotted" in the DESCRIPTION clauses, which is no longer present in -05. For example, -04 had=20 "When the latter has the value 'ipv4(1)', this object =20 contains the dotted IP address of the primary DHCP=20 server." in the description of pktcMtaDevServerDhcp1, whereas -05 has "When the latter has the value 'ipv4(1)', this object =20 contains the IP address of the primary DHCP=20 server." Hence my original comment has been resolved in -05 and in response to = your proposed text above, I actually prefer the current wording (just "value '0.0.0.0'" rather than "value equivalent to '0.0.0.0'"). -Dave _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Jan 12 09:27:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16271 for ; Wed, 12 Jan 2005 09:27:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cojgm-000717-Fn for ipcdn-archive@ietf.org; Wed, 12 Jan 2005 09:41:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CojJv-0008RN-BR; Wed, 12 Jan 2005 09:17:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoYPt-0004Mc-OO for ipcdn@megatron.ietf.org; Tue, 11 Jan 2005 21:39:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28829 for ; Tue, 11 Jan 2005 21:39:23 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoYdn-0008Mr-KN for ipcdn@ietf.org; Tue, 11 Jan 2005 21:53:50 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Jan 2005 18:38:51 -0800 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Jan 2005 18:38:51 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Tue, 11 Jan 2005 18:38:50 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Tue, 11 Jan 2005 18:38:50 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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, 11 Jan 2005 18:38:49 -0800 Message-ID: Thread-Topic: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt Thread-Index: AcR6thTZfq+7VKivT3+3uhPKgFAc5B9gDNXgAAJle9A= From: "Dave Thaler" To: "Jean-Francois Mule" , X-OriginalArrivalTime: 12 Jan 2005 02:38:50.0785 (UTC) FILETIME=[D9782110:01C4F84F] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 12 Jan 2005 09:17:52 -0500 Cc: randy_presuhn@mindspring.com, "Wijnen, Bert \(Bert\)" , enechamkin@broadcom.com, "C. M. Heard" Subject: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Jean-Francois Mule writes: > To close on one additional comment: > Dave wrote: > > 12) pktcMtaDevErrorOid, pktcMtaDevErrorValue, etc: > > why are OIDs of type SnmpAdminString rather than an > > OBJECT IDENTIFIER > > type/subtype? As is, the management station cannot do > > simple things > > like expanding the OID into the defined string tokens in the MIB. [...] > So, the resolution is: > - no object syntax change > - change the description of the pktcMtaDevErrorOid to indicate the > following: > "Note that the syntax of this object is SnmpAdminString > rather OBJECT IDENTIFIER because the object value is > provided by an operator in the MTA configuration file > in the form of a character string." > - after more review of the pktcMtaDevErrorValue object, we do not > believe the above text should be added to its description as this > pktcMtaDevErrorValue object may contain all kinds of object values in the > case where the MTA can recognize the OID but cannot interpret the given > value. [...] This resolution looks fine to me. -Dave _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Jan 12 10:34:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22194 for ; Wed, 12 Jan 2005 10:34:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cokjr-00007T-Nr for ipcdn-archive@ietf.org; Wed, 12 Jan 2005 10:48:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CokT1-0000oS-7S; Wed, 12 Jan 2005 10:31:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CokN9-0006wL-5n for ipcdn@megatron.ietf.org; Wed, 12 Jan 2005 10:25:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21561 for ; Wed, 12 Jan 2005 10:25:21 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cokb8-0008Lt-G9 for ipcdn@ietf.org; Wed, 12 Jan 2005 10:39:53 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j0CFOj1e023852; Wed, 12 Jan 2005 08:24:45 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt Date: Wed, 12 Jan 2005 08:24:45 -0700 Message-ID: Thread-Topic: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt Thread-Index: AcR6thTZfq+7VKivT3+3uhPKgFAc5B9gt0cwAAHmZ4AAHod+mQ== From: "Jean-Francois Mule" To: "Dave Thaler" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: randy_presuhn@mindspring.com, "Wijnen, Bert \(Bert\)" , ipcdn@ietf.org, "C. M. Heard" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0083058306==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 This is a multi-part message in MIME format. --===============0083058306== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4F8BA.D87143F0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4F8BA.D87143F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T2ssIEkgbWlzc2VkIHRvIHJlY29yZCB0aGUgcmVtb3ZhbCBvZiAiZG90dGVkIiBpbiBteSBsb2cu IFdpbGwga2VlcCB0aGUgdGV4dCBvZiBkcmFmdDA1IHRoZW4uDQpUaGFua3MsDQpKZWFuLUZyYW5j b2lzLg0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJRnJvbTogRGF2ZSBUaGFsZXIg W21haWx0bzpkdGhhbGVyQHdpbmRvd3MubWljcm9zb2Z0LmNvbV0gDQoJU2VudDogVHVlIDEvMTEv MjAwNSA3OjM4IFBNIA0KCVRvOiBKZWFuLUZyYW5jb2lzIE11bGU7IGVuZWNoYW1raW5AYnJvYWRj b20uY29tIA0KCUNjOiByYW5keV9wcmVzdWhuQG1pbmRzcHJpbmcuY29tOyBXaWpuZW4sIEJlcnQg KEJlcnQpOyBpcGNkbkBpZXRmLm9yZzsgQy4gTS4gSGVhcmQgDQoJU3ViamVjdDogW2lwY2RuXSBS RTogUmV2aWV3IG9mIGRyYWZ0LWlldGYtaXBjZG4tcGt0Yy1tdGFtaWItMDQudHh0DQoJDQoJDQoN Cgk+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoJPiBGcm9tOiBKZWFuLUZyYW5jb2lzIE11 bGUgW21haWx0bzpqZi5tdWxlQGNhYmxlbGFicy5jb21dDQoJPiBTZW50OiBUdWVzZGF5LCBKYW51 YXJ5IDExLCAyMDA1IDQ6MDcgUE0NCgk+IFRvOiBEYXZlIFRoYWxlcjsgZW5lY2hhbWtpbkBicm9h ZGNvbS5jb20NCgk+IENjOiBpcGNkbkBpZXRmLm9yZzsgV2lqbmVuLCBCZXJ0IChCZXJ0KTsgcmFu ZHlfcHJlc3VobkBtaW5kc3ByaW5nLmNvbTsgQy4NCgk+IE0uIEhlYXJkDQoJPiBTdWJqZWN0OiBS RTogUmV2aWV3IG9mIGRyYWZ0LWlldGYtaXBjZG4tcGt0Yy1tdGFtaWItMDQudHh0DQoJPg0KCT4g RGF2ZSBUaGFsZXIgd3JvdGU6DQoJPiA+IFNIT1VMRCBmaXgNCgk+ID4gLS0tLS0tLS0tLQ0KCT4g W3NuaXBdDQoJPiA+IDEzKSBwa3RjTXRhRGV2U2VydmVyRGhjcDEsIHBrdGNNdGFEZXZTZXJ2ZXJE bnMxLCBldGM6IHRoZQ0KCT4gPiBERVNDUklQVElPTiBvZg0KCT4gPg0KCT4gPiAgICAgdGhlc2Ug b2JqZWN0cyBpcyB3b3JkZWQgYXMgaWYgdGhlIHR5cGUgaXMgYSBzdHJpbmcgcmF0aGVyIHRoYW4g YW4NCgk+ID4gICAgIEluZXRBZGRyZXNzICh0aGUgImRvdHRlZCIgSVAgYWRkcmVzcywgZXRjKS4g IFRlY2huaWNhbGx5LA0KCT4gPiB0aGVyZSdzIG5vDQoJPiA+ICAgICBkb3RzIGluIHRoZSB2YWx1 ZSwgb25seSBpbiB0aGUgZGlzcGxheWVkIHZlcnNpb24gb2YgaXQuDQoJPg0KCT4gR29vZCBwb2lu dCBhbmQgeWVzLCB0aGlzIG1heSBiZSBjb25mdXNpbmcuDQoJPiBIZXJlJ3MgYSBwcm9wb3NlZCBy ZXdvcmRpbmcgZm9yIGFsbCB0aGUgYWZmZWN0ZWQgb2JqZWN0IGRlc2NyaXB0aW9uDQoJPiBjbGF1 c2VzIChpdCdzIGEgYml0IG9mIGEgY29udm9sdXRlZCByZXdvcmRpbmcgYnV0IHRoYXQncyB0aGUg YmVzdCBJIGNvdWxkDQoJPiBjb21lIHVwIHdpdGgpOg0KCT4gUmVwbGFjZToNCgk+IDwgICAgICAg ICBJZiB0aGlzIG9iamVjdCBpcyBvZiB2YWx1ZSAnMC4wLjAuMCcsIHRoZSBNVEEgTVVTVCBzdG9w DQoJPiA8ICAgICAgICAgYWxsIHByb3Zpc2lvbmluZyBhdHRlbXB0cyBhcyB3ZWxsIGFzIGFsbCBv dGhlciBhY3Rpdml0aWVzLg0KCT4gPCAgICAgICAgIElmIHRoaXMgb2JqZWN0IGlzIG9mIHZhbHVl ICcyNTUuMjU1LjI1NS4yNTUnLCBpdCBtZWFucw0KCT4gICAgICAgICAgIHRoZXJlIHdhcyBubyBw cmVmZXJlbmNlIGdpdmVuIGZvciB0aGUgcHJpbWFyeSBESENQDQoJPiAgICAgICAgICAgc2VydmVy LCBhbmQsIHRoZSBNVEEgbXVzdCBmb2xsb3cgdGhlIGxvZ2ljIG9mIFJGQzIxMzEsIGFuZA0KCT4g ICAgICAgICAgIHRoZSB2YWx1ZSBvZiBESENQIG9wdGlvbiAxMjIgc3ViLW9wdGlvbiAyIG11c3Qg YmUNCgk+ICAgICAgICAgICBpZ25vcmVkLiINCgk+DQoJPiB3aXRoOg0KCT4gPiAgICAgICAgIElm IHRoaXMgb2JqZWN0IGlzIG9mIGFuIEluZXRBZGRyZXNzIHZhbHVlIGVxdWl2YWxlbnQgdG8NCgk+ ID4gICAgICAgICAnMC4wLjAuMCcsIHRoZSBNVEEgTVVTVCBzdG9wIGFsbCBwcm92aXNpb25pbmcg YXR0ZW1wdHMNCgk+ID4gICAgICAgICBhcyB3ZWxsIGFzIGFsbCBvdGhlciBhY3Rpdml0aWVzLg0K CT4gPiAgICAgICAgIElmIHRoaXMgb2JqZWN0IGlzIG9mIGFuIEluZXRBZGRyZXNzIHZhbHVlIGVx dWl2YWxlbnQgdG8NCgk+ID4gICAgICAgICAnMjU1LjI1NS4yNTUuMjU1JywgaXQgbWVhbnMNCgk+ ICAgICAgICAgICB0aGVyZSB3YXMgbm8gcHJlZmVyZW5jZSBnaXZlbiBmb3IgdGhlIHByaW1hcnkg REhDUA0KCT4gICAgICAgICAgIHNlcnZlciwgYW5kLCB0aGUgTVRBIG11c3QgZm9sbG93IHRoZSBs b2dpYyBvZiBSRkMyMTMxLCBhbmQNCgk+ICAgICAgICAgICB0aGUgdmFsdWUgb2YgREhDUCBvcHRp b24gMTIyIHN1Yi1vcHRpb24gMiBtdXN0IGJlDQoJPiAgICAgICAgICAgaWdub3JlZC4iDQoJPg0K CT4gT2s/DQoJPiBKZWFuLUZyYW7Dp29pcw0KCQ0KCU15IG9yaWdpbmFsIGNvbW1lbnQgd2FzIHNw ZWNpZmljYWxseSBpbiByZXNwb25zZSB0byB0aGUgdXNlIG9mIHRoZSB3b3JkICJkb3R0ZWQiIGlu IHRoZSBERVNDUklQVElPTiBjbGF1c2VzLCB3aGljaCBpcyBubyBsb25nZXIgcHJlc2VudCBpbiAt MDUuDQoJRm9yIGV4YW1wbGUsIC0wNCBoYWQNCgkgICAgICAgICJXaGVuIHRoZSBsYXR0ZXIgaGFz IHRoZSB2YWx1ZSAnaXB2NCgxKScsIHRoaXMgb2JqZWN0IA0KCSAgICAgICAgY29udGFpbnMgdGhl IGRvdHRlZCBJUCBhZGRyZXNzIG9mIHRoZSBwcmltYXJ5IERIQ1ANCgkgICAgICAgIHNlcnZlci4i DQoJaW4gdGhlIGRlc2NyaXB0aW9uIG9mIHBrdGNNdGFEZXZTZXJ2ZXJEaGNwMSwgd2hlcmVhcyAt MDUgaGFzDQoJICAgICAgICAiV2hlbiB0aGUgbGF0dGVyIGhhcyB0aGUgdmFsdWUgJ2lwdjQoMSkn LCB0aGlzIG9iamVjdCANCgkgICAgICBjb250YWlucyB0aGUgSVAgYWRkcmVzcyBvZiB0aGUgcHJp bWFyeSBESENQDQoJICAgICAgc2VydmVyLiINCgkNCglIZW5jZSBteSBvcmlnaW5hbCBjb21tZW50 IGhhcyBiZWVuIHJlc29sdmVkIGluIC0wNSBhbmQgaW4gcmVzcG9uc2UgdG8geW91cg0KCXByb3Bv c2VkIHRleHQgYWJvdmUsIEkgYWN0dWFsbHkgcHJlZmVyIHRoZSBjdXJyZW50IHdvcmRpbmcgKGp1 c3QNCgkidmFsdWUgJzAuMC4wLjAnIiByYXRoZXIgdGhhbiAidmFsdWUgZXF1aXZhbGVudCB0byAn MC4wLjAuMCciKS4NCgkNCgktRGF2ZQ0KCQ0KCV9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQoJSVBDRE4gbWFpbGluZyBsaXN0DQoJSVBDRE5AaWV0Zi5vcmcN CglodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcGNkbg0KCQ0KCQ0KDQo= ------_=_NextPart_001_01C4F8BA.D87143F0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPgo8IURPQ1RZUEUgSFRNTCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgMy4yLy9F TiI+CjxIVE1MPgo8SEVBRD4KCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMgRXhj aGFuZ2UgU2VydmVyIHZlcnNpb24gNi4wLjYyNDkuMSI+CjxUSVRMRT5baXBjZG5dIFJFOiBSZXZp ZXcgb2YgZHJhZnQtaWV0Zi1pcGNkbi1wa3RjLW10YW1pYi0wNC50eHQ8L1RJVExFPgo8L0hFQUQ+ CjxCT0RZIGRpcj1sdHI+CjxESVY+T2ssIEkgbWlzc2VkIHRvIHJlY29yZCB0aGUgcmVtb3ZhbCBv ZiAiZG90dGVkIiBpbiBteSBsb2cuIFdpbGwga2VlcCB0aGUgCnRleHQgb2YgZHJhZnQwNSB0aGVu LjwvRElWPgo8RElWPlRoYW5rcyw8L0RJVj4KPERJVj5KZWFuLUZyYW5jb2lzLjwvRElWPgo8QkxP Q0tRVU9URSBkaXI9bHRyIHN0eWxlPSJNQVJHSU4tUklHSFQ6IDBweCI+CiAgPERJVj48Rk9OVCBz aXplPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gPEJSPjxCPkZyb206PC9CPiBEYXZlIFRo YWxlciAKICBbbWFpbHRvOmR0aGFsZXJAd2luZG93cy5taWNyb3NvZnQuY29tXSA8QlI+PEI+U2Vu dDo8L0I+IFR1ZSAxLzExLzIwMDUgNzozOCBQTSAKICA8QlI+PEI+VG86PC9CPiBKZWFuLUZyYW5j b2lzIE11bGU7IGVuZWNoYW1raW5AYnJvYWRjb20uY29tIDxCUj48Qj5DYzo8L0I+IAogIHJhbmR5 X3ByZXN1aG5AbWluZHNwcmluZy5jb207IFdpam5lbiwgQmVydCAoQmVydCk7IGlwY2RuQGlldGYu b3JnOyBDLiBNLiBIZWFyZCAKICA8QlI+PEI+U3ViamVjdDo8L0I+IFtpcGNkbl0gUkU6IFJldmll dyBvZiAKICBkcmFmdC1pZXRmLWlwY2RuLXBrdGMtbXRhbWliLTA0LnR4dDxCUj48QlI+PC9GT05U PjwvRElWPgogIDxQPjxGT05UIHNpemU9Mj4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PEJSPiZndDsgRnJvbTogSmVhbi1GcmFuY29pcyAKICBNdWxlIFs8QSAKICBocmVmPSJtYWlsdG86 amYubXVsZUBjYWJsZWxhYnMuY29tIj5tYWlsdG86amYubXVsZUBjYWJsZWxhYnMuY29tPC9BPl08 QlI+Jmd0OyAKICBTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDExLCAyMDA1IDQ6MDcgUE08QlI+Jmd0 OyBUbzogRGF2ZSBUaGFsZXI7IAogIGVuZWNoYW1raW5AYnJvYWRjb20uY29tPEJSPiZndDsgQ2M6 IGlwY2RuQGlldGYub3JnOyBXaWpuZW4sIEJlcnQgKEJlcnQpOyAKICByYW5keV9wcmVzdWhuQG1p bmRzcHJpbmcuY29tOyBDLjxCUj4mZ3Q7IE0uIEhlYXJkPEJSPiZndDsgU3ViamVjdDogUkU6IFJl dmlldyAKICBvZiBkcmFmdC1pZXRmLWlwY2RuLXBrdGMtbXRhbWliLTA0LnR4dDxCUj4mZ3Q7PEJS PiZndDsgRGF2ZSBUaGFsZXIgCiAgd3JvdGU6PEJSPiZndDsgJmd0OyBTSE9VTEQgZml4PEJSPiZn dDsgJmd0OyAtLS0tLS0tLS0tPEJSPiZndDsgW3NuaXBdPEJSPiZndDsgCiAgJmd0OyAxMykgcGt0 Y010YURldlNlcnZlckRoY3AxLCBwa3RjTXRhRGV2U2VydmVyRG5zMSwgZXRjOiB0aGU8QlI+Jmd0 OyAmZ3Q7IAogIERFU0NSSVBUSU9OIG9mPEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgdGhlc2Ugb2JqZWN0cyAKICBpcyB3b3JkZWQgYXMgaWYgdGhlIHR5 cGUgaXMgYSBzdHJpbmcgcmF0aGVyIHRoYW4gYW48QlI+Jmd0OyAKICAmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEluZXRBZGRyZXNzICh0aGUgImRvdHRlZCIgSVAgYWRkcmVzcywgZXRjKS4m bmJzcDsgCiAgVGVjaG5pY2FsbHksPEJSPiZndDsgJmd0OyB0aGVyZSdzIG5vPEJSPiZndDsgJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkb3RzIAogIGluIHRoZSB2YWx1ZSwgb25seSBpbiB0 aGUgZGlzcGxheWVkIHZlcnNpb24gb2YgaXQuPEJSPiZndDs8QlI+Jmd0OyBHb29kIHBvaW50IAog IGFuZCB5ZXMsIHRoaXMgbWF5IGJlIGNvbmZ1c2luZy48QlI+Jmd0OyBIZXJlJ3MgYSBwcm9wb3Nl ZCByZXdvcmRpbmcgZm9yIGFsbCAKICB0aGUgYWZmZWN0ZWQgb2JqZWN0IGRlc2NyaXB0aW9uPEJS PiZndDsgY2xhdXNlcyAoaXQncyBhIGJpdCBvZiBhIGNvbnZvbHV0ZWQgCiAgcmV3b3JkaW5nIGJ1 dCB0aGF0J3MgdGhlIGJlc3QgSSBjb3VsZDxCUj4mZ3Q7IGNvbWUgdXAgd2l0aCk6PEJSPiZndDsg CiAgUmVwbGFjZTo8QlI+Jmd0OyAmbHQ7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IElmIHRoaXMgCiAgb2JqZWN0IGlzIG9mIHZhbHVlICcwLjAuMC4wJywg dGhlIE1UQSBNVVNUIHN0b3A8QlI+Jmd0OyAKICAmbHQ7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFsbCBwcm92aXNpb25pbmcgYXR0ZW1wdHMgCiAgYXMg d2VsbCBhcyBhbGwgb3RoZXIgYWN0aXZpdGllcy48QlI+Jmd0OyAKICAmbHQ7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElmIHRoaXMgb2JqZWN0IGlzIG9m IAogIHZhbHVlICcyNTUuMjU1LjI1NS4yNTUnLCBpdCAKICBtZWFuczxCUj4mZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIHRo ZXJlIHdhcyBubyBwcmVmZXJlbmNlIGdpdmVuIGZvciB0aGUgcHJpbWFyeSAKICBESENQPEJSPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgCiAgc2VydmVyLCBhbmQsIHRoZSBNVEEgbXVzdCBmb2xsb3cgdGhlIGxvZ2ljIG9mIFJG QzIxMzEsIAogIGFuZDxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSAKICB2YWx1ZSBvZiBESENQIG9wdGlvbiAxMjIg c3ViLW9wdGlvbiAyIG11c3QgCiAgYmU8QlI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKICBpZ25vcmVkLiI8QlI+Jmd0OzxC Uj4mZ3Q7IHdpdGg6PEJSPiZndDsgCiAgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBJZiB0aGlzIG9iamVjdCBpcyBvZiBhbiAKICBJbmV0QWRkcmVz cyB2YWx1ZSBlcXVpdmFsZW50IHRvPEJSPiZndDsgCiAgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAnMC4wLjAuMCcsIHRoZSBNVEEgTVVTVCAKICBz dG9wIGFsbCBwcm92aXNpb25pbmcgYXR0ZW1wdHM8QlI+Jmd0OyAKICAmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFzIHdlbGwgYXMgYWxsIG90aGVy IAogIGFjdGl2aXRpZXMuPEJSPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBJZiAKICB0aGlzIG9iamVjdCBpcyBvZiBhbiBJbmV0QWRkcmVz cyB2YWx1ZSBlcXVpdmFsZW50IHRvPEJSPiZndDsgCiAgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAnMjU1LjI1NS4yNTUuMjU1JywgaXQgCiAgbWVh bnM8QlI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAKICB0aGVyZSB3YXMgbm8gcHJlZmVyZW5jZSBnaXZlbiBmb3IgdGhlIHBy aW1hcnkgCiAgREhDUDxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIHNlcnZlciwgYW5kLCB0aGUgTVRBIG11c3QgZm9s bG93IHRoZSBsb2dpYyBvZiBSRkMyMTMxLCAKICBhbmQ8QlI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgCiAgdmFsdWUg b2YgREhDUCBvcHRpb24gMTIyIHN1Yi1vcHRpb24gMiBtdXN0IAogIGJlPEJSPiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAg aWdub3JlZC4iPEJSPiZndDs8QlI+Jmd0OyBPaz88QlI+Jmd0OyBKZWFuLUZyYW7Dp29pczxCUj48 QlI+TXkgb3JpZ2luYWwgY29tbWVudCAKICB3YXMgc3BlY2lmaWNhbGx5IGluIHJlc3BvbnNlIHRv IHRoZSB1c2Ugb2YgdGhlIHdvcmQgImRvdHRlZCIgaW4gdGhlIAogIERFU0NSSVBUSU9OIGNsYXVz ZXMsIHdoaWNoIGlzIG5vIGxvbmdlciBwcmVzZW50IGluIC0wNS48QlI+Rm9yIGV4YW1wbGUsIC0w NCAKICBoYWQ8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICJX aGVuIHRoZSBsYXR0ZXIgaGFzIHRoZSAKICB2YWx1ZSAnaXB2NCgxKScsIHRoaXMgCiAgb2JqZWN0 Jm5ic3A7PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb250 YWlucyB0aGUgZG90dGVkIAogIElQIGFkZHJlc3Mgb2YgdGhlIHByaW1hcnkgREhDUDxCUj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgc2VydmVyLiI8QlI+aW4g dGhlIGRlc2NyaXB0aW9uIG9mIHBrdGNNdGFEZXZTZXJ2ZXJEaGNwMSwgd2hlcmVhcyAtMDUgCiAg aGFzPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAiV2hlbiB0 aGUgbGF0dGVyIGhhcyB0aGUgCiAgdmFsdWUgJ2lwdjQoMSknLCB0aGlzIG9iamVjdCZuYnNwOzxC Uj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29udGFpbnMgCiAgdGhlIElQIGFkZHJl c3Mgb2YgdGhlIHByaW1hcnkgREhDUDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg CiAgc2VydmVyLiI8QlI+PEJSPkhlbmNlIG15IG9yaWdpbmFsIGNvbW1lbnQgaGFzIGJlZW4gcmVz b2x2ZWQgaW4gLTA1IGFuZCBpbiAKICByZXNwb25zZSB0byB5b3VyPEJSPnByb3Bvc2VkIHRleHQg YWJvdmUsIEkgYWN0dWFsbHkgcHJlZmVyIHRoZSBjdXJyZW50IHdvcmRpbmcgCiAgKGp1c3Q8QlI+ InZhbHVlICcwLjAuMC4wJyIgcmF0aGVyIHRoYW4gInZhbHVlIGVxdWl2YWxlbnQgdG8gCiAgJzAu MC4wLjAnIikuPEJSPjxCUj4tRGF2ZTxCUj48QlI+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188QlI+SVBDRE4gCiAgbWFpbGluZyBsaXN0PEJSPklQQ0ROQGll dGYub3JnPEJSPjxBIAogIGhyZWY9Imh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lwY2RuIj5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcGNkbjwv QT48QlI+PEJSPjwvRk9OVD48L1A+PC9CTE9DS1FVT1RFPgoKPC9CT0RZPgo8L0hUTUw+ ------_=_NextPart_001_01C4F8BA.D87143F0-- --===============0083058306== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============0083058306==-- From ipcdn-bounces@ietf.org Wed Jan 12 17:04:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21956 for ; Wed, 12 Jan 2005 17:04:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoqpM-0001XD-9d for ipcdn-archive@ietf.org; Wed, 12 Jan 2005 17:18:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoqXV-00041b-Nl; Wed, 12 Jan 2005 17:00:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoqUJ-0002Ak-G2 for ipcdn@megatron.ietf.org; Wed, 12 Jan 2005 16:57:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21507 for ; Wed, 12 Jan 2005 16:57:09 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoqiN-0001Nd-MO for ipcdn@ietf.org; Wed, 12 Jan 2005 17:11:46 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j0CLwqJD026351 for ; Wed, 12 Jan 2005 14:58:53 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id j0CLuxNx016063 for ; Wed, 12 Jan 2005 15:57:00 -0600 Received: by ca25exm01 with Internet Mail Service (5.5.2657.72) id ; Wed, 12 Jan 2005 13:56:59 -0800 Message-ID: From: Marez Kevin-MGI1375 To: "'ipcdn@ietf.org'" Date: Wed, 12 Jan 2005 13:56:55 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [ipcdn] RFC2669bis comments to be incorporated X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 To all: I am currently working on the draft-07 version of the Cable Device MIB (rfc2669bis). With the help of Jean-Francois, Greg Nakanishi and Rich Woundy I have compiled a listing of the current outstanding comments on this revision. The following threads from the IPCDN Archives list are the current outstanding issues that I am aware of: <> <> (resolved by <>) <> <> (resolved by <>) Please review this listing and if you are aware of any other outstanding issues that have been overlooked, please forward them and I will work on getting them incorporated. Thanks very much for your help, Kevin Marez Motorola _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Jan 12 18:57:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00895 for ; Wed, 12 Jan 2005 18:57:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CosbD-0003o6-1I for ipcdn-archive@ietf.org; Wed, 12 Jan 2005 19:12:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CosCd-0001ID-OZ; Wed, 12 Jan 2005 18:47:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cos0y-0007Zs-S8 for ipcdn@megatron.ietf.org; Wed, 12 Jan 2005 18:35:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29209 for ; Wed, 12 Jan 2005 18:34:58 -0500 (EST) Received: from mms-nat.broadcom.com ([63.70.210.58] helo=mms1.broadcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CosF2-0003Jd-KL for ipcdn@ietf.org; Wed, 12 Jan 2005 18:49:36 -0500 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Wed, 12 Jan 2005 15:34:03 -0800 X-Server-Uuid: 97B92932-364A-4474-92D6-5CFE9C59AD14 Received: from nt-irva-0740.brcm.ad.broadcom.com ( nt-irva-0740.brcm.ad.broadcom.com [10.8.194.53]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id PAA21492; Wed, 12 Jan 2005 15:34:03 -0800 (PST) Received: from nt-rmna-0740.brcm.ad.broadcom.com ([10.136.192.33]) by nt-irva-0740.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Jan 2005 15:34:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of questions Date: Wed, 12 Jan 2005 15:34:01 -0800 Message-ID: <24CDBA67F085904999751B3C4F9E8C0B01E76CB4@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of questions Thread-Index: AcQHvN926xVuYmLvRFuX5nS5/On1/wD5ERZwAAG0zlABimPhABuwhhFwAALJl5AABA/rAAAHRsZsHdoI4fAAK0/i0AAHZKzQ From: "Eugene Nechamkin" To: "Dave Thaler" , "Jean-Francois Mule" , ipcdn@ietf.org X-OriginalArrivalTime: 12 Jan 2005 23:34:02.0861 (UTC) FILETIME=[32F6F1D0:01C4F8FF] X-WSS-ID: 6DFB6C611WW35433-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Content-Transfer-Encoding: quoted-printable Cc: Leandro Rzezak , PacketCable Provisioning and OSS Majordomo List X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Content-Transfer-Encoding: quoted-printable As the "must" is not a normative requirement in this particular case, = the string mentioned in the decsription clause does not seem to be too = restrictive and should not pose problems in localized environments. Eugene.=20 -----Original Message----- From: Dave Thaler [mailto:dthaler@windows.microsoft.com]=20 Sent: Wednesday, January 12, 2005 12:03 PM To: Jean-Francois Mule; ipcdn@ietf.org Cc: Eugene Nechamkin; Sumanth Channabasappa; PacketCable Provisioning = and OSS Majordomo List; Leandro Rzezak Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of = questions The problem I have with=20 > must all be equal to > 'TOO MANY ERRORS IN THE CONFIGURATION FILE' is that nothing else in the DESCRIPTION clauses indicates that the text = must be in English, and this introduces a MUST which is not localizable = to other languages. -Dave > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: Tuesday, January 11, 2005 3:35 PM > To: ipcdn@ietf.org > Cc: enechamkin@broadcom.com; Dave Thaler; Sumanth Channabasappa;=20 > PacketCable Provisioning and OSS Majordomo List; Leandro Rzezak > Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of=20 > questions >=20 > All, >=20 > Eugene and I are updating the IETF IPCDN MTA MIB draft 06. >=20 > We'd like to close one of the open items that did not get address in = > the > draft05 released in October: pktcMtaDevErrorOidsTable and what MTA=20 > behavior should be when the number of errors exceeds the table size=20 > limit of 1024. >=20 > Based on the input received, we'd like to propose the following: > 1. keep 1024 as a reasonable number of errors in a single config file = =20 > 2. if more than 1024 I had ping the list, >/dev/null": the MTA should=20 > forget about any subsequent errors i.e. any error after 1024 does not=20 > get stored in the table, and the last entry (1024th)'s is populated=20 > with a reason indicating that there are more errors per the=20 > suggestions received by Leandro and Sumanth on the list. >=20 > Proposed text changes: > pktcMtaDevErrorOidIndex OBJECT-TYPE > SYNTAX Unsigned32 (1..1024) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > " This object is the index of the MTA configuration error > table. It is an integer value which starts at value '1' > and is incremented for each encountered configuration > file error or warning. > If the number of configuration errors exceeds 1024, all > errors beyond the 1024th one must be ignored - these > subsequent errors are not reflected in the > pktcMtaDevErrorOidsTable. In this case, the value of the > pktcMtaDevErrorOid, pktcMtaDevErrorValue, and > pktcMtaDevErrorReason objects for the 1024-th table entry > must all be equal to > 'TOO MANY ERRORS IN THE CONFIGURATION FILE'." > ::=3D {pktcMtaDevErrorOidsEntry 1} >=20 >=20 > Let us know if this change is acceptable or else, feel free to propose = > text improvements or suggestions. > Thanks, > Jean-Fran=E7ois >=20 > > -----Original Message----- > > From: Sumanth Channabasappa [mailto:SChanna@alopa.com] > > Sent: Thursday, August 12, 2004 6:32 PM > > To: Leandro Rzezak; Jean-Francois Mule; ipcdn@ietf.org; PacketCable=20 > > Provisioning and OSS Majordomo List > > Cc: enechamkin@broadcom.com; Dave Thaler > > Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number=20 > > of questions > > > > > > Hi, > > > > I am unaware of any specific reason for the range when it was=20 > > proposed. (I guess it was assumed that 1024 errors would exceed any=20 > > errors in a single configuration file!). > > > > I would agree on the /dev/null (but indicating in the 1024th entry=20 > > there were more errors!). > > > > Sumanth > > > > . > > > > -----Original Message----- > > From: ipcdn-bounces@ietf.org on behalf of Leandro Rzezak > > Sent: Thu 8/12/2004 3:00 PM > > To: 'Jean-Francois Mule'; ipcdn@ietf.org; 'PacketCable Provisioning=20 > > and OSS Majordomo List' > > Cc: enechamkin@broadcom.com; 'Dave Thaler' > > Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number=20 > > of questions > > > > > > About the 2nd issue, perhaps going with the ">/dev/null" mode but=20 > > overwriting the 1024th error with a warning... > > > > Regards, > > > > Leandro Rzezak > > Intraway Corp. > > http://www.intraway.com > > > > -----Original Message----- > > From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On=20 > > Behalf Of Jean-Francois Mule > > Sent: Thursday, August 12, 2004 5:11 PM > > To: ipcdn@ietf.org; PacketCable Provisioning and OSS Majordomo List > > Cc: enechamkin@broadcom.com; Dave Thaler > > Subject: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of=20 > > questions > > > > Folks, > > > > We received one comment from Dave Thaler during the IETF mib=20 > > doctor review on the MTA MIB ErrorOID table for which I would like=20 > > to request some input from the lists (comment #11 from Dave). > > > > 1. Max range of the index object: > > pktcMtaDevErrorOidIndex OBJECT-TYPE > > SYNTAX Unsigned32 (1..1024) > > ^^^^ > > Is there any reason why we are limiting the size of this object?=20 > > From an implementation point of view on the snmp mib agent, is this=20 > > limitation buying much? > > > > > > 2. What happens if more than 1024 errors are encountered? > > Hopefully this does not happen often since the operators manage the=20 > > config files and it is extremely rare to have config files with over = > > 1024 entries or with a smaller number of entries causing 1024=20 > > errors. That said, if we keep the range as-is, per Dave's=20 > > recommendation, we should define properly what happens after the=20 > > value 1024 is reached so that all MTA vendors do it consistently and = > > so that SNMP mgers can act accordingly in those cases. > > > > Assuming we keep the range as is (1..1024), there are a couple of=20 > > options for MTAs to populate the table when a 1025th error is=20 > > encountered: > > - ">/dev/null": forget about it, any error after 1024 does not get = > > stored, only the first 1024 errors are present in the table, > > - "wrap": overwrite entries starting with entry 1, so 1025 > > -> 1, 1026 -> 2, etc. > > - "tail": just overwrite the last entry (1..1023 remain stable,=20 > > 1024 is updated with the latest error: 1025 -> 1024, > > 1026 -> 1024, etc.) > > > > The "wrap" mode is not a good option in my opinion for 2 reasons: > > - by analogy with compilation errors we sometimes encounter=20 > > with > > C++/C/SMI, an error early on in the file being parsed can > > cause numerous > > subsequent errors which are not very relevant; > > - in this particular case of config files with TLV tuples, if=20 > > something goes wrong on the MTA misinterpreting the length of a TLV=20 > > for e.g., all subsequent TLV parsing will be affected. =3D> "wrap"=20 > > won't help troubleshoot the primary errors. > > > > My preference would be ">/dev/null". It is simpler for MTAs and if=20 > > there are 1024 errors, who cares about the remaining ones (based on=20 > > the above). The "tail" mode is misleading in my opinion and is not=20 > > very relevant as intermediate entries > > (1025..max_errors-1) will be missed. > > > > Are there any other/better options if we keep the range? Any=20 > > comments on the above? > > > > Jean-Fran=E7ois _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Jan 12 19:39:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04512 for ; Wed, 12 Jan 2005 19:39:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CotF7-0004oq-VD for ipcdn-archive@ietf.org; Wed, 12 Jan 2005 19:53:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CosqB-0002PT-Ep; Wed, 12 Jan 2005 19:27:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoshI-0000OL-Jl for ipcdn@megatron.ietf.org; Wed, 12 Jan 2005 19:18:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02867 for ; Wed, 12 Jan 2005 19:18:41 -0500 (EST) Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CosvP-0004M7-QK for ipcdn@ietf.org; Wed, 12 Jan 2005 19:33:20 -0500 Message-ID: From: "Woundy, Richard" To: ipcdn@ietf.org Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2 Date: Wed, 12 Jan 2005 19:17:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.1 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: "'Jean-Francois Mule'" , "Woundy, Richard" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0098765761==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0098765761== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4F905.529F3594" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4F905.529F3594 Content-Type: text/plain IPCDN folks, After review of the WG input and comments on the email thread started on 1/5/2005 on the IPCDN mailing list, the WG chairs have come to the decision to request a change of the OID MIB root for the IPCDN QoS MIB Internet-Draft from ..mib-2(1) transmission(10) docsIfMib(127) to ..mib-2(1). If you have any further comments on this matter, or wish to object to the decision, please feel free to contact one or both of the WG chairs, or feel free to escalate to our WG AD Bert Wijnen. The proposed alternative was to keep the QoS MIB module under docsIfMIB, and per the explicit request of the AD, to write an RFC3737-like document to define IANA guidelines for registering MIB modules under the docsIfMIB branch. The WG chairs have reviewed all the comments expressed publicly to the list. We would like to add the following notes: - Some of the technical comments made in favor of maintaining the OID root do not take into account the fact that the IETF IPCDN Internet-Drafts have evolved and that the MIB modules have changed drastically in the many revisions, from object syntax changes to table entry OID renumbering, to object deletions (not obsolescence), etc. - The backward compatibility issues raised between the final IETF IDs to be RFC'ed and the original IPCDN submissions are not caused strictly by the IETF. The IETF supports backward compatibility between published versions of RFCs (e.g. between RFC2669 and the to-be-published version of Cable Modem Device MIBv2, RFC2669bis; between RFC2670 and the to-be-published version of RF MIBv2, RFC2670bis), per the IETF documented guidelines of the procedures to follow when updating IETF RFC MIB modules. The IETF does NOT support backward compatibility between Internet-Draft versions of MIBs, or between an Internet-Draft version and an RFC version, because an Internet-Draft is not a stable reference. Note the following relevant statement that is required to be included in every Internet-Draft submitted to the IETF: >Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." With respect to the rest of the IPCDN Internet-Drafts (i.e. other than the updates to RFC2669 and RFC2670), the backward compatibility problem lies in the fact that some Internet-Drafts have been implemented in products and the associated MIB module implementations rooted under an IANA-controlled MIB tree, wrongfully assigned outside the IANA jurisdiction. The consequences of this backward compatibility problem must be addressed by specific CableLabs product requirements in a CableLabs specification forum -- not in the IETF. - The change of a MIB module OID root (and MIB module identity names) was previously done for the IPCDN BPI+ MIB in February 2003. This is documented in the IPCDN meeting notes, see >. The MIB module OID root for the Subscriber Management MIB was changed in November 2002; see > and >. - Maintaining the QoS MIB and other MIB modules under docsIfMib may cause some serious interoperability problems due to the illegal (i.e. non-IETF sanctioned) OID assignments and implementations mentioned above. - Writing an RFC3737-like document would delay the publication of the QoS MIB which we do not feel justified based on the WG input and comments. --- Rich Woundy and Jean-Francois Mule IPCDN co-chairs ------_=_NextPart_001_01C4F905.529F3594 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules = O ID assignmen ts: Assigning new RFCs under mib-2

IPCDN folks,

After review of the WG input and = comments on the email thread started on 1/5/2005 on the IPCDN mailing = list, the WG chairs have come to the decision to request a change of = the OID MIB root for the IPCDN QoS MIB Internet-Draft from ..mib-2(1) = transmission(10) docsIfMib(127) to ..mib-2(1). If you have any further = comments on this matter, or wish to object to the decision, please feel = free to contact one or both of the WG chairs, or feel free to escalate = to our WG AD Bert Wijnen.

The proposed alternative was to keep = the QoS MIB module under docsIfMIB, and per the explicit request of the = AD, to write an RFC3737-like document to define IANA guidelines for = registering MIB modules under the docsIfMIB branch.

The WG chairs have reviewed all the = comments expressed publicly to the list. We would like to add the = following notes:

- Some of the technical comments made = in favor of maintaining the OID root do not take into account the fact = that the IETF IPCDN Internet-Drafts have evolved and that the MIB = modules have changed drastically in the many revisions, from object = syntax changes to table entry OID renumbering, to object deletions (not = obsolescence), etc.

- The backward compatibility issues = raised between the final IETF IDs to be RFC'ed and the original IPCDN = submissions are not caused strictly by the IETF. The IETF supports = backward compatibility between published versions of RFCs (e.g. between = RFC2669 and the to-be-published version of Cable Modem Device MIBv2, = RFC2669bis; between RFC2670 and the to-be-published version of RF = MIBv2, RFC2670bis), per the IETF documented guidelines of the = procedures to follow when updating IETF RFC MIB modules.

The IETF does NOT support backward = compatibility between Internet-Draft versions of MIBs, or between an = Internet-Draft version and an RFC version, because an Internet-Draft is = not a stable reference. Note the following relevant statement that is = required to be included in every Internet-Draft submitted to the = IETF:

>Internet-Drafts are draft = documents valid for a maximum of six months and may be updated, = replaced, or obsoleted by other documents at any time. It is = inappropriate to use Internet-Drafts as reference material or to cite = them other than as "work in progress."

With respect to the rest of the IPCDN = Internet-Drafts (i.e. other than the updates to RFC2669 and RFC2670), = the backward compatibility problem lies in the fact that some = Internet-Drafts have been implemented in products and the associated = MIB module implementations rooted under an IANA-controlled MIB tree, = wrongfully assigned outside the IANA jurisdiction.

The consequences of this backward = compatibility problem must be addressed by specific CableLabs product = requirements in a CableLabs specification forum -- not in the = IETF.

- The change of a MIB module OID root = (and MIB module identity names) was previously done for the IPCDN BPI+ = MIB in February 2003. This is documented in the IPCDN meeting notes, = see <http://www.ietf.org/proceedings/03mar/slides/ipcdn-1/inde= x.html>. The MIB module = OID root for the Subscriber Management MIB was changed in November = 2002; see <http://www1.ietf.org/mail-archive/web/ipcdn/current/msg00= 333.html> and = <http://www1.ietf.org/mail-archive/web/ipcdn/current/msg00= 367.html>.

- Maintaining the QoS MIB and other = MIB modules under docsIfMib may cause some serious interoperability = problems due to the illegal (i.e. non-IETF sanctioned) OID assignments = and implementations mentioned above.

- Writing an RFC3737-like document = would delay the publication of the QoS MIB which we do not feel = justified based on the WG input and comments.

--- Rich Woundy and Jean-Francois = Mule
    IPCDN = co-chairs

------_=_NextPart_001_01C4F905.529F3594-- --===============0098765761== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============0098765761==-- From ipcdn-bounces@ietf.org Wed Jan 12 21:48:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12099 for ; Wed, 12 Jan 2005 21:48:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CovGs-0007Ew-7F for ipcdn-archive@ietf.org; Wed, 12 Jan 2005 22:03:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cov1t-0003tT-KY; Wed, 12 Jan 2005 21:48:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Couxi-0003FW-2B for ipcdn@megatron.ietf.org; Wed, 12 Jan 2005 21:43:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11861 for ; Wed, 12 Jan 2005 21:43:47 -0500 (EST) Received: from pop-a065c32.pas.sa.earthlink.net ([207.217.121.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CovBq-00078e-5y for ipcdn@ietf.org; Wed, 12 Jan 2005 21:58:26 -0500 Received: from h-66-167-207-234.snvacaid.dynamic.covad.net ([66.167.207.234] helo=oemcomputer) by pop-a065c32.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1Couxf-00037Q-00 for ipcdn@ietf.org; Wed, 12 Jan 2005 18:43:47 -0800 Message-ID: <001201c4f919$d6133c60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <24CDBA67F085904999751B3C4F9E8C0B01E76CB4@NT-RMNA-0740.brcm.ad.broadcom.com> Subject: Re: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of questions Date: Wed, 12 Jan 2005 18:44:42 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Hi - > From: "Eugene Nechamkin" > To: "Dave Thaler" ; "Jean-Francois Mule" ; > Cc: "Leandro Rzezak" ; "PacketCable Provisioning and OSS Majordomo List" > Sent: Wednesday, January 12, 2005 3:34 PM > Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of questions > > As the "must" is not a normative requirement in this particular case, That's not what the proposed text says. The proposal says | pktcMtaDevErrorOidsTable. In this case, the value of the | pktcMtaDevErrorOid, pktcMtaDevErrorValue, and | pktcMtaDevErrorReason objects for the 1024-th table entry | must all be equal to | 'TOO MANY ERRORS IN THE CONFIGURATION FILE'." I see no way to read those words as non-normative. An implementation that used any other string would not be conformant. > the string mentioned in the decsription clause does not seem to be too > restrictive and should not pose problems in localized environments. ... These objects worry me. Has someone looked at them from the perspective of RFC 2130? Also, is the fact that all the examples are all in English and all in capital letters somehow significant? Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Jan 12 22:56:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16385 for ; Wed, 12 Jan 2005 22:56:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CowKf-0008Va-Gk for ipcdn-archive@ietf.org; Wed, 12 Jan 2005 23:11:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cow3o-0000q3-An; Wed, 12 Jan 2005 22:54:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cow0x-00088y-EW for ipcdn@megatron.ietf.org; Wed, 12 Jan 2005 22:51:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15892 for ; Wed, 12 Jan 2005 22:51:13 -0500 (EST) Received: from mms-nat.broadcom.com ([63.70.210.58] helo=mms3.broadcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CowF6-0008Ni-I9 for ipcdn@ietf.org; Wed, 12 Jan 2005 23:05:53 -0500 Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Wed, 12 Jan 2005 19:50:27 -0800 X-Server-Uuid: 062D48FB-9769-4139-967C-478C67B5F9C9 Received: from nt-irva-0740.brcm.ad.broadcom.com ( nt-irva-0740.brcm.ad.broadcom.com [10.8.194.53]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id TAA02231; Wed, 12 Jan 2005 19:50:27 -0800 (PST) Received: from nt-rmna-0740.brcm.ad.broadcom.com ([10.136.192.33]) by nt-irva-0740.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Jan 2005 19:50:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of questions Date: Wed, 12 Jan 2005 19:50:22 -0800 Message-ID: <24CDBA67F085904999751B3C4F9E8C0B01E76CCA@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of questions Thread-Index: AcT5GrCoVsZ+/g3uQFWaY5Tz7qdTKwABzr/A From: "Eugene Nechamkin" To: "Randy Presuhn" X-OriginalArrivalTime: 13 Jan 2005 03:50:27.0129 (UTC) FILETIME=[04B3F290:01C4F923] X-WSS-ID: 6DFB2F892C077227-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Cc: ipcdn@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable How about the following: | pktcMtaDevErrorOidsTable. In this case, the value of the | pktcMtaDevErrorOid, pktcMtaDevErrorValue, and | pktcMtaDevErrorReason objects for the 1024-th table entry must=20 | all contain the string 'TOO MANY ERRORS IN THE CONFIGURATION FILE'=20 | or its semantic equivalent." Eugene. -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Randy Presuhn Sent: Wednesday, January 12, 2005 6:45 PM To: ipcdn@ietf.org Subject: Re: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of questions Hi - > From: "Eugene Nechamkin" > To: "Dave Thaler" ; "Jean-Francois=20 > Mule" ; > Cc: "Leandro Rzezak" ; "PacketCable Provisioning and OSS Majordomo List" > Sent: Wednesday, January 12, 2005 3:34 PM > Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of=20 > questions > > As the "must" is not a normative requirement in this particular case, That's not what the proposed text says. The proposal says | pktcMtaDevErrorOidsTable. In this case, the value of the | pktcMtaDevErrorOid, pktcMtaDevErrorValue, and | pktcMtaDevErrorReason objects for the 1024-th table entry | must all be equal to | 'TOO MANY ERRORS IN THE CONFIGURATION FILE'." I see no way to read those words as non-normative. An implementation that used any other string would not be conformant. > the string mentioned in the decsription clause does not seem to be=20 > too restrictive and should not pose problems in localized environments. ... These objects worry me. Has someone looked at them from the perspective of RFC 2130? Also, is the fact that all the examples are all in English and all in capital letters somehow significant? Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Jan 12 23:32:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18079 for ; Wed, 12 Jan 2005 23:32:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cowsf-0000gE-Mh for ipcdn-archive@ietf.org; Wed, 12 Jan 2005 23:46:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CowbF-0007wO-3w; Wed, 12 Jan 2005 23:28:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CowX0-0006tV-EM for ipcdn@megatron.ietf.org; Wed, 12 Jan 2005 23:24:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17668 for ; Wed, 12 Jan 2005 23:24:19 -0500 (EST) Received: from pop-a065b10.pas.sa.earthlink.net ([207.217.121.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cowl8-0000X8-U7 for ipcdn@ietf.org; Wed, 12 Jan 2005 23:39:00 -0500 Received: from h-66-167-207-234.snvacaid.dynamic.covad.net ([66.167.207.234] helo=oemcomputer) by pop-a065b10.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CowWx-0000P1-00 for ipcdn@ietf.org; Wed, 12 Jan 2005 20:24:19 -0800 Message-ID: <001101c4f927$e1612f60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <24CDBA67F085904999751B3C4F9E8C0B01E76CCA@NT-RMNA-0740.brcm.ad.broadcom.com> Subject: Re: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of questions Date: Wed, 12 Jan 2005 20:25:14 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Hi - > From: "Eugene Nechamkin" > To: "Randy Presuhn" > Cc: > Sent: Wednesday, January 12, 2005 7:50 PM > Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of questions > > How about the following: > > | pktcMtaDevErrorOidsTable. In this case, the value of the > | pktcMtaDevErrorOid, pktcMtaDevErrorValue, and > | pktcMtaDevErrorReason objects for the 1024-th table entry must > | all contain the string 'TOO MANY ERRORS IN THE CONFIGURATION FILE' > | or its semantic equivalent." ... This worries me even more. I don't see how this change to the change could possibly help interoperability. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Jan 12 23:50:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19379 for ; Wed, 12 Jan 2005 23:50:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoxA8-0001Bt-3n for ipcdn-archive@ietf.org; Thu, 13 Jan 2005 00:04:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cowuf-0004A3-2K; Wed, 12 Jan 2005 23:48:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cowr4-0003E7-Ef for ipcdn@megatron.ietf.org; Wed, 12 Jan 2005 23:45:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19073 for ; Wed, 12 Jan 2005 23:45:03 -0500 (EST) Received: from mms-nat.broadcom.com ([63.70.210.58] helo=mms2.broadcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cox5A-0000vF-Lv for ipcdn@ietf.org; Wed, 12 Jan 2005 23:59:44 -0500 Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Wed, 12 Jan 2005 20:44:19 -0800 X-Server-Uuid: 011F2A72-58F1-4BCE-832F-B0D661E896E8 Received: from nt-irva-0740.brcm.ad.broadcom.com ( nt-irva-0740.brcm.ad.broadcom.com [10.8.194.53]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id UAA07159; Wed, 12 Jan 2005 20:44:19 -0800 (PST) Received: from nt-rmna-0740.brcm.ad.broadcom.com ([10.136.192.33]) by nt-irva-0740.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Jan 2005 20:44:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of questions Date: Wed, 12 Jan 2005 20:44:17 -0800 Message-ID: <24CDBA67F085904999751B3C4F9E8C0B01E76CCB@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of questions Thread-Index: AcT5KOy6OLdeLOzMQh2yScfhEKFUcQAACIHQ From: "Eugene Nechamkin" To: "Randy Presuhn" X-OriginalArrivalTime: 13 Jan 2005 04:44:19.0238 (UTC) FILETIME=[8B30A460:01C4F92A] X-WSS-ID: 6DFB23292BK97776-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: ipcdn@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable If your concern is the usage of the object in the different lingual environments with presumably normative language in the object's description, then the proposed, I believe, adequately addresses your concern. If your concern is the interoperability, then the object itself, without the normative requirement, carries the informative meaning for the NMS personal, and is becoming even wider interoperable. If this is still not satisafctory, please feel free to make a specific editorial suggestion. Eugene. -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Randy Presuhn Sent: Wednesday, January 12, 2005 8:25 PM To: ipcdn@ietf.org Subject: Re: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of questions Hi - > From: "Eugene Nechamkin" > To: "Randy Presuhn" > Cc: > Sent: Wednesday, January 12, 2005 7:50 PM > Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of=20 > questions > > How about the following: > > | pktcMtaDevErrorOidsTable. In this case, the value of the > | pktcMtaDevErrorOid, pktcMtaDevErrorValue, and > | pktcMtaDevErrorReason objects for the 1024-th table entry must > | all contain the string 'TOO MANY ERRORS IN THE CONFIGURATION FILE' > | or its semantic equivalent." ... This worries me even more. I don't see how this change to the change could possibly help interoperability. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Jan 13 02:24:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12964 for ; Thu, 13 Jan 2005 02:24:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CozZ1-00043V-5U for ipcdn-archive@ietf.org; Thu, 13 Jan 2005 02:38:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CozGw-0006Cs-L0; Thu, 13 Jan 2005 02:19:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CozFZ-0005KS-HA for ipcdn@megatron.ietf.org; Thu, 13 Jan 2005 02:18:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12329 for ; Thu, 13 Jan 2005 02:18:31 -0500 (EST) Received: from pop-a065d19.pas.sa.earthlink.net ([207.217.121.253]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CozTh-0003xj-7u for ipcdn@ietf.org; Thu, 13 Jan 2005 02:33:12 -0500 Received: from h-66-167-207-234.snvacaid.dynamic.covad.net ([66.167.207.234] helo=oemcomputer) by pop-a065d19.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CozFP-00007N-00 for ipcdn@ietf.org; Wed, 12 Jan 2005 23:18:24 -0800 Message-ID: <000601c4f940$334b1bc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <24CDBA67F085904999751B3C4F9E8C0B01E76CCB@NT-RMNA-0740.brcm.ad.broadcom.com> Subject: Re: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of questions Date: Wed, 12 Jan 2005 23:19:20 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Hi - > From: "Eugene Nechamkin" > To: "Randy Presuhn" > Cc: > Sent: Wednesday, January 12, 2005 8:44 PM > Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of questions > > If your concern is the usage of the object in the different lingual > environments with presumably normative language in the object's > description, then the proposed, I believe, adequately addresses your > concern. If your concern is the interoperability, then the object > itself, without the normative requirement, carries the informative > meaning for the NMS personal, and is becoming even wider interoperable. > > If this is still not satisafctory, please feel free to make a specific > editorial suggestion. ... A managed device has no way of knowing what locale(s) may be in effect on the network management systems (both human-controlled and purely automated) that are communicating with it. The locale in effect may even change, depending on which operator is currently using a management system. Consequently, localization of error messages is something to be done at the management systems, not the managed devices. NMS operators are not all human. More and more work is done by scripts and programs working on behalf of humans. In general software isn't all that good at figuring out "semantic equivalents". The problem is even worse if the localized text doesn't carry some kind of language tag. Error messages are quite different from names and labels. The latter can be treated as opaque values by software, and in general there's no a priori value that can be associated with them. Error messages, on the other hand, do have semantics, and management software will be expected to alter its behaviour based on the messages it encounters. My preference is for a machine-readable enumeration of error codes. If that is not practical, then, at least for the cases that a script or automated management system would need to recognize, the EXACT strings that appear in protocol should be spelled out, with recognition that a user interface might present some localized equivalent. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Jan 13 13:21:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00433 for ; Thu, 13 Jan 2005 13:21:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp9p8-0002AA-3p for ipcdn-archive@ietf.org; Thu, 13 Jan 2005 13:36:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp9X0-0004sd-RF; Thu, 13 Jan 2005 13:17:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CooWI-0008MC-G6 for ipcdn@megatron.ietf.org; Wed, 12 Jan 2005 14:51:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08260 for ; Wed, 12 Jan 2005 14:51:05 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CookK-0005c3-05 for ipcdn@ietf.org; Wed, 12 Jan 2005 15:05:39 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Jan 2005 11:50:28 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Wed, 12 Jan 2005 11:50:26 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Wed, 12 Jan 2005 11:50:26 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Wed, 12 Jan 2005 11:50:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt Date: Wed, 12 Jan 2005 11:50:44 -0800 Message-ID: Thread-Topic: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt Thread-Index: AcR6thTZfq+7VKivT3+3uhPKgFAc5B9gt0cwAAHmZ4AAHod+mQAIR77w From: "Dave Thaler" To: "Jean-Francois Mule" , X-OriginalArrivalTime: 12 Jan 2005 19:50:26.0438 (UTC) FILETIME=[F6274260:01C4F8DF] X-Spam-Score: 0.9 (/) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad X-Mailman-Approved-At: Thu, 13 Jan 2005 13:17:13 -0500 Cc: randy_presuhn@mindspring.com, "Wijnen, Bert \(Bert\)" , ipcdn@ietf.org, "C. M. Heard" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1705889136==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 96e0f8497f38c15fbfc8f6f315bcdecb This is a multi-part message in MIME format. --===============1705889136== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4F8DF.F5EBA0CA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4F8DF.F5EBA0CA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It would also make sense to remove the ' ' from around the address = values to=20 make it clear they're not strings. Hence: > < If this object is of value 0.0.0.0, the MTA MUST stop > < all provisioning attempts as well as all other activities. > < If this object is of value 255.255.255.255, it means -Dave From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 Sent: Wednesday, January 12, 2005 7:25 AM To: Dave Thaler; enechamkin@broadcom.com Cc: randy_presuhn@mindspring.com; Wijnen, Bert (Bert); ipcdn@ietf.org; = C. M. Heard Subject: RE: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt Ok, I missed to record the removal of "dotted" in my log. Will keep the = text of draft05 then. Thanks, Jean-Francois. -----Original Message-----=20 From: Dave Thaler [mailto:dthaler@windows.microsoft.com]=20 Sent: Tue 1/11/2005 7:38 PM=20 To: Jean-Francois Mule; enechamkin@broadcom.com=20 Cc: randy_presuhn@mindspring.com; Wijnen, Bert (Bert); ipcdn@ietf.org; = C. M. Heard=20 Subject: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: Tuesday, January 11, 2005 4:07 PM > To: Dave Thaler; enechamkin@broadcom.com > Cc: ipcdn@ietf.org; Wijnen, Bert (Bert); randy_presuhn@mindspring.com; = C. > M. Heard > Subject: RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt > > Dave Thaler wrote: > > SHOULD fix > > ---------- > [snip] > > 13) pktcMtaDevServerDhcp1, pktcMtaDevServerDns1, etc: the > > DESCRIPTION of > > > > these objects is worded as if the type is a string rather than = an > > InetAddress (the "dotted" IP address, etc). Technically, > > there's no > > dots in the value, only in the displayed version of it. > > Good point and yes, this may be confusing. > Here's a proposed rewording for all the affected object description > clauses (it's a bit of a convoluted rewording but that's the best I = could > come up with): > Replace: > < If this object is of value '0.0.0.0', the MTA MUST stop > < all provisioning attempts as well as all other activities. > < If this object is of value '255.255.255.255', it means > there was no preference given for the primary DHCP > server, and, the MTA must follow the logic of RFC2131, and > the value of DHCP option 122 sub-option 2 must be > ignored." > > with: > > If this object is of an InetAddress value equivalent to > > '0.0.0.0', the MTA MUST stop all provisioning attempts > > as well as all other activities. > > If this object is of an InetAddress value equivalent to > > '255.255.255.255', it means > there was no preference given for the primary DHCP > server, and, the MTA must follow the logic of RFC2131, and > the value of DHCP option 122 sub-option 2 must be > ignored." > > Ok? > Jean-Fran=E7ois My original comment was specifically in response to the use of the word = "dotted" in the DESCRIPTION clauses, which is no longer present in -05. For example, -04 had "When the latter has the value 'ipv4(1)', this object=20 contains the dotted IP address of the primary DHCP server." in the description of pktcMtaDevServerDhcp1, whereas -05 has "When the latter has the value 'ipv4(1)', this object=20 contains the IP address of the primary DHCP server." Hence my original comment has been resolved in -05 and in response to = your proposed text above, I actually prefer the current wording (just "value '0.0.0.0'" rather than "value equivalent to '0.0.0.0'"). -Dave _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn ------_=_NextPart_001_01C4F8DF.F5EBA0CA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipcdn] RE: Review of = draft-ietf-ipcdn-pktc-mtamib-04.txt

It would also make sense to remove = the ‘ ’ from around the address values to

make = it clear they’re not strings.  Hence:

> = <=A0=A0=A0=A0=A0=A0=A0=A0 If this object is of value 0.0.0.0, the MTA = MUST stop
> <=A0=A0=A0=A0=A0=A0=A0=A0 all provisioning attempts as well as = all other activities.
> <=A0=A0=A0=A0=A0=A0=A0=A0 If this object is of value = 255.255.255.255, it means

-Dave


From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] Sent: Wednesday, January 12, = 2005 7:25 AM
To: Dave Thaler; = enechamkin@broadcom.com
Cc: = randy_presuhn@mindspring.com; Wijnen, Bert (Bert); ipcdn@ietf.org; C. M. = Heard
Subject: RE: [ipcdn] RE: Review of = draft-ietf-ipcdn-pktc-mtamib-04.txt

Ok, I missed to record the removal = of "dotted" in my log. Will keep the text of draft05 = then.

Thanks,

Jean-Francois.

-----Original = Message-----
From: Dave Thaler = [mailto:dthaler@windows.micr= osoft.com]
Sent: Tue 1/11/2005 = 7:38 PM
To: Jean-Francois = Mule; enechamkin@broadcom.com
Cc: = randy_presuhn@mindspring.com; Wijnen, Bert (Bert); ipcdn@ietf.org; C. M. = Heard
Subject: [ipcdn] RE: = Review of draft-ietf-ipcdn-pktc-mtamib-04.txt

> -----Original = Message-----
> From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]
> Sent: Tuesday, January 11, 2005 4:07 PM
> To: Dave Thaler; enechamkin@broadcom.com
> Cc: ipcdn@ietf.org; Wijnen, Bert (Bert); = randy_presuhn@mindspring.com; C.
> M. Heard
> Subject: RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt
>
> Dave Thaler wrote:
> > SHOULD fix
> > ----------
> [snip]
> > 13) pktcMtaDevServerDhcp1, pktcMtaDevServerDns1, etc: the
> > DESCRIPTION of
> >
> >=A0=A0=A0=A0 these objects is worded as if the type is a string = rather than an
> >=A0=A0=A0=A0 InetAddress (the "dotted" IP address, = etc).=A0 Technically,
> > there's no
> >=A0=A0=A0=A0 dots in the value, only in the displayed version = of it.
>
> Good point and yes, this may be confusing.
> Here's a proposed rewording for all the affected object = description
> clauses (it's a bit of a convoluted rewording but that's the best I = could
> come up with):
> Replace:
> <=A0=A0=A0=A0=A0=A0=A0=A0 If this object is of value '0.0.0.0', = the MTA MUST stop
> <=A0=A0=A0=A0=A0=A0=A0=A0 all provisioning attempts as well as = all other activities.
> <=A0=A0=A0=A0=A0=A0=A0=A0 If this object is of value = '255.255.255.255', it means
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 there was no preference given for the = primary DHCP
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 server, and, the MTA must follow the = logic of RFC2131, and
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the value of DHCP option 122 = sub-option 2 must be
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ignored."
>
> with:
> >=A0=A0=A0=A0=A0=A0=A0=A0 If this object is of an InetAddress = value equivalent to
> >=A0=A0=A0=A0=A0=A0=A0=A0 '0.0.0.0', the MTA MUST stop all = provisioning attempts
> >=A0=A0=A0=A0=A0=A0=A0=A0 as well as all other activities.
> >=A0=A0=A0=A0=A0=A0=A0=A0 If this object is of an InetAddress = value equivalent to
> >=A0=A0=A0=A0=A0=A0=A0=A0 '255.255.255.255', it means
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 there was no preference given for the = primary DHCP
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 server, and, the MTA must follow the = logic of RFC2131, and
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the value of DHCP option 122 = sub-option 2 must be
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ignored."
>
> Ok?
> Jean-Fran=E7ois

My original comment was specifically in response to the use of the word = "dotted" in the DESCRIPTION clauses, which is no longer = present in -05.
For example, -04 had
=A0=A0=A0=A0=A0=A0=A0 "When the latter has the value 'ipv4(1)', = this object=A0
=A0=A0=A0=A0=A0=A0=A0 contains the dotted IP address of the primary = DHCP
=A0=A0=A0=A0=A0=A0=A0 server."
in the description of pktcMtaDevServerDhcp1, whereas -05 has
=A0=A0=A0=A0=A0=A0=A0 "When the latter has the value 'ipv4(1)', = this object=A0
=A0=A0=A0=A0=A0 contains the IP address of the primary DHCP
=A0=A0=A0=A0=A0 server."

Hence my original comment has been resolved in -05 and in response to = your
proposed text above, I actually prefer the current wording (just
"value '0.0.0.0'" rather than "value equivalent to = '0.0.0.0'").

-Dave

_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn

------_=_NextPart_001_01C4F8DF.F5EBA0CA-- --===============1705889136== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============1705889136==-- From ipcdn-bounces@ietf.org Thu Jan 13 13:22:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00588 for ; Thu, 13 Jan 2005 13:22:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp9q5-0002Ck-Gs for ipcdn-archive@ietf.org; Thu, 13 Jan 2005 13:37:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp9X1-0004si-20; Thu, 13 Jan 2005 13:17:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Coohl-0003e5-WF for ipcdn@megatron.ietf.org; Wed, 12 Jan 2005 15:03:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08910 for ; Wed, 12 Jan 2005 15:02:56 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Coovq-0005pZ-VF for ipcdn@ietf.org; Wed, 12 Jan 2005 15:17:31 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Wed, 12 Jan 2005 12:02:27 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Wed, 12 Jan 2005 12:02:22 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Wed, 12 Jan 2005 12:02:22 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Wed, 12 Jan 2005 12:02:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of questions Date: Wed, 12 Jan 2005 12:02:42 -0800 Message-ID: Thread-Topic: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of questions Thread-Index: AcQHvN926xVuYmLvRFuX5nS5/On1/wD5ERZwAAG0zlABimPhABuwhhFwAALJl5AABA/rAAAHRsZsHdoI4fAAK0/i0A== From: "Dave Thaler" To: "Jean-Francois Mule" , X-OriginalArrivalTime: 12 Jan 2005 20:02:21.0818 (UTC) FILETIME=[A08D95A0:01C4F8E1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 13 Jan 2005 13:17:13 -0500 Cc: enechamkin@broadcom.com, PacketCable Provisioning and OSS Majordomo List , Leandro Rzezak X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Content-Transfer-Encoding: quoted-printable The problem I have with=20 > must all be equal to > 'TOO MANY ERRORS IN THE CONFIGURATION FILE' is that nothing else in the DESCRIPTION clauses indicates that the text must be in English, and this introduces a MUST which is not localizable to other languages. -Dave > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: Tuesday, January 11, 2005 3:35 PM > To: ipcdn@ietf.org > Cc: enechamkin@broadcom.com; Dave Thaler; Sumanth Channabasappa; > PacketCable Provisioning and OSS Majordomo List; Leandro Rzezak > Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of > questions >=20 > All, >=20 > Eugene and I are updating the IETF IPCDN MTA MIB draft 06. >=20 > We'd like to close one of the open items that did not get address in = the > draft05 released in October: pktcMtaDevErrorOidsTable and what MTA > behavior should be when the number of errors exceeds the table size = limit > of 1024. >=20 > Based on the input received, we'd like to propose the following: > 1. keep 1024 as a reasonable number of errors in a single config file > 2. if more than 1024 I had ping the list, >/dev/null": the MTA should > forget about any subsequent errors i.e. any error after 1024 does not = get > stored in the table, and the last entry (1024th)'s is populated with a > reason indicating that there are more errors per the suggestions = received > by Leandro and Sumanth on the list. >=20 > Proposed text changes: > pktcMtaDevErrorOidIndex OBJECT-TYPE > SYNTAX Unsigned32 (1..1024) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > " This object is the index of the MTA configuration error > table. It is an integer value which starts at value '1' > and is incremented for each encountered configuration > file error or warning. > If the number of configuration errors exceeds 1024, all > errors beyond the 1024th one must be ignored - these > subsequent errors are not reflected in the > pktcMtaDevErrorOidsTable. In this case, the value of the > pktcMtaDevErrorOid, pktcMtaDevErrorValue, and > pktcMtaDevErrorReason objects for the 1024-th table entry > must all be equal to > 'TOO MANY ERRORS IN THE CONFIGURATION FILE'." > ::=3D {pktcMtaDevErrorOidsEntry 1} >=20 >=20 > Let us know if this change is acceptable or else, feel free to propose > text improvements or suggestions. > Thanks, > Jean-Fran=E7ois >=20 > > -----Original Message----- > > From: Sumanth Channabasappa [mailto:SChanna@alopa.com] > > Sent: Thursday, August 12, 2004 6:32 PM > > To: Leandro Rzezak; Jean-Francois Mule; ipcdn@ietf.org; > > PacketCable Provisioning and OSS Majordomo List > > Cc: enechamkin@broadcom.com; Dave Thaler > > Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a > > number of questions > > > > > > Hi, > > > > I am unaware of any specific reason for the range when it was > > proposed. (I guess it was assumed that 1024 errors would > > exceed any errors in a single configuration file!). > > > > I would agree on the /dev/null (but indicating in the 1024th > > entry there were more errors!). > > > > Sumanth > > > > . > > > > -----Original Message----- > > From: ipcdn-bounces@ietf.org on behalf of Leandro Rzezak > > Sent: Thu 8/12/2004 3:00 PM > > To: 'Jean-Francois Mule'; ipcdn@ietf.org; 'PacketCable > > Provisioning and OSS Majordomo List' > > Cc: enechamkin@broadcom.com; 'Dave Thaler' > > Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a > > number of questions > > > > > > About the 2nd issue, perhaps going with the ">/dev/null" mode > > but overwriting the 1024th error with a warning... > > > > Regards, > > > > Leandro Rzezak > > Intraway Corp. > > http://www.intraway.com > > > > -----Original Message----- > > From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] > > On Behalf Of Jean-Francois Mule > > Sent: Thursday, August 12, 2004 5:11 PM > > To: ipcdn@ietf.org; PacketCable Provisioning and OSS Majordomo List > > Cc: enechamkin@broadcom.com; Dave Thaler > > Subject: [ipcdn] [pkt-prov] MTA MIB Error OID table - a > > number of questions > > > > Folks, > > > > We received one comment from Dave Thaler during the IETF > > mib doctor review on the MTA MIB ErrorOID table for which I > > would like to request some input from the lists (comment #11 > > from Dave). > > > > 1. Max range of the index object: > > pktcMtaDevErrorOidIndex OBJECT-TYPE > > SYNTAX Unsigned32 (1..1024) > > ^^^^ > > Is there any reason why we are limiting the size of this > > object? From an implementation point of view on the snmp mib > > agent, is this limitation buying much? > > > > > > 2. What happens if more than 1024 errors are encountered? > > Hopefully this does not happen often since the operators > > manage the config files and it is extremely rare to have > > config files with over 1024 entries or with a smaller number > > of entries causing 1024 errors. That said, if we keep the > > range as-is, per Dave's recommendation, we should define > > properly what happens after the value 1024 is reached so that > > all MTA vendors do it consistently and so that SNMP mgers can > > act accordingly in those cases. > > > > Assuming we keep the range as is (1..1024), there are a > > couple of options for MTAs to populate the table when a > > 1025th error is encountered: > > - ">/dev/null": forget about it, any error after 1024 does > > not get stored, only the first 1024 errors are present in the table, > > - "wrap": overwrite entries starting with entry 1, so 1025 > > -> 1, 1026 -> 2, etc. > > - "tail": just overwrite the last entry (1..1023 remain > > stable, 1024 is updated with the latest error: 1025 -> 1024, > > 1026 -> 1024, etc.) > > > > The "wrap" mode is not a good option in my opinion for 2 reasons: > > - by analogy with compilation errors we sometimes encounter = with > > C++/C/SMI, an error early on in the file being parsed can > > cause numerous > > subsequent errors which are not very relevant; > > - in this particular case of config files with TLV > > tuples, if something goes wrong on the MTA misinterpreting > > the length of a TLV for e.g., all subsequent TLV parsing will > > be affected. =3D> "wrap" won't help troubleshoot the primary errors. > > > > My preference would be ">/dev/null". It is simpler for MTAs > > and if there are 1024 errors, who cares about the remaining > > ones (based on the above). The "tail" mode is misleading in > > my opinion and is not very relevant as intermediate entries > > (1025..max_errors-1) will be missed. > > > > Are there any other/better options if we keep the range? Any > > comments on the above? > > > > Jean-Fran=E7ois _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Jan 13 13:41:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02704 for ; Thu, 13 Jan 2005 13:41:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpA92-0002n5-Po for ipcdn-archive@ietf.org; Thu, 13 Jan 2005 13:56:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp9pC-0001hI-E6; Thu, 13 Jan 2005 13:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp9fE-0007Il-Vc for ipcdn@megatron.ietf.org; Thu, 13 Jan 2005 13:25:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01247 for ; Thu, 13 Jan 2005 13:25:41 -0500 (EST) Received: from mms-nat.broadcom.com ([63.70.210.58] helo=mms2.broadcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp9tS-0002Km-OW for ipcdn@ietf.org; Thu, 13 Jan 2005 13:40:30 -0500 Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Thu, 13 Jan 2005 09:46:44 -0800 X-Server-Uuid: 011F2A72-58F1-4BCE-832F-B0D661E896E8 Received: from nt-irva-0740.brcm.ad.broadcom.com ( nt-irva-0740.brcm.ad.broadcom.com [10.8.194.53]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id JAA29271; Thu, 13 Jan 2005 09:46:44 -0800 (PST) Received: from nt-rmna-0740.brcm.ad.broadcom.com ([10.136.192.33]) by nt-irva-0740.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Jan 2005 09:46:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of questions Date: Thu, 13 Jan 2005 09:46:42 -0800 Message-ID: <24CDBA67F085904999751B3C4F9E8C0B01E76CD0@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of questions Thread-Index: AcT5QQMUEjwNsPhNTFC3uAyRAOJvWgAUtVaA From: "Eugene Nechamkin" To: "Randy Presuhn" X-OriginalArrivalTime: 13 Jan 2005 17:46:43.0986 (UTC) FILETIME=[D870B720:01C4F997] X-WSS-ID: 6DF86B8E2BK253869-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable Cc: ipcdn@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable > If that is not practical, then,=20 > at least for the cases that a script or automated management=20 > system would need to recognize, the EXACT strings that appear=20 > in protocol should be spelled out, with recognition that a=20 > user interface might present some localized equivalent. Let me remind you that the initial concern was the presense of almost mandatory requirement for the EXACT particular string 'TOO MANY ERRORS IN THE CONFIGURATION FILE' which seemed to be not in line with the language localization on the managed device (if such required in some environments). As a recognition of this, the modification has been proposed which softened the requirement. Given the fact that the NMSs can accommodate various logics of mapping the messages generated by the range of devices to the locally meaningfull events, the last proposed text seems to be satisfactory because it 1). allows localized text on the managed devices (if necessary), and 2). still does not prevent the NMSs from using the corresponding localization policies with the managed devices. Eugene. -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Randy Presuhn Sent: Wednesday, January 12, 2005 11:19 PM To: ipcdn@ietf.org Subject: Re: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of questions Hi - > From: "Eugene Nechamkin" > To: "Randy Presuhn" > Cc: > Sent: Wednesday, January 12, 2005 8:44 PM > Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of=20 > questions > > If your concern is the usage of the object in the different lingual=20 > environments with presumably normative language in the object's=20 > description, then the proposed, I believe, adequately addresses your=20 > concern. If your concern is the interoperability, then the object=20 > itself, without the normative requirement, carries the informative=20 > meaning for the NMS personal, and is becoming even wider interoperable. > > If this is still not satisafctory, please feel free to make a specific > editorial suggestion. ... A managed device has no way of knowing what locale(s) may be in effect on the network management systems (both human-controlled and purely automated) that are communicating with it. The locale in effect may even change, depending on which operator is currently using a management system. Consequently, localization of error messages is something to be done at the management systems, not the managed devices. NMS operators are not all human. More and more work is done by scripts and programs working on behalf of humans. In general software isn't all that good at figuring out "semantic equivalents". The problem is even worse if the localized text doesn't carry some kind of language tag. Error messages are quite different from names and labels. The latter can be treated as opaque values by software, and in general there's no a priori value that can be associated with them. Error messages, on the other hand, do have semantics, and management software will be expected to alter its behaviour based on the messages it encounters. My preference is for a machine-readable enumeration of error codes. If that is not practical, then, at least for the cases that a script or automated management system would need to recognize, the EXACT strings that appear in protocol should be spelled out, with recognition that a user interface might present some localized equivalent. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Jan 13 13:44:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02971 for ; Thu, 13 Jan 2005 13:44:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpABO-0002rk-3G for ipcdn-archive@ietf.org; Thu, 13 Jan 2005 13:58:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp9qx-0002Kb-GV; Thu, 13 Jan 2005 13:37:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp9lO-0000Q4-BS for ipcdn@megatron.ietf.org; Thu, 13 Jan 2005 13:32:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01985 for ; Thu, 13 Jan 2005 13:32:02 -0500 (EST) Received: from mms-nat.broadcom.com ([63.70.210.58] helo=mms2.broadcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cp9zf-0002X4-Gz for ipcdn@ietf.org; Thu, 13 Jan 2005 13:46:51 -0500 Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Thu, 13 Jan 2005 10:31:06 -0800 X-Server-Uuid: 011F2A72-58F1-4BCE-832F-B0D661E896E8 Received: from nt-irva-0740.brcm.ad.broadcom.com ( nt-irva-0740.brcm.ad.broadcom.com [10.8.194.53]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id KAA11531; Thu, 13 Jan 2005 10:31:05 -0800 (PST) Received: from nt-rmna-0740.brcm.ad.broadcom.com ([10.136.192.33]) by nt-irva-0740.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Jan 2005 10:31:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of questions Date: Thu, 13 Jan 2005 10:31:03 -0800 Message-ID: <24CDBA67F085904999751B3C4F9E8C0B01E76CD7@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of questions Thread-Index: AcQHvN926xVuYmLvRFuX5nS5/On1/wD5ERZwAAG0zlABimPhABuwhhFwAALJl5AABA/rAAAHRsZsHdoI4fAAK0/i0AAvAIaw From: "Eugene Nechamkin" To: "Dave Thaler" , "Jean-Francois Mule" , ipcdn@ietf.org X-OriginalArrivalTime: 13 Jan 2005 18:31:05.0495 (UTC) FILETIME=[0AD2C270:01C4F99E] X-WSS-ID: 6DF861E02BK263561-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Cc: Leandro Rzezak , PacketCable Provisioning and OSS Majordomo List X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable To address this concern, the last veraion of the description clause with = the softer language allowing the locatlization has been introduced (see = the latest e-mail exchange on the topic). Eugene. -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf = Of Dave Thaler Sent: Wednesday, January 12, 2005 12:03 PM To: Jean-Francois Mule; ipcdn@ietf.org Cc: Eugene Nechamkin; PacketCable Provisioning and OSS Majordomo List; = Leandro Rzezak Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of = questions The problem I have with=20 > must all be equal to > 'TOO MANY ERRORS IN THE CONFIGURATION FILE' is that nothing else in the DESCRIPTION clauses indicates that the text = must be in English, and this introduces a MUST which is not localizable = to other languages. -Dave > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: Tuesday, January 11, 2005 3:35 PM > To: ipcdn@ietf.org > Cc: enechamkin@broadcom.com; Dave Thaler; Sumanth Channabasappa;=20 > PacketCable Provisioning and OSS Majordomo List; Leandro Rzezak > Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of=20 > questions >=20 > All, >=20 > Eugene and I are updating the IETF IPCDN MTA MIB draft 06. >=20 > We'd like to close one of the open items that did not get address in = > the > draft05 released in October: pktcMtaDevErrorOidsTable and what MTA=20 > behavior should be when the number of errors exceeds the table size=20 > limit of 1024. >=20 > Based on the input received, we'd like to propose the following: > 1. keep 1024 as a reasonable number of errors in a single config file = =20 > 2. if more than 1024 I had ping the list, >/dev/null": the MTA should=20 > forget about any subsequent errors i.e. any error after 1024 does not=20 > get stored in the table, and the last entry (1024th)'s is populated=20 > with a reason indicating that there are more errors per the=20 > suggestions received by Leandro and Sumanth on the list. >=20 > Proposed text changes: > pktcMtaDevErrorOidIndex OBJECT-TYPE > SYNTAX Unsigned32 (1..1024) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > " This object is the index of the MTA configuration error > table. It is an integer value which starts at value '1' > and is incremented for each encountered configuration > file error or warning. > If the number of configuration errors exceeds 1024, all > errors beyond the 1024th one must be ignored - these > subsequent errors are not reflected in the > pktcMtaDevErrorOidsTable. In this case, the value of the > pktcMtaDevErrorOid, pktcMtaDevErrorValue, and > pktcMtaDevErrorReason objects for the 1024-th table entry > must all be equal to > 'TOO MANY ERRORS IN THE CONFIGURATION FILE'." > ::=3D {pktcMtaDevErrorOidsEntry 1} >=20 >=20 > Let us know if this change is acceptable or else, feel free to propose = > text improvements or suggestions. > Thanks, > Jean-Fran=E7ois >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Jan 13 14:03:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04047 for ; Thu, 13 Jan 2005 14:03:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpATd-0003G3-Bw for ipcdn-archive@ietf.org; Thu, 13 Jan 2005 14:17:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpA9O-0008Es-0R; Thu, 13 Jan 2005 13:56:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpA3a-0006Hi-7H for ipcdn@megatron.ietf.org; Thu, 13 Jan 2005 13:50:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03340 for ; Thu, 13 Jan 2005 13:50:52 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpAHp-00030A-PD for ipcdn@ietf.org; Thu, 13 Jan 2005 14:05:40 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j0DIka1g007631; Thu, 13 Jan 2005 11:50:16 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt Date: Thu, 13 Jan 2005 11:49:56 -0700 Message-ID: Thread-Topic: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt Thread-Index: AcR6thTZfq+7VKivT3+3uhPKgFAc5B9gt0cwAAHmZ4AAHod+mQAIR77wADErG6A= From: "Jean-Francois Mule" To: "Dave Thaler" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Cc: ipcdn@ietf.org, enechamkin@broadcom.com X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Dave wrote: > It would also make sense to remove the ' ' from around the=20 > address values to=20 > make it clear they're not strings. =20 Absolutely, otherwise it implies this could be the object value. Done. > Hence: > > < If this object is of value 0.0.0.0, the MTA MUST stop > > < all provisioning attempts as well as all other activities. > > < If this object is of value 255.255.255.255, it means > -Dave Thanks, Jean-Fran=E7ois=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Jan 13 14:31:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06267 for ; Thu, 13 Jan 2005 14:31:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpAv1-0003xz-Ku for ipcdn-archive@ietf.org; Thu, 13 Jan 2005 14:46:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpARr-0006MS-Gq; Thu, 13 Jan 2005 14:15:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpANY-0004Up-U9 for ipcdn@megatron.ietf.org; Thu, 13 Jan 2005 14:11:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04771 for ; Thu, 13 Jan 2005 14:11:31 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpAbo-0003Sj-DE for ipcdn@ietf.org; Thu, 13 Jan 2005 14:26:18 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j0DJBRRL008052 for ; Thu, 13 Jan 2005 13:11:28 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 13 Jan 2005 20:11:26 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155062BE8CA@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Eugene Nechamkin , Randy Presuhn Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of ques tions Date: Thu, 13 Jan 2005 20:11:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: ipcdn@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Would it be a solution to assign some OID for this message and then say that entry 1024 would contain " - Too many errors in the configuration file." In which case you have a specific value for machine readable checking () and human readable text that people can even localize if they want to. Just thinking aloud here. Bert > -----Original Message----- > From: ipcdn-bounces@ietf.org > [mailto:ipcdn-bounces@ietf.org]On Behalf Of > Eugene Nechamkin > Sent: Thursday, January 13, 2005 18:47 > To: Randy Presuhn > Cc: ipcdn@ietf.org > Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of > questions > > > > > If that is not practical, then, > > at least for the cases that a script or automated management > > system would need to recognize, the EXACT strings that appear > > in protocol should be spelled out, with recognition that a > > user interface might present some localized equivalent. > > Let me remind you that the initial concern was the presense of almost > mandatory requirement for the EXACT particular string 'TOO MANY ERRORS > IN THE CONFIGURATION FILE' which seemed to be not in line with the > language localization on the managed device (if such required in some > environments). As a recognition of this, the modification has been > proposed which softened the requirement. > > Given the fact that the NMSs can accommodate various logics of mapping > the messages generated by the range of devices to the locally > meaningfull events, the last proposed text seems to be satisfactory > because it 1). allows localized text on the managed devices (if > necessary), and 2). still does not prevent the NMSs from using the > corresponding localization policies with the managed devices. > > Eugene. > > > -----Original Message----- > From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf > Of Randy Presuhn > Sent: Wednesday, January 12, 2005 11:19 PM > To: ipcdn@ietf.org > Subject: Re: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of > questions > > Hi - > > > From: "Eugene Nechamkin" > > To: "Randy Presuhn" > > Cc: > > Sent: Wednesday, January 12, 2005 8:44 PM > > Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a > number of > > questions > > > > If your concern is the usage of the object in the different lingual > > environments with presumably normative language in the object's > > description, then the proposed, I believe, adequately > addresses your > > concern. If your concern is the interoperability, then the object > > itself, without the normative requirement, carries the informative > > meaning for the NMS personal, and is becoming even wider > interoperable. > > > > If this is still not satisafctory, please feel free to make > a specific > > > editorial suggestion. > ... > > A managed device has no way of knowing what locale(s) may be in effect > on the network management systems (both human-controlled and purely > automated) that are communicating with it. The locale in effect may > even change, depending on which operator is currently using a > management > system. > Consequently, localization of error messages is something to > be done at > the management systems, not the managed devices. > > NMS operators are not all human. More and more work is done > by scripts > and programs working on behalf of humans. In general > software isn't all > that good at figuring out "semantic equivalents". The problem is even > worse if the localized text doesn't carry some kind of language tag. > > Error messages are quite different from names and labels. The latter > can be treated as opaque values by software, and in general > there's no a > priori value that can be associated with them. Error messages, on the > other hand, do have semantics, and management software will > be expected > to alter its behaviour based on the messages it encounters. > > My preference is for a machine-readable enumeration of error codes. > If that is not practical, then, at least for the cases that a > script or > automated management system would need to recognize, the EXACT strings > that appear in protocol should be spelled out, with recognition that a > user interface might present some localized equivalent. > > Randy > > > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn > > > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Jan 14 00:25:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27916 for ; Fri, 14 Jan 2005 00:25:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpKBm-0002H6-LQ for ipcdn-archive@ietf.org; Fri, 14 Jan 2005 00:40:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpJwN-0000wf-O7; Fri, 14 Jan 2005 00:24:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpJsn-00088R-6r for ipcdn@megatron.ietf.org; Fri, 14 Jan 2005 00:20:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27614 for ; Fri, 14 Jan 2005 00:20:21 -0500 (EST) Received: from mms-nat.broadcom.com ([63.70.210.58] helo=mms1.broadcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpK76-0002BC-P3 for ipcdn@ietf.org; Fri, 14 Jan 2005 00:35:16 -0500 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Thu, 13 Jan 2005 21:19:32 -0800 X-Server-Uuid: 97B92932-364A-4474-92D6-5CFE9C59AD14 Received: from nt-irva-0740.brcm.ad.broadcom.com ( nt-irva-0740.brcm.ad.broadcom.com [10.8.194.53]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id VAA16872; Thu, 13 Jan 2005 21:19:32 -0800 (PST) Received: from nt-rmna-0740.brcm.ad.broadcom.com ([10.136.192.33]) by nt-irva-0740.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Jan 2005 21:19:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of ques tions Date: Thu, 13 Jan 2005 21:19:25 -0800 Message-ID: <24CDBA67F085904999751B3C4F9E8C0B01E76CF4@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of ques tions Thread-Index: AcT5pBi0mi847DD+S/ec9SdVCbhRdwAUokrQ From: "Eugene Nechamkin" To: "Wijnen, Bert (Bert)" X-OriginalArrivalTime: 14 Jan 2005 05:19:32.0018 (UTC) FILETIME=[A0EB0920:01C4F9F8] X-WSS-ID: 6DF989EE1WW356573-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Content-Transfer-Encoding: quoted-printable Cc: ipcdn@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Content-Transfer-Encoding: quoted-printable Based on the proposed, here are the required modifications in the MTA MIB to implement it: 1. The following two new objects are introduced: pktcMtaDevErrors OBJECT IDENTIFIER ::=3D { pktcMtaMibObjects 4 } =20 pktcMtaDevErrorsTooManyErrs OBJECT-IDENTITY STATUS current DESCRIPTION "This object defines the OID corresponding to the error=20 condition when Too Many Errors are registered in the=20 Configuration file during provisioning." ::=3D { pktcMtaDevErrors 1 } 2. The DESCRIPTION of the pktcMtaDevErrorOidIndex is modified as follows: pktcMtaDevErrorOidIndex OBJECT-TYPE =20 SYNTAX Unsigned32 (1..1024) MAX-ACCESS not-accessible STATUS current DESCRIPTION=20 " This object is the index of the MTA configuration error=20 table. It is an integer value which starts at value '1' and is incremented for each encountered configuration=20 file error or warning. If the number of configuration errors exceeds 1024, all errors beyond the 1024th one MUST be ignored - these=20 subsequent errors MUST NOT be reflected in the pktcMtaDevErrorOidsTable. In this case, the value of the pktcMtaDevErrorOid, pktcMtaDevErrorValue, and=20 pktcMtaDevErrorReason objects for the 1024-th table entry MUST all be contain the following error string:=20 ' - Too many errors in the configuration file.'. In this string, the is the meta-symbol representing=20 the corresponding Error OID. This meta-symbol contains=20 the human readable representation (character=20 string) of the pktcMtaDevErrorsTooManyErrs object, i.e. the string '.1.3.6.1.2.1.XXX.1.1.4.1'. ************************************************************ * NOTES TO RFC Editor (to be removed prior to publication) * * Please replace XXX with the IANA-assigned number under * * mib-2. * ************************************************************ The MUST be present in the error string. The=20 rest of the error string will contain explanatory text=20 which should be semantically close to the error being=20 indicated." ::=3D {pktcMtaDevErrorOidsEntry 1} Eugene. -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Thursday, January 13, 2005 11:11 AM To: Eugene Nechamkin; Randy Presuhn Cc: ipcdn@ietf.org Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of ques tions Would it be a solution to assign some OID for this message and then say that entry 1024 would contain " - Too many errors in the configuration file." In which case you have a specific value for machine readable checking () and human readable text that people can even localize if they want to. Just thinking aloud here. Bert > -----Original Message----- > From: ipcdn-bounces@ietf.org > [mailto:ipcdn-bounces@ietf.org]On Behalf Of Eugene Nechamkin > Sent: Thursday, January 13, 2005 18:47 > To: Randy Presuhn > Cc: ipcdn@ietf.org > Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of=20 > questions >=20 >=20 >=20 > > If that is not practical, then, > > at least for the cases that a script or automated management system=20 > > would need to recognize, the EXACT strings that appear in protocol=20 > > should be spelled out, with recognition that a user interface might=20 > > present some localized equivalent. >=20 > Let me remind you that the initial concern was the presense of almost=20 > mandatory requirement for the EXACT particular string 'TOO MANY ERRORS > IN THE CONFIGURATION FILE' which seemed to be not in line with the=20 > language localization on the managed device (if such required in some=20 > environments). As a recognition of this, the modification has been=20 > proposed which softened the requirement. >=20 > Given the fact that the NMSs can accommodate various logics of mapping > the messages generated by the range of devices to the locally=20 > meaningfull events, the last proposed text seems to be satisfactory=20 > because it 1). allows localized text on the managed devices (if=20 > necessary), and 2). still does not prevent the NMSs from using the=20 > corresponding localization policies with the managed devices. >=20 > Eugene. >=20 >=20 > -----Original Message----- > From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf > Of Randy Presuhn > Sent: Wednesday, January 12, 2005 11:19 PM > To: ipcdn@ietf.org > Subject: Re: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of=20 > questions >=20 > Hi - >=20 > > From: "Eugene Nechamkin" > > To: "Randy Presuhn" > > Cc: > > Sent: Wednesday, January 12, 2005 8:44 PM > > Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a > number of > > questions > > > > If your concern is the usage of the object in the different lingual=20 > > environments with presumably normative language in the object's=20 > > description, then the proposed, I believe, adequately > addresses your > > concern. If your concern is the interoperability, then the object=20 > > itself, without the normative requirement, carries the informative=20 > > meaning for the NMS personal, and is becoming even wider > interoperable. > > > > If this is still not satisafctory, please feel free to make > a specific >=20 > > editorial suggestion. > ... >=20 > A managed device has no way of knowing what locale(s) may be in effect > on the network management systems (both human-controlled and purely > automated) that are communicating with it. The locale in effect may=20 > even change, depending on which operator is currently using a=20 > management system. > Consequently, localization of error messages is something to be done=20 > at the management systems, not the managed devices. >=20 > NMS operators are not all human. More and more work is done by=20 > scripts and programs working on behalf of humans. In general software > isn't all that good at figuring out "semantic equivalents". The=20 > problem is even worse if the localized text doesn't carry some kind of > language tag. >=20 > Error messages are quite different from names and labels. The latter=20 > can be treated as opaque values by software, and in general there's no > a priori value that can be associated with them. Error messages, on=20 > the other hand, do have semantics, and management software will be=20 > expected to alter its behaviour based on the messages it encounters. >=20 > My preference is for a machine-readable enumeration of error codes. > If that is not practical, then, at least for the cases that a script=20 > or automated management system would need to recognize, the EXACT=20 > strings that appear in protocol should be spelled out, with=20 > recognition that a user interface might present some localized=20 > equivalent. >=20 > Randy >=20 >=20 >=20 > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn >=20 >=20 >=20 > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Jan 14 00:41:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28921 for ; Fri, 14 Jan 2005 00:41:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpKRH-0002ax-4I for ipcdn-archive@ietf.org; Fri, 14 Jan 2005 00:56:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpKAp-00054X-LX; Fri, 14 Jan 2005 00:39:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpK6y-00049o-B8 for ipcdn@megatron.ietf.org; Fri, 14 Jan 2005 00:35:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28581 for ; Fri, 14 Jan 2005 00:35:00 -0500 (EST) Received: from pop-a065c32.pas.sa.earthlink.net ([207.217.121.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpKLI-0002TD-FA for ipcdn@ietf.org; Fri, 14 Jan 2005 00:49:55 -0500 Received: from h-69-3-24-195.snvacaid.dynamic.covad.net ([69.3.24.195] helo=oemcomputer) by pop-a065c32.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CpK6g-0002qo-00 for ipcdn@ietf.org; Thu, 13 Jan 2005 21:34:46 -0800 Message-ID: <004701c4f9fa$e40b42e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <7D5D48D2CAA3D84C813F5B154F43B155062BE8CA@nl0006exch001u.nl.lucent.com> Subject: Re: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of questions Date: Thu, 13 Jan 2005 21:35:43 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Hi - > From: "Wijnen, Bert (Bert)" > To: "Eugene Nechamkin" ; "Randy Presuhn" > Cc: > Sent: Thursday, January 13, 2005 11:11 AM > Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number of questions > > Would it be a solution to assign some OID for this message and > then say that entry 1024 would contain > > " - Too many errors in the configuration file." > > In which case you have a specific value for machine readable checking > () and human readable text that people can even > localize if they want to. ... I would be much more comfortable with this kind of a solution. The current proposal requires management application vendors to go on "error message fishing expeditions" in the hope of being able to find out what localized error strings could possibly be produced by the various vendors' implementations of the managed devices, both in order to support scripting, as well as to map the localized strings coming from the device into the locale that should be in effect for the operator of the management system. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Jan 14 00:51:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29588 for ; Fri, 14 Jan 2005 00:51:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpKbI-0002nU-4t for ipcdn-archive@ietf.org; Fri, 14 Jan 2005 01:06:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpKJ4-0006z2-QZ; Fri, 14 Jan 2005 00:47:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpKEN-00062l-RC for ipcdn@megatron.ietf.org; Fri, 14 Jan 2005 00:42:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28985 for ; Fri, 14 Jan 2005 00:42:40 -0500 (EST) Received: from pop-a065c32.pas.sa.earthlink.net ([207.217.121.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpKSl-0002cP-3q for ipcdn@ietf.org; Fri, 14 Jan 2005 00:57:35 -0500 Received: from h-69-3-24-195.snvacaid.dynamic.covad.net ([69.3.24.195] helo=oemcomputer) by pop-a065c32.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CpKEL-0005Lt-00 for ipcdn@ietf.org; Thu, 13 Jan 2005 21:42:41 -0800 Message-ID: <004c01c4f9fb$ffb6e3e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <24CDBA67F085904999751B3C4F9E8C0B01E76CF4@NT-RMNA-0740.brcm.ad.broadcom.com> Subject: Re: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number ofques tions Date: Thu, 13 Jan 2005 21:43:39 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Hi - I like this latest proposal more. However, I think the DESCRIPTION of pktcMtaDevErrorOidIndex needs a little more work. Specifically, > From: "Eugene Nechamkin" > To: "Wijnen, Bert (Bert)" > Cc: > Sent: Thursday, January 13, 2005 9:19 PM > Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number ofques tions ... > pktcMtaDevErrorOidIndex OBJECT-TYPE ... > pktcMtaDevErrorOidsTable. In this case, the value of the > pktcMtaDevErrorOid, pktcMtaDevErrorValue, and remove pktMtaDevErrorOid from this list. > pktcMtaDevErrorReason objects for the 1024-th table entry > MUST all be contain the following error string: replace "be contain" with "be" > ' - Too many errors in the configuration file.'. > In this string, the is the meta-symbol representing > the corresponding Error OID. This meta-symbol contains "contains" should be something like "will be replaced with" > the human readable representation (character > string) of the pktcMtaDevErrorsTooManyErrs object, > i.e. the string '.1.3.6.1.2.1.XXX.1.1.4.1'. Delete the leading "." Add: The object pktMtaDevErrorOid MUST in this case have the value '1.3.6.1.2.1.XXX.1.1.4.1' > ************************************************************ > * NOTES TO RFC Editor (to be removed prior to publication) * > * Please replace XXX with the IANA-assigned number under * > * mib-2. * > ************************************************************ > > The MUST be present in the error string. The > rest of the error string will contain explanatory text > which should be semantically close to the error being > indicated." ... This "should be semantically close" contradicts the "MUST" which appears earlier. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Jan 14 17:55:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03622 for ; Fri, 14 Jan 2005 17:55:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cpaa8-000192-99 for ipcdn-archive@ietf.org; Fri, 14 Jan 2005 18:10:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpaE6-0007BZ-9k; Fri, 14 Jan 2005 17:47:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cpa9K-0004yY-Qi for ipcdn@megatron.ietf.org; Fri, 14 Jan 2005 17:42:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02933 for ; Fri, 14 Jan 2005 17:42:32 -0500 (EST) Received: from mms-nat.broadcom.com ([63.70.210.58] helo=mms1.broadcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpaNq-0000s2-QV for ipcdn@ietf.org; Fri, 14 Jan 2005 17:57:35 -0500 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Fri, 14 Jan 2005 14:41:39 -0800 X-Server-Uuid: 97B92932-364A-4474-92D6-5CFE9C59AD14 Received: from nt-irva-0740.brcm.ad.broadcom.com ( nt-irva-0740.brcm.ad.broadcom.com [10.8.194.53]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id OAA12415; Fri, 14 Jan 2005 14:41:38 -0800 (PST) Received: from nt-rmna-0740.brcm.ad.broadcom.com ([10.136.192.33]) by nt-irva-0740.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Jan 2005 14:41:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number ofques tions Date: Fri, 14 Jan 2005 14:41:36 -0800 Message-ID: <24CDBA67F085904999751B3C4F9E8C0B01E76CFC@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number ofques tions Thread-Index: AcT5/S/aJrpIKAeASr2BJG4cmEt8+wAhhObg From: "Eugene Nechamkin" To: "Randy Presuhn" , ipcdn@ietf.org X-OriginalArrivalTime: 14 Jan 2005 22:41:38.0575 (UTC) FILETIME=[35A679F0:01C4FA8A] X-WSS-ID: 6DF695291WW564013-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Content-Transfer-Encoding: quoted-printable X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Content-Transfer-Encoding: quoted-printable A slight modification of the approach: if we use the pktcMtaDevErrorOid and pktcMtaDevErrorValue to indicate the patrticular OID of pktcMtaDevErrorsTooManyErrs, and use the pktcMtaDevErrorReason to indicate the non-mandatory part of the error message, then it should provide both - interoperability and flexibility.=20 So the following should address additional concerns: pktcMtaDevErrorOidIndex OBJECT-TYPE =20 SYNTAX Unsigned32 (1..1024) MAX-ACCESS not-accessible STATUS current DESCRIPTION=20 " This object is the index of the MTA configuration error=20 table. It is an integer value which starts at value '1' and is incremented for each encountered configuration=20 file error or warning. If the number of the errors in the configuration file exceeds 1024, all errors beyond the 1024th one MUST=20 be ignored - these subsequent errors MUST NOT be=20 reflected in the pktcMtaDevErrorOidsTable." ::=3D {pktcMtaDevErrorOidsEntry 1} pktcMtaDevErrorOid OBJECT-TYPE =20 SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION=20 " This object contains a human readable representation (character string) of the OID corresponding to the configuration file parameter that caused the particular error. For example, if the value of the pktcMtaDevEnabled object in the configuration file caused an error, then this object instance will contain the human readable string of '.1.3.6.1.2.1.XXX.1.1.6.0'. ************************************************************ * NOTES TO RFC Editor (to be removed prior to publication) * * Please replace XXX with the IANA-assigned number under * * mib-2. * ************************************************************ If the MTA generated an error because it was not able=20 to recognize a particular OID, then this object=20 instance would contain an empty value (zero-length string). For example, if the value of an OID in the configuration=20 file was interpreted by the MTA as being .1.2.3.4.5, and=20 the MTA was not able to recognize this OID as a valid one, this object instance will contain a zero-length string. =20 If the numbers of errors in the configuration file exceeds=20 1024, then for all subsiquent errors, the pktcMtaDevErrorOid=20 of 1024th table's entry MUST contain the a human readable=20 representation of the pktcMtaDevErrorsTooManyErrs object,=20 i.e. the string '.1.3.6.1.2.1.XXX.1.1.4.1.0'. ************************************************************ * NOTES TO RFC Editor (to be removed prior to publication) * * Please replace XXX with the IANA-assigned number under * * mib-2. * ************************************************************ Note that the syntax of this object is SnmpAdminString rather OBJECT IDENTIFIER because not all of the parameters which can be potentially included into the configuration=20 file have necessarily the OID associated with them. For=20 example, TLV38 parameters do not have the valid mapping to=20 any particular valid OID. In such cases, the object MUST=20 contain the string uniquely identifying the parameter in error among all the parameters included into the=20 configuration file. For example, for the TLV38=20 parameter which has the wrong value in its suboption-1,=20 the string may look like '38.1'." ::=3D {pktcMtaDevErrorOidsEntry 2} pktcMtaDevErrorValue OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION " This object contains the value of the OID corresponding to the configuration file parameter that caused the error. If the MTA cannot recognize the OID of the configuration parameter causing the error, then this object instance contains the OID itself as interpreted by the MTA in human readable representation. If the MTA can recognize the OID but generate an error due to a wrong value of the parameter, then the object instance contains the erroneous value of the parameter as read from the configuration file. In both cases, the value of this object must be represented in human readable form as a character string. For example, if the value of the pktcMtaDevEnabled object in the configuration file was 3 (invalid value), then the pktcMtaDevErrorValue object instance will contain the human readable (string) representation of value '3'. Similarly, if the OID in the configuration file has been interpreted by the MTA as being .1.2.3.4.5, and the MTA cannot recognize this OID as a valid one, then this pktcMtaDevErrorValue object instance will contain human readable (string) representation of value '.1.2.3.4.5'. If the numbers of errors in the configuration file exceeds=20 1024, then for all subsiquent errors, the pktcMtaDevErrorValue of 1024th table's entry MUST contain the a human readable=20 representation of the pktcMtaDevErrorsTooManyErrs object,=20 i.e. the string '.1.3.6.1.2.1.XXX.1.1.4.1.0'. ************************************************************ * NOTES TO RFC Editor (to be removed prior to publication) * * Please replace XXX with the IANA-assigned number under * * mib-2. * ************************************************************" ::=3D {pktcMtaDevErrorOidsEntry 3} pktcMtaDevErrorReason OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION " This object indicates the reason for the error or warning, as per the MTA's interpretation, in human readable form. =20 Example of possible reason values are: 'VALUE NOT IN RANGE', 'VALUE DOES NOT MATCH TYPE', 'UNSUPPORTED VALUE', 'LAST 4 BITS MUST BE SET TO ZERO', 'OUT OF MEMORY - CANNOT STORE', etc. This object may also contain vendor specific errors for private vendor OIDs and any proprietary error codes or=20 messages which can help diagnose configuration errors. If the numbers of errors in the configuration file exceeds=20 1024, then for all subsiquent errors, the pktcMtaDevErrorReason=20 of 1024th table's entry will contain a human readable string=20 indicating the reason for an error, for example,=20 'Too many errors in the configuration file.'." ::=3D {pktcMtaDevErrorOidsEntry 4} Eugene. -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Randy Presuhn Sent: Thursday, January 13, 2005 9:44 PM To: ipcdn@ietf.org Subject: Re: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number ofques tions Hi - I like this latest proposal more. However, I think the DESCRIPTION of pktcMtaDevErrorOidIndex needs a little more work. Specifically, > From: "Eugene Nechamkin" > To: "Wijnen, Bert (Bert)" > Cc: > Sent: Thursday, January 13, 2005 9:19 PM > Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number=20 > ofques tions ... > pktcMtaDevErrorOidIndex OBJECT-TYPE ... > pktcMtaDevErrorOidsTable. In this case, the value of the > pktcMtaDevErrorOid, pktcMtaDevErrorValue, and remove pktMtaDevErrorOid from this list. > pktcMtaDevErrorReason objects for the 1024-th table entry > MUST all be contain the following error string: replace "be contain" with "be" > ' - Too many errors in the configuration file.'. > In this string, the is the meta-symbol representing > the corresponding Error OID. This meta-symbol contains "contains" should be something like "will be replaced with" > the human readable representation (character > string) of the pktcMtaDevErrorsTooManyErrs object, > i.e. the string '.1.3.6.1.2.1.XXX.1.1.4.1'. Delete the leading "." Add: The object pktMtaDevErrorOid MUST in this case have the value '1.3.6.1.2.1.XXX.1.1.4.1' > ************************************************************ > * NOTES TO RFC Editor (to be removed prior to publication) * > * Please replace XXX with the IANA-assigned number under * > * mib-2. * > ************************************************************ > > The MUST be present in the error string. The > rest of the error string will contain explanatory text > which should be semantically close to the error being > indicated." ... This "should be semantically close" contradicts the "MUST" which appears earlier. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Sat Jan 15 19:22:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20569 for ; Sat, 15 Jan 2005 19:22:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpyQ0-0003i1-N4 for ipcdn-archive@ietf.org; Sat, 15 Jan 2005 19:37:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cpy5x-0002KZ-9Y; Sat, 15 Jan 2005 19:16:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cpy0r-0000z4-Qn for ipcdn@megatron.ietf.org; Sat, 15 Jan 2005 19:11:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19249 for ; Sat, 15 Jan 2005 19:11:22 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpyCg-000306-J0 for ipcdn@ietf.org; Sat, 15 Jan 2005 19:23:39 -0500 Received: from pop-a065d23.pas.sa.earthlink.net ([207.217.121.254]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Cpu96-0002bd-TW for ipcdn@ietf.org; Sat, 15 Jan 2005 15:03:41 -0500 Received: from h-68-165-173-58.snvacaid.dynamic.covad.net ([68.165.173.58] helo=oemcomputer) by pop-a065d23.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1Cpu95-0000ek-00 for ipcdn@ietf.org; Sat, 15 Jan 2005 12:03:39 -0800 Message-ID: <001b01c4fb3d$729d3a20$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn \(E-mail\)" Date: Sat, 15 Jan 2005 12:04:40 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 2.9 (++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [ipcdn] ifspeed definition in rfimibv2-12 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Hi - Current definition in rfimibv2-12 draft: ifSpeed Return the maximum channel throughput (not payload throughput) supported by the interface. The maximum throughput is calculated for the case where upstream channels are configured to maximize interface throughput. In RFC 2670 the definition reads: ifSpeed Return the speed of this upstream channel. The returned value is the raw bandwidth in bits/s of this interface, regarding the highest speed modulation profile that is defined. This is the symbol rate multiplied with the number of bits per symbol for this modulation profile. Is this a clarification or a technical change? If the latter, is it due to evolving technology or operational experience? (I'm just trying to understand.) Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Jan 17 11:27:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20606 for ; Mon, 17 Jan 2005 11:27:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqZy7-0000Bm-2L for ipcdn-archive@ietf.org; Mon, 17 Jan 2005 11:43:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqZgt-0007n1-3B; Mon, 17 Jan 2005 11:25:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqZYV-0005OZ-5i for ipcdn@megatron.ietf.org; Mon, 17 Jan 2005 11:16:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19568 for ; Mon, 17 Jan 2005 11:16:36 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqZnW-0008Mz-Sa for ipcdn@ietf.org; Mon, 17 Jan 2005 11:32:14 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j0HGFx1e011461; Mon, 17 Jan 2005 09:15:59 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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: [ipcdn] ifspeed definition in rfimibv2-12 Date: Mon, 17 Jan 2005 09:15:59 -0700 Message-ID: <5259D0D7419C6149B347837A2E64F46F06A4D9@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] ifspeed definition in rfimibv2-12 Thread-Index: AcT7YY35B5owtRFkT1uPX4zu4i22ewBSmj/A From: "Eduardo Cardona" To: "Randy Presuhn" , "Ipcdn (E-mail)" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable It is basically a evolution of the interface In RFC 2670 and Upstream channel (ifType 129) for Cable Modem Terminal System (CMTS) and Cable modem (CM) measure the raw data RFIv2.0 defines sub-interfaces (ifType =3D205) (logical channels )below the Upstream channel (ifType 129) for the CMTS only=20 CM in RFIv2.0 still uses one US interface (ifType 129) and can select one of the various logical channels (ifType 205) bundled in the CMTS Upstream Interface (ifType 129 ) The new definition tries to cover the maximum throughput for ifType 129 in terms of the bonding of logical channels (ifType 205) in the CMTS. Let me know if is clear Eduardo -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 Sent: Saturday, January 15, 2005 1:05 PM To: Ipcdn (E-mail) Subject: [ipcdn] ifspeed definition in rfimibv2-12 Hi - Current definition in rfimibv2-12 draft: ifSpeed Return the maximum channel throughput (not payload throughput) supported by the interface. The maximum throughput is calculated for the case where upstream channels are configured to maximize interface throughput. In RFC 2670 the definition reads: ifSpeed Return the speed of this upstream channel. The returned value is the raw bandwidth in bits/s of this interface, regarding the highest speed modulation profile that is defined. This is the symbol rate multiplied with the number of bits per symbol for this modulation profile. Is this a clarification or a technical change? If the latter, is it due to evolving technology or operational experience? (I'm just trying to understand.) Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Jan 17 12:27:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25674 for ; Mon, 17 Jan 2005 12:27:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqatn-0001fY-Ki for ipcdn-archive@ietf.org; Mon, 17 Jan 2005 12:42:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqadi-0003ch-UD; Mon, 17 Jan 2005 12:26:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqaZz-0002qj-4z for ipcdn@megatron.ietf.org; Mon, 17 Jan 2005 12:22:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25135 for ; Mon, 17 Jan 2005 12:22:12 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqap4-0001WK-SV for ipcdn@ietf.org; Mon, 17 Jan 2005 12:37:51 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j0HHO7JD015968 for ; Mon, 17 Jan 2005 10:24:07 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id j0HHKofD007188 for ; Mon, 17 Jan 2005 11:20:51 -0600 Received: by ca25exm01 with Internet Mail Service (5.5.2657.72) id ; Mon, 17 Jan 2005 09:22:11 -0800 Message-ID: From: Beacham Gordon-CGB005 To: "'ipcdn@ietf.org'" Subject: RE: [ipcdn] IETF NCS Sig MIB Tone Table Date: Mon, 17 Jan 2005 09:22:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.4 (++) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1560257392==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 2.7 (++) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1560257392== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4FCB9.13EA5972" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4FCB9.13EA5972 Content-Type: text/plain Motorola agrees the alternative tone table structure suggested by Randy Presuhn is a satsifactory solution for simplifying the existing tone table definition. It also provides the flexibility for accomodating the missing functionality in this international MIB for handling embedded cadences and amplitude modulation for the international customers using the IETF signaling MIB. The comment on Japan does not make sense to me. It should be noted the amplitude modulation example proposed for Japan was generalized as there may be other operators that require the flexibility for amplitude modulated tones. Gordon * To: "Beacham Gordon-CGB005" < Gordon.Beacham at motorola.com>, sumanth at cablelabs.com * Subject: RE: [ipcdn] IETF NCS Sig MIB Tone Table * From: "Eugene Nechamkin" < enechamkin at broadcom.com> * Date: Tue, 11 Jan 2005 18:07:01 -0800 * Cc: ipcdn at ietf.org We believe the tone generation capabilities are getting overly complicated for the added benefit they are providing. Operators need to be able to easily fill these out and we may be getting into a situation where we create more problems than solutions. In addition, we believe the interpretation of E.180 below in the examples may not be correct. (In the Japan case, f1 is not modulated by f2, it is modulated by 16Hz). This needs to be reconsidered further to find an alternative which provides the necessary functionality in a less complicated way. As the solution does not seem to be obvious, some time for further dicussions is needed to come up with the reasonable approach. Eugene. _____ From: ipcdn-bounces at ietf.org [mailto:ipcdn-bounces at ietf.org] On Behalf Of Beacham Gordon-CGB005 Sent: Wednesday, January 05, 2005 8:23 AM To: 'ipcdn at ietf.org'; 'sumanth at cablelabs.com' Subject: [ipcdn] IETF NCS Sig MIB Tone Table <<>> ------_=_NextPart_001_01C4FCB9.13EA5972 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0NzkiIG5hbWU9R0VORVJBVE9S PjwvSEVBRD4NCjxCT0RZPg0KPERJVj48U1BBTiBjbGFzcz03NTIzNzMyMDAtMTIwMTIwMDU+PFNQ QU4gY2xhc3M9ODcwNDIxNzE3LTE3MDEyMDA1Pg0KPFAgZGlyPWx0ciBhbGlnbj1sZWZ0PjxGT05U IGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+TW90b3JvbGEgYWdyZWVzIHRoZSANCmFs dGVybmF0aXZlIHRvbmUgdGFibGUgc3RydWN0dXJlIHN1Z2dlc3RlZCBieSBSYW5keSBQPFNQQU4g DQpjbGFzcz04NzA0MjE3MTctMTcwMTIwMDU+cmVzdWhuPC9TUEFOPiBpcyBhIHNhdHNpZmFjdG9y eSBzb2x1dGlvbiBmb3IgDQpzaW1wbGlmeWluZyB0aGUgZXhpc3RpbmcgdG9uZSB0YWJsZSBkZWZp bml0aW9uLiBJdCBhbHNvIHByb3ZpZGVzIHRoZSBmbGV4aWJpbGl0eSANCmZvciBhY2NvbW9kYXRp bmcgdGhlIG1pc3NpbmcgZnVuY3Rpb25hbGl0eSBpbiB0aGlzIGludGVybmF0aW9uYWwgTUlCIGZv ciANCmhhbmRsaW5nIGVtYmVkZGVkIGNhZGVuY2VzIGFuZCBhbXBsaXR1ZGUgbW9kdWxhdGlvbjxT UEFOIA0KY2xhc3M9ODcwNDIxNzE3LTE3MDEyMDA1PiBmb3IgdGhlIGludGVybmF0aW9uYWwgY3Vz dG9tZXJzIHVzaW5nIHRoZSBJRVRGIA0Kc2lnbmFsaW5nIE1JQjwvU1BBTj4uPC9GT05UPjwvUD4N CjxQIGRpcj1sdHIgYWxpZ249bGVmdD48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIGNvbG9yPSMwMDAw ZmY+PEZPTlQgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9ODcwNDIxNzE3LTE3MDEyMDA1PlRoZSBjb21t ZW50IG9uIEphcGFuIGRvZXMgbm90IG1ha2Ugc2Vuc2UgdG8gbWUuIA0KPC9TUEFOPkl0IHNob3Vs ZCBiZSBub3RlZCB0aGUgYW1wbGl0dWRlIG1vZHVsYXRpb24gZXhhbXBsZSBwcm9wb3NlZCBmb3Ig SmFwYW4gDQp3YXMgZ2VuZXJhbGl6ZWQgYXMgdGhlcmUgbWF5IGJlIG90aGVyIG9wZXJhdG9ycyB0 aGF0IHJlcXVpcmUgdGhlIGZsZXhpYmlsaXR5IGZvciANCmFtcGxpdHVkZSBtb2R1bGF0ZWQgdG9u ZXMuPC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9QPg0KPFAgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFO IGNsYXNzPTg3MDQyMTcxNy0xNzAxMjAwNT48Rk9OVCBmYWNlPUFyaWFsIA0KY29sb3I9IzAwMDBm ZiBzaXplPTI+R29yZG9uPC9GT05UPjwvU1BBTj48L1A+PEZPTlQgY29sb3I9IzAwMDBmZiBzaXpl PTI+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD4NCjxMST48Rk9OVCBmYWNlPUFyaWFsPjxFTT5U bzwvRU0+OiAiQmVhY2hhbSBHb3Jkb24tQ0dCMDA1IiAmbHQ7PC9GT05UPjxBIA0KaHJlZj0ibWFp bHRvOkdvcmRvbi5CZWFjaGFtQERPTUFJTi5ISURERU4iPjxGT05UIGZhY2U9QXJpYWw+R29yZG9u LkJlYWNoYW0gYXQgDQptb3Rvcm9sYS5jb208L0ZPTlQ+PC9BPjxGT05UIGZhY2U9QXJpYWw+Jmd0 OywgPC9GT05UPjxBIA0KaHJlZj0ibWFpbHRvOnN1bWFudGhARE9NQUlOLkhJRERFTiI+PEZPTlQg ZmFjZT1BcmlhbD5zdW1hbnRoIGF0IA0KY2FibGVsYWJzLmNvbTwvRk9OVD48L0E+PEZPTlQgZmFj ZT1BcmlhbD4gPC9GT05UPjwvTEk+PC9ESVY+DQo8TEk+PEZPTlQgZmFjZT1BcmlhbD48RU0+U3Vi amVjdDwvRU0+OiBSRTogW2lwY2RuXSBJRVRGIE5DUyBTaWcgTUlCIFRvbmUgVGFibGUgDQo8L0ZP TlQ+DQo8TEk+PEZPTlQgZmFjZT1BcmlhbD48RU0+RnJvbTwvRU0+OiAiRXVnZW5lIE5lY2hhbWtp biIgJmx0OzwvRk9OVD48QSANCmhyZWY9Im1haWx0bzplbmVjaGFta2luQERPTUFJTi5ISURERU4i PjxGT05UIGZhY2U9QXJpYWw+ZW5lY2hhbWtpbiBhdCANCmJyb2FkY29tLmNvbTwvRk9OVD48L0E+ PEZPTlQgZmFjZT1BcmlhbD4mZ3Q7IDwvRk9OVD4NCjxMST48Rk9OVCBmYWNlPUFyaWFsPjxFTT5E YXRlPC9FTT46IFR1ZSwgMTEgSmFuIDIwMDUgMTg6MDc6MDEgLTA4MDAgPC9GT05UPg0KPExJPjxG T05UIGZhY2U9QXJpYWw+PEVNPkNjPC9FTT46IDwvRk9OVD48QSANCmhyZWY9Im1haWx0bzppcGNk bkBET01BSU4uSElEREVOIj48Rk9OVCBmYWNlPUFyaWFsPmlwY2RuIGF0IA0KaWV0Zi5vcmc8L0ZP TlQ+PC9BPjxGT05UIGZhY2U9QXJpYWw+IDwvRk9OVD48L0xJPjwvRk9OVD48L1NQQU4+PC9TUEFO PjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjxTUEFOIGNsYXNzPTc1MjM3MzIwMC0xMjAx MjAwNT48U1BBTiANCmNsYXNzPTg3MDQyMTcxNy0xNzAxMjAwNT48Rk9OVCBjb2xvcj0jMDAwMGZm IA0Kc2l6ZT0yPjwvRk9OVD48L1NQQU4+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT1BcmlhbD48U1BBTiBjbGFzcz03NTIzNzMyMDAtMTIwMTIwMDU+PEZPTlQgY29s b3I9IzAwMDBmZiANCnNpemU9Mj5XZSBiZWxpZXZlIHRoZSB0b25lIGdlbmVyYXRpb24gY2FwYWJp bGl0aWVzIGFyZSBnZXR0aW5nIG92ZXJseSANCmNvbXBsaWNhdGVkIGZvciB0aGUgYWRkZWQgYmVu ZWZpdCB0aGV5IGFyZSBwcm92aWRpbmcuIE9wZXJhdG9ycyBuZWVkIHRvIGJlIGFibGUgDQp0byBl YXNpbHkgZmlsbCB0aGVzZSBvdXQgYW5kIHdlIG1heSBiZSBnZXR0aW5nIGludG8gYSBzaXR1YXRp b24gd2hlcmUgd2UgY3JlYXRlIA0KbW9yZSBwcm9ibGVtcyB0aGFuIHNvbHV0aW9ucy48L0ZPTlQ+ PC9TUEFOPjwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NzUyMzcz MjAwLTEyMDEyMDA1PjxGT05UIGNvbG9yPSMwMDAwZmYgDQpzaXplPTI+PC9GT05UPjwvU1BBTj4m bmJzcDs8L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTc1MjM3MzIw MC0xMjAxMjAwNT48Rk9OVCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPkluIGFkZGl0aW9uLCB3ZSBi ZWxpZXZlIHRoZSBpbnRlcnByZXRhdGlvbiBvZiBFLjE4MCBiZWxvdyBpbiB0aGUgZXhhbXBsZXMg DQptYXkgbm90IGJlIGNvcnJlY3QuIChJbiB0aGUgSmFwYW4gY2FzZSwgZjEgaXMgbm90IG1vZHVs YXRlZCBieSBmMiwgaXQgaXMgDQptb2R1bGF0ZWQgYnkgMTZIeikuPC9GT05UPjwvU1BBTj48L0RJ Vj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTc1MjM3MzIwMC0xMjAxMjAw NT48Rk9OVCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+ DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz03NTIzNzMyMDAtMTIwMTIwMDU+ PEZPTlQgY29sb3I9IzAwMDBmZj48Rk9OVCANCnNpemU9Mj5UaGlzIG5lZWRzIHRvIGJlIHJlY29u c2lkZXJlZCBmdXJ0aGVyPFNQQU4gY2xhc3M9NzA0MjI1NzAxLTEyMDEyMDA1PiB0byANCmZpbmQg PC9TUEFOPmFuIGFsdGVybmF0aXZlJm5ic3A7PFNQQU4gY2xhc3M9NzA0MjI1NzAxLTEyMDEyMDA1 PndoaWNoIA0KPC9TUEFOPnByb3ZpZGVzIHRoZSBuZWNlc3NhcnkgZnVuY3Rpb25hbGl0eSBpbiBh IGxlc3MgY29tcGxpY2F0ZWQmbmJzcDs8U1BBTiANCmNsYXNzPTcwNDIyNTcwMS0xMjAxMjAwNT53 YXk8L1NQQU4+LjxTUEFOIGNsYXNzPTcwNDIyNTcwMS0xMjAxMjAwNT4gQXMgdGhlIA0Kc29sdXRp b24gZG9lcyBub3Qgc2VlbSB0byBiZSBvYnZpb3VzLCBzb21lIHRpbWUgZm9yIGZ1cnRoZXIgZGlj dXNzaW9ucyBpcyANCm5lZWRlZCZuYnNwO3RvIGNvbWUgdXAgd2l0aCB0aGUmbmJzcDtyZWFzb25h YmxlIGFwcHJvYWNoLiANCjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVYg ZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTc1MjM3MzIwMC0xMjAxMjAwNT48Rk9OVCBj b2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWIGRp cj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz03NTIzNzMyMDAtMTIwMTIwMDU+PFNQQU4gDQpj bGFzcz03MDQyMjU3MDEtMTIwMTIwMDU+PEZPTlQgY29sb3I9IzAwMDBmZiANCnNpemU9Mj5FdWdl bmUuPC9GT05UPjwvU1BBTj48L1NQQU4+PC9ESVY+DQo8RElWPjxCUj48L0RJVj4NCjxESVYgY2xh c3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgbGFuZz1lbi11cyBkaXI9bHRyIGFsaWduPWxlZnQ+PEZP TlQgc2l6ZT0yPg0KPEhSIHRhYkluZGV4PS0xPg0KPC9GT05UPjxGT05UIHNpemU9Mj48Rk9OVCBm YWNlPVRhaG9tYT48Qj5Gcm9tOjwvQj4gaXBjZG4tYm91bmNlcyBhdCBpZXRmLm9yZyANClttYWls dG86aXBjZG4tYm91bmNlcyBhdCBpZXRmLm9yZ10gPEI+T24gQmVoYWxmIE9mIDwvQj5CZWFjaGFt IA0KR29yZG9uLUNHQjAwNTxCUj48Qj5TZW50OjwvQj4gV2VkbmVzZGF5LCBKYW51YXJ5IDA1LCAy MDA1IDg6MjMgQU08QlI+PEI+VG86PC9CPiANCidpcGNkbiBhdCBpZXRmLm9yZyc7ICdzdW1hbnRo IGF0IGNhYmxlbGFicy5jb20nPEJSPjxCPlN1YmplY3Q6PC9CPiBbaXBjZG5dIElFVEYgDQpOQ1Mg U2lnIE1JQiBUb25lIFRhYmxlPEJSPjwvRk9OVD48QlI+PFNQQU4gDQpjbGFzcz04NzA0MjE3MTct MTcwMTIwMDU+Jmx0OyZsdDsmbHQ7c25pcCZndDsmZ3Q7Jmd0OzwvU1BBTj48L0ZPTlQ+PC9ESVY+ PC9GT05UPjwvQk9EWT48L0hUTUw+DQo= ------_=_NextPart_001_01C4FCB9.13EA5972-- --===============1560257392== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============1560257392==-- From ipcdn-bounces@ietf.org Mon Jan 17 17:35:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01168 for ; Mon, 17 Jan 2005 17:35:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqfie-0004N5-CV for ipcdn-archive@ietf.org; Mon, 17 Jan 2005 17:51:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqfRu-0003au-7I; Mon, 17 Jan 2005 17:34:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqfQ4-00035W-Ad for ipcdn@megatron.ietf.org; Mon, 17 Jan 2005 17:32:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00865 for ; Mon, 17 Jan 2005 17:32:16 -0500 (EST) Received: from pop-a065d05.pas.sa.earthlink.net ([207.217.121.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqffC-0004GN-AB for ipcdn@ietf.org; Mon, 17 Jan 2005 17:47:58 -0500 Received: from h-66-167-205-141.snvacaid.dynamic.covad.net ([66.167.205.141] helo=oemcomputer) by pop-a065d05.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CqfQ0-0003EE-00 for ipcdn@ietf.org; Mon, 17 Jan 2005 14:32:17 -0800 Message-ID: <012701c4fce4$8db7ea00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <24CDBA67F085904999751B3C4F9E8C0B01E76CFC@NT-RMNA-0740.brcm.ad.broadcom.com> Subject: Re: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number ofques tions Date: Mon, 17 Jan 2005 14:33:21 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Hi - > From: "Eugene Nechamkin" > To: "Randy Presuhn" ; > Sent: Friday, January 14, 2005 2:41 PM > Subject: RE: [ipcdn] [pkt-prov] MTA MIB Error OID table - a number ofques tions ... > pktcMtaDevErrorOid OBJECT-TYPE > object instance will contain the human readable string of > '.1.3.6.1.2.1.XXX.1.1.6.0'. Get rid of the leading "." ... > For example, if the value of an OID in the configuration > file was interpreted by the MTA as being .1.2.3.4.5, and Get rid of the leading "." ... > representation of the pktcMtaDevErrorsTooManyErrs object, > i.e. the string '.1.3.6.1.2.1.XXX.1.1.4.1.0'. Get rid of the leading "." ... > pktcMtaDevErrorValue OBJECT-TYPE ... > interpreted by the MTA as being .1.2.3.4.5, and the MTA > cannot recognize this OID as a valid one, then this > pktcMtaDevErrorValue object instance will contain human > readable (string) representation of value '.1.2.3.4.5'. Get rid of both leading "." characters. ... > representation of the pktcMtaDevErrorsTooManyErrs object, > i.e. the string '.1.3.6.1.2.1.XXX.1.1.4.1.0'. ... Get rid of the leading "." The grammar for the dotted decimal notation does not permit a leading dot. The following message explains it all: |Message-Id: <3.0.5.32.20000623121552.00955190@infidel.boolean.net> |X-Sender: guru@infidel.boolean.net |X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) |Date: Fri, 23 Jun 2000 12:15:52 -0700 |To: michaelm@NETSOL.COM |From: "Kurt D. Zeilenga" |Subject: Re: Where is the OID "dot convention" spelled out? |Cc: ietf@ietf.org |In-Reply-To: <20000622072720.B27587@bailey.dscga.com> |Mime-Version: 1.0 |Content-Type: text/plain; charset="us-ascii" |X-Loop: ietf@ietf.org |Status: RO | |See RFC 1778, 2.15: | Values of type objectIdentifierSyntax are encoded according to the | following BNF: | | ::= | '.' | | | ::= | | ::= | '.' | | In the above BNF, is the syntactic representation of an | object descriptor. When encoding values of type | objectIdentifierSyntax, the first encoding option should be used in | preference to the second, which should be used in preference to the | third wherever possible. That is, in encoding object identifiers, | object descriptors (where assigned and known by the implementation) | should be used in preference to numeric oids to the greatest extent | possible. For example, in encoding the object identifier representing | an organizationName, the descriptor "organizationName" is preferable | to "ds.4.10", which is in turn preferable to the string "2.5.4.10". | |This was refined in RFC 2252, 4.1. In particular, it eliminates | the "ds.4.10" form. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Jan 19 00:21:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12045 for ; Wed, 19 Jan 2005 00:21:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cr8Wj-00080y-9C for ipcdn-archive@ietf.org; Wed, 19 Jan 2005 00:37:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cr8F6-0001yw-Pk; Wed, 19 Jan 2005 00:18:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cr8EA-0001Xu-5l for ipcdn@megatron.ietf.org; Wed, 19 Jan 2005 00:17:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11709 for ; Wed, 19 Jan 2005 00:17:54 -0500 (EST) Received: from mms-nat.broadcom.com ([63.70.210.58] helo=mms3.broadcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cr8TY-0007sl-N1 for ipcdn@ietf.org; Wed, 19 Jan 2005 00:33:53 -0500 Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Tue, 18 Jan 2005 21:16:43 -0800 X-Server-Uuid: 062D48FB-9769-4139-967C-478C67B5F9C9 Received: from nt-irva-0740.brcm.ad.broadcom.com ( nt-irva-0740.brcm.ad.broadcom.com [10.8.194.53]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id TAA10999 for ; Tue, 18 Jan 2005 19:08:44 -0800 (PST) Received: from nt-rmna-0740.brcm.ad.broadcom.com ([10.136.192.33]) by nt-irva-0740.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Jan 2005 19:08:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Jan 2005 19:08:35 -0800 Message-ID: <24CDBA67F085904999751B3C4F9E8C0B01E76D2D@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: pktcSigDevToneWholeToneRepeatCount description in draft-07 of the Signaling MIB Thread-Index: AcS322CGQqzjzPECTGKmCmMgb76oQAAIgbXwEXPcviA= From: "Eugene Nechamkin" To: ipcdn@ietf.org X-OriginalArrivalTime: 19 Jan 2005 03:08:44.0046 (UTC) FILETIME=[2F3A4AE0:01C4FDD4] X-WSS-ID: 6DF335B21W42986-1737-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] pktcSigDevToneWholeToneRepeatCount description in draft-07 of the Signaling MIB X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable The draft-07 of the Signaling MIB contains the following wording on the requirement for pktcSigDevToneWholeToneRepeatCount object: If the pktcSigDevToneType is callWaiting1-4, the=20 pktcSigDevToneWholeToneRepeatCount does not apply and MUST=20 be ignored on SNMP get/set operations. I have two issues here: 1. The MUST requirement above should be located in the description of the object which it refers to, i.e. it should be moved to the DESCRIPTION clause of the pktcSigDevToneWholeToneRepeatCount object. 2. The requirement above is not speific on what particulary it means "MUST be ignored on SNMP get/set operations". Does this mean that all SNMP GET/SET must be dropped as ifi they did not exist ? Does this mean that MTA must return "success" of the SNMP operation without actually doing anything ?=20 To address these concerns the following is proposed: 1. Change the DESCRIPTION of the pktcSigDevToneTable: " The Tone Table defines the various tone operations. Any=20 definition of the tones callWaiting1-4 in this table=20 should just contain the audible tone itself and NOT=20 contain the delay between tones or the tone repeat count.=20 The delay between tones or the repeat count is controlled=20 by the objects pktcNcsEndPntConfigCallWaitingDelay, and=20 pktcNcsEndPntConfigCallWaitingMaxRep. The MTA MUST=20 make sure that, after the provisioning cycle, the table is=20 fully populated (i.e., for each possible index, an entry=20 MUST be defined) using reasonable defaults for each row=20 that was not defined by the provisioning information.=20 Objects in this table do not persist across MTA reboots." =20 2. Change the DESCRIPTION of the pktcSigDevToneWholeToneRepeatCount: "This is the repeat count, which signifies how many times=20 to repeat the entire on-off sequence. Setting this object=20 may result in a tone duration longer or shorter than the=20 overall signal duration specified by the time out (TO)=20 object for a particular signal. If the repeat count results=20 in a longer tone duration than the signal duration=20 specified by the TO, the tone duration defined=20 by the TO object for a particular signal always represents=20 the overall signal duration for a tone. In this case, the=20 tone duration repeat count will not be fully exercised and=20 the desired tone duration will be truncated per the TO=20 setting. If the repeat count results in a shorter tone=20 duration than the signal duration specified by the TO, the=20 tone duration defined by the repeat count takes precedence=20 over the TO and will end the signal event. In this case,=20 the TO represents a time not to be exceeded for the signal.=20 It is recommended to ensure proper telephony signaling that=20 The TO duration setting should always be longer than the=20 desired repeat count time duration. =20 If the pktcSigDevToneType is set to either of the values=20 callWaiting1, .. callWaiting4, the=20 the MTA MUST return "noSuchInstance" for all SNMP SET/GET=20 operations on pktcSigDevToneWholeToneRepeatCount object." =20 Eugene. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Jan 19 01:23:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14932 for ; Wed, 19 Jan 2005 01:23:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cr9Ud-0000jg-Dl for ipcdn-archive@ietf.org; Wed, 19 Jan 2005 01:39:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cr9EA-0006nx-QC; Wed, 19 Jan 2005 01:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cr9BA-0005w7-8M for ipcdn@megatron.ietf.org; Wed, 19 Jan 2005 01:18:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14774 for ; Wed, 19 Jan 2005 01:18:55 -0500 (EST) Received: from pop-a065b10.pas.sa.earthlink.net ([207.217.121.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cr9QY-0000ex-Ub for ipcdn@ietf.org; Wed, 19 Jan 2005 01:34:52 -0500 Received: from h-66-167-205-170.snvacaid.dynamic.covad.net ([66.167.205.170] helo=oemcomputer) by pop-a065b10.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1Cr9B7-0003eb-00 for ipcdn@ietf.org; Tue, 18 Jan 2005 22:18:53 -0800 Message-ID: <000601c4fdee$c1ce8f00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <24CDBA67F085904999751B3C4F9E8C0B01E76D2D@NT-RMNA-0740.brcm.ad.broadcom.com> Subject: Re: [ipcdn] pktcSigDevToneWholeToneRepeatCount description in draft-07 of the Signaling MIB Date: Tue, 18 Jan 2005 22:18:56 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Hi - > From: "Eugene Nechamkin" > To: > Sent: Tuesday, January 18, 2005 7:08 PM > Subject: [ipcdn] pktcSigDevToneWholeToneRepeatCount description in draft-07 of the Signaling MIB ... > 2. Change the DESCRIPTION of the pktcSigDevToneWholeToneRepeatCount: ... > If the pktcSigDevToneType is set to either of the values > callWaiting1, .. callWaiting4, the > the MTA MUST return "noSuchInstance" for all SNMP SET/GET > operations on pktcSigDevToneWholeToneRepeatCount object." ... This can be messy to implement correctly, particularly when one considers how getNext and getBulk work. As an alternative, I'd suggest: | If the pktcSigDevToneType is set to either of the values | callWaiting1 or callWaiting4, then the value of the | pktcSigDevToneWholeToneRepeatCount object has no | effect on the tone." Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Jan 20 03:44:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06381 for ; Thu, 20 Jan 2005 03:44:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrYAo-0007eC-UW for ipcdn-archive@ietf.org; Thu, 20 Jan 2005 04:00:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrXtD-0001Xq-AR; Thu, 20 Jan 2005 03:42:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrXsW-0001QN-HR for ipcdn@megatron.ietf.org; Thu, 20 Jan 2005 03:41:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06243 for ; Thu, 20 Jan 2005 03:41:18 -0500 (EST) Received: from poros.telenet-ops.be ([195.130.132.44]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrY88-0007aV-Jm for ipcdn@ietf.org; Thu, 20 Jan 2005 03:57:29 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by poros.telenet-ops.be (Postfix) with SMTP id 62D7C3BC253 for ; Thu, 20 Jan 2005 09:41:12 +0100 (MET) Received: from tcomlabs.com (dD5E00656.access.telenet.be [213.224.6.86]) by poros.telenet-ops.be (Postfix) with ESMTP id 4AB3F3BC221 for ; Thu, 20 Jan 2005 09:41:12 +0100 (MET) Received: (qmail 20561 invoked from network); 20 Jan 2005 09:41:06 +0100 Received: from localhost (HELO gateway) (127.0.0.1) by localhost with SMTP; 20 Jan 2005 09:41:06 +0100 Received: from ([10.5.5.72]) by gateway.tcomlabs.com (MailMonitor for SMTP v1.2.2 ) ; Thu, 20 Jan 2005 09:41:04 +0100 (CET) From: "David De Reu" To: Subject: RE: [ipcdn] pktcSigDevToneWholeToneRepeatCount description indraft-07 of the Signaling MIB Date: Thu, 20 Jan 2005 09:41:04 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <000601c4fdee$c1ce8f00$7f1afea9@oemcomputer> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Hi all, > ... > This can be messy to implement correctly, particularly when one considers > how getNext and getBulk work. As an alternative, I'd suggest: > > | If the pktcSigDevToneType is set to either of the values > | callWaiting1 or callWaiting4, then the value of the > | pktcSigDevToneWholeToneRepeatCount object has no > | effect on the tone." Sounds like a good idea. Just one little thing: this applies to callWaiting1-4, which includes ...2 and ...3. Being a little explicit doesn't harm, so: If the pktcSigDevToneType is set to either of the values callWaiting1, callWaiting2, callWaiting3 or callWaiting4, then the value of the pktcSigDevToneWholeToneRepeatCount object has no effect on the tone. >From an SNMP point of view, would this wording require that the MTA has to store the value, without using it, or does this allow the MTA not even to store a new value? Regards, David _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Jan 20 11:22:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10822 for ; Thu, 20 Jan 2005 11:22:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrfKz-0002eu-4W for ipcdn-archive@ietf.org; Thu, 20 Jan 2005 11:39:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Creyw-0007xC-8f; Thu, 20 Jan 2005 11:16:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Creox-00069N-GL for ipcdn@megatron.ietf.org; Thu, 20 Jan 2005 11:06:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09513 for ; Thu, 20 Jan 2005 11:06:05 -0500 (EST) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crf4e-0002Ao-6U for ipcdn@ietf.org; Thu, 20 Jan 2005 11:22:21 -0500 Received: from h-69-3-91-39.snvacaid.dynamic.covad.net ([69.3.91.39] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1Creos-0006cl-00 for ipcdn@ietf.org; Thu, 20 Jan 2005 08:06:02 -0800 Message-ID: <005601c4ff09$f383b4a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [ipcdn] pktcSigDevToneWholeToneRepeatCount description indraft-07of the Signaling MIB Date: Thu, 20 Jan 2005 08:06:07 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Hi - > From: "David De Reu" > To: > Sent: Thursday, January 20, 2005 12:41 AM > Subject: RE: [ipcdn] pktcSigDevToneWholeToneRepeatCount description indraft-07of the Signaling MIB > > Hi all, > > > ... > > This can be messy to implement correctly, particularly when one considers > > how getNext and getBulk work. As an alternative, I'd suggest: > > > > | If the pktcSigDevToneType is set to either of the values > > | callWaiting1 or callWaiting4, then the value of the > > | pktcSigDevToneWholeToneRepeatCount object has no > > | effect on the tone." > > Sounds like a good idea. Just one little thing: this applies to > callWaiting1-4, which includes ...2 and ...3. Being a little explicit > doesn't harm, so: > > If the pktcSigDevToneType is set to either of the values > callWaiting1, callWaiting2, callWaiting3 or callWaiting4, > then the value of the pktcSigDevToneWholeToneRepeatCount > object has no effect on the tone. Thanks for the correction. The "either" language in the original proposal tripped me up. My bad. :-) Perhaps "either" should be "any" in this case? > From an SNMP point of view, would this wording require that the MTA > has to store the value, without using it, or does this allow the MTA > not even to store a new value? ... >From an implementor / onetime toolkit vendor perspective, it's simpler to store and ignore, which is what default access methods would do. Not storing a value would require a non-default access method to be written, since the access method would need conditional logic to decide whether it could skip storing the value. Also, from a testing perspective, if MTAs are permitted to disregard the value supplied in a set-request, then the value returned by a get-request is not well defined, and that would not be good. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Jan 20 13:56:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24392 for ; Thu, 20 Jan 2005 13:56:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrhjG-0006uX-2y for ipcdn-archive@ietf.org; Thu, 20 Jan 2005 14:12:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrhKq-0001TV-GC; Thu, 20 Jan 2005 13:47:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrhCG-0008Ei-TM for ipcdn@megatron.ietf.org; Thu, 20 Jan 2005 13:38:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23213 for ; Thu, 20 Jan 2005 13:38:17 -0500 (EST) Received: from mms-nat.broadcom.com ([63.70.210.58] helo=mms1.broadcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrhRy-0006Rs-AF for ipcdn@ietf.org; Thu, 20 Jan 2005 13:54:35 -0500 Received: from 63.70.210.1 by mms1.broadcom.com with SMTP (Broadcom SMTP Relay (MMS v5.6.0)); Thu, 20 Jan 2005 10:37:35 -0800 X-Server-Uuid: 97B92932-364A-4474-92D6-5CFE9C59AD14 Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Thu, 20 Jan 2005 10:37:31 -0800 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AHM27571; Thu, 20 Jan 2005 10:37:18 -0800 (PST) Received: from nt-irva-0740.brcm.ad.broadcom.com ( nt-irva-0740.brcm.ad.broadcom.com [10.8.194.53]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id KAA19625; Thu, 20 Jan 2005 10:37:18 -0800 (PST) Received: from nt-rmna-0740.brcm.ad.broadcom.com ([10.136.192.33]) by nt-irva-0740.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Jan 2005 10:37:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] pktcSigDevToneWholeToneRepeatCount description indraft-07 of the Signaling MIB Date: Thu, 20 Jan 2005 10:37:16 -0800 Message-ID: <24CDBA67F085904999751B3C4F9E8C0B01E76D49@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] pktcSigDevToneWholeToneRepeatCount description indraft-07 of the Signaling MIB Thread-Index: AcT+zKHWBDR8vxZpSVO1qvRRtiOpcwAUFKQg From: "Eugene Nechamkin" To: "David De Reu" , ipcdn@ietf.org X-OriginalArrivalTime: 20 Jan 2005 18:37:18.0015 (UTC) FILETIME=[11C10CF0:01C4FF1F] X-WSS-ID: 6DF125E51BW449018-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable > | If the pktcSigDevToneType is set to either of the values > | callWaiting1 or callWaiting4, then the value of the > | pktcSigDevToneWholeToneRepeatCount object has no > | effect on the tone." Though this approach addresses one concern on how the value in this object affects the tone generation functionality of the MTA, it does not address the SNMP behavior of the MTA, and also does not provide for the unamigous feedback to the NMS. The following might address all of those: If the pktcSigDevToneType is set to any of the values callWaiting1, callWaiting2, callWaiting3 or callWaiting4, then the value of the pktcSigDevToneWholeToneRepeatCount object has no effect on the tone. In this case, the MTA=20 MUST return "noSuchInstance" for all SNMP SET operations,=20 and "noError" for all SNMP GET operations on pktcSigDevToneWholeToneRepeatCount object. Eugene. -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of David De Reu Sent: Thursday, January 20, 2005 12:41 AM To: ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevToneWholeToneRepeatCount description indraft-07 of the Signaling MIB Hi all, > ... > This can be messy to implement correctly, particularly when one=20 > considers how getNext and getBulk work. As an alternative, I'd suggest: >=20 > | If the pktcSigDevToneType is set to either of the values > | callWaiting1 or callWaiting4, then the value of the > | pktcSigDevToneWholeToneRepeatCount object has no > | effect on the tone." Sounds like a good idea. Just one little thing: this applies to callWaiting1-4, which includes ...2 and ...3. Being a little explicit doesn't harm, so: If the pktcSigDevToneType is set to either of the values callWaiting1, callWaiting2, callWaiting3 or callWaiting4, then the value of the pktcSigDevToneWholeToneRepeatCount object has no effect on the tone. >From an SNMP point of view, would this wording require that the MTA has to store the value, without using it, or does this allow the MTA not even to store a new value? Regards, David _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Jan 20 17:22:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18650 for ; Thu, 20 Jan 2005 17:22:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrkxB-0006Ib-Jz for ipcdn-archive@ietf.org; Thu, 20 Jan 2005 17:39:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrkYS-0000aw-Rz; Thu, 20 Jan 2005 17:13:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crk6l-0006sS-Vt for ipcdn@megatron.ietf.org; Thu, 20 Jan 2005 16:44:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11689 for ; Thu, 20 Jan 2005 16:44:49 -0500 (EST) Received: from pop-a065c32.pas.sa.earthlink.net ([207.217.121.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrkMW-00040k-Hb for ipcdn@ietf.org; Thu, 20 Jan 2005 17:01:08 -0500 Received: from h-69-3-24-225.snvacaid.dynamic.covad.net ([69.3.24.225] helo=oemcomputer) by pop-a065c32.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1Crk6i-000435-00 for ipcdn@ietf.org; Thu, 20 Jan 2005 13:44:48 -0800 Message-ID: <002401c4ff39$3ee60fe0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <24CDBA67F085904999751B3C4F9E8C0B01E76D49@NT-RMNA-0740.brcm.ad.broadcom.com> Subject: Re: [ipcdn] pktcSigDevToneWholeToneRepeatCount descriptionindraft-07 of the Signaling MIB Date: Thu, 20 Jan 2005 13:44:40 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Hi - > From: "Eugene Nechamkin" > To: "David De Reu" ; > Sent: Thursday, January 20, 2005 10:37 AM > Subject: RE: [ipcdn] pktcSigDevToneWholeToneRepeatCount descriptionindraft-07 of the Signaling MIB > > > | If the pktcSigDevToneType is set to either of the values > | callWaiting1 or callWaiting4, then the value of the > | pktcSigDevToneWholeToneRepeatCount object has no > | effect on the tone." > > Though this approach addresses one concern on how the value in this > object affects the tone generation functionality of the MTA, it does not > address the SNMP behavior of the MTA, and also does not provide for the > unamigous feedback to the NMS. How is it ambiguous? > The following might address all of those: > > If the pktcSigDevToneType is set to any of the values > callWaiting1, callWaiting2, callWaiting3 or callWaiting4, > then the value of the pktcSigDevToneWholeToneRepeatCount > object has no effect on the tone. In this case, the MTA > MUST return "noSuchInstance" for all SNMP SET operations, > and "noError" for all SNMP GET operations on > pktcSigDevToneWholeToneRepeatCount object. ... I think this counter-proposal has some problems. 1) it would violate SNMP protocol to return noError if, for example, VACM prohibits access to the object of the get-request. 2) returning noSuchInstance in response to a set-request violates SNMP protocol. See RFC 3416 section 4.2.5, which spells out the permissible responses. 3) it's even more complicated for the implementor than the original proposal, requiring "custom" access methods for both get and set requests, as well as special-case logic for get-next and get-bulk, since this column would have to be processed differently from the others. 4) it doesn't address the behaviour when the value of pktcSigDevToneType is changed. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Jan 20 18:37:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27752 for ; Thu, 20 Jan 2005 18:37:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crm7o-0000PK-Ie for ipcdn-archive@ietf.org; Thu, 20 Jan 2005 18:54:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrlqT-0007G8-Fn; Thu, 20 Jan 2005 18:36:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrlmM-0006SU-Ge for ipcdn@megatron.ietf.org; Thu, 20 Jan 2005 18:31:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27064 for ; Thu, 20 Jan 2005 18:31:51 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crm27-0000E0-ST for ipcdn@ietf.org; Thu, 20 Jan 2005 18:48:12 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j0KNVH1e012176; Thu, 20 Jan 2005 16:31:17 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt Date: Thu, 20 Jan 2005 16:31:17 -0700 Message-ID: Thread-Topic: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt Thread-Index: AcR6thTZfq+7VKivT3+3uhPKgFAc5B9gDNXgAcRWksA= From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc Content-Transfer-Encoding: quoted-printable Cc: "Wijnen, Bert \(Bert\)" , enechamkin@broadcom.com X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8 Content-Transfer-Encoding: quoted-printable Just a minor editorial change in our informative text to explain why the = pktcMtaDevErrorOid is of type SnmpAdminString. : On Tuesday, January 11, 2005 at 4:47 PM, I had proposed: > "Note that the syntax of this object is SnmpAdminString > rather OBJECT IDENTIFIER because the object value is > provided by an operator in the MTA configuration file > in the form of a character string." Based on Eugene's comment, the newly proposed text is: Note that the syntax of this object is SnmpAdminString rather OBJECT IDENTIFIER because the object value may not be a valid OID due to human or configuration tool encoding errors. Let us know if this new proposed text is an issue. Jean-Fran=E7ois=20 > -----Original Message----- > From: Jean-Francois Mule=20 > Sent: Tuesday, January 11, 2005 4:47 PM > To: Dave Thaler; ipcdn@ietf.org > Cc: randy_presuhn@mindspring.com; Wijnen, Bert (Bert);=20 > enechamkin@broadcom.com; C. M. Heard > Subject: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt >=20 >=20 > To close on one additional comment: > Dave wrote: > > 12) pktcMtaDevErrorOid, pktcMtaDevErrorValue, etc: > > why are OIDs of type SnmpAdminString rather than an > > OBJECT IDENTIFIER > > type/subtype? As is, the management station cannot do=20 > > simple things > > like expanding the OID into the defined string tokens=20 > in the MIB. >=20 > We discussed this point during the IETF IPCDN meeting #61,=20 > see proceedings at: =20 > >=20 > The meeting minutes recorded: > In the WG meeting, we had consensus that since the OID and its > value is provided in the MTA config file by an operator in the > form of a character string, it is better to leave the syntax > as SnmpAdminString rather than OBJECT IDENTIFIER. It was also > requested that the above explanation be mentioned in the doc. >=20 > So, the resolution is: > - no object syntax change > - change the description of the pktcMtaDevErrorOid to=20 > indicate the following: > "Note that the syntax of this object is SnmpAdminString > rather OBJECT IDENTIFIER because the object value is > provided by an operator in the MTA configuration file > in the form of a character string." > - after more review of the pktcMtaDevErrorValue object,=20 > we do not believe the above text should be added to its=20 > description as this pktcMtaDevErrorValue object may contain=20 > all kinds of object values in the case where the MTA can=20 > recognize the OID but cannot interpret the given value. >=20 > Proposed text changes: > pktcMtaDevErrorOid OBJECT-TYPE =20 > SYNTAX SnmpAdminString > MAX-ACCESS read-only > STATUS current > DESCRIPTION=20 > " This object contains a human readable representation > (character string) of the OID corresponding to the > configuration file parameter that caused the particular > error. > For example, if the value of the pktcMtaDevEnabled object > in the configuration file caused an error, then this > object instance will contain the human readable string of > '.1.3.6.1.2.1.XXX.1.1.6.0'. > ************************************************************ > * NOTES TO RFC Editor (to be removed prior to publication) * > * Please replace XXX with the IANA-assigned number under * > * mib-2. * > ************************************************************ >=20 > If the MTA generated an error because it was not able=20 > to recognize a particular OID, then this object=20 > instance would contain an empty value (zero-length > string). > For example, if the value of an OID in the configuration=20 > file was interpreted by the MTA as being .1.2.3.4.5, and=20 > the MTA was not able to recognize this OID as a valid one, > this object instance will contain a zero-length string. > Note that the syntax of this object is SnmpAdminString > rather OBJECT IDENTIFIER because the object value is > provided by an operator in the MTA configuration file > in the form of a character string." > ::=3D {pktcMtaDevErrorOidsEntry 2} >=20 > Let us know if this change is acceptable or else, feel free=20 > to propose text improvements or suggestions. >=20 > Thanks, >=20 > Jean-Fran=E7ois=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Dave Thaler [mailto:dthaler@windows.microsoft.com] > > Sent: Thursday, August 05, 2004 12:33 AM > > To: enechamkin@broadcom.com; Jean-Francois Mule > > Cc: ipcdn@ietf.org; Wijnen, Bert (Bert);=20 > > randy_presuhn@mindspring.com; C. M. Heard > > Subject: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt > >=20 > >=20 > > Here's my MIB Doctor review of this document and what I > > believe MUST/SHOULD/MAY be fixed. > >=20 > > MUST fix > > -------- > > 1) There is no IANA Considerations section, and this is now > > required in the > > new guidelines. The draft needs something like (based on=20 > > the template=20 > > in the guidelines): > >=20 > > 9. IANA Considerations > >=20 > > The MIB module in this document uses the following > > IANA-assigned > > OBJECT IDENTIFIER values recorded in the SMI Numbers=20 > registry: > >=20 > > Descriptor OBJECT IDENTIFIER value > > ---------- ----------------------- > > pktcMtaMib { mib-2 XXX } > >=20 > > Editor's Note (to be removed prior to publication): > > the IANA is > > requested to assign a value for "XXX" under the 'mib-2' > > subtree and to record the assignment in the SMI=20 > > Numbers registry. > > When the assignment has been made, the RFC Editor is asked to > > replace "XXX" (here and in the MIB module) with the assigned > > value and to remove this note. > >=20 > > 2) The page header on pages 2-51 says July 2002 > >=20 > > 3) MIB Guidelines say > > If the module was developed by an IETF working group, then the > > ORGANIZATION clause MUST provide the full name of the > > working group > > ^^^^^^^^^ > >=20 > > The draft just uses the WG acronym: > > ORGANIZATION "IETF IPCDN Working Group " > >=20 > > 4) The LAST-UPDATED date predates the REVISION date: > > LAST-UPDATED "200406160000Z" -- June 16, 2004 > > REVISION "200407160000Z" > > ^ > >=20 > > 5) pktcMtaBasicSmtaCompliance contains > > MODULE DOCS-CABLE-DEVICE-MIB > > MANDATORY-GROUPS { > > docsDevSoftwareGroupV2 > > } > > but RFC2669 is not referenced as a normative reference > > and docsDevSoftwareGroupV2 isn't in there anyway, only > > docsDevSoftwareGroup. Is this blocked on the progression > > of another > > document containing this? Looks like this used to be in > > draft-ietf-ipcdn-device-mibv2-*.txt which has now expired. > >=20 > > 6) SEQUENCE element #4 `pktcMtaDevCmsSolicitedKeyTimeout' > > does not match > >=20 > > order of columnar objects under `pktcMtaDevCmsEntry'. > > Should swap the following two lines: > > pktcMtaDevCmsSolicitedKeyTimeout Unsigned32, > > pktcMtaDevCmsMaxClockSkew Unsigned32, > >=20 > > 7) pktcMtaDevProvisioningState has 'passWithWarning'=20 > (singular) in the > > enum, but 'passWithWarnings' (plural) twice in the DESCRIPTION. > > Also has 'failOtherReason' in the enum but 'failureOtherReason'=20 > > in the DESCRIPTION. > >=20 > > 8) The comment on page 29 refers to > > draft-ietf-ipcdn-pktc-signaling-02.txt > > This should be added to the references section of the doc. > > Also grammar error "Upper case must be use to" > > ^^^ > >=20 > > 9) Typo in DESCRIPTION of pktcMtaDevCmsKerbRealmName: > > realm table (pktcMtaDevRealmtable)." > > ^ capitalize > >=20 > > 10) The DESCRIPTION of pktcMtaDevRealmTgsGracePeriod has > > weird indentation, > > and includes weird characters (as do several other objects). > >=20 > > SHOULD fix > > ---------- > > 11) pktcMtaDevErrorOidIndex: say what happens after the=20 > value 1024 is=20 > > reached > >=20 > > 12) pktcMtaDevErrorOid, pktcMtaDevErrorValue, etc: > > why are OIDs of type SnmpAdminString rather than an > > OBJECT IDENTIFIER > > type/subtype? As is, the management station cannot do=20 > > simple things > > like expanding the OID into the defined string tokens=20 > in the MIB. > >=20 > > 13) pktcMtaDevServerDhcp1, pktcMtaDevServerDns1, etc: the > > DESCRIPTION of > >=20 > > these objects is worded as if the type is a string=20 > rather than an > > InetAddress (the "dotted" IP address, etc). Technically, > > there's no > > dots in the value, only in the displayed version of it. > >=20 > > 14) pktcMtaDevServerAddressType: what does it mean for this > > to be read-write > > but the dependent InetAddress fields to be read-only? =20 > I.e., what=20 > > happens to the latter immediately after the former is set? > >=20 > > MAY fix > > ------- > > 15) Consider defining a TC for kerberos realm names, since > > this is used by=20 > > multiple objects (pktcMtaDevProvKerbRealmName,=20 > > pktcMtaDevRealmName, > > and pktcMtaDevCmsKerbRealmName) and has special syntax=20 > > restrictions=20 > > (1..255 upper case ASCII chars)=20 > >=20 > > 16) The current conformance statements require read-write in > > implementations > > to be compliant. Is this intended? Since it currently=20 > > only supports > > ipv4, it doesn't seem useful to require read-write access to the > > InetAddressType objects. > >=20 > > 17) pktcMtaDevSwCurrentVers is redundant with sysDescr, so > > why is this=20 > > needed? The draft says: > > The data presented in this object MUST be > > identical to the software version information contained > > in the 'sysDescr' MIB object of the MTA. > >=20 > > 18) The MIB guidelines suggest using { pktcMtaMib 0 } for the=20 > > notification prefix. The draft currently requires two > > definitions: > >=20 > > pktcMtaNotificationPrefix OBJECT IDENTIFIER ::=3D { pktcMtaMib 2 = } > > pktcMtaNotification OBJECT IDENTIFIER ::=3D { > > pktcMtaNotificationPrefix 0 } > >=20 > > Is there a good reason for this? (e.g. already deployed > > implementations?) > >=20 > > 19) What is the expected behavior when reading > > pktcMtaDevRealmName and=20 > > pktcMtaDevRealmOrgName when the row is first created=20 > and they are=20 > > not set? (There's no DEFVAL, and the MIB doesn't say=20 > > they have to=20 > > be set in the initial createAndWait set.) > >=20 > > 20) draft-ietf-ipcdn-bpiplus-mib-12.txt is referenced, and is now > > draft-ietf-ipcdn-bpiplus-mib-13.txt > >=20 > > 21) The wording in section 8 varies marginally from the template. > >=20 > > Template: > > > Some of the readable objects in this MIB module (i.e., > > objects with a > > > MAX-ACCESS other than not-accessible) may be considered=20 > > sensitive or > > =20 > > Actual: > > > Some of the readable objects in this MIB module may be > > considered > > > sensitive or [...] > >=20 > >=20 > >=20 >=20 > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn >=20 >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Jan 20 19:08:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00008 for ; Thu, 20 Jan 2005 19:08:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crmb9-00016s-O4 for ipcdn-archive@ietf.org; Thu, 20 Jan 2005 19:24:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrmIE-00034Z-M0; Thu, 20 Jan 2005 19:04:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrmDH-0002Hq-31 for ipcdn@megatron.ietf.org; Thu, 20 Jan 2005 18:59:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29245 for ; Thu, 20 Jan 2005 18:59:39 -0500 (EST) Received: from mms-nat.broadcom.com ([63.70.210.58] helo=mms1.broadcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrmT2-0000u4-99 for ipcdn@ietf.org; Thu, 20 Jan 2005 19:16:00 -0500 Received: from 63.70.210.1 by mms1.broadcom.com with SMTP (Broadcom SMTP Relay (MMS v5.6.0)); Thu, 20 Jan 2005 15:58:16 -0800 X-Server-Uuid: 97B92932-364A-4474-92D6-5CFE9C59AD14 Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Thu, 20 Jan 2005 15:58:15 -0800 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AHN11142; Thu, 20 Jan 2005 15:58:11 -0800 (PST) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id PAA09718; Thu, 20 Jan 2005 15:58:10 -0800 (PST) Received: from nt-rmna-0740.brcm.ad.broadcom.com ([10.136.192.33]) by nt-irva-0741.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Jan 2005 15:58:10 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Jan 2005 15:58:08 -0800 Message-ID: <24CDBA67F085904999751B3C4F9E8C0B01E76D61@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: draft-ietf-ipcdn-pktc-mtamib-05 clarifications for pktcMtaDevProvConfigKey, pktcMtaDevProvConfigHash, and pktcMtaDevConfigFile Thread-Index: AcR6thTZfq+7VKivT3+3uhPKgFAc5B9gDNXgAcRWksAAAD0PAA== From: "Eugene Nechamkin" To: ipcdn@ietf.org X-OriginalArrivalTime: 20 Jan 2005 23:58:10.0454 (UTC) FILETIME=[E51A1B60:01C4FF4B] X-WSS-ID: 6DEE9A121BW505627-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: quoted-printable Cc: Jean-Francois Mule Subject: [ipcdn] draft-ietf-ipcdn-pktc-mtamib-05 clarifications for pktcMtaDevProvConfigKey, pktcMtaDevProvConfigHash, and pktcMtaDevConfigFile X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Content-Transfer-Encoding: quoted-printable 1. The current pktcMtaDevProvConfigKey object is described as follows: pktcMtaDevProvConfigKey OBJECT-TYPE=20 SYNTAX OCTET STRING (SIZE(0|8))=20 MAX-ACCESS read-write=20 STATUS current=20 DESCRIPTION=20 " This object contains the key used to encrypt/decrypt=20 the configuration file when secure SNMPv3 provisioning=20 is used.=20 It is sent to the MTA prior to sending the config file.=20 If the privacy algorithm is null, the length is 0. If=20 the privacy algorithm is DES, the length is 64 bits.=20 This object must not be used in non secure provisioning=20 mode.=20 In non secure provisioning modes, the MTA MUST return an=20 'inconsistentValue' in response to SNMP SET operations,=20 and, the MTA MUST return a 'genErr' error in response to=20 SNMP GET operations."=20 ::=3D { pktcMtaDevServer 10 } =20 As the PackeCable Security Specification does not allow the Encryption Key to be of '0' length and also requires the pktcMtaDevProvConfigKey to be sent to the MTA in one single PDU with other two objects (pktcMtaDevProvConfigHash, pktcMtaDevConfigFile), the 2nd paragraph of the description and SYNTAX clause are wrong. The following modification is proposed: pktcMtaDevProvConfigKey OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0|8)) MAX-ACCESS read-write STATUS current DESCRIPTION " This object contains the key used to encrypt/decrypt the configuration file when secure SNMPv3 provisioning is used. If configuration file is encrypted, this object MUST be=20 set in the MTA along with the pktcMtaDevProvConfigHash and pktcMtaDevConfigFile objects (in one SNMP PDU). The=20 privacy algorithm is DES, the key length is 64 bits. If=20 this object is set at any other Provisioning steps than=20 required by the Provisioning Specification or if this=20 object is set in a separate SNMP PDU, the MTA MUST return=20 'inconsistentValue' Error in SNMP Response. This object must not be used in non secure provisioning mode. In non secure provisioning modes, the MTA MUST return an 'inconsistentValue' in response to SNMP SET operations, and, the MTA MUST return a 'genErr' error in response to SNMP GET operations." REFERENCE " PacketCable MTA Device Provisioning Specification; PacketCable Security Specification." ::=3D { pktcMtaDevServer 10 }=20 2. Corresponding similar modifications for two other objects are also proposed: Existing description of the pktcMtaDevProvConfigHash object: " This object contains the hash value of the contents of the=20 configuration file.=20 If the authentication algorithm is MD5, the length is 128=20 bits. If the authentication algorithm is SHA-1, the length=20 is 160 bits. The hash calculation MUST follow the=20 requirements defined in the PacketCable Security=20 Specification.=20 When the MTA SNMP Enrollment mechanism is used, this=20 hash value is calculated and sent to the MTA prior=20 to sending the config file. This object value is then=20 provided by the Provisioning server via an SNMP=20 SET operation.=20 When the MTA SNMP Enrollment mechanism is not in use, the=20 hash value is provided in the configuration file itself=20 and it is also calculated by the MTA. This object value=20 MUST represent the hash value calculated by the MTA.=20 When the MTA SNMP Enrollment mechanism is not in use, the=20 MTA must reject all SNMP SET operations on this object and=20 return an 'inconsistentValue' error."=20 Proposed description of the pktcMtaDevProvConfigHash object: " This object contains the hash value of the contents of the configuration file. The authentication algorithm is SHA-1, the length is 160 bits. The hash calculation MUST follow the requirements defined in the PacketCable Security Specification. When the MTA SNMP Enrollment mechanism is used, this hash value is calculated and sent to the MTA prior to sending the config file. This object value is then provided by the Provisioning server via an SNMP SET operation. This object MUST be set to the MTA in the=20 same SNMP PDU which also sets the pktcMtaDevConfigFile and=20 (possibly) the pktcMtaDevProvConfigKey object. If this=20 object is set at any other Provisioning steps than=20 required by the Provisioning Specification or if this=20 object is set in a separate SNMP PDU, the MTA MUST return=20 'inconsistentValue' Error in SNMP Response. When the MTA SNMP Enrollment mechanism is not in use, the hash value is provided in the configuration file itself and it is also calculated by the MTA. This object value MUST represent the hash value calculated by the MTA. When the MTA SNMP Enrollment mechanism is not in use, the MTA must reject all SNMP SET operations on this object and return an 'inconsistentValue' error." Existing description of the pktcMtaDevConfigFile object: " This object specifies the MTA device configuration file=20 information, including the access method, the server name=20 and the configuration file name. The value of this object=20 is the Uniform Resource Locator (URL) of the configuration=20 file for TFTP or HTTP download.=20 If this object value is a TFTP URL, it must be formatted =20 as defined in RFC 3617.=20 If this object value is an HTTP URL, it must be formatted =20 as defined in RFC 2616.=20 If the MTA SNMP Enrollment mechanism is used, then the MTA=20 must download the file provided by the Provisioning Server=20 during provisioning via an SNMP SET on this object.=20 If the MTA SNMP Enrollment mechanism is not used, this=20 object MUST contain the URL value corresponding to the=20 'siaddr' and 'file' fields received in the DHCP ACK to=20 locate the configuration file: the 'siaddr' & 'file' =20 fields represents the host and file of the TFTP URL.=20 In this case, the MTA MUST return an=20 'inconsistentValue' error in response to SNMP SET =20 operations.=20 The MTA MUST return a zero-length string if the server=20 address (host part of the URL) is unknown."=20 Proposed description of the pktcMtaDevConfigFile object: " This object specifies the MTA device configuration file information, including the access method, the server name and the configuration file name. The value of this object is the Uniform Resource Locator (URL) of the configuration file for TFTP or HTTP download. If this object value is a TFTP URL, it must be formatted=20 as defined in RFC 3617. If this object value is an HTTP URL, it must be formatted=20 as defined in RFC 2616. If the MTA SNMP Enrollment mechanism is used, then the MTA must download the file provided by the Provisioning Server during provisioning via an SNMP SET on this object. This=20 object MUST be set in one SNMP PDU along with the=20 pktcMtaDevProvConfigHash object and, optionally, with the=20 pktcMtaDevProvConfigKey object. If this object is set on=20 any other Provisioning steps than required by the=20 Provisioning Specification or it is set in one SNMP PDU=20 without the pktcMtaDevProvConfigHash object being set by=20 the same SNMP PDU, the MTA MUST return an 'inconsistentValue' error in response to SNMP SET=20 operations. If the MTA SNMP Enrollment mechanism is not used, this object MUST contain the URL value corresponding to the 'siaddr' and 'file' fields received in the DHCP ACK to locate the configuration file: the 'siaddr' & 'file'=20 fields represents the host and file of the TFTP URL. In this case, the MTA MUST return an 'inconsistentValue' error in response to SNMP SET=20 operations. The MTA MUST return a zero-length string if the server address (host part of the URL) is unknown." Eugene. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Jan 20 19:20:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00985 for ; Thu, 20 Jan 2005 19:20:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crmne-0001PM-Ji for ipcdn-archive@ietf.org; Thu, 20 Jan 2005 19:37:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrmTy-0005pk-SQ; Thu, 20 Jan 2005 19:16:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrmP1-0004Mf-LV for ipcdn@megatron.ietf.org; Thu, 20 Jan 2005 19:11:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00474 for ; Thu, 20 Jan 2005 19:11:48 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crmel-0001CE-Kc for ipcdn@ietf.org; Thu, 20 Jan 2005 19:28:10 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j0L0BF1e020211; Thu, 20 Jan 2005 17:11:15 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Jan 2005 17:11:15 -0700 Message-ID: Thread-Topic: draft-ietf-ipcdn-pktc-mtamib-05 - SMI question for pktcMtaDevErrorsTooManyErrors Thread-Index: AcR6thTZfq+7VKivT3+3uhPKgFAc5B9gDNXgAcRWksAAAD0PAAABCuwA From: "Jean-Francois Mule" To: "Eugene Nechamkin" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] draft-ietf-ipcdn-pktc-mtamib-05 - SMI question for pktcMtaDevErrorsTooManyErrors X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: quoted-printable I like Bert's proposal to create an OID to deal with the = internationalization issue raised by Dave and Randy. See below, a quick = SMI question. Eugene integrated the comments and proposed the following text: pktcMtaDevErrorOid OBJECT-TYPE =20 SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION=20 " This object contains a human readable representation (character string) of the OID corresponding to the configuration file parameter that caused the particular error. For example, if the value of the pktcMtaDevEnabled object in the configuration file caused an error, then this object instance will contain the human readable string of '1.3.6.1.2.1.XXX.1.1.6.0'. -- ************************************************************ -- * NOTES TO RFC Editor (to be removed prior to publication) * -- * * -- * Please replace XXX with the IANA-assigned number under * -- * mib-2. * -- ************************************************************ If the MTA generated an error because it was not able=20 to recognize a particular OID, then this object=20 instance would contain an empty value (zero-length string). For example, if the value of an OID in the configuration=20 file was interpreted by the MTA as being .1.2.3.4.5, and=20 the MTA was not able to recognize this OID as a valid one, this object instance will contain a zero-length string. | If the numbers of errors in the configuration file exceeds=20 | 1024, then for all subsequent errors, the=20 | pktcMtaDevErrorOid of 1024th table's entry MUST contain=20 | a human readable representation of the=20 | pktcMtaDevErrorsTooManyErrors object, i.e. the string | '1.3.6.1.2.1.XXX.1.1.4.1.0'. -- ************************************************************ -- * NOTES TO RFC Editor (to be removed prior to publication) * -- * * -- * Please replace XXX with the IANA-assigned number under * -- * mib-2. * -- ************************************************************ Note that the syntax of this object is SnmpAdminString rather OBJECT IDENTIFIER because the object value may not be a valid OID due to human or configuration tool encoding errors." ::=3D {pktcMtaDevErrorOidsEntry 2} pktcMtaDevErrorValue OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION " This object contains the value of the OID corresponding to the configuration file parameter that caused the error. If the MTA cannot recognize the OID of the configuration parameter causing the error, then this object instance contains the OID itself as interpreted by the MTA in human readable representation. If the MTA can recognize the OID but generate an error due to a wrong value of the parameter, then the object instance contains the erroneous value of the parameter as read from the configuration file. In both cases, the value of this object must be represented in human readable form as a character string. For example, if the value of the pktcMtaDevEnabled object in the configuration file was 3 (invalid value), then the pktcMtaDevErrorValue object instance will contain the human readable (string) representation of value '3'. Similarly, if the OID in the configuration file has been interpreted by the MTA as being 1.2.3.4.5, and the MTA cannot recognize this OID as a valid one, then this pktcMtaDevErrorValue object instance will contain human readable (string) representation of value '1.2.3.4.5'. | If the numbers of errors in the configuration file exceeds=20 | 1024, then for all subsequent errors, the=20 | pktcMtaDevErrorValue of 1024th table's entry MUST contain=20 | a human readable representation of the=20 | pktcMtaDevErrorsTooManyErrors object, i.e. the string=20 | '1.3.6.1.2.1.XXX.1.1.4.1.0'." -- ************************************************************ -- * NOTES TO RFC Editor (to be removed prior to publication) * -- * * -- * Please replace XXX with the IANA-assigned number under * -- * mib-2. * -- ************************************************************ ::=3D {pktcMtaDevErrorOidsEntry 3} pktcMtaDevErrorReason OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION " This object indicates the reason for the error or warning, as per the MTA's interpretation, in human readable form, =20 for example: 'VALUE NOT IN RANGE', 'VALUE DOES NOT MATCH TYPE', 'UNSUPPORTED VALUE', 'LAST 4 BITS MUST BE SET TO ZERO', 'OUT OF MEMORY - CANNOT STORE', etc. This object may also contain vendor specific errors for private vendor OIDs and any proprietary error codes or=20 messages which can help diagnose configuration errors. | If the number of errors in the configuration file exceeds=20 | 1024, then for all subsequent errors, the | pktcMtaDevErrorReason of 1024th table's entry must contain=20 | a human readable string indicating the reason for an=20 | error, for example, 'Too many errors in the configuration=20 | file.'." ::=3D {pktcMtaDevErrorOidsEntry 4} ||| and | pktcMtaDevErrorsTooManyErrors OBJECT-IDENTITY -- ^^^^^^^^^^^^^^^ STATUS current DESCRIPTION "This object defines the OID corresponding to the error=20 condition when too many errors are encountered in the=20 MTA configuration file during provisioning." ::=3D { pktcMtaDevErrors 1 } Question:=20 Since this definition uses OBJECT-IDENTITY instead of OBJECT-TYPE, we = cannot use it in the MODULE-COMPLIANCE, hence cannot formerly mandate = that vendors support it (other than in the DESCRIPTION clause of = pktcMtaDevErrorOid. Is this the best way we can do this in SMI? Should = we use something else? We'd like to release draft05 tomorrow. Any help & comments are = appreciated.=20 Jean-Fran=E7ois=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Jan 21 00:42:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19199 for ; Fri, 21 Jan 2005 00:42:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crros-00087q-U8 for ipcdn-archive@ietf.org; Fri, 21 Jan 2005 00:58:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrrVk-0005yV-NM; Fri, 21 Jan 2005 00:39:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrrN5-0005HS-TW for ipcdn@megatron.ietf.org; Fri, 21 Jan 2005 00:30:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18227 for ; Fri, 21 Jan 2005 00:30:08 -0500 (EST) Received: from pop-a065c32.pas.sa.earthlink.net ([207.217.121.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crrct-0007qS-I8 for ipcdn@ietf.org; Fri, 21 Jan 2005 00:46:32 -0500 Received: from h-66-167-205-179.snvacaid.dynamic.covad.net ([66.167.205.179] helo=oemcomputer) by pop-a065c32.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CrrN2-0001rB-00 for ipcdn@ietf.org; Thu, 20 Jan 2005 21:30:08 -0800 Message-ID: <001f01c4ff7a$495337a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <24CDBA67F085904999751B3C4F9E8C0B01E76D61@NT-RMNA-0740.brcm.ad.broadcom.com> Subject: Re: [ipcdn] draft-ietf-ipcdn-pktc-mtamib-05 clarifications for pktcMtaDevProvConfigKey, pktcMtaDevProvConfigHash, and pktcMtaDevConfigFile Date: Thu, 20 Jan 2005 21:30:15 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Hi - > From: "Eugene Nechamkin" > To: > Cc: "Jean-Francois Mule" > Sent: Thursday, January 20, 2005 3:58 PM > Subject: [ipcdn] draft-ietf-ipcdn-pktc-mtamib-05 clarifications for pktcMtaDevProvConfigKey, pktcMtaDevProvConfigHash, and pktcMtaDevConfigFile ... > pktcMtaDevProvConfigKey OBJECT-TYPE ... > and, the MTA MUST return a 'genErr' error in response to > SNMP GET operations." ... This strikes me as very strange. The intent in RFC 3416 section 4.2.1 was for genErr to be the "error of last resort". When one considers how this would interact with, for example, AgentX infrastructure, the consequences for Get-Next and Get-Bulk processing could well be very bad. My suggestion, since this object contains sensitive information anyway, is for it to always return a zero-length string, rather than playing strange games with error codes. (I also see no value to requiring that the three objects be set in the same PDU. It would increase agent complexity, and I see no benefits to doing so.) Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Jan 21 00:58:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21310 for ; Fri, 21 Jan 2005 00:58:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crs4O-0000AX-IX for ipcdn-archive@ietf.org; Fri, 21 Jan 2005 01:14:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crrho-0008Qo-1Z; Fri, 21 Jan 2005 00:51:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crrdz-0007PI-96 for ipcdn@megatron.ietf.org; Fri, 21 Jan 2005 00:47:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19825 for ; Fri, 21 Jan 2005 00:47:36 -0500 (EST) Received: from pop-a065c32.pas.sa.earthlink.net ([207.217.121.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crrto-0008Gd-D2 for ipcdn@ietf.org; Fri, 21 Jan 2005 01:04:00 -0500 Received: from h-66-167-205-179.snvacaid.dynamic.covad.net ([66.167.205.179] helo=oemcomputer) by pop-a065c32.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1Crrdx-0006x3-00 for ipcdn@ietf.org; Thu, 20 Jan 2005 21:47:37 -0800 Message-ID: <002401c4ff7c$ba649cc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [ipcdn] draft-ietf-ipcdn-pktc-mtamib-05 - SMI question forpktcMtaDevErrorsTooManyErrors Date: Thu, 20 Jan 2005 21:47:43 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Hi - > From: "Jean-Francois Mule" > To: "Eugene Nechamkin" ; > Sent: Thursday, January 20, 2005 4:11 PM > Subject: [ipcdn] draft-ietf-ipcdn-pktc-mtamib-05 - SMI question forpktcMtaDevErrorsTooManyErrors ... > file was interpreted by the MTA as being .1.2.3.4.5, and Please get rid of the leading "." ... > | If the numbers of errors in the configuration file exceeds > | 1024, then for all subsequent errors, the > | pktcMtaDevErrorOid of 1024th table's entry MUST contain you mean "of the table's 1024th entry" > | a human readable representation of the > | pktcMtaDevErrorsTooManyErrors object, i.e. the string > | '1.3.6.1.2.1.XXX.1.1.4.1.0'. ... > | pktcMtaDevErrorValue of 1024th table's entry MUST contain again "of the table's 1024th entry" ... > | pktcMtaDevErrorReason of 1024th table's entry must contain ditto > | pktcMtaDevErrorsTooManyErrors OBJECT-IDENTITY > -- ^^^^^^^^^^^^^^^ ... > Question: > Since this definition uses OBJECT-IDENTITY instead of OBJECT-TYPE, > we cannot use it in the MODULE-COMPLIANCE, hence cannot formerly > mandate that vendors support it (other than in the DESCRIPTION clause of > pktcMtaDevErrorOid. Is this the best way we can do this in SMI? The MUST in the DESCRIPTION clause of pktcMtaDevErrorOid is pretty definitive. If the condition can occur in an implementation, and that implementation does not use that value, then that implementation is not conformant. > Should we use something else? ... If the data type were, for example, an integer type, then one could use the SYNTAX clause within the OBJECT clause to specify in the conformance material that the value was absolutely required. There's no way that I know of to do that with OBJECT IDENTIFIERs. However, the MUST in the DESCRIPTION clause of the object leaves no wiggle room that I can see, so I wouldn't worry about it. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Jan 21 04:32:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22046 for ; Fri, 21 Jan 2005 04:32:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrvPm-0005Vw-7l for ipcdn-archive@ietf.org; Fri, 21 Jan 2005 04:49:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crv8t-0004zN-IQ; Fri, 21 Jan 2005 04:31:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crv4Y-0004L3-UA for ipcdn@megatron.ietf.org; Fri, 21 Jan 2005 04:27:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21569 for ; Fri, 21 Jan 2005 04:27:16 -0500 (EST) Received: from asia.telenet-ops.be ([195.130.132.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrvKO-0005NR-DD for ipcdn@ietf.org; Fri, 21 Jan 2005 04:43:41 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by asia.telenet-ops.be (Postfix) with SMTP id CDF302241E1 for ; Fri, 21 Jan 2005 10:27:12 +0100 (MET) Received: from tcomlabs.com (dD5E00656.access.telenet.be [213.224.6.86]) by asia.telenet-ops.be (Postfix) with ESMTP id A676E2240A2 for ; Fri, 21 Jan 2005 10:27:12 +0100 (MET) Received: (qmail 4725 invoked from network); 21 Jan 2005 10:27:12 +0100 Received: from localhost (HELO gateway) (127.0.0.1) by localhost with SMTP; 21 Jan 2005 10:27:12 +0100 Received: from ([10.5.5.72]) by gateway.tcomlabs.com (MailMonitor for SMTP v1.2.2 ) ; Fri, 21 Jan 2005 10:27:12 +0100 (CET) From: "David De Reu" To: "IPCDN Mailing List" Date: Fri, 21 Jan 2005 10:27:12 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] pktcSigDevCodecTable request for clarification X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Dear all, Some MTA vendors are a bit puzzled regarding what to include in the pktcSigDevCodecTable table. On their and my own behalf, I would like to request some clarification. More specifically, there actually are two types of codecs: - First, the "real" voice codecs, like the ones listed in the PktcCodecTy= pe TEXTUAL-CONVENTION (PCMA, PCMU, G.729... etc) - Second, supplementary "codecs", for example for DTMF relay (RFC 2833). = In (Euro-)PacketCable/IPCablecom, this is the "telephone-event" "codec". Oth= er, proprietary solutions for DTMF relay exist as well, by the way, so this i= s not limited to "telephone-event" alone. >From a signaling point of view (NCS and SDP in our case), the "codecs" of the second type, are treated as all other codecs. However in practice the= y cannot be used for the entire call, they have to be used in conjunction w= ith a "real" codec. The question now is: do the codecs of the second type have to be included= in the pktcSigDevCodecTable, or is this table just intended for "real" codec= s? Either way, a clarification of some sort in the DESCRIPTION clause would = be helpful to implementors (and testers, as a matter of fact). If they are t= o be included, currently the only way is to use "other (1)" as the type, wh= ich is of course allowed but not very informative. This leads me to my second point: if things like "telephone-event" are supposed to be included in the pktcSigDevCodecTable, then I at least sugg= est extending the PktcCodecType with something like "telephoneEvent (15)". Any feedback would be appreciated. Regards, David _____________________________________________________ David De Reu tComLabs Stapelplein 70/004 =96 9000 Ghent =96 Belgium Tel: +32 9 269 22 91 =96 Fax: +32 9 329 31 74 www.tComLabs.com _____________________________________________________ _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Jan 21 05:26:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25607 for ; Fri, 21 Jan 2005 05:26:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrwFs-0006pZ-DY for ipcdn-archive@ietf.org; Fri, 21 Jan 2005 05:43:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crvvm-0004Nf-2b; Fri, 21 Jan 2005 05:22:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crvun-0004FI-5w for ipcdn@megatron.ietf.org; Fri, 21 Jan 2005 05:21:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25284 for ; Fri, 21 Jan 2005 05:21:15 -0500 (EST) Received: from poros.telenet-ops.be ([195.130.132.44]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrwAd-0006hT-Jp for ipcdn@ietf.org; Fri, 21 Jan 2005 05:37:40 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by poros.telenet-ops.be (Postfix) with SMTP id 8DCB93BC0E7 for ; Fri, 21 Jan 2005 11:21:14 +0100 (MET) Received: from tcomlabs.com (dD5E00656.access.telenet.be [213.224.6.86]) by poros.telenet-ops.be (Postfix) with ESMTP id 590A33BC1B1 for ; Fri, 21 Jan 2005 11:21:14 +0100 (MET) Received: (qmail 6928 invoked from network); 21 Jan 2005 11:21:08 +0100 Received: from localhost (HELO gateway) (127.0.0.1) by localhost with SMTP; 21 Jan 2005 11:21:08 +0100 Received: from ([10.5.5.72]) by gateway.tcomlabs.com (MailMonitor for SMTP v1.2.2 ) ; Fri, 21 Jan 2005 11:21:06 +0100 (CET) From: "David De Reu" To: Subject: RE: [ipcdn] pktcSigDevToneWholeToneRepeatCount descriptionindraft-07of the Signaling MIB Date: Fri, 21 Jan 2005 11:21:06 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <005601c4ff09$f383b4a0$7f1afea9@oemcomputer> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable > > From an SNMP point of view, would this wording require that the MTA > > has to store the value, without using it, or does this allow the MTA > > not even to store a new value? > ... > > From an implementor / onetime toolkit vendor perspective, it's simpler > to store and ignore, which is what default access methods would > do. Not storing a value would require a non-default access method > to be written, since the access method would need conditional logic > to decide whether it could skip storing the value. Also, from a testin= g > perspective, if MTAs are permitted to disregard the value supplied > in a set-request, then the value returned by a get-request is not well > defined, and that would not be good. For what it's worth: based upon these and other comments from Randy, I fe= el his suggestion is the simplest and most clean one. It would in this case also be useful to clarify the "store-and-ignore" semantics in the DESCRIPTION clause, so that the exact requirements are clear to everyone. Regards, David _____________________________________________________ David De Reu tComLabs Stapelplein 70/004 =96 9000 Ghent =96 Belgium Tel: +32 9 269 22 91 =96 Fax: +32 9 329 31 74 www.tComLabs.com _____________________________________________________ _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Jan 21 09:15:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12822 for ; Fri, 21 Jan 2005 09:15:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crzoy-0004OO-N1 for ipcdn-archive@ietf.org; Fri, 21 Jan 2005 09:31:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrzKQ-0008LJ-2v; Fri, 21 Jan 2005 08:59:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrzFh-0007GH-7W for ipcdn@megatron.ietf.org; Fri, 21 Jan 2005 08:55:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11080 for ; Fri, 21 Jan 2005 08:55:03 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrzVY-0003lE-Bn for ipcdn@ietf.org; Fri, 21 Jan 2005 09:11:30 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j0LDsve2011772 for ; Fri, 21 Jan 2005 07:55:00 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 21 Jan 2005 14:54:56 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550639C932@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Jean-Francois Mule , ipcdn@ietf.org Subject: RE: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt Date: Fri, 21 Jan 2005 14:54:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 142a000676f5977e1797396caab8b611 Content-Transfer-Encoding: quoted-printable Cc: enechamkin@broadcom.com X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1094b1c84fa6e846d476f39271f5074f Content-Transfer-Encoding: quoted-printable Fine by me Bert > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: Friday, January 21, 2005 00:31 > To: ipcdn@ietf.org > Cc: Wijnen, Bert (Bert); enechamkin@broadcom.com > Subject: RE: [ipcdn] RE: Review of = draft-ietf-ipcdn-pktc-mtamib-04.txt >=20 >=20 > Just a minor editorial change in our informative text to=20 > explain why the pktcMtaDevErrorOid is of type SnmpAdminString. >=20 > : > On Tuesday, January 11, 2005 at 4:47 PM, I had proposed: > > "Note that the syntax of this object is SnmpAdminString > > rather OBJECT IDENTIFIER because the object value is > > provided by an operator in the MTA configuration file > > in the form of a character string." >=20 > Based on Eugene's comment, the newly proposed text is: > Note that the syntax of this object is SnmpAdminString > rather OBJECT IDENTIFIER because the object value may > not be a valid OID due to human or configuration tool > encoding errors. >=20 > Let us know if this new proposed text is an issue. > Jean-Fran=E7ois=20 >=20 > > -----Original Message----- > > From: Jean-Francois Mule=20 > > Sent: Tuesday, January 11, 2005 4:47 PM > > To: Dave Thaler; ipcdn@ietf.org > > Cc: randy_presuhn@mindspring.com; Wijnen, Bert (Bert);=20 > > enechamkin@broadcom.com; C. M. Heard > > Subject: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt > >=20 > >=20 > > To close on one additional comment: > > Dave wrote: > > > 12) pktcMtaDevErrorOid, pktcMtaDevErrorValue, etc: > > > why are OIDs of type SnmpAdminString rather than an > > > OBJECT IDENTIFIER > > > type/subtype? As is, the management station cannot do=20 > > > simple things > > > like expanding the OID into the defined string tokens=20 > > in the MIB. > >=20 > > We discussed this point during the IETF IPCDN meeting #61,=20 > > see proceedings at: =20 > > > >=20 > > The meeting minutes recorded: > > In the WG meeting, we had consensus that since the OID and its > > value is provided in the MTA config file by an operator in the > > form of a character string, it is better to leave the syntax > > as SnmpAdminString rather than OBJECT IDENTIFIER. It was also > > requested that the above explanation be mentioned in the doc. > >=20 > > So, the resolution is: > > - no object syntax change > > - change the description of the pktcMtaDevErrorOid to=20 > > indicate the following: > > "Note that the syntax of this object is SnmpAdminString > > rather OBJECT IDENTIFIER because the object value is > > provided by an operator in the MTA configuration file > > in the form of a character string." > > - after more review of the pktcMtaDevErrorValue object,=20 > > we do not believe the above text should be added to its=20 > > description as this pktcMtaDevErrorValue object may contain=20 > > all kinds of object values in the case where the MTA can=20 > > recognize the OID but cannot interpret the given value. > >=20 > > Proposed text changes: > > pktcMtaDevErrorOid OBJECT-TYPE =20 > > SYNTAX SnmpAdminString > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION=20 > > " This object contains a human readable representation > > (character string) of the OID corresponding to the > > configuration file parameter that caused the particular > > error. > > For example, if the value of the pktcMtaDevEnabled object > > in the configuration file caused an error, then this > > object instance will contain the human readable string of > > '.1.3.6.1.2.1.XXX.1.1.6.0'. > > ************************************************************ > > * NOTES TO RFC Editor (to be removed prior to publication) * > > * Please replace XXX with the IANA-assigned number under * > > * mib-2. * > > ************************************************************ > >=20 > > If the MTA generated an error because it was not able=20 > > to recognize a particular OID, then this object=20 > > instance would contain an empty value (zero-length > > string). > > For example, if the value of an OID in the configuration=20 > > file was interpreted by the MTA as being .1.2.3.4.5, and=20 > > the MTA was not able to recognize this OID as a valid = one, > > this object instance will contain a zero-length string. > > Note that the syntax of this object is SnmpAdminString > > rather OBJECT IDENTIFIER because the object value is > > provided by an operator in the MTA configuration file > > in the form of a character string." > > ::=3D {pktcMtaDevErrorOidsEntry 2} > >=20 > > Let us know if this change is acceptable or else, feel free=20 > > to propose text improvements or suggestions. > >=20 > > Thanks, > >=20 > > Jean-Fran=E7ois=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Dave Thaler [mailto:dthaler@windows.microsoft.com] > > > Sent: Thursday, August 05, 2004 12:33 AM > > > To: enechamkin@broadcom.com; Jean-Francois Mule > > > Cc: ipcdn@ietf.org; Wijnen, Bert (Bert);=20 > > > randy_presuhn@mindspring.com; C. M. Heard > > > Subject: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt > > >=20 > > >=20 > > > Here's my MIB Doctor review of this document and what I > > > believe MUST/SHOULD/MAY be fixed. > > >=20 > > > MUST fix > > > -------- > > > 1) There is no IANA Considerations section, and this is now > > > required in the > > > new guidelines. The draft needs something like (based on=20 > > > the template=20 > > > in the guidelines): > > >=20 > > > 9. IANA Considerations > > >=20 > > > The MIB module in this document uses the following > > > IANA-assigned > > > OBJECT IDENTIFIER values recorded in the SMI Numbers=20 > > registry: > > >=20 > > > Descriptor OBJECT IDENTIFIER value > > > ---------- ----------------------- > > > pktcMtaMib { mib-2 XXX } > > >=20 > > > Editor's Note (to be removed prior to publication): > > > the IANA is > > > requested to assign a value for "XXX" under the 'mib-2' > > > subtree and to record the assignment in the SMI=20 > > > Numbers registry. > > > When the assignment has been made, the RFC Editor=20 > is asked to > > > replace "XXX" (here and in the MIB module) with=20 > the assigned > > > value and to remove this note. > > >=20 > > > 2) The page header on pages 2-51 says July 2002 > > >=20 > > > 3) MIB Guidelines say > > > If the module was developed by an IETF working group, then = the > > > ORGANIZATION clause MUST provide the full name of the > > > working group > > > ^^^^^^^^^ > > >=20 > > > The draft just uses the WG acronym: > > > ORGANIZATION "IETF IPCDN Working Group " > > >=20 > > > 4) The LAST-UPDATED date predates the REVISION date: > > > LAST-UPDATED "200406160000Z" -- June 16, 2004 > > > REVISION "200407160000Z" > > > ^ > > >=20 > > > 5) pktcMtaBasicSmtaCompliance contains > > > MODULE DOCS-CABLE-DEVICE-MIB > > > MANDATORY-GROUPS { > > > docsDevSoftwareGroupV2 > > > } > > > but RFC2669 is not referenced as a normative reference > > > and docsDevSoftwareGroupV2 isn't in there anyway, only > > > docsDevSoftwareGroup. Is this blocked on the progression > > > of another > > > document containing this? Looks like this used to be in > > > draft-ietf-ipcdn-device-mibv2-*.txt which has now expired. > > >=20 > > > 6) SEQUENCE element #4 `pktcMtaDevCmsSolicitedKeyTimeout' > > > does not match > > >=20 > > > order of columnar objects under `pktcMtaDevCmsEntry'. > > > Should swap the following two lines: > > > pktcMtaDevCmsSolicitedKeyTimeout Unsigned32, > > > pktcMtaDevCmsMaxClockSkew Unsigned32, > > >=20 > > > 7) pktcMtaDevProvisioningState has 'passWithWarning'=20 > > (singular) in the > > > enum, but 'passWithWarnings' (plural) twice in the = DESCRIPTION. > > > Also has 'failOtherReason' in the enum but=20 > 'failureOtherReason'=20 > > > in the DESCRIPTION. > > >=20 > > > 8) The comment on page 29 refers to > > > draft-ietf-ipcdn-pktc-signaling-02.txt > > > This should be added to the references section of the doc. > > > Also grammar error "Upper case must be use to" > > > ^^^ > > >=20 > > > 9) Typo in DESCRIPTION of pktcMtaDevCmsKerbRealmName: > > > realm table (pktcMtaDevRealmtable)." > > > ^ capitalize > > >=20 > > > 10) The DESCRIPTION of pktcMtaDevRealmTgsGracePeriod has > > > weird indentation, > > > and includes weird characters (as do several other objects). > > >=20 > > > SHOULD fix > > > ---------- > > > 11) pktcMtaDevErrorOidIndex: say what happens after the=20 > > value 1024 is=20 > > > reached > > >=20 > > > 12) pktcMtaDevErrorOid, pktcMtaDevErrorValue, etc: > > > why are OIDs of type SnmpAdminString rather than an > > > OBJECT IDENTIFIER > > > type/subtype? As is, the management station cannot do=20 > > > simple things > > > like expanding the OID into the defined string tokens=20 > > in the MIB. > > >=20 > > > 13) pktcMtaDevServerDhcp1, pktcMtaDevServerDns1, etc: the > > > DESCRIPTION of > > >=20 > > > these objects is worded as if the type is a string=20 > > rather than an > > > InetAddress (the "dotted" IP address, etc). Technically, > > > there's no > > > dots in the value, only in the displayed version of it. > > >=20 > > > 14) pktcMtaDevServerAddressType: what does it mean for this > > > to be read-write > > > but the dependent InetAddress fields to be read-only? =20 > > I.e., what=20 > > > happens to the latter immediately after the former is set? > > >=20 > > > MAY fix > > > ------- > > > 15) Consider defining a TC for kerberos realm names, since > > > this is used by=20 > > > multiple objects (pktcMtaDevProvKerbRealmName,=20 > > > pktcMtaDevRealmName, > > > and pktcMtaDevCmsKerbRealmName) and has special syntax=20 > > > restrictions=20 > > > (1..255 upper case ASCII chars)=20 > > >=20 > > > 16) The current conformance statements require read-write in > > > implementations > > > to be compliant. Is this intended? Since it currently=20 > > > only supports > > > ipv4, it doesn't seem useful to require read-write=20 > access to the > > > InetAddressType objects. > > >=20 > > > 17) pktcMtaDevSwCurrentVers is redundant with sysDescr, so > > > why is this=20 > > > needed? The draft says: > > > The data presented in this object MUST be > > > identical to the software version information contained > > > in the 'sysDescr' MIB object of the MTA. > > >=20 > > > 18) The MIB guidelines suggest using { pktcMtaMib 0 } for the=20 > > > notification prefix. The draft currently requires two > > > definitions: > > >=20 > > > pktcMtaNotificationPrefix OBJECT IDENTIFIER ::=3D {=20 > pktcMtaMib 2 } > > > pktcMtaNotification OBJECT IDENTIFIER ::=3D { > > > pktcMtaNotificationPrefix 0 } > > >=20 > > > Is there a good reason for this? (e.g. already deployed > > > implementations?) > > >=20 > > > 19) What is the expected behavior when reading > > > pktcMtaDevRealmName and=20 > > > pktcMtaDevRealmOrgName when the row is first created=20 > > and they are=20 > > > not set? (There's no DEFVAL, and the MIB doesn't say=20 > > > they have to=20 > > > be set in the initial createAndWait set.) > > >=20 > > > 20) draft-ietf-ipcdn-bpiplus-mib-12.txt is referenced, and is now > > > draft-ietf-ipcdn-bpiplus-mib-13.txt > > >=20 > > > 21) The wording in section 8 varies marginally from the template. > > >=20 > > > Template: > > > > Some of the readable objects in this MIB module (i.e., > > > objects with a > > > > MAX-ACCESS other than not-accessible) may be considered=20 > > > sensitive or > > > =20 > > > Actual: > > > > Some of the readable objects in this MIB module may be > > > considered > > > > sensitive or [...] > > >=20 > > >=20 > > >=20 > >=20 > > _______________________________________________ > > IPCDN mailing list > > IPCDN@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipcdn > >=20 > >=20 >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Jan 21 09:15:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12823 for ; Fri, 21 Jan 2005 09:15:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crzoy-0004OQ-Rx for ipcdn-archive@ietf.org; Fri, 21 Jan 2005 09:31:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrzKO-0008L7-W6; Fri, 21 Jan 2005 08:59:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrzFg-0007GF-9w for ipcdn@megatron.ietf.org; Fri, 21 Jan 2005 08:55:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11075 for ; Fri, 21 Jan 2005 08:55:02 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrzVW-0003l8-DN for ipcdn@ietf.org; Fri, 21 Jan 2005 09:11:29 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j0LDsve1011772 for ; Fri, 21 Jan 2005 07:54:58 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 21 Jan 2005 14:54:56 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550639C931@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Jean-Francois Mule , Eugene Nechamkin , ipcdn@ietf.org Subject: RE: [ipcdn] draft-ietf-ipcdn-pktc-mtamib-05 - SMI question for pk tcMtaDevErrorsTooManyErrors Date: Fri, 21 Jan 2005 14:54:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by hoemail1.lucent.com id j0LDsve1011772 X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Content-Transfer-Encoding: quoted-printable I agree with Randy's answer. Bert > -----Original Message----- > From: ipcdn-bounces@ietf.org=20 > [mailto:ipcdn-bounces@ietf.org]On Behalf Of > Jean-Francois Mule > Sent: Friday, January 21, 2005 01:11 > To: Eugene Nechamkin; ipcdn@ietf.org > Subject: [ipcdn] draft-ietf-ipcdn-pktc-mtamib-05 - SMI question for > pktcMtaDevErrorsTooManyErrors >=20 >=20 >=20 > I like Bert's proposal to create an OID to deal with the=20 > internationalization issue raised by Dave and Randy. See=20 > below, a quick SMI question. >=20 > Eugene integrated the comments and proposed the following text: > pktcMtaDevErrorOid OBJECT-TYPE =20 > SYNTAX SnmpAdminString > MAX-ACCESS read-only > STATUS current > DESCRIPTION=20 > " This object contains a human readable representation > (character string) of the OID corresponding to the > configuration file parameter that caused the particular > error. > For example, if the value of the pktcMtaDevEnabled object > in the configuration file caused an error, then this > object instance will contain the human readable string of > '1.3.6.1.2.1.XXX.1.1.6.0'. >=20 > -- ************************************************************ > -- * NOTES TO RFC Editor (to be removed prior to publication) * > -- * * > -- * Please replace XXX with the IANA-assigned number under * > -- * mib-2. * > -- ************************************************************ >=20 > If the MTA generated an error because it was not able=20 > to recognize a particular OID, then this object=20 > instance would contain an empty value (zero-length > string). > For example, if the value of an OID in the configuration=20 > file was interpreted by the MTA as being .1.2.3.4.5, and=20 > the MTA was not able to recognize this OID as a valid one, > this object instance will contain a zero-length string. >=20 > | If the numbers of errors in the configuration file exceeds=20 > | 1024, then for all subsequent errors, the=20 > | pktcMtaDevErrorOid of 1024th table's entry MUST contain=20 > | a human readable representation of the=20 > | pktcMtaDevErrorsTooManyErrors object, i.e. the string > | '1.3.6.1.2.1.XXX.1.1.4.1.0'. >=20 > -- ************************************************************ > -- * NOTES TO RFC Editor (to be removed prior to publication) * > -- * * > -- * Please replace XXX with the IANA-assigned number under * > -- * mib-2. * > -- ************************************************************ > Note that the syntax of this object is SnmpAdminString > rather OBJECT IDENTIFIER because the object value may > not be a valid OID due to human or configuration tool > encoding errors." >=20 > ::=3D {pktcMtaDevErrorOidsEntry 2} >=20 > pktcMtaDevErrorValue OBJECT-TYPE > SYNTAX SnmpAdminString > MAX-ACCESS read-only > STATUS current > DESCRIPTION > " This object contains the value of the OID corresponding to > the configuration file parameter that caused the error. > If the MTA cannot recognize the OID of the > configuration parameter causing the error, then this > object instance contains the OID itself as interpreted > by the MTA in human readable representation. > If the MTA can recognize the OID but generate an error due > to a wrong value of the parameter, then the object > instance contains the erroneous value of the parameter as > read from the configuration file. > In both cases, the value of this object must be > represented in human readable form as a character string. > For example, if the value of the pktcMtaDevEnabled object > in the configuration file was 3 (invalid value), then the > pktcMtaDevErrorValue object instance will contain the > human readable (string) representation of value '3'. > Similarly, if the OID in the configuration file has been > interpreted by the MTA as being 1.2.3.4.5, and the MTA > cannot recognize this OID as a valid one, then this > pktcMtaDevErrorValue object instance will contain human > readable (string) representation of value '1.2.3.4.5'. >=20 > | If the numbers of errors in the configuration file exceeds=20 > | 1024, then for all subsequent errors, the=20 > | pktcMtaDevErrorValue of 1024th table's entry MUST contain=20 > | a human readable representation of the=20 > | pktcMtaDevErrorsTooManyErrors object, i.e. the string=20 > | '1.3.6.1.2.1.XXX.1.1.4.1.0'." > -- ************************************************************ > -- * NOTES TO RFC Editor (to be removed prior to publication) * > -- * * > -- * Please replace XXX with the IANA-assigned number under * > -- * mib-2. * > -- ************************************************************ >=20 > ::=3D {pktcMtaDevErrorOidsEntry 3} >=20 > pktcMtaDevErrorReason OBJECT-TYPE > SYNTAX SnmpAdminString > MAX-ACCESS read-only > STATUS current > DESCRIPTION > " This object indicates the reason for the error or warning, > as per the MTA's interpretation, in human readable form, =20 > for example: > 'VALUE NOT IN RANGE', 'VALUE DOES NOT MATCH TYPE', > 'UNSUPPORTED VALUE', 'LAST 4 BITS MUST BE SET TO ZERO', > 'OUT OF MEMORY - CANNOT STORE', etc. > This object may also contain vendor specific errors for > private vendor OIDs and any proprietary error codes or=20 > messages which can help diagnose configuration errors. >=20 > | If the number of errors in the configuration file exceeds=20 > | 1024, then for all subsequent errors, the > | pktcMtaDevErrorReason of 1024th table's entry must contain=20 > | a human readable string indicating the reason for an=20 > | error, for example, 'Too many errors in the configuration=20 > | file.'." > ::=3D {pktcMtaDevErrorOidsEntry 4} >=20 >=20 > ||| and >=20 > | pktcMtaDevErrorsTooManyErrors OBJECT-IDENTITY > -- ^^^^^^^^^^^^^^^ > STATUS current > DESCRIPTION > "This object defines the OID corresponding to the error=20 > condition when too many errors are encountered in the=20 > MTA configuration file during provisioning." > ::=3D { pktcMtaDevErrors 1 } >=20 > Question:=20 > Since this definition uses OBJECT-IDENTITY instead of=20 > OBJECT-TYPE, we cannot use it in the MODULE-COMPLIANCE, hence=20 > cannot formerly mandate that vendors support it (other than=20 > in the DESCRIPTION clause of pktcMtaDevErrorOid. Is this the=20 > best way we can do this in SMI? Should we use something else? >=20 > We'd like to release draft05 tomorrow. Any help & comments=20 > are appreciated.=20 > Jean-Fran=E7ois=20 >=20 > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Jan 21 12:31:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29560 for ; Fri, 21 Jan 2005 12:31:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs2se-00024l-I3 for ipcdn-archive@ietf.org; Fri, 21 Jan 2005 12:47:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs2VJ-0005oS-Pq; Fri, 21 Jan 2005 12:23:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs2Ks-0000il-7R for ipcdn@megatron.ietf.org; Fri, 21 Jan 2005 12:12:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28173 for ; Fri, 21 Jan 2005 12:12:35 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs2am-0001W3-C9 for ipcdn@ietf.org; Fri, 21 Jan 2005 12:29:05 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j0LHC31e017076; Fri, 21 Jan 2005 10:12:04 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] draft-ietf-ipcdn-pktc-mtamib-05 - SMI questionforpktcMtaDevErrorsTooManyErrors Date: Fri, 21 Jan 2005 10:12:03 -0700 Message-ID: Thread-Topic: [ipcdn] draft-ietf-ipcdn-pktc-mtamib-05 - SMI questionforpktcMtaDevErrorsTooManyErrors Thread-Index: AcT/flTZ5ygekZkTRoWWeYmIYQrtIwAXScsA From: "Jean-Francois Mule" To: "Randy Presuhn" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable Hi Randy, As usual, thanks for your good comments. See inline. Jean-Fran=E7ois=20 Randy wrote: > > file was interpreted by the MTA as being .1.2.3.4.5, and >=20 > Please get rid of the leading "." Corrected, sorry. My global search on leading zeros for OIDs missed that = one. > ... > > | If the numbers of errors in the configuration file exceeds > > | 1024, then for all subsequent errors, the > > | pktcMtaDevErrorOid of 1024th table's entry MUST contain >=20 > you mean "of the table's 1024th entry" Yes. Grammar corrected everywhere, thanks for catching this. > > | a human readable representation of the > > | pktcMtaDevErrorsTooManyErrors object, i.e. the string > > | '1.3.6.1.2.1.XXX.1.1.4.1.0'. >=20 > ... > > | pktcMtaDevErrorValue of 1024th table's entry MUST contain >=20 > again "of the table's 1024th entry" Yes. Corrected. > > | pktcMtaDevErrorReason of 1024th table's entry must contain >=20 > ditto Yes. Corrected. > > | pktcMtaDevErrorsTooManyErrors OBJECT-IDENTITY > > -- ^^^^^^^^^^^^^^^ > ... > > Question: > > Since this definition uses OBJECT-IDENTITY instead of=20 > OBJECT-TYPE, we=20 > > cannot use it in the MODULE-COMPLIANCE, hence cannot=20 > formerly mandate=20 > > that vendors support it (other than in the DESCRIPTION clause of=20 > > pktcMtaDevErrorOid. Is this the best way we can do this in SMI? >=20 >=20 > The MUST in the DESCRIPTION clause of pktcMtaDevErrorOid is=20 > pretty definitive. If the condition can occur in an=20 > implementation, and that implementation does not use that=20 > value, then that implementation is not conformant. Good, that is the intent and we wanted to make sure that other readers = would draw that conclusion as well.=20 > > Should we use something else? > ... >=20 > If the data type were, for example, an integer type, then one=20 > could use the SYNTAX clause within the OBJECT clause to=20 > specify in the conformance material that the value was=20 > absolutely required. There's no way that I know of to do that=20 > with OBJECT IDENTIFIERs. >=20 > However, the MUST in the DESCRIPTION clause of the object=20 > leaves no wiggle room that I can see, so I wouldn't worry about it. Agreed, no change required. =20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Jan 21 13:16:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02903 for ; Fri, 21 Jan 2005 13:16:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs3aW-0003JK-T2 for ipcdn-archive@ietf.org; Fri, 21 Jan 2005 13:32:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs39i-0006I1-9R; Fri, 21 Jan 2005 13:05:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs35O-0005Wy-Ij for ipcdn@megatron.ietf.org; Fri, 21 Jan 2005 13:00:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01807 for ; Fri, 21 Jan 2005 13:00:39 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs3LI-0002uw-Tq for ipcdn@ietf.org; Fri, 21 Jan 2005 13:17:10 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j0LI081e029169; Fri, 21 Jan 2005 11:00:08 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] pktcSigDevCodecTable request for clarification Date: Fri, 21 Jan 2005 11:00:07 -0700 Message-ID: Thread-Topic: [ipcdn] pktcSigDevCodecTable request for clarification Thread-Index: AcT/nFDemDNM37oxQ1qcShA+NVTd8AAQeCrQ From: "Jean-Francois Mule" To: "David De Reu" , "IPCDN Mailing List" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: quoted-printable X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: quoted-printable Hi David, See inline. Jean-Fran=E7ois=20 > -----Original Message----- > From: David De Reu [mailto:DeReu@tComLabs.com]=20 > Sent: Friday, January 21, 2005 2:27 AM > To: IPCDN Mailing List > Subject: [ipcdn] pktcSigDevCodecTable request for clarification >=20 >=20 > Dear all, >=20 > Some MTA vendors are a bit puzzled regarding what to include in the > pktcSigDevCodecTable table. On their and my own behalf, I=20 What strikes me in your introduction is the lack of operator's view on = this table, I'd be curious to see what the operators' input is there. > would like to > request some clarification. >=20 >=20 > More specifically, there actually are two types of codecs: >=20 > - First, the "real" voice codecs, like the ones listed in the=20 > PktcCodecType > TEXTUAL-CONVENTION (PCMA, PCMU, G.729... etc) A note on this, during my review of draft00, on Tuesday, March 18, 2003 = at 11:33 AM, I wrote: > - PktcCodecType TEXTUAL-CONVENTION=20 > See IETF AVT draft-ietf-avt-profile-new-13.txt, section 4.5:=20 > this draft is an update to rfc1890 and it defines the latest=20 > and greatest encoding names for audio video codecs. The=20 > PktcCodecType object definition should use the encoding names=20 > defined in AVT. In particular, g711a/mu must be replaced by=20 > PCMA/PCMU, etc. These changes were made in the latest=20 > PacketCable spec PKT-SP-MIB-SIG-I05-021127 and should be=20 > reflected in the IETF ipcdn ID. The ID mentioned above is now RFC 3551. I'm not sure I understand your point or comment here but I'd recommend = keeping the TC based on the literals names used in NCS-SIP/SDP to = negotiate the codecs. =20 > - Second, supplementary "codecs", for example for DTMF relay=20 > (RFC 2833).=20 The issue here is to understand how IETF AVT wg is dealing with RFC = 2833. See section 6 of RFC3551 - there is no "codec" defined as rfc2833 = for a good reason: you usually don't use it in the m=3D line, it's not a = "primary" codec. Some other codecs have dynamic payload types and dtmf = relay/rfc2833 - for the RTP payload type falls in this case.=20 > In > (Euro-)PacketCable/IPCablecom, this is the "telephone-event"=20 > "codec".=20 Where is the spec you are refering to? Can we have a look at it? The = ipCablecom spec referenced in the draft does not seem to have such a = "codec". In the DSP media connection line (m=3D), you still have to indicate a = vocoder, even if you advertise support 2833 (which is done in the media = attribute line a=3D). That difference is key to understand. Per se, this = is not a voice codec, just an additional capability to extract = tone/events inside the media payloads and encapsulate them in an RTP = format so that it can be reliably regenerated on the other side. > Other, > proprietary solutions for DTMF relay exist as well, by the=20 > way, so this is > not limited to "telephone-event" alone. We can't do much there.=20 > >From a signaling point of view (NCS and SDP in our case),=20 > the "codecs" of > the second type, are treated as all other codecs.=20 > However in=20 > practice they > cannot be used for the entire call, they have to be used in=20 > conjunction with > a "real" codec. Yes, again, RFC2833 is a very special case (for e.g. the MTA starts a = G.729E call - that is the codec, then turn on dtmf detection on your DSP = and encodes those dtmf in rfc2833 while maintaining the voice payloads = isnide the rtp voice channel). > The question now is: do the codecs of the second type have to=20 > be included in > the pktcSigDevCodecTable, or is this table just intended for=20 > "real" codecs? I would say no based on the current definition and description clause of = this TC.=20 > Either way, a clarification of some sort in the DESCRIPTION=20 > clause would be > helpful to implementors (and testers, as a matter of fact).=20 If an integer value is not given for other codecs, or represented in the = TC, then testers cannot expect vendors to advertise it. RFC3551 does not = make a special case for RFC 2833 either. > If they are to > be included, currently the only way is to use "other (1)" as=20 > the type, which > is of course allowed but not very informative. In my opinion, they should not be included. If what you want is the MTA = to indicate support for RFC2833, then this belongs to another MIB = object. > This leads me to my second point: if things like "telephone-event" are > supposed to be included in the pktcSigDevCodecTable, then I=20 > at least suggest > extending the PktcCodecType with something like "telephoneEvent (15)". But then this is not a valid codec literal name as the TC mandates so = that is not a good option to me. >=20 >=20 > Any feedback would be appreciated. >=20 >=20 > Regards, >=20 > David >=20 > _____________________________________________________ > David De Reu > tComLabs > Stapelplein 70/004 - 9000 Ghent - Belgium > Tel: +32 9 269 22 91 - Fax: +32 9 329 31 74 > www.tComLabs.com > _____________________________________________________ >=20 >=20 >=20 >=20 > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn >=20 >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Jan 21 13:39:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04726 for ; Fri, 21 Jan 2005 13:39:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs3wd-0003yh-B5 for ipcdn-archive@ietf.org; Fri, 21 Jan 2005 13:55:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs3Yv-0003F3-8b; Fri, 21 Jan 2005 13:31:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs3SW-0001Ry-PI for ipcdn@megatron.ietf.org; Fri, 21 Jan 2005 13:24:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03428 for ; Fri, 21 Jan 2005 13:24:33 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs3iS-0003Ui-IM for ipcdn@ietf.org; Fri, 21 Jan 2005 13:41:04 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j0LIO21e005738; Fri, 21 Jan 2005 11:24:03 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] draft-ietf-ipcdn-pktc-mtamib-05 - why 1024? Date: Fri, 21 Jan 2005 11:24:02 -0700 Message-ID: Thread-Topic: [ipcdn] draft-ietf-ipcdn-pktc-mtamib-05 - why 1024? Thread-Index: AcR6thTZfq+7VKivT3+3uhPKgFAc5B9gDNXgAcRWksAAAD0PAAABCuwAACWq3MA= From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: Eugene Nechamkin X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable A question was posed w.r.t. the choice of the max number of errors in = the MTA ErrorOID table, currently set as 1024 in the object definition. = I just wanted to close the loop on the comment and the suggestions to = not limit the error OID table to 1024 but instead, put a max in = MODULE-COMPLIANCE. After talking to some folks here and some vendors, here's a summary of = our discussions: - we think that a limit of 1024 errors in a config file that is = usually 20-100(say even 300) lines or OID assignments is sufficient, = even for future extensions, - the cable operators do control this config file very strictly and = run lab tests before rolling out a new config file and this table is a = pre-deployment tool to check config file errors and 1024 is ok. =3D> So, the authors are recommending we keep the object as-is. We have = had many discussions and valuable refinements to state what happens = beyond the 1024th error.=20 We will add the following text in the object description clause to = explain the rationale: "The maximum number of errors or warnings that can be recorded in the = pktcMtaDevErrorOidsTable is set to 1024 as a configuration file is = usually validated by operators before deployment. Given the possible = number of configuration parameter assignments in the MTA configuration = file, 1024 is perceived as a sufficient limit even with future = extensions." Feel free to propose better text.=20 Let me know if this is ok. Jean-Fran=E7ois PS: The alternative to get rid of the limit in the object definition, = add it to the module compliance, which also provides strong guidance to = vendors for their implementations. Let me know if this is a better = route, I really think that this is a minor comment given how this table = is used. And we're all used to SMICng barking after a certain number of = errors when compiling a MIB module and that pretty much means: too many = errors, fix those first, then come back and try again... _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Jan 21 17:16:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28334 for ; Fri, 21 Jan 2005 17:16:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs7Kn-0003rX-H7 for ipcdn-archive@ietf.org; Fri, 21 Jan 2005 17:32:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs6rW-0004wI-PD; Fri, 21 Jan 2005 17:02:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs6lQ-0002cd-SR for ipcdn@megatron.ietf.org; Fri, 21 Jan 2005 16:56:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26932 for ; Fri, 21 Jan 2005 16:56:18 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs71M-0003F2-HA for ipcdn@ietf.org; Fri, 21 Jan 2005 17:12:50 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j0LLtj1e024392; Fri, 21 Jan 2005 14:55:45 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] pktcMtaDevProvConfigKey Date: Fri, 21 Jan 2005 14:55:45 -0700 Message-ID: Thread-Topic: [ipcdn] pktcMtaDevProvConfigKey Thread-Index: AcT/fCha2gOcHp+XSa+y5wmD2GAHbgAfxuoA From: "Jean-Francois Mule" To: "Randy Presuhn" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable Hi Randy, You wrote: > > pktcMtaDevProvConfigKey OBJECT-TYPE > ... > > and, the MTA MUST return a 'genErr' error in response to > > SNMP GET operations." > ... >=20 > This strikes me as very strange. The intent in RFC 3416 section 4.2.1 > was for genErr to be the "error of last resort". When one considers > how this would interact with, for example, AgentX > infrastructure, the consequences for Get-Next and Get-Bulk=20 > processing could well be very bad. =20 Eugene and I discussed this live today. We had not thought about that before, you have a point.=20 Do I interpret your comment above correctly by assuming that, on some SNMP agents, the return of a genErr would break a MIB walktrhough via get-next/get-bulk for e.g.? If that is the case, I agree we don't want this. > My suggestion, since this > object contains sensitive information anyway, is for it to=20 > always return a zero-length string, rather than playing=20 > strange games with error codes. Ok.=20 I assume a "zero length string" means an octet string of size 0?=20 How about this new text? pktcMtaDevProvConfigKey OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0|8)) MAX-ACCESS read-write STATUS current DESCRIPTION " This object contains the key used to encrypt/decrypt the configuration file when secure SNMPv3 provisioning is used. The privacy algorithm is DES, the key length is 64 bits. If this object is set at any other provisioning steps than=20 the one(s) allowed by the PacketCable MTA Device Provisioning Specification, or, if this object is set to a zero-length string value, the MTA MUST return an 'inconsistentValue' error. This object must not be used in non secure provisioning mode. In non secure provisioning modes, the MTA MUST return an 'inconsistentValue' in response to SNMP SET=20 operations, and, the MTA MUST return a zero-length string in response to SNMP GET operations." REFERENCE " PacketCable MTA Device Provisioning Specification; PacketCable Security Specification." ::=3D { pktcMtaDevServer 10 }=20 Let us know if the above is acceptable. Thanks for raising this issue. > (I also see no value to requiring that the three objects be > set in the same PDU. It would increase agent complexity, and=20 > I see no benefits to doing so.) Removed from all objects where it had been inserted. Eugene will start a thread on this before the change gets in the draft. >=20 > Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Jan 21 18:33:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03771 for ; Fri, 21 Jan 2005 18:33:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs8XQ-0005ex-5A for ipcdn-archive@ietf.org; Fri, 21 Jan 2005 18:50:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs8GG-0002ZP-OZ; Fri, 21 Jan 2005 18:32:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs87B-0000L1-Np for ipcdn@megatron.ietf.org; Fri, 21 Jan 2005 18:22:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03163 for ; Fri, 21 Jan 2005 18:22:49 -0500 (EST) Received: from pop-a065d14.pas.sa.earthlink.net ([207.217.121.252]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs8N8-0005Se-U7 for ipcdn@ietf.org; Fri, 21 Jan 2005 18:39:23 -0500 Received: from h-69-3-28-223.snvacaid.dynamic.covad.net ([69.3.28.223] helo=oemcomputer) by pop-a065d14.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1Cs872-0005M1-00 for ipcdn@ietf.org; Fri, 21 Jan 2005 15:22:44 -0800 Message-ID: <000801c50010$20eff280$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [ipcdn] pktcMtaDevProvConfigKey Date: Fri, 21 Jan 2005 15:22:51 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Hi - > From: "Jean-Francois Mule" > To: "Randy Presuhn" ; > Sent: Friday, January 21, 2005 1:55 PM > Subject: [ipcdn] pktcMtaDevProvConfigKey ... > Do I interpret your comment above correctly by assuming that, on some > SNMP agents, the return of a genErr would break a MIB walktrhough via > get-next/get-bulk for e.g.? If that is the case, I agree we don't want > this. Yes, it would break MIB walks implemented using AgentX. See RFC 2741 section 7.2.5.3. for details explaining why. > > My suggestion, since this > > object contains sensitive information anyway, is for it to > > always return a zero-length string, rather than playing > > strange games with error codes. > > Ok. > I assume a "zero length string" means an octet string of size 0? Yes. > How about this new text? > > pktcMtaDevProvConfigKey OBJECT-TYPE > SYNTAX OCTET STRING (SIZE(0|8)) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > " This object contains the key used to encrypt/decrypt > the configuration file when secure SNMPv3 provisioning > is used. > The privacy algorithm is DES, the key length is 64 bits. Which DES mode? CBC? CFB? ECB? ...? Is there an IV for the DES? > If this object is set at any other provisioning steps than > the one(s) allowed by the PacketCable MTA Device > Provisioning Specification, or, if this object is > set to a zero-length string value, the MTA MUST return > an 'inconsistentValue' error. One can also formalize this using the WRITE-SYNTAX in the OBJECT clause of the conformance material. > This object must not be used in non secure provisioning > mode. In non secure provisioning modes, the MTA MUST > return an 'inconsistentValue' in response to SNMP SET > operations, and, the MTA MUST return a zero-length string > in response to SNMP GET operations." ... Ok, though I meant that the MTA would ALWAYS return a zero-length string in response to GET requests, not just in "non secure provisioning modes." Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Jan 21 19:22:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09215 for ; Fri, 21 Jan 2005 19:22:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs9JA-0007B9-IR for ipcdn-archive@ietf.org; Fri, 21 Jan 2005 19:39:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs902-0007ti-Ri; Fri, 21 Jan 2005 19:19:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs8sU-0004cF-8M for ipcdn@megatron.ietf.org; Fri, 21 Jan 2005 19:11:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08008 for ; Fri, 21 Jan 2005 19:11:43 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs98T-0006iY-4K for ipcdn@ietf.org; Fri, 21 Jan 2005 19:28:17 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j0M0B81e020832 for ; Fri, 21 Jan 2005 17:11:08 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] pktcMtaDevProvConfigKey Date: Fri, 21 Jan 2005 17:11:08 -0700 Message-ID: Thread-Topic: [ipcdn] pktcMtaDevProvConfigKey Thread-Index: AcUAEdnU7NUnKG5iT/C2p8tNBhFPFgAA5xdw From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable What's fun is that you always find more good stuff to address.=20 see Inline. Jean-Fran=E7ois=20 > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 > Sent: Friday, January 21, 2005 4:23 PM > To: ipcdn@ietf.org > Subject: Re: [ipcdn] pktcMtaDevProvConfigKey >=20 >=20 > Hi - >=20 > > From: "Jean-Francois Mule" > > To: "Randy Presuhn" ; > > Sent: Friday, January 21, 2005 1:55 PM > > Subject: [ipcdn] pktcMtaDevProvConfigKey > ... > > Do I interpret your comment above correctly by assuming that, on=20 > > some SNMP agents, the return of a genErr would break a MIB=20 > walktrhough=20 > > via get-next/get-bulk for e.g.? If that is the case, I=20 > agree we don't=20 > > want this. >=20 > Yes, it would break MIB walks implemented using AgentX. > See RFC 2741 section 7.2.5.3. for details explaining why. >=20 > > > My suggestion, since this > > > object contains sensitive information anyway, is for it to always=20 > > > return a zero-length string, rather than playing strange=20 > games with=20 > > > error codes. > > > > Ok. > > I assume a "zero length string" means an octet string of size 0? >=20 > Yes. >=20 > > How about this new text? > > > > pktcMtaDevProvConfigKey OBJECT-TYPE > > SYNTAX OCTET STRING (SIZE(0|8)) > > MAX-ACCESS read-write > > STATUS current > > DESCRIPTION > > " This object contains the key used to encrypt/decrypt > > the configuration file when secure SNMPv3 provisioning > > is used. > > The privacy algorithm is DES, the key length is 64 bits. >=20 > Which DES mode? CBC? CFB? ECB? ...? Is there an IV for the DES? This was there before, nobody commented.... Arg...=20 DES CBC mode as defined the reference of the object, PacketCable = security spec, = http://www.packetcable.com/downloads/specs/PKT-SP-SEC-I11-040730.pdf , = section 6.3. I will add CBC mode in the text but I'm reluctant to = mention the section number or add more. Text now says: The privacy algorithm is defined by the PacketCable Security Specification, it is DES in CBC mode and the key length is 64 bits. > > If this object is set at any other provisioning steps than > > the one(s) allowed by the PacketCable MTA Device > > Provisioning Specification, or, if this object is > > set to a zero-length string value, the MTA MUST return > > an 'inconsistentValue' error. >=20 > One can also formalize this using the WRITE-SYNTAX in the=20 > OBJECT clause of the conformance material. Ok, this is a refinement, nice to have but believe the above is enough = for now (we are trying to close this revision tonight). No changes = required - if that's ok with you. >=20 > > This object must not be used in non secure provisioning > > mode. In non secure provisioning modes, the MTA MUST > > return an 'inconsistentValue' in response to SNMP SET > > operations, and, the MTA MUST return a zero-length string > > in response to SNMP GET operations." > ... >=20 > Ok, though I meant that the MTA would ALWAYS return a=20 > zero-length string in response to GET requests, not just in=20 > "non secure provisioning modes." Ok. In secure mode, one could get the actual key in a GET and that could = help troubleshoot some issues when the MTA has pbs to decrypt the = configuration file. No changes required - if that's ok with you. >=20 > Randy >=20 >=20 >=20 >=20 > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn >=20 >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Jan 21 19:36:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09903 for ; Fri, 21 Jan 2005 19:36:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs9WC-0007Ts-Pt for ipcdn-archive@ietf.org; Fri, 21 Jan 2005 19:52:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs9EC-00049L-9X; Fri, 21 Jan 2005 19:34:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs9BV-00039l-3H for ipcdn@megatron.ietf.org; Fri, 21 Jan 2005 19:31:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09657 for ; Fri, 21 Jan 2005 19:31:21 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs9RU-0007Ml-02 for ipcdn@ietf.org; Fri, 21 Jan 2005 19:47:56 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j0M0Uo1e025173; Fri, 21 Jan 2005 17:30:51 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Jan 2005 17:30:50 -0700 Message-ID: Thread-Topic: MTA MIB pktcMtaDevProvSolicitedKeyTimeout Thread-Index: AcUAEdnU7NUnKG5iT/C2p8tNBhFPFgABSMkA From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: quoted-printable Cc: enechamkin@broadcom.com Subject: [ipcdn] MTA MIB pktcMtaDevProvSolicitedKeyTimeout X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: quoted-printable Along the same lines, scanning through the same genError use in the MIB, = we have the same pb in pktcMtaDevProvUnsolicitedKeyMaxTimeout, = pktcMtaDevProvUnsolicitedKeyNomTimeout, = pktcMtaDevProvUnsolicitedKeyMaxRetries and many other timers. Along the same lines of what we agreed for the configkey object, here = are the changes: pktcMtaDevProvSolicitedKeyTimeout OBJECT-TYPE=20 SYNTAX Unsigned32 (1..180)=20 UNITS "seconds"=20 MAX-ACCESS read-write=20 STATUS current=20 DESCRIPTION " This object defines a Kerberos Key Management timer on the MTA. It is the time period during which the MTA saves the nonce and Server Kerberos Principal Identifier to match an AP Request and its associated AP Reply response from the Provisioning Server. After the timeout has been exceeded, the client discards this (nonce, Server Kerberos Principal Identifier) pair, after which it will no longer accept a matching AP Reply. This timer only applies when the Provisioning Server initiated key management for SNMPv3 (with a Wake Up message).=20 ---> This object should not be used in non secure provisioning modes. In non secure provisioning modes, the MTA MUST return an 'inconsistentValue' in response to SNMP SET operations, and the MTA MUST ---> return a 'genErr' error in response to SNMP GET operations." DEFVAL { 3 }=20 ::=3D { pktcMtaDevServer 11 }=20 So I changed it to allow 0 to be returned in non secure modes: pktcMtaDevProvSolicitedKeyTimeout OBJECT-TYPE=20 SYNTAX Unsigned32 (0..180)=20 [snip] ---> If this object is set to a zero value, the MTA MUST return an 'inconsistentValue' in response to SNMP SET operations. This object should not be used in non secure provisioning modes. In non secure provisioning modes, the MTA MUST return an 'inconsistentValue' in response to SNMP SET operations, and the MTA MUST return a zero value in response to SNMP GET operations." DEFVAL { 3 }=20 ::=3D { pktcMtaDevServer 11 }=20 And same for the rest (lines changed marked with bars): pktcMtaDevProvUnsolicitedKeyMaxTimeout OBJECT-TYPE=20 | SYNTAX Unsigned32 (0..600)=20 UNITS "seconds"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 " This object defines the timeout value that applies to an MTA-initiated AP-REQ/REP key management exchange with the Provisioning Server in SNMPv3 provisioning. It is the maximum timeout value and it may not be exceeded in the exponential back-off algorithm. If the DHCP option code 122 sub-option 5 is provided to the MTA, it=20 overwrites this value. | If this object is set to a zero value, the MTA MUST return | an 'inconsistentValue' in response to SNMP SET operations. | In non secure provisioning modes, the MTA MUST | MTA MUST return a zero value in response to SNMP GET | operations." REFERENCE=20 " PacketCable Security Specification."=20 DEFVAL {600}=20 ::=3D { pktcMtaDevServer 12 }=20 pktcMtaDevProvUnsolicitedKeyNomTimeout OBJECT-TYPE=20 | SYNTAX Unsigned32 (0..600)=20 UNITS "seconds"=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION =20 " This object defines the starting value of the timeout for the AP-REQ/REP Backoff and Retry mechanism with exponential timeout in SNMPv3 provisioning. If the DHCP option code 122 sub-option 5 is provided the MTA, it overwrites this value. | If this object is set to a zero value, the MTA MUST return | an 'inconsistentValue' in response to SNMP SET operations. | In non secure provisioning modes, the MTA MUST | MTA MUST return a zero value in response to SNMP GET | operations." REFERENCE=20 " PacketCable Security Specification."=20 DEFVAL {3}=20 ::=3D { pktcMtaDevServer 13}=20 pktcMtaDevProvUnsolicitedKeyMaxRetries OBJECT-TYPE=20 | SYNTAX Unsigned32 (0..32)=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 " This object contains a retry counter that applies to an MTA-initiated AP-REQ/REP key management exchange with the Provisioning Server in secure SNMPv3 provisioning. It is the maximum number of retries before the MTA stops attempting to establish a Security Association with Provisioning Server. If the DHCP option code 122 sub-option 5 is provided to the MTA, it overwrites this value. | If this object is set to a zero value, the MTA MUST return | an 'inconsistentValue' in response to SNMP SET operations. | In non secure provisioning modes, the MTA MUST | MTA MUST return a zero value in response to SNMP GET | operations." REFERENCE=20 " PacketCable Security Specification."=20 DEFVAL {8}=20 ::=3D { pktcMtaDevServer 14 }=20 These set of changes will be integrated in draft06. If the wg = participants have strong objections, please comment and we will consider = reverting the text back. Jean-Fran=E7ois=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Jan 21 19:51:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11046 for ; Fri, 21 Jan 2005 19:51:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs9kj-0007qf-N6 for ipcdn-archive@ietf.org; Fri, 21 Jan 2005 20:07:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs9Th-0008Kr-72; Fri, 21 Jan 2005 19:50:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs9Sv-00085r-G4 for ipcdn@megatron.ietf.org; Fri, 21 Jan 2005 19:49:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10775 for ; Fri, 21 Jan 2005 19:49:22 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs9it-0007mU-O5 for ipcdn@ietf.org; Fri, 21 Jan 2005 20:05:57 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j0M0mo1e028754; Fri, 21 Jan 2005 17:48:50 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] MTA MIB pktcMtaDevProvSolicitedKeyTimeout Date: Fri, 21 Jan 2005 17:48:50 -0700 Message-ID: Thread-Topic: [ipcdn] MTA MIB pktcMtaDevProvSolicitedKeyTimeout Thread-Index: AcUAEdnU7NUnKG5iT/C2p8tNBhFPFgABSMkAAAE6YOA= From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable Cc: enechamkin@broadcom.com X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable I wrote: > Along the same lines, scanning through the same genError use=20 > in the MIB, we have the same pb in=20 > pktcMtaDevProvUnsolicitedKeyMaxTimeout,=20 > pktcMtaDevProvUnsolicitedKeyNomTimeout,=20 > pktcMtaDevProvUnsolicitedKeyMaxRetries and many other timers. ^^^^^^^^^^^^^^^^^^^^^^ This was incorrect, all the other timers that had genErr return are = listed above and have been fixed. Jean-Fran=E7ois=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Jan 21 21:14:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15160 for ; Fri, 21 Jan 2005 21:14:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsB3g-00013E-IC for ipcdn-archive@ietf.org; Fri, 21 Jan 2005 21:31:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsAjf-0001Dt-12; Fri, 21 Jan 2005 21:10:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsAfG-00007D-EK for ipcdn@megatron.ietf.org; Fri, 21 Jan 2005 21:06:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14662 for ; Fri, 21 Jan 2005 21:06:12 -0500 (EST) Received: from pop-a065c10.pas.sa.earthlink.net ([207.217.121.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsAvF-0000rP-N3 for ipcdn@ietf.org; Fri, 21 Jan 2005 21:22:46 -0500 Received: from h-69-3-28-223.snvacaid.dynamic.covad.net ([69.3.28.223] helo=oemcomputer) by pop-a065c10.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CsAfC-0006A0-00 for ipcdn@ietf.org; Fri, 21 Jan 2005 18:06:10 -0800 Message-ID: <002501c50026$f33940a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [ipcdn] pktcMtaDevProvConfigKey Date: Fri, 21 Jan 2005 18:06:05 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Hi - > From: "Jean-Francois Mule" > To: > Sent: Friday, January 21, 2005 4:11 PM > Subject: RE: [ipcdn] pktcMtaDevProvConfigKey ... > > > The privacy algorithm is DES, the key length is 64 bits. > > > > Which DES mode? CBC? CFB? ECB? ...? Is there an IV for the DES? > This was there before, nobody commented.... Arg... > DES CBC mode as defined the reference of the object, PacketCable security > spec, http://www.packetcable.com/downloads/specs/PKT-SP-SEC-I11-040730.pdf , > section 6.3. I will add CBC mode in the text but I'm reluctant to mention the section > number or add more. Text now says: > The privacy algorithm is defined by the PacketCable > Security Specification, it is DES in CBC mode and the key > length is 64 bits. CBC mode requires an IV. Section 6.3 of the reference you gave seems to be about setting SNMP keys, where a 64-bit IV needs to be supplied. Other sections of the document seem to use other ways of deriving IVs, so something is still missing here. ... > > One can also formalize this using the WRITE-SYNTAX in the > > OBJECT clause of the conformance material. > Ok, this is a refinement, nice to have but believe the above is enough > for now (we are trying to close this revision tonight). Ok with me. Since there had been a previous question about nailing down implementation requirements in the conformance material, I thought it helpful to point out the *opportunity* (not requirement) to do so here. ... > > Ok, though I meant that the MTA would ALWAYS return a > > zero-length string in response to GET requests, not just in > > "non secure provisioning modes." > > Ok. In secure mode, one could get the actual key in a GET > and that could help troubleshoot some issues when the MTA > has pbs to decrypt the configuration file. No changes required - > if that's ok with you. This begs the question of what is meant by "secure mode". If it means "the SNMP request being processed arrived with an authPriv security level", then this solution won't work with, for example, AgentX infrastructure. In that environment, the subagent has no idea what the security level of the request was. All the security-related aspects of SNMP are handled in the master agent, and the AgentX protocol provides no way to communicate this information. If you *really* want keys to be readable (note that we went out of our way to prevent them from being read in the USM SNMPv3 security model), then the normal way of protecting them would be through the VACM configuration, permitting them to be read or written only by authorized users using authPriv requests. If "secure mode" means something else, then you're going to have a really complicated security considerations section, I fear. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Jan 24 04:29:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20870 for ; Mon, 24 Jan 2005 04:29:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct0ne-0004xG-5K for ipcdn-archive@ietf.org; Mon, 24 Jan 2005 04:46:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct0WE-0007Yb-VP; Mon, 24 Jan 2005 04:28:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct0S2-0007Dh-Qv for ipcdn@megatron.ietf.org; Mon, 24 Jan 2005 04:24:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20696 for ; Mon, 24 Jan 2005 04:23:59 -0500 (EST) Received: from europa.telenet-ops.be ([195.130.132.60]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct0iV-0004qO-4z for ipcdn@ietf.org; Mon, 24 Jan 2005 04:41:03 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by europa.telenet-ops.be (Postfix) with SMTP id 3A4B919804B for ; Mon, 24 Jan 2005 10:23:55 +0100 (MET) Received: from tcomlabs.com (dD5E00656.access.telenet.be [213.224.6.86]) by europa.telenet-ops.be (Postfix) with ESMTP id F189F198028 for ; Mon, 24 Jan 2005 10:23:54 +0100 (MET) Received: (qmail 2149 invoked from network); 24 Jan 2005 10:23:46 +0100 Received: from localhost (HELO gateway) (127.0.0.1) by localhost with SMTP; 24 Jan 2005 10:23:46 +0100 Received: from ([10.5.5.72]) by gateway.tcomlabs.com (MailMonitor for SMTP v1.2.2 ) ; Mon, 24 Jan 2005 10:23:43 +0100 (CET) From: "David De Reu" To: "IPCDN Mailing List" Subject: RE: [ipcdn] pktcSigDevCodecTable request for clarification Date: Mon, 24 Jan 2005 10:23:38 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 Importance: Normal In-Reply-To: Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Content-Transfer-Encoding: quoted-printable Thank you for your comments, Jean-Fran=E7ois. See inline. > > Some MTA vendors are a bit puzzled regarding what to include in the > > pktcSigDevCodecTable table. On their and my own behalf, I > > What strikes me in your introduction is the lack of operator's > view on this table, I'd be curious to see what the operators' > input is there. Me too, as a matter of fact. I hope that some of the actual "users" of th= is table are following this thread and are willing to provide some input. > > More specifically, there actually are two types of codecs: > > > > - First, the "real" voice codecs, like the ones listed in the > > PktcCodecType > > TEXTUAL-CONVENTION (PCMA, PCMU, G.729... etc) > > A note on this, during my review of draft00, on Tuesday, March > 18, 2003 at 11:33 AM, I wrote: > > - PktcCodecType TEXTUAL-CONVENTION > > See IETF AVT draft-ietf-avt-profile-new-13.txt, section 4.5: > > this draft is an update to rfc1890 and it defines the latest > > and greatest encoding names for audio video codecs. The > > PktcCodecType object definition should use the encoding names > > defined in AVT. In particular, g711a/mu must be replaced by > > PCMA/PCMU, etc. These changes were made in the latest > > PacketCable spec PKT-SP-MIB-SIG-I05-021127 and should be > > reflected in the IETF ipcdn ID. > The ID mentioned above is now RFC 3551. > > I'm not sure I understand your point or comment here but I'd > recommend keeping the TC based on the literals names used in > NCS-SIP/SDP to negotiate the codecs. Of course, I didn't mean to suggest a change here. I merely wanted to giv= e some exampes of what I meant by "real" voice codecs, since this is far fr= om an official term. > > In > > (Euro-)PacketCable/IPCablecom, this is the "telephone-event" > > "codec". > Where is the spec you are refering to? Can we have a look at it? Unfortunately, PacketCable specs are a bit vague about this, and IPCablec= om seems to have left it out entirely. I believe RFC2833 was primarily inten= ded for use in the Line Control Signaling architecure: see PKT-TR-ARCH-LCS-V01-010730, which is unfortunately rather outdated and strictly speaking a technical report instead of a specification, but also PKT-SP-EC-MGCP-I10-040402 (the NCS specification) for example uses. The bottom line is: RFC 2833 (called "telephone-event" in PacketCable), c= an be present in the NCS LocalConnectionOptions and in SDP (both in the m=3D= and a=3Drtpmap lines, via a dynamic payload type and the "telephone-event" encoding name). A number of MTA vendors support this feature. I have no i= dea whether it's used by operators in practice. > In the SDP media connection line (m=3D), you still have to indicate > a vocoder, even if you advertise support 2833 (which is done in > the media attribute line a=3D). That difference is key to > understand. Exactly. > > The question now is: do the codecs of the second type have to > > be included in > > the pktcSigDevCodecTable, or is this table just intended for > > "real" codecs? > I would say no based on the current definition and description > clause of this TC. Until now, that was my interpretation as well. However, some people have interpreted this differently, and it would be useful to agree on the exac= t interpretation. The problem is that "other(1)" has no strict interpretati= on. If it would be impossible to include RFC 2833, things would be clear, but now there is a "back door" through "other(1)". > > Either way, a clarification of some sort in the DESCRIPTION > > clause would be > > helpful to implementors (and testers, as a matter of fact). > If an integer value is not given for other codecs, or represented > in the TC, then testers cannot expect vendors to advertise it. True, hence the "other(1)" some vendors currently use if they feel they h= ave to include it. Given the requirement that all combinations have to be lis= ted in the codec table, this gives you a table that is half filled with "other(1)" in a manner of speaking. > RFC3551 does not make a special case for RFC 2833 either. Again true, another argument not to include it in the TC and hence the co= dec table. > > If they are to > > be included, currently the only way is to use "other (1)" as > > the type, which > > is of course allowed but not very informative. > In my opinion, they should not be included. Agreed. > If what you want is > the MTA to indicate support for RFC2833, then this belongs to > another MIB object. Currently, there is no such MIB object indeed, but by using an NCS "Audit Endpoint" command, the MTA can be asked for its capabilities - support fo= r "telephone-event" being one of these. I understand that you are not suggesting that we need such an object, but before someone does: I see no reason to include MIB objects for all of these capabilities, because you would then actually be doing "NCS over SNMP" :) Which is, in my opinion, another reason not to include RFC2833 in the cod= ec table. Things like the supported voice codecs and silence suppression capability etc. are rather fundamental, and do belong in the MIBs, but ex= tra features like support for RFC2833, proprietary solutions for DTMF relay, additional NCS signaling packages, etc. belong in the capabilities return= ed upon an "Audit Endpoint" command. > > This leads me to my second point: if things like "telephone-event" ar= e > > supposed to be included in the pktcSigDevCodecTable, then I > > at least suggest > > extending the PktcCodecType with something like "telephoneEvent (15)"= . > But then this is not a valid codec literal name as the TC > mandates so that is not a good option to me. Agreed. To relieve all doubt, and to make things simpler for vendors, I would suggest a subtle change of the DESCRIPTION of pktcSigDevCodecTable. A first suggestion: pktcSigDevCodecTable OBJECT-TYPE SYNTAX SEQUENCE OF PktcSigDevCodecEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " This table describes the MTA supported voice codec types. This table MUST NOT include non-voice codecs. A MTA MUST populate this table with all possible combinations of codecs it supports for simultaneous operation. For example, ..." "Design decisions" behind this wording: - if the actual codecs (all but "other(1)", "unknown(2)" and "reserved(4)= ") from the PktcCodecType TEXTUAL-CONVENTION are used, the new "MUST NOT" requirement is automagically fulfilled and nothing changes for existing implementations; - the "other(1)", "unknown(2)" and "reserved(4)" from the TC are limited = to *voice* codecs within the context of the pktcSigDevCodecTable, which was = the original intention. Any support for or objections against this change? Thanks, David _____________________________________________________ David De Reu tComLabs Stapelplein 70/004 =96 9000 Ghent =96 Belgium Tel: +32 9 269 22 91 =96 Fax: +32 9 329 31 74 www.tComLabs.com _____________________________________________________ _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Jan 24 09:47:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16405 for ; Mon, 24 Jan 2005 09:47:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct5lI-0006MJ-0E for ipcdn-archive@ietf.org; Mon, 24 Jan 2005 10:04:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct5LQ-0007lI-0i; Mon, 24 Jan 2005 09:37:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct5Dv-00044s-79 for ipcdn@megatron.ietf.org; Mon, 24 Jan 2005 09:29:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14970 for ; Mon, 24 Jan 2005 09:29:44 -0500 (EST) Received: from go4.ext.ti.com ([192.91.75.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct5UO-0005Zy-5k for ipcdn@ietf.org; Mon, 24 Jan 2005 09:46:51 -0500 Received: from dlep90.itg.ti.com ([157.170.152.54]) by go4.ext.ti.com (8.13.1/8.13.1) with ESMTP id j0OET8bT007903; Mon, 24 Jan 2005 08:29:08 -0600 (CST) Received: from dlee2k71.ent.ti.com (localhost [127.0.0.1]) by dlep90.itg.ti.com (8.12.11/8.12.11) with ESMTP id j0OET8SO007033; Mon, 24 Jan 2005 08:29:08 -0600 (CST) Received: from dlee2k05.ent.ti.com ([157.170.152.114]) by dlee2k71.ent.ti.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 24 Jan 2005 08:29:08 -0600 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, 24 Jan 2005 08:29:08 -0600 Message-ID: Thread-Topic: pktcMtaDevProvisioningTimer description Thread-Index: AcUCIQ+PaWy9kpJcTnqx4uSIsLckgg== From: "Kumar, Satish" To: X-OriginalArrivalTime: 24 Jan 2005 14:29:08.0456 (UTC) FILETIME=[1089A680:01C50221] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: Eugene Nechamkin , Jean-Francois Mule Subject: [ipcdn] pktcMtaDevProvisioningTimer description X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable The beow mib is a read-write MIB. When the MIB value is changed after the MTA is accessible by SNMP station, then what action does the MTA has to do?? I would suggest to change read-write to read-only access.=20 pktcMtaDevProvisioningTimer OBJECT-TYPE=20 SYNTAX Unsigned32 (0..30) =20 UNITS "minutes" =20 MAX-ACCESS read-write =20 STATUS current =20 DESCRIPTION =20 " This object defines the time interval for the provisioning=20 flow to complete. The MTA MUST finish all provisioning=20 operations starting from the moment when an MTA receives=20 its DHCP ACK and ending at the moment when the MTA =20 downloads its configuration file (e.g., MTA5 to MTA23)=20 within the period of time set by this object.=20 Failure to comply with this condition constitutes=20 a provisioning flow failure. If the object is set to 0,=20 the MTA MUST ignore the provisioning timer condition." =20 REFERENCE=20 " PacketCable MTA Device Provisioning Specification."=20 DEFVAL {10} =20 ::=3D {pktcMtaDevBase 10} Comments please.. Thx, Satish _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Jan 24 11:07:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25026 for ; Mon, 24 Jan 2005 11:07:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct70q-0001Bb-3s for ipcdn-archive@ietf.org; Mon, 24 Jan 2005 11:24:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct6cz-00047W-JY; Mon, 24 Jan 2005 10:59:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct6ao-0003kB-FB for ipcdn@megatron.ietf.org; Mon, 24 Jan 2005 10:57:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24227 for ; Mon, 24 Jan 2005 10:57:27 -0500 (EST) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct6rH-0000kV-Ov for ipcdn@ietf.org; Mon, 24 Jan 2005 11:14:35 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id j0OG0Al6028155 for ; Mon, 24 Jan 2005 09:00:11 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id j0OFtxcm030873 for ; Mon, 24 Jan 2005 09:56:00 -0600 Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id ; Mon, 24 Jan 2005 10:57:18 -0500 Message-ID: <62173B970AE0A044AED8723C3BCF23810636B261@ma19exm01.e6.bcs.mot.com> From: Murwin William-LWM008 To: "IPCDN (E-mail) (E-mail)" Date: Mon, 24 Jan 2005 10:57:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: "'Jean-Francois Mule'" , Patrick Michael-LZZ007 , "'Richard_woundy@cable.comcast.com'" Subject: [ipcdn] The prefix for the DOCSIS-IEFT-QOS-MIB X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab I am currently in the process of updating the draft-ietf-ipcdn-qos-mib-11.txt, in-order to address the rooting issue of this MIB. There has been significant discussion about how this version and version 4 will exist together in SNMP manager and agents. IPCDN even went as far as changing this mib MODULE-IDENTIER in order to be able to support both mibs within the same SNMP manager. However, from my own personal experience this seems not to be enough for some SNMP managers, and usually only one of the version can only be installed. With this update I am willing on change the the MIB Module Descriptor from "docsQosMIB" to "docsIetfQosMIB" and changing all the MIB objects prefix from "docsQos" to "docsIetfQos". Please respond if you feel strongly either way. Sincerely, Will ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 786-7594 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Jan 24 16:36:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02528 for ; Mon, 24 Jan 2005 16:36:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtC9b-0007jZ-Ph for ipcdn-archive@ietf.org; Mon, 24 Jan 2005 16:53:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtBgY-0000nK-95; Mon, 24 Jan 2005 16:23:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtBLd-0001Nk-BT for ipcdn@megatron.ietf.org; Mon, 24 Jan 2005 16:02:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25286 for ; Mon, 24 Jan 2005 16:02:06 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtBc9-0004sz-GQ for ipcdn@ietf.org; Mon, 24 Jan 2005 16:19:16 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j0OL1M1e020761; Mon, 24 Jan 2005 14:01:23 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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, 24 Jan 2005 14:01:22 -0700 Message-ID: Thread-Topic: The prefix for the DOCSIS-IEFT-QOS-MIB Thread-Index: AcUCLWV4Fh3bQoP5T3OIXjbPcWnXhAAKldQA From: "Jean-Francois Mule" To: "Murwin William-LWM008" , "IPCDN (E-mail) (E-mail)" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: Patrick Michael-LZZ007 , "Richard Woundy @ Comcast" Subject: [ipcdn] RE: The prefix for the DOCSIS-IEFT-QOS-MIB X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable > Please respond if you feel strongly either way. Please provide your input to Will and the ipcdn list by COB Wednesday January 26 before 10am ET. Jean-Francois=20 > -----Original Message----- > From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com]=20 > Sent: Monday, January 24, 2005 8:57 AM > To: IPCDN (E-mail) (E-mail) > Cc: Jean-Francois Mule; Richard Woundy @ Comcast; Patrick=20 > Michael-LZZ007 > Subject: The prefix for the DOCSIS-IEFT-QOS-MIB >=20 >=20 > I am currently in the process of updating the=20 > draft-ietf-ipcdn-qos-mib-11.txt, in-order to address the=20 > rooting issue of this MIB. >=20 > There has been significant discussion about how this version=20 > and version 4 will exist together in SNMP manager and agents.=20 > IPCDN even went as far as changing this mib MODULE-IDENTIER=20 > in order to be able to support both mibs within the same SNMP=20 > manager. However, from my own personal experience this seems=20 > not to be enough for some SNMP managers, and usually only one=20 > of the version can only be installed.=20 >=20 > With this update I am willing on change the the MIB Module=20 > Descriptor from "docsQosMIB" to "docsIetfQosMIB" and changing=20 > all the MIB objects prefix from "docsQos" to "docsIetfQos". >=20 > Please respond if you feel strongly either way. >=20 > Sincerely, > Will >=20 > ______________________________ > William Murwin > Broadband Communications Sector > Motorola Inc. > Email: W.Murwin@motorola.com > Tel: (508) 786-7594 >=20 >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Jan 24 17:04:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07657 for ; Mon, 24 Jan 2005 17:04:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtCaK-0001FW-Ro for ipcdn-archive@ietf.org; Mon, 24 Jan 2005 17:21:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtCEb-0007aV-Nd; Mon, 24 Jan 2005 16:58:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtC4J-0000lH-9N for ipcdn@megatron.ietf.org; Mon, 24 Jan 2005 16:48:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04496 for ; Mon, 24 Jan 2005 16:48:16 -0500 (EST) Received: from pop-a065d10.pas.sa.earthlink.net ([207.217.121.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtCKr-0008Vq-Dc for ipcdn@ietf.org; Mon, 24 Jan 2005 17:05:27 -0500 Received: from h-66-167-206-251.snvacaid.dynamic.covad.net ([66.167.206.251] helo=oemcomputer) by pop-a065d10.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CtC4D-0004cc-00 for ipcdn@ietf.org; Mon, 24 Jan 2005 13:48:13 -0800 Message-ID: <005a01c5025e$70e71160$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn \(E-mail\)" References: <62173B970AE0A044AED8723C3BCF23810636B261@ma19exm01.e6.bcs.mot.com> Subject: Re: [ipcdn] The prefix for the DOCSIS-IEFT-QOS-MIB Date: Mon, 24 Jan 2005 13:48:28 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Hi - > From: "Murwin William-LWM008" > To: "IPCDN (E-mail) (E-mail)" > Cc: "'Jean-Francois Mule'" ; "Patrick Michael-LZZ007" ; > Sent: Monday, January 24, 2005 7:57 AM > Subject: [ipcdn] The prefix for the DOCSIS-IEFT-QOS-MIB ... > There has been significant discussion about how this version and version 4 > will exist together in SNMP manager and agents. IPCDN even went as far > as changing this mib MODULE-IDENTIER in order to be able to support > both mibs within the same SNMP manager. However, from my own > personal experience this seems not to be enough for some SNMP managers, > and usually only one of the version can only be installed. ... I'm amazed that after these years these broken tools could still be in use. Though the need to keep name spaces distinct has been obvious since RFC 1212 in 1991, and was spelled out even more clearly back in 1993, in RFC 1442. If a vendor can't fix an obvious error after a decade, it's time to find a different implementation. But, if this broken gear is pervasive in the IPCDN sector, and vendors aren't willing or able to do things correctly, then Murwin's suggestion is a prudent course to follow. (Note that if both versions are to in some sense be considered "standards", then one could argue that RFC 2578 section 3.1 paragraph four applies.) Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Jan 24 18:35:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17981 for ; Mon, 24 Jan 2005 18:35:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtE0j-0005NH-S1 for ipcdn-archive@ietf.org; Mon, 24 Jan 2005 18:52:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtDXF-0005g5-2v; Mon, 24 Jan 2005 18:22:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtDTU-0001sn-Go for ipcdn@megatron.ietf.org; Mon, 24 Jan 2005 18:18:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15830 for ; Mon, 24 Jan 2005 18:18:21 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtDk5-0004Xw-AL for ipcdn@ietf.org; Mon, 24 Jan 2005 18:35:33 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j0ONHo1e025250; Mon, 24 Jan 2005 16:17:51 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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: [ipcdn] pktcMtaDevProvConfigKey Date: Mon, 24 Jan 2005 16:17:50 -0700 Message-ID: Thread-Topic: [ipcdn] pktcMtaDevProvConfigKey Thread-Index: AcUAKBUdW0fQYMeUTWyyh7973ZY7JgCL9Neg From: "Jean-Francois Mule" To: "Randy Presuhn" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: quoted-printable X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: quoted-printable Randy, I'll start with a few clarifications. See additional comments inline as well. You wrote: > CBC mode requires an IV. Section 6.3 of the reference you=20 > gave seems to be about setting SNMP keys, where a 64-bit IV=20 > needs to be supplied. Other sections of the document seem to=20 > use other ways of deriving IVs, so something is still missing here. DES CBC mode for SNMPv3 requires an IV indeed. The object description is misleading and the explanation I provided (section 6.3 of the security spec) was not the right one. I gave the reference to setting the SNMPv3 keys, where a 64-bit IV needs to be supplied. I pasted it quickly but this section does not seem to apply. Clarification:=20 This config file key is not the same as the key used in SNMPv3 Privacy. The key contained by the MIB Object pktcMtaDevProvConfigKey is the key used to 'encrypt' the configuration file, not the key to secure the SNMPv3 communications.=20 The PacketCable/IPcablecom requirements for the config file key are: - Use the same 'encryption algorithm' as the one chosen for SNMPv3 privacy (Privacy must be enabled), - 'DES in CBC mode' is the only privacy algorithm chosen today (Section 6.3) - For DES in CBC mode, during encryption, use "IV=3D0" for all cases (Section 7.1.1.2.2 of http://www.packetcable.com/downloads/specs/PKT-SP-SEC-I11-040730.pdf , first paragraph of page 120). Based on your comment and input from Sumanth, our recommendation would be to change the description to: pktcMtaDevProvConfigKey OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0|8)) MAX-ACCESS read-write STATUS current DESCRIPTION "This object contains the key used to encrypt/decrypt the configuration file when the secure provisioning mode is selected to provision the MTA. The value of this object is provided along with the=20 configuration file information (pktcMtaDevConfigFile) and hash (pktcMtaDevProvConfigHash) by the Provisioning Server via SNMP SET once the configuration file has been created as defined by the PacketCable Security=20 specification. If the configuration file the MTA receives is not=20 encrypted, the length of this object value is zero.=20 If the file is encrypted, then the algorithm is DES in CBC mode and the length of this object value is 64 bits (an IV of zero is used to encrypt the file as specified in the PacketCable Security specification). If this object is set at any other provisioning steps than=20 the one(s) allowed by the PacketCable MTA Device Provisioning Specification, or, if this object is explicitely set to a zero-length string value, the MTA=20 MUST return an 'inconsistentValue' error. This object must not be used in non secure provisioning mode. In non secure provisioning modes, the MTA MUST return an 'inconsistentValue' in response to SNMP SET=20 operations, and, the MTA MUST return a zero-length string in response to SNMP GET operations." REFERENCE " PacketCable MTA Device Provisioning Specification; PacketCable Security Specification." ::=3D { pktcMtaDevServer 10 }=20 > ... > > > Ok, though I meant that the MTA would ALWAYS return a zero-length=20 > > > string in response to GET requests, not just in "non secure=20 > > > provisioning modes." > > > > Ok. In secure mode, one could get the actual key in a GET > > and that could help troubleshoot some issues when the MTA > > has pbs to decrypt the configuration file. No changes required - if=20 > > that's ok with you. >=20 > This begs the question of what is meant by "secure mode". Note that we say secure provisioning mode. It is defined in the provisioning spec,=20 http://www.packetcable.com/downloads/specs/PKT-SP-PROV-I10-040730.pdf , section 7. This is a normative reference to the MIB module and implementors building such devices should know. I paste here the relevant intro: An MTA device is provisioned via one of three provisioning flows: - The Secure Flow supports Kerberos mutual authentication between the MTA and the provisioning system, as well as Kerberized SNMPv3 messaging. The Secure Flow MUST be supported by PacketCable MTAs and the Provisioning Applications. - The Basic Flows are a simplified DOCSIS-like provisioning flows with no Kerberos or SNMPv3 security and no SNMP enrollment via SNMP INFORM. The Basic Flows SHOULD be supported by PacketCable MTAs and Provisioning Applications. - The Hybrid Flows are essentially the Secure flow with the Kerberos message exchanges removed, and SNMPv2c substituted for SNMPv3. The Hybrid Flows SHOULD be supported by PacketCable MTAs and Provisioning Applications . The bottom line is compliant implementations MUST support the secure provisioning mode. We introduced the basic and hybrid modes to meet some operator requirements, when security at the DOCSIS MAC layer (BPI+) is provided and the back office tools our operators have are not yet upgrade to deal with the secure flow provisioning. > If it means "the SNMP request being processed arrived with > an authPriv security level", then this solution won't work=20 > with, for example, AgentX infrastructure. In that=20 > environment, the subagent has no idea what the security level=20 > of the request was. All the security-related aspects of SNMP=20 > are handled in the master agent, and the AgentX protocol=20 > provides no way to communicate this information. >=20 > If you *really* want keys to be readable (note that we went=20 > out of our way to prevent them from being read in the USM=20 > SNMPv3 security model), then the normal way of protecting=20 > them would be through the VACM configuration, permitting them=20 > to be read or written only by authorized users using authPriv=20 > requests. >=20 > If "secure mode" means something else, then you're going to=20 > have a really complicated security considerations section, I fear. a PacketCable MTA can be provisioned in 3 modes: - Secure, which enables SNMPv3 between the MTA and its Manager - Basic or Hybrid, where the access is 'SNMPv2' Sumanth & Jean-Francois. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Jan 24 19:02:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20245 for ; Mon, 24 Jan 2005 19:02:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtEQi-0006Ox-Bz for ipcdn-archive@ietf.org; Mon, 24 Jan 2005 19:19:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtDzy-0007Tc-I8; Mon, 24 Jan 2005 18:51:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtDvF-0005hv-FO for ipcdn@megatron.ietf.org; Mon, 24 Jan 2005 18:47:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19125 for ; Mon, 24 Jan 2005 18:47:01 -0500 (EST) Received: from pop-a065c28.pas.sa.earthlink.net ([207.217.121.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtEBo-0005qp-43 for ipcdn@ietf.org; Mon, 24 Jan 2005 19:04:14 -0500 Received: from h-66-167-206-251.snvacaid.dynamic.covad.net ([66.167.206.251] helo=oemcomputer) by pop-a065c28.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CtDv6-0006ZK-00 for ipcdn@ietf.org; Mon, 24 Jan 2005 15:46:56 -0800 Message-ID: <001801c5026f$0628f4e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [ipcdn] pktcMtaDevProvConfigKey Date: Mon, 24 Jan 2005 15:47:09 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Hi - > From: "Jean-Francois Mule" > To: "Randy Presuhn" ; > Cc: "Sumanth Channabasappa" > Sent: Monday, January 24, 2005 3:17 PM > Subject: RE: [ipcdn] pktcMtaDevProvConfigKey ... > I'll start with a few clarifications. See additional comments inline as > well. Thanks. I have some responses inline below. ... > Clarification: > This config file key is not the same as the key used in SNMPv3 Privacy. > The key contained by the MIB Object pktcMtaDevProvConfigKey is the key > used to 'encrypt' the configuration file, not the key to secure the > SNMPv3 communications. So far so good. > The PacketCable/IPcablecom requirements for the config file key are: > - Use the same 'encryption algorithm' as the one chosen for SNMPv3 > privacy (Privacy must be enabled), Multiple encryption algorithms may be in use concurrently in an SNMP engine. For example, DES (RFC 3414) and AES (RFC 3826) can both be used in USM. > - 'DES in CBC mode' is the only privacy algorithm chosen today (Section > 6.3) Is the algorithm visible to or controllable via the management interface? > - For DES in CBC mode, during encryption, use "IV=0" for all cases > (Section 7.1.1.2.2 of > http://www.packetcable.com/downloads/specs/PKT-SP-SEC-I11-040730.pdf , > first paragraph of page 120). Fine with me, as long as it's spelled out. > Based on your comment and input from Sumanth, our recommendation would > be to change the description to: > pktcMtaDevProvConfigKey OBJECT-TYPE > SYNTAX OCTET STRING (SIZE(0|8)) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "This object contains the key used to encrypt/decrypt > the configuration file when the secure provisioning > mode is selected to provision the MTA. > > The value of this object is provided along with the > configuration file information (pktcMtaDevConfigFile) > and hash (pktcMtaDevProvConfigHash) by the Provisioning > Server via SNMP SET once the configuration file has been > created as defined by the PacketCable Security > specification. > > If the configuration file the MTA receives is not > encrypted, the length of this object value is zero. > If the file is encrypted, then the algorithm is DES in > CBC mode and the length of this object value is 64 bits > (an IV of zero is used to encrypt the file as specified > in the PacketCable Security specification). Nice and clear. Thanks. > If this object is set at any other provisioning steps than > the one(s) allowed by the PacketCable MTA Device > Provisioning Specification, or, if this object is > explicitely set to a zero-length string value, the MTA > MUST return an 'inconsistentValue' error. If that's what you really want. > This object must not be used in non secure provisioning > mode. In non secure provisioning modes, the MTA MUST > return an 'inconsistentValue' in response to SNMP SET This is not implementable in AgentX environments, since the subagent has no way of knowing what the security level of a given SNMP request is. This kind of constraint should be left to VACM confirguration, not the object's behaviour. > operations, and, the MTA MUST return a zero-length string > in response to SNMP GET operations." ... The ", and," makes the specification ambiguous. Does it ALWAYS return a zero-length string, or only when in "non-secure provisioning modes"? If it's the latter, it won't be implementable using subagent technology like AgentX, since that protocol does not give the subagent any knowledge of the security level in effect for a given operation request. If you really do want these to be readable, then VACM configuration is the correct way to prevent unencrypted access to this information. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Jan 24 20:06:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26233 for ; Mon, 24 Jan 2005 20:06:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtFQh-0000Zt-Rp for ipcdn-archive@ietf.org; Mon, 24 Jan 2005 20:23:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtF5y-0003WC-MK; Mon, 24 Jan 2005 20:02:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtF2F-0002J0-Gh for ipcdn@megatron.ietf.org; Mon, 24 Jan 2005 19:58:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25905 for ; Mon, 24 Jan 2005 19:58:21 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtFIq-0000Ip-Qr for ipcdn@ietf.org; Mon, 24 Jan 2005 20:15:33 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j0P0vl1e019535 for ; Mon, 24 Jan 2005 17:57:47 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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: [ipcdn] pktcMtaDevProvConfigKey Date: Mon, 24 Jan 2005 17:57:46 -0700 Message-ID: Thread-Topic: [ipcdn] pktcMtaDevProvConfigKey Thread-Index: AcUCcS1JsWDkZwzrSkyXIXEO0SPCZAABsPqg From: "Sumanth Channabasappa" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Randy, Thanks, a few comments inline: =20 > The PacketCable/IPcablecom requirements for the config file key are: > - Use the same 'encryption algorithm' as the one chosen for SNMPv3=20 > privacy (Privacy must be enabled), Multiple encryption algorithms may be in use concurrently in an SNMP engine. For example, DES (RFC 3414) and AES (RFC 3826) can both be used in USM. [s] True, but the PacketCable Security Specification limits this to DES/CBC (Section 6.3.1 of http://www.packetcable.com/downloads/specs/PKT-SP-SEC-I11-040730.pdf) > - 'DES in CBC mode' is the only privacy algorithm chosen today=20 > (Section > 6.3) Is the algorithm visible to or controllable via the management interface? [s] It is controllable via the communication defined between the MTA and the Provisioning Server (using Kerberos) as defined in the Security Specification. However, the chosen privacy algorithm (DES or NULL) can neither be controlled nor is it reflected in the 'MTA MIB'.=20 =20 =20 > This object must not be used in non secure provisioning > mode. In non secure provisioning modes, the MTA MUST > return an 'inconsistentValue' in response to SNMP SET This is not implementable in AgentX environments, since the subagent has no way of knowing what the security level of a given SNMP request is. This kind of constraint should be left to VACM confirguration, not the object's behaviour. [s] Just to make it clear, 'Secure Provisioning' mode or 'non secure provisioning' modes refer to the provisioning mode an MTA was provisioned in and not necessarily the level of SNMP security. Perhaps we should change 'non secure provisioning modes' to 'Basic and Hybrid Flows' (Since they are the technical terms used in PacketCable). Would that help? regards Sumanth=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Jan 24 20:38:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28204 for ; Mon, 24 Jan 2005 20:38:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtFvb-0001ac-6E for ipcdn-archive@ietf.org; Mon, 24 Jan 2005 20:55:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtFcr-0002yL-4g; Mon, 24 Jan 2005 20:36:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtFc8-0002jJ-20 for ipcdn@megatron.ietf.org; Mon, 24 Jan 2005 20:35:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27917 for ; Mon, 24 Jan 2005 20:35:25 -0500 (EST) Received: from pop-a065c05.pas.sa.earthlink.net ([207.217.121.183]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtFsg-0001Ui-Qq for ipcdn@ietf.org; Mon, 24 Jan 2005 20:52:38 -0500 Received: from h-66-167-206-251.snvacaid.dynamic.covad.net ([66.167.206.251] helo=oemcomputer) by pop-a065c05.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CtFc2-0007Ql-00 for ipcdn@ietf.org; Mon, 24 Jan 2005 17:35:22 -0800 Message-ID: <000c01c5027e$2ae961c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [ipcdn] pktcMtaDevProvConfigKey Date: Mon, 24 Jan 2005 17:35:35 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Hi - > From: "Sumanth Channabasappa" > To: > Sent: Monday, January 24, 2005 4:57 PM > Subject: RE: [ipcdn] pktcMtaDevProvConfigKey ... >> The PacketCable/IPcablecom requirements for the config file key are: >> - Use the same 'encryption algorithm' as the one chosen for SNMPv3 >> privacy (Privacy must be enabled), > >Multiple encryption algorithms may be in use concurrently in an SNMP >engine. For example, DES (RFC 3414) and AES (RFC 3826) can both be used >in USM. >[s] True, but the PacketCable Security Specification limits this to >DES/CBC (Section 6.3.1 of >http://www.packetcable.com/downloads/specs/PKT-SP-SEC-I11-040730.pdf) The point is that (1) subagent protocols provide no way for a subagent to know which encryption algorithm was used for a given request (2) SNMP engines may support multiple encryption algorithms (3) if PacketCable ever permits the use of the more secure AES, specifying things in terms of "the same 'encryption algorithm; as the one [sic] chosen for SNMPv3 privacy" is just plain broken. > > - 'DES in CBC mode' is the only privacy algorithm chosen today > > (Section > > 6.3) > > Is the algorithm visible to or controllable via the management > interface? > [s] It is controllable via the communication defined between the MTA and > the Provisioning Server (using Kerberos) as defined in the Security > Specification. However, the chosen privacy algorithm (DES or NULL) can > neither be controlled nor is it reflected in the 'MTA MIB'. As long as it's DES-CBC or nothing, you're probably ok. If the architecture is expected to ever be able to support anything else, you might give it some thought. >> This object must not be used in non secure provisioning >> mode. In non secure provisioning modes, the MTA MUST >> return an 'inconsistentValue' in response to SNMP SET > >This is not implementable in AgentX environments, since the subagent has >no way of knowing what the security level of a given SNMP request is. >This kind of constraint should be left to VACM confirguration, not the >object's behaviour. >[s] Just to make it clear, 'Secure Provisioning' mode or 'non secure >provisioning' modes refer to the provisioning mode an MTA was >provisioned in and not necessarily the level of SNMP security. Perhaps >we should change 'non secure provisioning modes' to 'Basic and Hybrid >Flows' (Since they are the technical terms used in PacketCable). Would >that help? It would help immensely. When I read Jean-Francois' clarification, the part that said " - The Secure Flow supports Kerberos mutual authentication between the MTA and the provisioning system, as well as Kerberized SNMPv3 messaging. The Secure Flow MUST be supported by PacketCable MTAs and the Provisioning Applications" led me to believe that the text required different behaviour depending on whether information was being accessed AuthPriv or not. Sorry about the confusion. As long the "provisioning mode" has nothing to do with the SNMP version or security level is use, I'll be less worried about it. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Jan 25 01:54:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17630 for ; Tue, 25 Jan 2005 01:54:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtKrG-0003Ne-CT for ipcdn-archive@ietf.org; Tue, 25 Jan 2005 02:11:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtKZ9-0007bK-RH; Tue, 25 Jan 2005 01:52:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtKUs-00078P-3x for ipcdn@megatron.ietf.org; Tue, 25 Jan 2005 01:48:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17426 for ; Tue, 25 Jan 2005 01:48:17 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtKlV-0003Cb-WE for ipcdn@ietf.org; Tue, 25 Jan 2005 02:05:31 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j0P6lh1e028190 for ; Mon, 24 Jan 2005 23:47:44 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] pktcMtaDevProvConfigKey Date: Mon, 24 Jan 2005 23:47:43 -0700 Message-ID: Thread-Topic: [ipcdn] pktcMtaDevProvConfigKey Thread-Index: AcUCfqfxrm8dHxegQGe0+NtbuRezCwAKYBIg From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: quoted-printable Hi Randy, Inline. Jean-Fran=E7ois=20 > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 > Sent: Monday, January 24, 2005 6:36 PM > To: ipcdn@ietf.org > Subject: Re: [ipcdn] pktcMtaDevProvConfigKey >=20 >=20 > Hi - >=20 > > From: "Sumanth Channabasappa" > > To: > > Sent: Monday, January 24, 2005 4:57 PM > > Subject: RE: [ipcdn] pktcMtaDevProvConfigKey > ... > >> The PacketCable/IPcablecom requirements for the config=20 > file key are: > >> - Use the same 'encryption algorithm' as the one chosen for SNMPv3=20 > >> privacy (Privacy must be enabled), > > > >Multiple encryption algorithms may be in use concurrently in an SNMP=20 > >engine. For example, DES (RFC 3414) and AES (RFC 3826) can=20 > both be used=20 > >in USM. [s] True, but the PacketCable Security Specification limits=20 > >this to DES/CBC (Section 6.3.1 of > >http://www.packetcable.com/downloads/specs/PKT-SP-SEC-I11-040730.pdf) >=20 > The point is that > (1) subagent protocols provide no way for a subagent to know > which encryption algorithm was used for a given request > (2) SNMP engines may support multiple encryption algorithms > (3) if PacketCable ever permits the use of the more secure AES, > specifying things in terms of "the same 'encryption=20 > algorithm; as the > one [sic] chosen for SNMPv3 privacy" is just plain broken. Your comment here is on the PacketCable and Ipcablecom 1.0 security = specifications to which the MTA MIB module is just providing managed = objects. I would not argue that some improvements could be made in the = spec itself - but that's what we have today and we can't fix this by MIB = changes. This is not specific to IPCDN: we define often mibs after = protocols and when we find issues, we log them for the next revision. I = think we can record your comment and pass it on to the proper folks for = consideration when they update the security spec. Ok? >=20 > > > - 'DES in CBC mode' is the only privacy algorithm chosen today=20 > > > (Section > > > 6.3) > > > > Is the algorithm visible to or controllable via the management=20 > > interface? [s] It is controllable via the communication defined=20 > > between the MTA and the Provisioning Server (using Kerberos) as=20 > > defined in the Security Specification. However, the chosen privacy=20 > > algorithm (DES or NULL) can neither be controlled nor is it=20 > reflected=20 > > in the 'MTA MIB'. >=20 > As long as it's DES-CBC or nothing, you're probably ok. If=20 > the architecture is expected to ever be able to support=20 > anything else, you might give it some thought. Agreed. >=20 > >> This object must not be used in non secure provisioning > >> mode. In non secure provisioning modes, the MTA MUST > >> return an 'inconsistentValue' in response to SNMP SET > > > >This is not implementable in AgentX environments, since the subagent=20 > >has no way of knowing what the security level of a given=20 > SNMP request=20 > >is. This kind of constraint should be left to VACM=20 > confirguration, not=20 > >the object's behaviour. [s] Just to make it clear, 'Secure=20 > >Provisioning' mode or 'non secure provisioning' modes refer to the=20 > >provisioning mode an MTA was provisioned in and not necessarily the=20 > >level of SNMP security. Perhaps we should change 'non secure=20 > >provisioning modes' to 'Basic and Hybrid Flows' (Since they are the=20 > >technical terms used in PacketCable). Would that help? >=20 > It would help immensely. I would actually rather not since we now use "provisioning modes" = through the mib module. I would prefer introducing a paragraph or 2 = upfront specifying what the provisioning modes are and what they refer = to in terms of provisioning flows. Is that ok? > When I read Jean-Francois'=20 > clarification, the part that said " - The Secure Flow=20 > supports Kerberos mutual authentication between the MTA and=20 > the provisioning system, as well as Kerberized SNMPv3=20 > messaging. The Secure Flow MUST be supported by PacketCable=20 > MTAs and the Provisioning Applications" led me to believe=20 > that the text required different behaviour depending on=20 > whether information was being accessed AuthPriv or not. =20 We can point this out in the new section proposed above. > Sorry about the confusion. As long the "provisioning mode"=20 > has nothing to do with the SNMP version or security level is=20 > use, I'll be less worried about it. Thanks for your comments. >=20 > Randy >=20 >=20 >=20 > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn >=20 >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Jan 25 02:10:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25794 for ; Tue, 25 Jan 2005 02:10:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtL6i-0003vH-Lg for ipcdn-archive@ietf.org; Tue, 25 Jan 2005 02:27:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtKo6-0004lZ-O1; Tue, 25 Jan 2005 02:08:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtKmi-00048N-Vq for ipcdn@megatron.ietf.org; Tue, 25 Jan 2005 02:06:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23092 for ; Tue, 25 Jan 2005 02:06:43 -0500 (EST) Received: from pop-a065d10.pas.sa.earthlink.net ([207.217.121.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtL3L-0003kx-Dq for ipcdn@ietf.org; Tue, 25 Jan 2005 02:23:57 -0500 Received: from h-66-167-206-251.snvacaid.dynamic.covad.net ([66.167.206.251] helo=oemcomputer) by pop-a065d10.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CtKmd-0006Im-00 for ipcdn@ietf.org; Mon, 24 Jan 2005 23:06:39 -0800 Message-ID: <000801c502ac$6b9cdd40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [ipcdn] pktcMtaDevProvConfigKey Date: Mon, 24 Jan 2005 23:05:40 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Hi - > From: "Jean-Francois Mule" > To: > Sent: Monday, January 24, 2005 10:47 PM > Subject: RE: [ipcdn] pktcMtaDevProvConfigKey ... > > The point is that > > (1) subagent protocols provide no way for a subagent to know > > which encryption algorithm was used for a given request > > (2) SNMP engines may support multiple encryption algorithms > > (3) if PacketCable ever permits the use of the more secure AES, > > specifying things in terms of "the same 'encryption > > algorithm; as the > > one [sic] chosen for SNMPv3 privacy" is just plain broken. > > Your comment here is on the PacketCable and Ipcablecom 1.0 security > specifications to which the MTA MIB module is just providing managed objects. > I would not argue that some improvements could be made in the spec itself - > but that's what we have today and we can't fix this by MIB changes. This is > not specific to IPCDN: we define often mibs after protocols and when we > find issues, we log them for the next revision. I think we can record your > comment and pass it on to the proper folks for consideration when they > update the security spec. > Ok? Ok. ... > > >level of SNMP security. Perhaps we should change 'non secure > > >provisioning modes' to 'Basic and Hybrid Flows' (Since they are the > > >technical terms used in PacketCable). Would that help? > > > > It would help immensely. > I would actually rather not since we now use "provisioning modes" > through the mib module. I would prefer introducing a paragraph or 2 > upfront specifying what the provisioning modes are and what they > refer to in terms of provisioning flows. > Is that ok? ... That would be fine with me. Making it clear that the "provisioning flows" are not the ones carried by SNMP would also help, since at least some of us are actually accustomed to using SNMP to provision things. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Jan 25 10:36:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13200 for ; Tue, 25 Jan 2005 10:36:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtT0v-0005P8-OY for ipcdn-archive@ietf.org; Tue, 25 Jan 2005 10:53:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtSjB-0007SW-Cr; Tue, 25 Jan 2005 10:35:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtSb3-0004np-8e for ipcdn@megatron.ietf.org; Tue, 25 Jan 2005 10:27:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12028 for ; Tue, 25 Jan 2005 10:27:11 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtSrl-00052c-Hd for ipcdn@ietf.org; Tue, 25 Jan 2005 10:44:31 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j0PFQc1e009878; Tue, 25 Jan 2005 08:26:38 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] pktcSigDevCodecTable request for clarification Date: Tue, 25 Jan 2005 08:26:37 -0700 Message-ID: Thread-Topic: [ipcdn] pktcSigDevCodecTable request for clarification Thread-Index: AcUB90rinrtnkiVkQ2Gpgf6mZnx6LgAsvvLQ From: "Jean-Francois Mule" To: "David De Reu" , "IPCDN Mailing List" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Content-Transfer-Encoding: quoted-printable David, Inline. Jean-Fran=E7ois=20 You wrote: > > > In > > > (Euro-)PacketCable/IPCablecom, this is the "telephone-event" > > > "codec". > > Where is the spec you are refering to? Can we have a look at it? >=20 > Unfortunately, PacketCable specs are a bit vague about this,=20 > and IPCablecom > seems to have left it out entirely.=20 Yes, DTMF relay using RFC2833 (or for some implementations using the = upcoming RFC2833bis) is out of scope of PacketCable 1.0. More news on = this later, probably next week but as far as this version of the ipcdn = sig MIB is concerned, I would say that this is out of scope. Note that vendors are free to implement it as they are to implement a = bunch of other codecs we don't put in the table. [snip] > The bottom line is: RFC 2833 (called "telephone-event" in=20 > PacketCable), can > be present in the NCS LocalConnectionOptions and in SDP (both=20 > in the m=3D and > a=3Drtpmap lines, via a dynamic payload type and the "telephone-event" > encoding name). A number of MTA vendors support this feature.=20 > I have no idea > whether it's used by operators in practice. DTMF relay is using in many VoIP services today. The use of dtmf = relay/rfc 2833 has several benefits to the operators: - reliable transmission of the DTMF tone and tone duration (see = timestamp + duration fields in 2833) when the voice path has been = established especially when using low-bit rate codecs (post = cut-through); - more reliable detection and notification of telephony events like fax = tones for detection of fax transmission and switch over to protocols = like t.38 fax relay. =20 > Until now, that was my interpretation as well. However, some=20 > people have > interpreted this differently, and it would be useful to agree=20 > on the exact > interpretation. The problem is that "other(1)" has no strict=20 > interpretation. > If it would be impossible to include RFC 2833, things would=20 > be clear, but > now there is a "back door" through "other(1)". Are u suggesting we remove other? It means "more" codecs are support but = it is not specific. > > > Either way, a clarification of some sort in the DESCRIPTION > > > clause would be > > > helpful to implementors (and testers, as a matter of fact). > > If an integer value is not given for other codecs, or represented > > in the TC, then testers cannot expect vendors to advertise it. >=20 > True, hence the "other(1)" some vendors currently use if they=20 > feel they have > to include it. Given the requirement that all combinations=20 > have to be listed > in the codec table, this gives you a table that is half filled with > "other(1)" in a manner of speaking. >=20 >=20 > > RFC3551 does not make a special case for RFC 2833 either. >=20 > Again true, another argument not to include it in the TC and=20 > hence the codec > table. ok >=20 >=20 > > > If they are to > > > be included, currently the only way is to use "other (1)" as > > > the type, which > > > is of course allowed but not very informative. > > In my opinion, they should not be included. >=20 > Agreed. >=20 > > If what you want is > > the MTA to indicate support for RFC2833, then this belongs to > > another MIB object. >=20 > Currently, there is no such MIB object indeed, but by using=20 ^^^^^^^^^^^^^^^^^^^ Because this is really outside the scope of the specs this mib covers. > To relieve all doubt, and to make things simpler for vendors, I would > suggest a subtle change of the DESCRIPTION of pktcSigDevCodecTable. >=20 > A first suggestion: >=20 > pktcSigDevCodecTable OBJECT-TYPE > SYNTAX SEQUENCE OF PktcSigDevCodecEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > " This table describes the MTA supported voice codec types. > This table MUST NOT include non-voice codecs. A MTA MUST > populate this table with all possible combinations of > codecs it supports for simultaneous operation. For > example, ..." >=20 > "Design decisions" behind this wording: >=20 > - if the actual codecs (all but "other(1)", "unknown(2)" and=20 > "reserved(4)") > from the PktcCodecType TEXTUAL-CONVENTION are used, the new "MUST NOT" > requirement is automagically fulfilled and nothing changes=20 > for existing > implementations; Isn't your pb solved by this MUST NOT though? An MTA vendor that = includes 2833 events as part of this table fails to meet this = requirement, no?=20 But that is missing the point. Again RFC2833 support means various = levels of implementations (dtmf0-9, abcd, flash,..., or named events = like ANS, etc.). It you want to know whether a device supports 2833, we = should have a more granular object syntax mapping the media attribute = line the implementation would advertise in SDP: for e.g. a=3Dfmtp:100 0-15,66,70 The idea would be to map the section 3 of RFC2833 and telephone event = capabilities into some kind of a mib syntax. My 2 cents. Jean-Fran=E7ois=20 > - the "other(1)", "unknown(2)" and "reserved(4)" from the TC=20 > are limited to > *voice* codecs within the context of the=20 > pktcSigDevCodecTable, which was the > original intention. >=20 >=20 > Any support for or objections against this change? >=20 >=20 > Thanks, >=20 > David >=20 > _____________________________________________________ > David De Reu > tComLabs > Stapelplein 70/004 - 9000 Ghent - Belgium > Tel: +32 9 269 22 91 - Fax: +32 9 329 31 74 > www.tComLabs.com > _____________________________________________________ >=20 >=20 >=20 >=20 > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn >=20 >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Jan 25 11:08:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16003 for ; Tue, 25 Jan 2005 11:08:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtTVg-0006ZI-1I for ipcdn-archive@ietf.org; Tue, 25 Jan 2005 11:25:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtT8p-0004Ec-Qh; Tue, 25 Jan 2005 11:02:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtT30-00031D-DL for ipcdn@megatron.ietf.org; Tue, 25 Jan 2005 10:56:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15049 for ; Tue, 25 Jan 2005 10:56:04 -0500 (EST) Received: from asia.telenet-ops.be ([195.130.132.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtTJj-00067I-Nn for ipcdn@ietf.org; Tue, 25 Jan 2005 11:13:24 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by asia.telenet-ops.be (Postfix) with SMTP id 29F8F22421C for ; Tue, 25 Jan 2005 16:55:56 +0100 (MET) Received: from tcomlabs.com (dD5E00656.access.telenet.be [213.224.6.86]) by asia.telenet-ops.be (Postfix) with ESMTP id CD43E22417D for ; Tue, 25 Jan 2005 16:55:55 +0100 (MET) Received: (qmail 2260 invoked from network); 25 Jan 2005 16:55:55 +0100 Received: from localhost (HELO gateway) (127.0.0.1) by localhost with SMTP; 25 Jan 2005 16:55:55 +0100 Received: from ([10.5.5.72]) by gateway.tcomlabs.com (MailMonitor for SMTP v1.2.2 ) ; Tue, 25 Jan 2005 16:55:54 +0100 (CET) From: "David De Reu" To: "'IPCDN Mailing List'" Subject: RE: [ipcdn] pktcSigDevCodecTable request for clarification Date: Tue, 25 Jan 2005 16:55:52 +0100 Message-ID: <000101c502f6$59bb88c0$4805050a@pcdavid> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 In-Reply-To: Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable ... > > The problem is that "other(1)" has no strict > > interpretation. > > If it would be impossible to include RFC 2833, things would > > be clear, but > > now there is a "back door" through "other(1)". > Are u suggesting we remove other? It means "more" codecs are > support but it is not specific. I am not if my suggestion regarding the "MUST NOT" is adopted. Then again, what is the difference between "other(1)" and "unknown(2)"? T= his is maybe a second issue that could use some clarification :-) ... > Isn't your pb solved by this MUST NOT though? An MTA vendor > that includes 2833 events as part of this table fails to meet > this requirement, no? This would indeed solve the problem, because it makes it clear what belon= gs in the table and what does not. Thanks, David _____________________________________________________ David De Reu tComLabs Stapelplein 70/004 =96 9000 Ghent =96 Belgium Tel: +32 9 269 22 91 =96 Fax: +32 9 329 31 74 www.tComLabs.com _____________________________________________________ _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Jan 25 16:55:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14645 for ; Tue, 25 Jan 2005 16:55:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtYvO-0002ft-3u for ipcdn-archive@ietf.org; Tue, 25 Jan 2005 17:12:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtYGO-000302-76; Tue, 25 Jan 2005 16:30:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtXuC-0007Fi-CS; Tue, 25 Jan 2005 16:07:20 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07823; Tue, 25 Jan 2005 16:07:17 -0500 (EST) Message-Id: <200501252107.QAA07823@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 25 Jan 2005 16:07:17 -0500 Cc: ipcdn@ietf.org Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-pktc-mtamib-06.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Multimedia Terminal Adapter (MTA) Management Information Base for PacketCable and IPCablecom compliant devices Author(s) : E. Nechamkin, J. Mule Filename : draft-ietf-ipcdn-pktc-mtamib-06.txt Pages : 55 Date : 2005-1-25 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP- based management of PacketCable and IPCablecom compliant Multimedia Terminal Adapter devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib-06.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-ietf-ipcdn-pktc-mtamib-06.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-ietf-ipcdn-pktc-mtamib-06.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: <2005-1-25163254.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-pktc-mtamib-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-pktc-mtamib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-25163254.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --NextPart-- From ipcdn-bounces@ietf.org Tue Jan 25 20:05:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03131 for ; Tue, 25 Jan 2005 20:05:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctbt8-0001ZW-Gl for ipcdn-archive@ietf.org; Tue, 25 Jan 2005 20:22:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtbTZ-0005jh-7x; Tue, 25 Jan 2005 19:56:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtbRp-0005ED-8H for ipcdn@megatron.ietf.org; Tue, 25 Jan 2005 19:54:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01922 for ; Tue, 25 Jan 2005 19:54:13 -0500 (EST) Received: from mail.stargus.com ([65.193.169.166] helo=xchange.stargus.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Ctbid-0001Az-BY for ipcdn@ietf.org; Tue, 25 Jan 2005 20:11:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] The prefix for the DOCSIS-IEFT-QOS-MIB Date: Tue, 25 Jan 2005 19:54:02 -0500 Message-ID: <6FEBB4954538C7408210BEDBE4843642311E7E@xchange.stargus.com> Thread-Topic: [ipcdn] The prefix for the DOCSIS-IEFT-QOS-MIB Thread-Index: AcUCLkTFlxGAzsd7QGKBcYXGqyupfQBD//Qw From: "Fred Oko" To: "Murwin William-LWM008" , "IPCDN (E-mail) (E-mail)" X-Spam-Score: 0.3 (/) X-Scan-Signature: 32a65c0bf5eb4ec26489239c7cdd0636 Cc: Jean-Francois Mule , Patrick Michael-LZZ007 , Richard_woundy@cable.comcast.com X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0884671515==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 5b943e80df8c8cad631fd60298783617 This is a multi-part message in MIME format. --===============0884671515== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50341.87120D03" This is a multi-part message in MIME format. ------_=_NextPart_001_01C50341.87120D03 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Arguably, the QOS-MIB needs this distinguisher the most across the current IPCDN drafts as a given short name may actually map to a different OID. So even if both versions could be installed, the matching algorithm for finding the OID to use may vary (though clearly fully-qualified (or at least MODULE::leaf style) requests are best practice to lock down the desired namespace at the client so this is only corner case). Would we consider whether this should be done for the other pre-RFC draft MIBs awaiting re-root on a case by case basis or select this as policy moving forward (or assume this is the only one as this is the only one for which the MODULE-IDENTITY has changed due to object renumbers)? I do not know of any precedence of such a rename in working-implementation draft MIBs (anyone else?) and definitely am not aware of 'Ietf' being placed into the object names by any other WG though it seems as good a choice as any except for the growing prefix length (granted, of no real operational concern). If nothing else, the suggested change improves consistency between the object prefix and the already agreed upon MODULE-IDENTITY. =20 -----Original Message----- From: Murwin William-LWM008 [mailto:W.Murwin@motorola.com]=20 Sent: Monday, January 24, 2005 10:57 AM To: IPCDN (E-mail) (E-mail) Cc: Jean-Francois Mule; Patrick Michael-LZZ007; Richard_woundy@cable.comcast.com Subject: [ipcdn] The prefix for the DOCSIS-IEFT-QOS-MIB =20 I am currently in the process of updating the draft-ietf-ipcdn-qos-mib-11.txt, in-order to address the rooting issue of this MIB. There has been significant discussion about how this version and version 4 will exist together in SNMP manager and agents. IPCDN even went as far as changing this mib MODULE-IDENTIER in order to be able to support both mibs within the same SNMP manager. However, from my own personal experience this seems not to be enough for some SNMP managers, and usually only one of the version can only be installed.=20 With this update I am willing on change the the MIB Module Descriptor from "docsQosMIB" to "docsIetfQosMIB" and changing all the MIB objects prefix from "docsQos" to "docsIetfQos". Please respond if you feel strongly either way.=20 Sincerely,=20 Will=20 ______________________________=20 William Murwin=20 Broadband Communications Sector=20 Motorola Inc.=20 Email: W.Murwin@motorola.com=20 Tel: (508) 786-7594=20 _______________________________________________=20 IPCDN mailing list=20 IPCDN@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ipcdn=20 ------_=_NextPart_001_01C50341.87120D03 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [ipcdn] The prefix for the DOCSIS-IEFT-QOS-MIB

Arguably, the QOS-MIB needs this distinguisher the most across the current IPCDN = drafts as a given short name may actually map to a different OID. So even if both = versions could be installed, the matching algorithm for finding the OID to use = may vary (though clearly fully-qualified (or at least MODULE::leaf style) requests are best practice to lock down the desired namespace at = the client so this is only corner case). Would we consider whether this should be = done for the other pre-RFC draft MIBs awaiting = re-root on a case by case basis or select this as policy moving forward (or assume = this is the only one as this is the only one for which the MODULE-IDENTITY has = changed due to object renumbers)? I do not know of any precedence of such a = rename in working-implementation draft MIBs (anyone else?) and definitely am = not aware of ‘Ietf’ being placed into the = object names by any other WG though it seems as good a choice as any except for = the growing prefix length (granted, of no real operational concern). If = nothing else, the suggested change improves consistency between the object = prefix and the already agreed upon MODULE-IDENTITY.

 

-----Original = Message-----
From: Murwin = William-LWM008 [mailto:W.Murwin@motorola.com]
Sent: Monday, January 24, = 2005 10:57 AM
To: IPCDN (E-mail) = (E-mail)
Cc: Jean-Francois Mule; = Patrick Michael-LZZ007; Richard_woundy@cable.comcast.com
Subject: [ipcdn] The = prefix for the DOCSIS-IEFT-QOS-MIB

 

I am currently in the process of updating the draft-ietf-ipcdn-qos-mib-11.txt, in-order to address the rooting issue = of this MIB.

There has been significant discussion about = how this version and version 4 will exist together in SNMP manager and agents. = IPCDN even went as far as changing this mib MODULE-IDENTIER in order to be = able to support both mibs within the same SNMP manager. However, from my own = personal experience this seems not to be enough for some SNMP managers, and = usually only one of the version can only be installed.

With this update I am willing on change the = the MIB Module Descriptor from "docsQosMIB" to = "docsIetfQosMIB" and changing all the MIB objects prefix from "docsQos" to "docsIetfQos".

Please respond if you feel strongly either = way.

Sincerely,
Will =

______________________________ =
William = Murwin
Broadband Communications = Sector
Motorola = Inc.
Email: = W.Murwin@motorola.com
Tel: (508) = 786-7594

______________________________________________= _
IPCDN mailing = list
IPCDN@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/ipcdn

=00 ------_=_NextPart_001_01C50341.87120D03-- --===============0884671515== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============0884671515==-- From ipcdn-bounces@ietf.org Tue Jan 25 22:44:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14735 for ; Tue, 25 Jan 2005 22:44:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CteNP-0006Uo-Ls for ipcdn-archive@ietf.org; Tue, 25 Jan 2005 23:01:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cte5M-0000T8-Nt; Tue, 25 Jan 2005 22:43:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cte0L-0007wC-Pf for ipcdn@megatron.ietf.org; Tue, 25 Jan 2005 22:38:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14430 for ; Tue, 25 Jan 2005 22:38:02 -0500 (EST) Received: from pop-a065b10.pas.sa.earthlink.net ([207.217.121.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CteHA-0006Ln-8N for ipcdn@ietf.org; Tue, 25 Jan 2005 22:55:29 -0500 Received: from h-66-167-206-174.snvacaid.dynamic.covad.net ([66.167.206.174] helo=oemcomputer) by pop-a065b10.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1Cte0H-0003LN-00 for ipcdn@ietf.org; Tue, 25 Jan 2005 19:38:01 -0800 Message-ID: <009001c50358$7a9026c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn \(E-mail\)" Date: Tue, 25 Jan 2005 19:38:19 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [ipcdn] pktcMtaDevRealmName X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Hi - I think the use of SnmpAdminString for pktcMtaDevRealmName might need some more thought. The language about "all capitals" and search operations using upper-case ASCII doesn't mesh too well with SnmpAdminString. Whether it makes any sense at all will depend on whether Kerberos will ever permit realm names which are not upper-case ASCII. For several writing systems, there is no upper-case/lower-case distinction. Chinese, Thai, Cambodian, and Japanese are just a few examples. Even for languages written with the Roman alphabet, there are problems. German "?" (which supposedly cannot be capitalized, and > should be transformed to "SS") is a classic example. > > If they're trying to future-proof things, they should take a > careful look at > http://www.unicode.org/versions/Unicode4.0.0/ch05.pdf#G21180 > as well as http://www.unicode.org/reports/tr15/, since they > really should > nail down which normalization form as well. (Actually, the choice of > normalization form is something we should have done in the definition > of SnmpAdminString, but no one else wanted to touch the issue then.) > > My advice, not knowing what the future of Kerberos will be and how it > will handle comparison of non-ascii realm names, is to just make this > object a DisplayString, and to spell out exactly what > characters are permitted. > > Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Jan 26 12:53:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23047 for ; Wed, 26 Jan 2005 12:53:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctrdd-0005qp-RF for ipcdn-archive@ietf.org; Wed, 26 Jan 2005 13:11:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtrKe-0004OO-Hb; Wed, 26 Jan 2005 12:51:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtrAT-0001pY-F5; Wed, 26 Jan 2005 12:41:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19855; Wed, 26 Jan 2005 12:41:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtrRR-0005KP-5l; Wed, 26 Jan 2005 12:58:57 -0500 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1Ctr62-0000kQ-Hk; Wed, 26 Jan 2005 12:36:50 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Wed, 26 Jan 2005 12:36:50 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: ipcdn mailing list , Internet Architecture Board , ipcdn chair , ipcdn chair , ipcdn chair , RFC Editor Subject: [ipcdn] Protocol Action: 'Management Information Base for DOCSIS Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus' to Proposed Standard X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 The IESG has approved the following document: - 'Management Information Base for DOCSIS Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus ' as a Proposed Standard This document is the product of the IP over Cable Data Network Working Group. The IESG contact persons are Bert Wijnen and David Kessens. Technical Summary This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for SNMP based management of the Baseline Privacy Plus features of DOCSIS1.1 and DOCSIS 2.0 compliant Cable Modems and Cable Modem Termination Systems. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for SNMP based management of the Baseline Privacy Plus features of DOCSIS1.1 and DOCSIS 2.0 (Data-over-Cable Service Interface Specification) compliant Cable Modems and Cable Modem Termination Working Group Summary There is Working Group consensus to publish this document as a Proposed Standard. Protocol Quality This document was reviewed for the IESG by Bert Wijnen RFC-Editor note: Please replace the last para of sect 7 OLD: BPI+ Encryption Algorithms: BPI+ Traffic Encryption Keys TEK (see [1]) uses DES (Data Encryption Standard) 56 or 40 bits encryption ciphers. Due DES cryptographic strength weakness, future revisions of BPI+ specification [1] should introduce advanced encryption algorithms to overcome the progress in cheaper and faster decryption tools. Traffic Encryption Keys (TEK) are configured per CM and per BPI+ multicast group which may reduce the threat of the DES weakness for the overall system. The time to crack DES could be additionally mitigated by a compromised value for the TEK lifetime and Grace Time (up to a minimum of 30 minutes for the TEK lifetime, see Appendix A [1]). Not exempt of the same recommendations as above, The CM BPI+ Authorization protocol uses triple DES encryption, which offers improved robustness compared to DES for CM Authorization and TEK re-key management. NEW: BPI+ Encryption Algorithms: The BPI+ Traffic Encryption Keys (TEK) defined in the DOCSIS BPI+ specification [1] use 40-bit or 56-bit DES for encryption (DES CBC mode). There is currently no mechanism or algorithm defined for data integrity. Due to the DES cryptographic weaknesses, future revisions of the DOCSIS BPI+ specification should introduce more advanced encryption algorithms as proposed in the DocsBpkmDataEncryptAlg textual convention to overcome the progress in cheaper and faster hardware or software decryption tools. Future revisions of the DOCSIS BPI+ specification [1] should also adopt authentication algorithms as described in DocsBpkmDataAuthentAlg textual convention. It is important to note that frequent key changes do not necessarily help to mitigate or reduce the risks of a DES attack. Indeed, the traffic encryption keys which are configured on a per cable modem basis and per BPI+ multicast group can be utilized to decrypt old traffic even when they are no longer in active use. Note that not exempt of the same recommendations as above, the CM BPI+ authorization protocol uses triple DES encryption, which offers improved robustness compared to DES for CM authorization and TEK re-key management. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Jan 27 16:25:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29416 for ; Thu, 27 Jan 2005 16:25:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuHPt-0008Tx-Rx for ipcdn-archive@ietf.org; Thu, 27 Jan 2005 16:43:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuGg0-0002ad-0o; Thu, 27 Jan 2005 15:55:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuGef-0001qz-BJ; Thu, 27 Jan 2005 15:54:17 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23494; Thu, 27 Jan 2005 15:54:14 -0500 (EST) Message-Id: <200501272054.PAA23494@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 27 Jan 2005 15:54:14 -0500 Cc: ipcdn@ietf.org Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-qos-mib-11.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Data Over Cable System Interface Specification Quality of Service Management Information Base (DOCSIS-QOS MIB) Author(s) : M. Patrick, W. Murwin Filename : draft-ietf-ipcdn-qos-mib-11.txt Pages : 88 Date : 2005-1-27 This document defines a basic set of managed objects for SNMP-based management of extended QOS features of Cable Modems (CMs) and Cable Modem Termination Systems (CMTSs) conforming to the Data over Cable System (DOCSIS) standard version 1.1 and 2.0. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib-11.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-ietf-ipcdn-qos-mib-11.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-ietf-ipcdn-qos-mib-11.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: <2005-1-27144001.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-qos-mib-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-qos-mib-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-27144001.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --NextPart-- From ipcdn-bounces@ietf.org Fri Jan 28 13:57:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29986 for ; Fri, 28 Jan 2005 13:57:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cubad-00050u-Qs for ipcdn-archive@ietf.org; Fri, 28 Jan 2005 14:15:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CubI3-0000Za-32; Fri, 28 Jan 2005 13:56:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CubEG-0007tA-5E for ipcdn@megatron.ietf.org; Fri, 28 Jan 2005 13:52:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29291 for ; Fri, 28 Jan 2005 13:52:22 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CubVc-0004na-Ff for ipcdn@ietf.org; Fri, 28 Jan 2005 14:10:21 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j0SIph1e021766; Fri, 28 Jan 2005 11:51:43 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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, 28 Jan 2005 11:51:43 -0700 Message-ID: Thread-Topic: IPCDN meeting in IETF #62 and Internet-Draft Submission Cutoff Dates for the 62nd IETF Meeting inMinneapolis, MN Thread-Index: AcUFUUY36i0F8LB7Ttqs9KH+A48eNgAF08Xw From: "Jean-Francois Mule" To: "Ipcdn (E-mail)" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Cc: "Richard Woundy @ Comcast" Subject: [ipcdn] IPCDN meeting in IETF #62 and Internet-Draft Submission Cutoff Dates for the 62nd IETF Meeting inMinneapolis, MN X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable =09 We will have an ipcdn wg meeting at the next IETF in Minneapolis. Please provide us with any agenda item you would like to cover at the meeting. Given the last wg meeting minutes and the open work items, I propose that: - we spend quite a bit of time discussing the open issues on the DOCSIS cable device mib v2 (Kevin Marez will have posted an updated ID by then, addressed a number of mib doctor comments and it would be wise to use face time to advance this important MIB module). - we discuss and try to close any remaining issues on the PacketCable MTA and Sig MIB modules - review the status of other wg items that have not been updated and determine the next steps (charter update in particular). Comments, input welcome. -- Rich and Jean-Francois=20 -----Original Message----- From: ietf-secretariat@ietf.org [mailto:ietf-secretariat@ietf.org]=20 Sent: Friday, January 28, 2005 8:36 AM To: IETF-Announce@ietf.org Subject: Internet-Draft Submission Cutoff Dates for the 62nd IETF Meeting inMinneapolis, MN=20 There are two (2) Internet-Draft cutoff dates for the 62nd IETF Meeting=20 in Minneapolis, MN: February 14th: Cutoff Date for Initial (i.e., -00) Internet-Draft Submissions=20 All initial Internet-Drafts (-00) must be submitted by Monday, February 14th at 9:00 AM ET.=20 As always, all initial submissions (-00) with a filename beginning with "draft-ietf"=20 must be approved by the appropriate WG Chair before they can be processed or announced.=20 WG Chair approval must be received by Monday, February 7th at 9:00 AM ET. February 21st: Cutoff Date for Revised (i.e., -01 and higher) Internet-Draft Submissions=20 All revised Internet-Drafts (-01 and higher) must be submitted by Monday, February 21st=20 at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not=20 be made available in the Internet-Drafts directory or announced, and will have to be=20 resubmitted. Please do not wait until the last minute to submit. The Secretariat will=20 begin accepting Internet-Draft submissions starting Monday, March 7th at 9:00 AM ET,=20 but may not post or announce them until Monday, March 14th. Thank you for your understanding and cooperation. If you have any questions or concerns,=20 then please send a message to internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 62nd IETF=20 Meeting can be found at http://www.ietf.org/meetings/IETF-62.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Jan 28 16:31:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18003 for ; Fri, 28 Jan 2005 16:31:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cudzb-0001H8-Ig for ipcdn-archive@ietf.org; Fri, 28 Jan 2005 16:49:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CudC8-0000rV-Qf; Fri, 28 Jan 2005 15:58:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CudBI-0008Ru-Ka; Fri, 28 Jan 2005 15:57:28 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12584; Fri, 28 Jan 2005 15:57:26 -0500 (EST) Message-Id: <200501282057.PAA12584@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 28 Jan 2005 15:57:26 -0500 Cc: ipcdn@ietf.org Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-docsisevent-mib-06.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Event Notification Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems Author(s) : A. Ahmad, G. Nakanishi Filename : draft-ietf-ipcdn-docsisevent-mib-06.txt Pages : 41 Date : 2005-1-28 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP- based event notification management of DOCSIS compliant Cable Modems and Cable Modem Termination Systems. This MIB is defined as an extension to the DOCSIS Cable Device MIB. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docsisevent-mib-06.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-ietf-ipcdn-docsisevent-mib-06.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-ietf-ipcdn-docsisevent-mib-06.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: <2005-1-28152626.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-docsisevent-mib-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-docsisevent-mib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-28152626.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --NextPart-- From ipcdn-bounces@ietf.org Sun Jan 30 20:02:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18578 for ; Sun, 30 Jan 2005 20:02:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvQFC-0005M0-C9 for ipcdn-archive@ietf.org; Sun, 30 Jan 2005 20:20:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvPwE-0001Ls-IR; Sun, 30 Jan 2005 20:01:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvPvH-000140-5G for ipcdn@megatron.ietf.org; Sun, 30 Jan 2005 20:00:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18456 for ; Sun, 30 Jan 2005 20:00:07 -0500 (EST) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvQD6-0005JX-Oh for ipcdn@ietf.org; Sun, 30 Jan 2005 20:18:38 -0500 Received: from h-68-165-173-25.snvacaid.dynamic.covad.net ([68.165.173.25] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CvPvE-0007Ve-00 for ipcdn@ietf.org; Sun, 30 Jan 2005 17:00:08 -0800 Message-ID: <001101c50730$457be7e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn \(E-mail\)" Date: Sun, 30 Jan 2005 17:00:34 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [ipcdn] problems with docsIfCmtsCmStatusTable in draft-ietf-ipcdn-docs-rfmibv2-12.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Hi - Bert asked me to take a look at draft-ietf-ipcdn-docs-rfmibv2-12 I haven't gotten through all of it, but am sending to the WG mailing list the problems that I've encountered so far. To keep things a little easier to manage (I hope) I've broken things down by MIB table. docsIfCmtsCmStatusIndex: "SHOULD not" -> "SHOULD NOT" docsIfCmtsCmStatusRxPower, docsIfCmtsCmStatusSignalNoise: the value in the UNITS clause doesn't match up with what the textual convention's definition says. docsIfCmtsCmStatusTimingOffset, docsIfCmtsCmStatusUnerroreds, docsIfCmtsCmStatusCorrecteds, docsIfCmtsCmStatusUncorrectables, docsIfCmtsCmStatusExtUnerroreds, docsIfCmtsCmStatusExtCorrecteds, docsIfCmtsCmStatusExtUncorrectables, and docsIfCmtsCmStatusHighResolutionTimingOffset all need UNITS clauses Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Sun Jan 30 20:10:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19023 for ; Sun, 30 Jan 2005 20:10:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvQMy-0005Tr-AJ for ipcdn-archive@ietf.org; Sun, 30 Jan 2005 20:28:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvPzA-0001kG-3v; Sun, 30 Jan 2005 20:04:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvPxf-0001Ug-0S for ipcdn@megatron.ietf.org; Sun, 30 Jan 2005 20:02:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18655 for ; Sun, 30 Jan 2005 20:02:35 -0500 (EST) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvQFV-0005MG-Rf for ipcdn@ietf.org; Sun, 30 Jan 2005 20:21:06 -0500 Received: from h-68-165-173-25.snvacaid.dynamic.covad.net ([68.165.173.25] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CvPxd-0000Ln-00 for ipcdn@ietf.org; Sun, 30 Jan 2005 17:02:37 -0800 Message-ID: <001701c50730$9ecbace0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn \(E-mail\)" Date: Sun, 30 Jan 2005 17:03:05 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [ipcdn] problems with docsIfCmtsStatusTable in draft-ietf-ipcdn-docs-rfmibv2-12 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Hi - Problems I saw with docsIfCmtsStatusTable in draft-ietf-ipcdn-docs-rfmibv2-12: docsIfCmtsStatusInvalidRangeReqs, dcsIfCmtsStatusRangingAborteds, dpcsIfCmtsStatusInvalidRegReqs, docsIfCmtsStatusFailedRegReqs, docsIfCmtsStatusInvalidDataReqs, and docsIfCmtsStatusT5Timeouts all need UNITS clauses Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Sun Jan 30 20:12:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19129 for ; Sun, 30 Jan 2005 20:12:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvQOo-0005Wd-V2 for ipcdn-archive@ietf.org; Sun, 30 Jan 2005 20:30:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvQ5t-0002Hi-F5; Sun, 30 Jan 2005 20:11:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvQ0B-0001ms-AU for ipcdn@megatron.ietf.org; Sun, 30 Jan 2005 20:05:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18784 for ; Sun, 30 Jan 2005 20:05:10 -0500 (EST) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvQHz-0005PX-Ht for ipcdn@ietf.org; Sun, 30 Jan 2005 20:23:40 -0500 Received: from h-68-165-173-25.snvacaid.dynamic.covad.net ([68.165.173.25] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CvQ06-00018p-00 for ipcdn@ietf.org; Sun, 30 Jan 2005 17:05:11 -0800 Message-ID: <001d01c50730$fa117580$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn \(E-mail\)" Date: Sun, 30 Jan 2005 17:05:38 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [ipcdn] problems with docsIfCmtsMacTable in draft-ietf-ipcdn-docs-rfmibv2-12 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hi - Here's what I encountered in docsIfCmtsMacTable in draft-ietf-ipcdn-docs-rfmibv2-12: docsIfCmtsMaxServiceIds needs UNITS docsIfCmtsInvitedRangingAttempts needs UNITS docsIfCmtsInsertInterval needs UNITS docsIfCmtsMacStorageType - RFC 2579 in the definition of the StorageType textual convention requires: " Every usage of this textual convention is required to specify the columnar objects which a permanent(4) row must at a minimum allow to be writable." Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Sun Jan 30 20:13:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19190 for ; Sun, 30 Jan 2005 20:13:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvQQM-0005Xv-3Y for ipcdn-archive@ietf.org; Sun, 30 Jan 2005 20:32:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvQ5u-0002I5-F8; Sun, 30 Jan 2005 20:11:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvQ2c-0001rv-Ja for ipcdn@megatron.ietf.org; Sun, 30 Jan 2005 20:07:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18845 for ; Sun, 30 Jan 2005 20:07:43 -0500 (EST) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvQKT-0005Rf-Fy for ipcdn@ietf.org; Sun, 30 Jan 2005 20:26:13 -0500 Received: from h-68-165-173-25.snvacaid.dynamic.covad.net ([68.165.173.25] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CvQ2b-0001jq-00 for ipcdn@ietf.org; Sun, 30 Jan 2005 17:07:45 -0800 Message-ID: <002801c50731$5620a8a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn \(E-mail\)" Date: Sun, 30 Jan 2005 17:07:28 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [ipcdn] problems with docsIfCmServiceTable in draft-ietf-ipcdn-docs-rfmibv2-12 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi - Here's what I saw in problems with docsIfCmServiceTable in draft-ietf-ipcdn-docs-rfmibv2-12: docsIfCmServiceTxRetries needs a UNITS clause docsIfCmServiceTxExceededs needs a UNITS clause docsIfCmServiceRqRetries needs a UNITS clause docsIfCmServiceRqExceededs needs a UNITS clause Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Sun Jan 30 20:16:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19276 for ; Sun, 30 Jan 2005 20:16:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvQSo-0005Zq-D2 for ipcdn-archive@ietf.org; Sun, 30 Jan 2005 20:34:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvQ9o-0002qw-B2; Sun, 30 Jan 2005 20:15:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvQ8W-0002aK-Rj for ipcdn@megatron.ietf.org; Sun, 30 Jan 2005 20:13:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19211 for ; Sun, 30 Jan 2005 20:13:49 -0500 (EST) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvQQN-0005Y1-Pg for ipcdn@ietf.org; Sun, 30 Jan 2005 20:32:20 -0500 Received: from h-68-165-173-25.snvacaid.dynamic.covad.net ([68.165.173.25] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CvQ8V-0003Oa-00 for ipcdn@ietf.org; Sun, 30 Jan 2005 17:13:51 -0800 Message-ID: <002901c50732$30433fc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn \(E-mail\)" Date: Sun, 30 Jan 2005 17:13:20 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [ipcdn] problems with docsIfCmStatusTable in draft-ietf-ipcdn-docs-rfmibv2-12 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Hi - Here's what I saw in docsIfCmStatusTable in draft-ietf-ipcdn-docs-rfmibv2-12: docsIfCmStatusCode: the SIZE doesn't fit what the DESCRIPTION says. The DESCRIPTION makes it sounds like the maximum length would be five. docsIfCmStatusTxPower: the UNITS clause doesn't match what the TC's definition says (dB or tenths of a dB) docsIfCmStatusReset, and docsIfCmStatusLostSyncs need UNITS clause and discontinuity indicator docsIfCmStatusInvalidMaps, docsIfCmStatusInvalidUcds, docsIfCmStatusInvalidRangingResponses, docsIfCmStatusInvalidRegistrationResponses, docsIfCmStatusT1Timeouts, docsIfCmStatusT2Timeouts, docsIfCmStatusT3Timeouts, docsIfCmStatusT4Timeouts, docsIfCmStatusRangingAborteds docsIfCmStatusUCCs, and docsIfCmStatusUCCFails all need UNITS clauses Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Sun Jan 30 20:22:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19680 for ; Sun, 30 Jan 2005 20:22:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvQYZ-0005fs-6Z for ipcdn-archive@ietf.org; Sun, 30 Jan 2005 20:40:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvQFa-0003WX-DL; Sun, 30 Jan 2005 20:21:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvQF6-0003P3-2F for ipcdn@megatron.ietf.org; Sun, 30 Jan 2005 20:20:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19577 for ; Sun, 30 Jan 2005 20:20:38 -0500 (EST) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvQWw-0005e0-19 for ipcdn@ietf.org; Sun, 30 Jan 2005 20:39:07 -0500 Received: from h-68-165-173-25.snvacaid.dynamic.covad.net ([68.165.173.25] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CvQF3-0005Av-00 for ipcdn@ietf.org; Sun, 30 Jan 2005 17:20:37 -0800 Message-ID: <002f01c50733$22650720$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn \(E-mail\)" Date: Sun, 30 Jan 2005 17:21:04 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [ipcdn] problem with docsIfCmMacTablein draft-ietf-ipcdn-docs-rfmibv2-12 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Hi - One minor problem in docsIfCmMacTable: docsIfCmRangingTimeout needs a UNITS clause Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Sun Jan 30 20:26:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19801 for ; Sun, 30 Jan 2005 20:26:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvQcJ-0005ir-DM for ipcdn-archive@ietf.org; Sun, 30 Jan 2005 20:44:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvQJS-0003xL-Ka; Sun, 30 Jan 2005 20:25:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvQIV-0003q3-33 for ipcdn@megatron.ietf.org; Sun, 30 Jan 2005 20:24:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19746 for ; Sun, 30 Jan 2005 20:24:09 -0500 (EST) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvQaL-0005he-4I for ipcdn@ietf.org; Sun, 30 Jan 2005 20:42:38 -0500 Received: from h-68-165-173-25.snvacaid.dynamic.covad.net ([68.165.173.25] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CvQIS-0006Ah-00 for ipcdn@ietf.org; Sun, 30 Jan 2005 17:24:08 -0800 Message-ID: <003701c50733$a05552c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn \(E-mail\)" Date: Sun, 30 Jan 2005 17:24:36 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [ipcdn] problems in docsIfSignalQualityTable in draft-ietf-ipcdn-docs-rfmibv2-12 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Hi - In docsIfSignalQualityTable in draft-ietf-ipcdn-docs-rfmibv2-12: docsIfSigQSignalNoise - the UNITS clause is in conflict with the TC definition docsIfSigQMicroreflections - is this really a case for SHOULD? (Just asking) Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Sun Jan 30 20:39:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20912 for ; Sun, 30 Jan 2005 20:39:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvQpS-0005zh-Jc for ipcdn-archive@ietf.org; Sun, 30 Jan 2005 20:58:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvQSK-0004Yz-Km; Sun, 30 Jan 2005 20:34:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvQRx-0004Rv-Q8 for ipcdn@megatron.ietf.org; Sun, 30 Jan 2005 20:33:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20449 for ; Sun, 30 Jan 2005 20:33:55 -0500 (EST) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvQjn-0005rI-AY for ipcdn@ietf.org; Sun, 30 Jan 2005 20:52:24 -0500 Received: from h-68-165-173-25.snvacaid.dynamic.covad.net ([68.165.173.25] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CvQRu-0001EF-00 for ipcdn@ietf.org; Sun, 30 Jan 2005 17:33:54 -0800 Message-ID: <003d01c50734$fd8569c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn \(E-mail\)" Date: Sun, 30 Jan 2005 17:34:21 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [ipcdn] problems in docsIfQosProfileTable in draft-ietf-ipcdn-docs-rfmibv2-12 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Hi - Problems in docsIfQosProfileTable in draft-ietf-ipcdn-docs-rfmibv2-12: In docsIfQosProfileEntry the words about read-create are a bit odd here. I know what you mean, but as a literal description of this OBJECT it seems odd. docsIfQosProfMaxTransmitBurst: the type would be better as Unsigned32, since these cannot be negative. docsIfQosProfStorageType - RFC 2579 requires that "Every usage of this textual convention is required to specify the columnar objects which a permanent(4) row must at a minimum allow to be writable." Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Sun Jan 30 20:48:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21503 for ; Sun, 30 Jan 2005 20:48:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvQxo-0006CA-Js for ipcdn-archive@ietf.org; Sun, 30 Jan 2005 21:06:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvQf3-0005xT-Lq; Sun, 30 Jan 2005 20:47:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvQeC-0005rk-Bp for ipcdn@megatron.ietf.org; Sun, 30 Jan 2005 20:46:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21251 for ; Sun, 30 Jan 2005 20:46:34 -0500 (EST) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvQw3-00068Q-71 for ipcdn@ietf.org; Sun, 30 Jan 2005 21:05:03 -0500 Received: from h-68-165-173-25.snvacaid.dynamic.covad.net ([68.165.173.25] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CvQeA-0004PY-00 for ipcdn@ietf.org; Sun, 30 Jan 2005 17:46:34 -0800 Message-ID: <005101c50736$c25b02e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn \(E-mail\)" Date: Sun, 30 Jan 2005 17:47:01 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [ipcdn] Problems with docsIfUpstreamChannelTable in draft-ietf-ipcdn-docs-rfmibv2-12 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Hi - There are some problems with docsIfUpstreamChannelTable in draft-ietf-ipcdn-docs-rfmibv2-12 docsIfUpChannelModulationProfile: returning a genErr under those circumstances would be inappropriate. RFC 3416 section 4.2.5 clearly indicates that inconsistentValue would be the correct response. docsIfUpChannelSlotSize - should have UNITS docsIfUpChannelTxTimingOffset - should have UNITS docsIfUpChannelScdmaActiveCodes - since the primes can never be set and can never be returned, they should be excluded in the SYNTAX docsIfUpChannelScdmaCodesPerSlot: needs UNITS, and would be better as Unsigned32 docsIfUpChannelScdmaFrameSize needs UNITS docsIfUpChannelScdmaHoppingSeed - may be set to non-zero for non-scdma? docsIfUpChannelUpdate: the use of genErr and commitFailed is inappropriate in this DESCRIPTION. RFC 3416 section 4.2.5 clearly indicates that inconsistentValue would be the correct response. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Sun Jan 30 21:00:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22117 for ; Sun, 30 Jan 2005 21:00:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvR9E-0006N7-EM for ipcdn-archive@ietf.org; Sun, 30 Jan 2005 21:18:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvQls-0006hB-7f; Sun, 30 Jan 2005 20:54:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvQhl-0006L1-1z for ipcdn@megatron.ietf.org; Sun, 30 Jan 2005 20:50:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21589 for ; Sun, 30 Jan 2005 20:50:15 -0500 (EST) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvQzc-0006Dv-AR for ipcdn@ietf.org; Sun, 30 Jan 2005 21:08:44 -0500 Received: from h-68-165-173-25.snvacaid.dynamic.covad.net ([68.165.173.25] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CvQhj-0005NP-00 for ipcdn@ietf.org; Sun, 30 Jan 2005 17:50:15 -0800 Message-ID: <005b01c50737$466be900$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn \(E-mail\)" Date: Sun, 30 Jan 2005 17:50:43 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [ipcdn] problems in docsIfDownstreamChannelTable in draft-ietf-ipcdn-docs-rfmibv2-12 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hi - I saw a few problems in docsIfDownstreamChannelTable in draft-ietf-ipcdn-docs-rfmibv2-12 docsIfDownChannelWidth and docsIfDownChannelModulation: question: what is meant by "associated compliance object"? docsIfDownChannelPower: looks like some words got lost in the update to the DESCRIPTION. docsIfDownChannelStorageType: RFC 2579 requires: "Every usage of this textual convention is required to specify the columnar objects which a permanent(4) row must at a minimum allow to be writable." Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Sun Jan 30 21:01:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22214 for ; Sun, 30 Jan 2005 21:01:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvRAT-0006OF-71 for ipcdn-archive@ietf.org; Sun, 30 Jan 2005 21:19:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvQoY-0006uA-Ol; Sun, 30 Jan 2005 20:57:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvQkb-0006b0-SX for ipcdn@megatron.ietf.org; Sun, 30 Jan 2005 20:53:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21744 for ; Sun, 30 Jan 2005 20:53:11 -0500 (EST) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvR2S-0006HL-Mw for ipcdn@ietf.org; Sun, 30 Jan 2005 21:11:40 -0500 Received: from h-68-165-173-25.snvacaid.dynamic.covad.net ([68.165.173.25] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CvQkZ-0006CC-00 for ipcdn@ietf.org; Sun, 30 Jan 2005 17:53:11 -0800 Message-ID: <006301c50737$af611ca0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn \(E-mail\)" Date: Sun, 30 Jan 2005 17:53:39 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [ipcdn] textual conventions in draft-ietf-ipcdn-docs-rfmibv2-12 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Hi - Some of the textual conventions in draft-ietf-ipcdn-docs-rfmibv2-12 need a little work. Specifically, The DocsisVersion, DocsisQosVersion, DocsisUpstreamType, and DocsisUpstreamTypeStatus TCs shouldspecify in their respective DESCRIPTIONS what each of their enumerated values means. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Sun Jan 30 21:02:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22324 for ; Sun, 30 Jan 2005 21:02:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvRBE-0006PQ-L7 for ipcdn-archive@ietf.org; Sun, 30 Jan 2005 21:20:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvQt0-0007Jx-Ue; Sun, 30 Jan 2005 21:01:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvQqf-00071r-5M for ipcdn@megatron.ietf.org; Sun, 30 Jan 2005 20:59:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22093 for ; Sun, 30 Jan 2005 20:59:27 -0500 (EST) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvR8V-0006MX-1t for ipcdn@ietf.org; Sun, 30 Jan 2005 21:17:56 -0500 Received: from h-68-165-173-25.snvacaid.dynamic.covad.net ([68.165.173.25] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CvQqc-0003Rx-00 for ipcdn@ietf.org; Sun, 30 Jan 2005 17:59:26 -0800 Message-ID: <006901c50738$8e74a7e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn \(E-mail\)" Date: Sun, 30 Jan 2005 17:59:53 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [ipcdn] question on docsIfCmtsServiceNewCmStatusIndex in X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Hi - A question on docsIfCmtsServiceNewCmStatusIndex in draft-ietf-ipcdn-docs-rfmibv2-12.txt The definition says: docsIfCmtsServiceNewCmStatusIndex OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "Pointer (via docsIfCmtsCmStatusIndex) to an entry in docsIfCmtsCmStatusTable identifying the Cable Modem using this Service Queue. If multiple Cable Modems are using this Service Queue, the value of this object is zero." ::= { docsIfCmtsServiceEntry 8 } What value would it have if no Cable Modems are using this Service Queue? Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Jan 31 15:02:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12911 for ; Mon, 31 Jan 2005 15:02:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvi2r-0004lb-Ul for ipcdn-archive@ietf.org; Mon, 31 Jan 2005 15:21:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvhf2-0005cA-DG; Mon, 31 Jan 2005 14:56:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvhcK-000546-CW for ipcdn@megatron.ietf.org; Mon, 31 Jan 2005 14:53:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12206 for ; Mon, 31 Jan 2005 14:53:46 -0500 (EST) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvhuK-0004ak-16 for ipcdn@ietf.org; Mon, 31 Jan 2005 15:12:25 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j0VJrD1e021414; Mon, 31 Jan 2005 12:53:13 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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: [ipcdn] question on docsIfCmtsServiceNewCmStatusIndex in Date: Mon, 31 Jan 2005 12:53:13 -0700 Message-ID: <5259D0D7419C6149B347837A2E64F46F06A525@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] question on docsIfCmtsServiceNewCmStatusIndex in Thread-Index: AcUHOQLT7HRr1YR3QWm3ljapwJQiWgAk5+/w From: "Eduardo Cardona" To: "Randy Presuhn" , "Ipcdn (E-mail)" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Randy, I will answer on details your q. by COB today. Also have in the Queue Bert's Questions whichI am resolving in conjuction. To this Q, all CMTS are associated to a Queue service (have to) . So one CM either has its own particular Queue service, or a group (all cms) are using the same Queue.=20 RFC 2670 did not defined in docsIfCmtsCmStatusTable (per modem) the matching ServiceQueue it belongs to, thus, by RFC 2670, it is probably safe to say that only one Service Queue group is available.=20 All the Service Queue mechanism (Class of Service) is being replaced for the service Flow QoS mechanism in the Qos MIB. The service Queue mechanism is being left as defined in RFC 2670 as backward compatibility support of DOCSIS 1.0 technology. =20 Eduardo -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 Sent: Sunday, January 30, 2005 7:00 PM To: Ipcdn (E-mail) Subject: [ipcdn] question on docsIfCmtsServiceNewCmStatusIndex in=20 Hi - A question on docsIfCmtsServiceNewCmStatusIndex in draft-ietf-ipcdn-docs-rfmibv2-12.txt The definition says: docsIfCmtsServiceNewCmStatusIndex OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "Pointer (via docsIfCmtsCmStatusIndex) to an entry in docsIfCmtsCmStatusTable identifying the Cable Modem using this Service Queue. If multiple Cable Modems are using this Service Queue, the value of this object is zero." ::=3D { docsIfCmtsServiceEntry 8 } What value would it have if no Cable Modems are using this Service Queue? Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Jan 31 17:39:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15281 for ; Mon, 31 Jan 2005 17:39:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvkUU-0005D4-2r for ipcdn-archive@ietf.org; Mon, 31 Jan 2005 17:57:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvk5v-0001EQ-8K; Mon, 31 Jan 2005 17:32:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvjlc-0005sA-QK for ipcdn@megatron.ietf.org; Mon, 31 Jan 2005 17:11:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08476 for ; Mon, 31 Jan 2005 17:11:30 -0500 (EST) Received: from mail.stargus.com ([65.193.169.166] helo=xchange.stargus.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cvk3d-0003K5-AJ for ipcdn@ietf.org; Mon, 31 Jan 2005 17:30:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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: [ipcdn] question on docsIfCmtsServiceNewCmStatusIndex in Date: Mon, 31 Jan 2005 17:11:29 -0500 Message-ID: <6FEBB4954538C7408210BEDBE4843642311E92@xchange.stargus.com> Thread-Topic: [ipcdn] question on docsIfCmtsServiceNewCmStatusIndex in Thread-Index: AcUHOQLT7HRr1YR3QWm3ljapwJQiWgAk5+/wAAUT72A= From: "Fred Oko" To: "Eduardo Cardona" , "Randy Presuhn" , "Ipcdn (E-mail)" X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Or simplified, a Service Queue would not exist in the absence of a parent CM (non-zero-docsIfCmtsServiceNewCmStatusIndex case) or multicast group defined by the CMTS (the "multiple Cable Modems" zero- docsIfCmtsServiceNewCmStatusIndex case). -----Original Message----- From: Eduardo Cardona [mailto:e.cardona@CableLabs.com]=20 Sent: Monday, January 31, 2005 2:53 PM To: Randy Presuhn; Ipcdn (E-mail) Subject: RE: [ipcdn] question on docsIfCmtsServiceNewCmStatusIndex in=20 Randy, I will answer on details your q. by COB today. Also have in the Queue Bert's Questions whichI am resolving in conjuction. To this Q, all CMTS are associated to a Queue service (have to) . So one CM either has its own particular Queue service, or a group (all cms) are using the same Queue.=20 RFC 2670 did not defined in docsIfCmtsCmStatusTable (per modem) the matching ServiceQueue it belongs to, thus, by RFC 2670, it is probably safe to say that only one Service Queue group is available.=20 All the Service Queue mechanism (Class of Service) is being replaced for the service Flow QoS mechanism in the Qos MIB. The service Queue mechanism is being left as defined in RFC 2670 as backward compatibility support of DOCSIS 1.0 technology. =20 Eduardo -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 Sent: Sunday, January 30, 2005 7:00 PM To: Ipcdn (E-mail) Subject: [ipcdn] question on docsIfCmtsServiceNewCmStatusIndex in=20 Hi - A question on docsIfCmtsServiceNewCmStatusIndex in draft-ietf-ipcdn-docs-rfmibv2-12.txt The definition says: docsIfCmtsServiceNewCmStatusIndex OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "Pointer (via docsIfCmtsCmStatusIndex) to an entry in docsIfCmtsCmStatusTable identifying the Cable Modem using this Service Queue. If multiple Cable Modems are using this Service Queue, the value of this object is zero." ::=3D { docsIfCmtsServiceEntry 8 } What value would it have if no Cable Modems are using this Service Queue? Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn