From owner-snmpconf@seymour39.snmp.com Mon May 26 17:42:28 2003 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28889 for ; Mon, 26 May 2003 17:42:27 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3p2/m.030206) id RAA02824 for snmpconf-outgoing; Mon, 26 May 2003 17:36:50 -0400 (EDT) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501A9FC88@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Steve Waldbusser (E-mail)" , "Hongal (E-mail)" , "'Jon Saperia (E-mail)'" Cc: "Snmpconf (E-mail)" Subject: AD review: draft-ietf-snmpconf-pm-13.txt Date: Mon, 26 May 2003 23:36:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com I am kind of ready to request an IETF Last Call for PS. However, I still see these issues/concerns, and so it might be better to fix them first. I know that IANA for example looks at IETF Last Calls and will come up with my issue on IANA Considerations below. So here we go: - Not sure if the Index entries that can go over 128 subids are documented completely in accordance with our draft-ietf-ops-mib-review-guidelines-01.txt document. I have asked Mike Heard to check. - The secuirty considerations potentially has these issues - It does not clearly describe which object or which tables are sensitive and WHY. The security ADs (I am pretty sure) will be looking for that, and I think rightfully so. - You refer to RFC3231 for the security mechanisms used. I think that what is done here is conceptually indeed the same, but the actual implementation is a tidbit different. I have to wonder if non-MIB experts and non VACM experts can easily understand it with pointing back to 3231. And the security ADs may be the first ones to complain. I suggest that it may be much better if you took the text from 3231 and adapted it to describe exactly what the mechanisms are in this MIB module. - In the references (normative) I see [5], [6], [7], [8], and [9], [11], [12], [19], which I cannot find any citations for... Probably left over from old MIB boilerplate I think they can be removed. - Reference [14] is also not cited, but probably should be cited somewhere in sect 8 - Sect 8.3.16 utf8Output. The stringprep profile used is specified below in Section XXX. If sucessful, the function returns 1. Pls fill in XXX (I think it is 9) - Inside DESCRIPTION clauses on the MIB module I see things like for example: RFC3454 [16]. The citation gets lost when the MIB module is extracted, and the RFC number seems sufficient. So I would propose to remove any citations within DESCRIPTION (or REFERENCE) clauses. - I see no IANA considerations section, and I think you need to instruct IANA to register the Stringprep Profile. - Page 98/99 says: 3) OIDs that represent one or a collection of capabilities which could be any collection of MIB Objects or hardware or software functions may be created in working groups and registered with IANA. Other entities (e.g., vendors) may also make registrations. Software will register these standard capability OIDs as well as vendor specific OIDs. If you keep that, then I suspect we need to add in IANA Considerations section how/what IANA needs to do or not do. And under which conditions such registrations can be done. See RFC2434 for guidelines. - I am still bothered by your UTF8String. You had explained why you had done it and want to keep it. So I will accept that the WG agrees with that. But the UTF8String is only different in case from Utf8String as in RFC2287. I do not think that this is wise. So if you do want to keep it, I'd like to see the name changed. Is it only meant for the Policy MMIB and or related MIBs? Then maybe PmUTF8String makes more sense Thanks, Bert From owner-snmpconf@seymour39.snmp.com Tue May 27 06:58:59 2003 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07533 for ; Tue, 27 May 2003 06:58:58 -0400 (EDT) Received: by seymour39.snmp.com (8.9.3p2/m.030206) id GAA08138 for snmpconf-outgoing; Tue, 27 May 2003 06:54:26 -0400 (EDT) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501A9FD99@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Steve Waldbusser (E-mail)" , "Jon Saperia (E-mail)" , "Hongal (E-mail)" Cc: "Snmpconf (E-mail)" , =?iso-8859-1?Q?Patrik_F=E4?= =?iso-8859-1?Q?ltstr=F6m_=28E-mail=29?= Subject: Comments on the Stringprep aspects of draft-ietf-snmpconf-pm-13.t xt Date: Tue, 27 May 2003 12:53:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by seymour39.snmp.com id GAA08129 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit Pls react to these comments from Patrik. Pls copy patrik explicitly on your responses, cause he is (probably) not subscribed to our WG list. Thanks, Bert -----Original Message----- From: Patrik Fältström [mailto:paf@cisco.com] Sent: dinsdag 27 mei 2003 5:46 To: Wijnen, Bert (Bert) Cc: Ted Hardie (E-mail); Ned Freed (E-mail) Subject: Re: help with Stringprep review On måndag, maj 26, 2003, at 23:36 Europe/Stockholm, Wijnen, Bert (Bert) wrote: > Patrik, I think you have been communicating with Steve > Waldbusser about the use of Stringprep in his document > draft-ietf-snmpconf-pm-13.txt (current version). > > Would you be so kind to check if what he has described and > documented is OK? The doc is missing an IANA Considerations > Section, and I have already told them that they must add > one to at least list what IANA needs to do for the Stringprep > profile registration. (1) This spec very explicitly states it uses UTF-8 encoding of Unicode all over the place. Still, the basic functions doesn't take that into account. Examples: The function Integer only look for the digits in the Unicode Codeset which is in the "US-ASCII area". There are digits in other locations as well. When searching for specific values, and doing string comparisons, no stringprep is applied to the UTF-8 strings (the values) before matching is happening. Etc etc. This is a pure US-ASCII spec, even though it claims to use UTF-8. Not good. Either this should be UTF-8/Unicode compliant, or it should be US-ASCII only. (2) The stringprep profile uses no normalization at all. Even though the stringprep profile say that is correct, I would very strongly discourage this for "human readable strings" which are to be compared. paf From owner-snmpconf@seymour39.snmp.com Wed May 28 13:35:42 2003 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12959 for ; Wed, 28 May 2003 13:35:42 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3p2/m.030206) id NAA29365 for snmpconf-outgoing; Wed, 28 May 2003 13:28:40 -0400 (EDT) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Wed, 28 May 2003 10:28:05 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: snmpconf@snmp.com cc: "Wijnen, Bert (Bert)" Subject: RE: UTF8String TC in draft-ietf-snmpconf-pm-13.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Snmpconf folks -- Here is some discussion about the UTF8String TC that Bert asked me to forward. The "meat" of the discussion is a suggestion to change the wording on requiring a SIZE constraint when a UTF8String index object might cause overflow. A SIZE constraint does not always solve the problem, especially when other variable-length index objects are present, and in some cases it may be preferable to describe the constraint in a DESCRIPTION clause (or elsewhere). I've suggested some rewording along those lines for your consideration. It's adapted from the text for InetAddress that was proposed in a recent discussion of 3291bis on the mibs@ops.ietf.org list. Mike ---------- Forwarded message ---------- Date: Wed, 28 May 2003 14:11:44 +0200 From: "Wijnen, Bert (Bert)" To: C. M. Heard , "Wijnen, Bert (Bert)" Subject: RE: UTF8String TC in draft-ietf-snmpconf-pm-13.txt Thanks again for your continued review and checking. W.r.t. the UTF8String TC. - My latest posting (last Monday) to the WG list was: - I am still bothered by your UTF8String. You had explained why you had done it and want to keep it. So I will accept that the WG agrees with that. But the UTF8String is only different in case from Utf8String as in RFC2287. I do not think that this is wise. So if you do want to keep it, I'd like to see the name changed. Is it only meant for the Policy MIB and or related MIBs? Then maybe PmUTF8String makes more sense And this is earlier (back in Feb) Discussion I had with authors: > > > - Why is there a UTF8String TC ?? > > > How does it differ (why must it differ) from SnmpAdminString? > > > Same question for Utf8String from RFC2287 ?? > > > I would like to avoid a proliferation of various UTF*String TCs > > > > SnmpAdminString > > They're not admin strings > > They're often too long for AdminString's 255 octet limit > > rfc2287 > > Odd place to look (only a minor objection) > > The definition of SnmpAdminString is *much* better than the > > circa-1998 def'n of LongUtf8String in rfc2287. > > > > What we have is a copy of SnmpAdminString without the length > > restriction. > > > > I'm definitely with you on the issue of proliferation of > > locally-defined versions of what-should-be-global types. We just have > > two problems and both stem from not having a central repository: > > 1. When I write a type for a central repository I take care not to > > embed stuff in it that makes it non-reusable (like length > > restrictions). If I write a type for my own use, I'm under no > > such restriction and as we see many otherwise-reusable types are > > fettered with bad stuff. > > 2. It seems wrong for documents to borrow stuff from unrelated > > non-framework documents. > > > > Issue #1 is the operative one. #2 is a style issue and maybe would be > > trumped by the benefit of reusability. > > > > Wouldn't it be great if we just did it right and created the central > > repository? > > We can keep pushing back only so much I guess. But If you have new arguments to bring to the table, that would be great. I keep thinking that maybe I (we) should start a IANA-GENERIC-TC-MIB module in which we bring together all common/generic TCs and which then also gets us out of the "need to advance TC docs along the stds track" issue. My idea would be to then move all current common TCs into that IANA MIB, and to tell people to import from there when they revise docs (or write new docs) and to start depracting the original TCs when such docs that contain origin al TCs get revised. Oh well... Seperate topic I gues. Your proposed text for the SIZE restrcition below is also a good suggestion. Will you post it or would you rather see me do it? Thanks, Bert > -----Original Message----- > From: C. M. Heard [mailto:heard@pobox.com] > Sent: woensdag 28 mei 2003 2:21 > To: Wijnen, Bert (Bert) > Subject: UTF8String TC in draft-ietf-snmpconf-pm-13.txt > > > Bert, > > There is one more issue with draft-ietf-snmpconf-pm-13.txt that I > should mention: it defines the UTF8String TC, whose base type is > OCTET STRING (SIZE (0..65535)) but which is otherwise similar to the > following TCs are defined in SYSAPPL-MIB [RFC2287]: > > Utf8String OCTET STRING (SIZE (0..255)) > LongUtf8String OCTET STRING (SIZE (0..1024)) > > Perhaps there is a real need for something longer than 1024 octets > (there are three object definitions where no constraint is used, all > the rest are 1024 or less), but I am a little concerned about the > proliferation of very similar TCs. I also notice the following in > the DESCRIPTION clause: > > Note that when this TC is used for an object that > is used or envisioned to be used as an index, then > a SIZE restriction MUST be specified so that the > number of sub-identifiers for any object instance > does not exceed the limit of 128, as defined by > RFC3416 [10]. > > They instead be using language similar to what we agreed > on the the InetAddress TC (which avoids the citation too): > > Note that when this TC is used for an object that > is used or envisioned to be used as an index, then > there may be issues with the limit of 128 sub-identifiers > specified in SMIv2, RFC 2578, STD 58, and in SNMPv3 > protocol operations, RFC 3416, STD 62. In this case, > the object definition MUST include a 'SIZE' clause to > limit the number of potential instance sub-identifiers > or else the applicable constraints MUST be stated in the > appropriate conceptual row DESCRIPTION clauses or in the > surrounding documentation if there is no single DESCRIPTION > clause that is appropriate. > > Mike > From owner-snmpconf@seymour39.snmp.com Wed May 28 13:36:05 2003 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12973 for ; Wed, 28 May 2003 13:36:04 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3p2/m.030206) id NAA29120 for snmpconf-outgoing; Wed, 28 May 2003 13:18:30 -0400 (EDT) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Wed, 28 May 2003 10:17:53 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: snmpconf@snmp.com cc: "Wijnen, Bert (Bert)" Subject: RE: draft-ietf-snmpconf-pm-13.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Snmpconf folks -- Bert Wijnen asked me to look at the SMICng warnings for the MIB module in this draft. Attached below are my comments, which he has asked me to forward to the WG mailing list. The main thrust of these comments is that I think it would be useful to users of the MIB module if precise limits on index object sizes were explicitly spelled out, and text to do that is offerred. The proposed language also corrects a couple of typos in the DESCRIPTION clauses of pmTrackingEPElement and pmDebuggingElement. A couple of points to note: - The 128 sub-id limit does not leave much room for all of the index objects that have been defined for pmRoleEntry. The WG _may_ wish to consider a different indexing scheme to avoid this. See discussion below. - My comments below on the unusual indexing for pmPolicyEntry were made without having read the Security Considerations sections. After having done so I see the reason why things are done this way and withdraw that comment. I hope that these comments are useful. Mike Heard ---------- Forwarded message ---------- Date: Wed, 28 May 2003 12:36:13 +0200 From: "Wijnen, Bert (Bert)" To: C. M. Heard , "Wijnen, Bert (Bert)" Subject: RE: draft-ietf-snmpconf-pm-13.txt W.r.t. the INDEXes being able to exceed 128 subIDs, this is what I posted to SNMPCONF mailing list: - Not sure if the Index entries that can go over 128 subids are documented completely in accordance with our draft-ietf-ops-mib-review-guidelines-01.txt document. I have asked Mike Heard to check. I did discuss it with the authors (they had ntohing about it in their DESCRIPTION clauses to begin with). So they added some text. Not sure if we already had the dinfite text in our guidelines about this stuff when they wrote up the text. In any event, since I posted to the list that I have asked you to check it (in the context of being author for the review guidelines), it seem quite appropriate if you post this to the WG list. It seems they will need to do one more rev anyway, and so, it should be easy for them to pick up your proposed text changes. If your not subscribed to the list, I can also post it for you and make a statement that I agree. See further comments inline > -----Original Message----- > From: C. M. Heard [mailto:heard@pobox.com] > Sent: woensdag 28 mei 2003 1:55 > To: Wijnen, Bert (Bert) > Subject: Re: draft-ietf-snmpconf-pm-13.txt > > > On Mon, 26 May 2003, Wijnen, Bert (Bert) wrote: > > Mike, could you take a quick look at this doc? > > > > Specifically, I think that these SMICng warningas are OK > > but want to check with you. I know that maybe the description > > on the potential more than 128 subIDs is not ideal yet.. but > > should we hold this doc for that? It does (in each case) > > at least mention that users should be carefull to not > > create OIDs with more than 128 subids. > > > > Thanks, > > Bert > > Personally, I think that some of these warnings warrant discussion > with the authors if the original MIB reviewer did not already do > so, but I will let you be the judge of that. Details inline. > > > ----- SMICng warnings ----- > > C:\bwijnen\smicng\work>smicng pm.inc > > W: f(pm.mi2), (773,1) Row "pmElementTypeRegEntry" has indexing > > that may create variables with more than 128 sub-ids > > Specifically, the index of pmElementTypeRegEntry can exceed the OID > size limit by 11 sub-ids. The DESCRIPTION clause for > pmElementTypeRegOIDPrefix, which is the only index component, does > say: > > As this object is used in the index for the > pmElementTypeRegTable, users of this table should be careful > not to create entries that would result in OIDs with more > than 128 subidentifiers. > > A more explicit statement would be: > > As this object is used in the index for the > pmElementTypeRegTable, users of this table should be careful > not to create entries that would result in instance names > with more than 128 subidentifiers. That will occur if this > object has more than 117 subidentifiers. > > That language serves the same purpose as a SIZE constraint (which > is not allowed for OBJECT IDENTIFIERs). > > > W: f(pm.mi2), (942,1) Row "pmRoleEntry" has indexing that may > > create variables with more than 128 sub-ids > > Specifically, the index of pmRoleEntry can exceed the OID size limit > by 142 sub-ids. The DESCRIPTION clause for pmRoleElement does say: > > As this object is used in the index for the pmRoleTable, > users of this table should be careful not to create entries > that would result in OIDs with more than 128 subidentifiers. > > In my opinion, this warning is inadequate, because there are other > variable-length index objects for this table, and no constraint on > this object could allow the 128 sub-id limit to be met if all of > those other index objects assume the maximum lengths indicated by > their SIZE constraints. So I think (following the advice in section > 4.6.5 of the guidelines document) that something like the following > text needs to be present in the DESCRIPTION clause of the row object > pmRoleEntry: > > Users of this table should be careful not to create entries > that would result in instance names with more than 128 > subidentifiers. That will occur if the total number of > components in pmRoleElement, pmRoleContextName, > pmRoleContextEngineID, and pmRoleString exceeds 114. > > NOTE: this table _may_ be dangerously close to the edge of > unusability. pmRoleContextName and pmRoleContextEngineID have a > maximum size of 32 octets. The latter is probably OK since the > practice in the SNMP-FRAMEWORK-MIB mandates a max size of 32 octets > for an engine ID; however, the former may be slim since RFC 3412 > does not (as far as I can tell) mandate a max size for a context > name. Mmm... 3412 may not. But 3415 has at least vacmContextName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) and based on that I made the pmMIB authors do things like: pmRoleContextName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) > pmRoleString has a max size of 64, which may or may not > be slim, but even if this were chopped down to a maximum of 32 > octets then pmRoleElement could have no more than 18 sub-ids, which > is definitely rather slim for a RowPointer object. This point could > merit discussion with the MIB module authors. > Mmm... I see your point. They first had pmRoleString limited to 32. So I wondered: "that means that in some langauges it can only be 4 characters... is that sufficient" and so they raised it to 64. So it sounds like we might be better off with a complete different idnexing scheme? > > W: f(pm.mi2), (1053,1) Row "pmCapabilitiesEntry" has indexing > > that may create variables with more than 128 sub-ids > > Specifically, the index of pmCapabilitiesEntry can exceed the OID > size limit by 11 sub-ids. The DESCRIPTION clause for > pmCapabilitiesType, which is the only index component, does say: > > As this object is used in the index for the > pmCapabilitiesTable, users of this table should be careful > not to create entries that would result in OIDs with more > than 128 subidentifiers. > > A more explicit statement would be: > > As this object is used in the index for the > pmCapabilitiesTable, users of this table should be careful > not to create entries that would result in instance names > with more than 128 subidentifiers. That will occur if this > object has more than 117 subidentifiers. > > That language serves the same purpose as a SIZE constraint (which > is not allowed for OBJECT IDENTIFIERs). > > > W: f(pm.mi2), (1181,1) Row "pmCapabilitiesOverrideEntry" has > > indexing that may create variables with more than 128 sub-ids > > Specifically, the index of pmCapabilitiesOverrideEntry can exceed > size limit by 11 sub-ids. The DESCRIPTION clause for > pmCapabilitiesOverrideType, which is the only index component, does > say: > > As this object is used in the index for the > pmCapabilitiesOverrideTable, users of this table should be > careful not to create entries that would result in OIDs > with more than 128 subidentifiers. > > A more explicit statement would be: > > As this object is used in the index for the > pmCapabilitiesOverrideTable, users of this table should be > careful not to create entries that would result in instance > names with more than 128 subidentifiers. That will occur > if this object has more than 117 subidentifiers. > > That language serves the same purpose as a SIZE constraint (which > is not allowed for OBJECT IDENTIFIERs). > > > W: f(pm.mi2), (1620,1) Row "pmTrackingPEEntry" has indexing that > > may create variables with more than 128 sub-ids > > Specifically, the index of pmTrackingPEEntry can exceed the OID size > limit by 78 sub-ids. The DESCRIPTION clause for pmTrackingPEElement > does say: > > As this object is used in the index for the > pmTrackingPETable, users of this table should be careful > not to create entries that would result in OIDs with more > than 128 subidentifiers. > > A more explicit statement would be: > > As this object is used in the index for the > pmTrackingPETable, users of this table should be careful > not to create entries that would result in instance names > with more than 128 subidentifiers. That may occur > if this object has more than 50 subidentifiers. > > That language serves the same purpose as a SIZE constraint (which > is not allowed for RowPointer objects, i.e., OBJECT IDENTIFIERs). > > A better solution in this case (because there are multiple > variable-length index objects) might be to put something like > the following language into the pmTrackingPEEntry DESCRIPTION > clause: > > Users of this table should be careful not to create entries > that would result in instance names with more than 128 > subidentifiers. That will occur if the total number of > components in pmTrackingPEElement, pmTrackingPEContextName, > and pmTrackingPEContextEngineID exceeds 114. > > > W: f(pm.mi2), (1730,1) Row "pmTrackingEPEntry" has indexing that > > may create variables with more than 128 sub-ids > > Specifically, the index of pmTrackingEPEntry can exceed the OID size > limit by 78 sub-ids. The DESCRIPTION clause for pmTrackingEPElement > does say: > > As this object is used in the index for the > pmElementTypeRegTable, users of this table should be > careful not to create entries that would result in OIDs > with more than 128 subidentifiers. > > The above should at least s/pmElementTypeRegTable/pmTrackingEPTable/. > A more explicit statement would be: > > As this object is used in the index for the > pmTrackingEPTable, users of this table should be careful > not to create entries that would result in instance names > with more than 128 subidentifiers. That may occur > if this object has more than 50 subidentifiers. > > That language serves the same purpose as a SIZE constraint (which > is not allowed for RowPointer objects, i.e., OBJECT IDENTIFIERs). > > A better solution in this case (because there are multiple > variable-length index objects) might be to put something like > the following language into the pmTrackingEPEntry DESCRIPTION > clause: > > Users of this table should be careful not to create entries > that would result in instance names with more than 128 > subidentifiers. That will occur if the total number of > components in pmTrackingEPElement, pmTrackingEPContextName, > and pmTrackingEPContextEngineID exceeds 114. > > > W: f(pm.mi2), (1841,1) Row "pmDebuggingEntry" has indexing that > > may create variables with more than 128 sub-ids > > Specifically, the index of pmDebuggingEntry can exceed the OID size > limit by 79 sub-ids. The DESCRIPTION clause for pmDebuggingElement > does say: > > As this object is used in the index for the > pmElementTypeRegTable, users of this table should be > careful not to create entries that would result in OIDs > with more than 128 subidentifiers. > > The above should at least s/pmElementTypeRegTable/pmDebuggingTable/. > A more explicit statement would be: > > As this object is used in the index for the > pmDebuggingTable, users of this table should be careful > not to create entries that would result in instance names > with more than 128 subidentifiers. That may occur if > this object has more than 49 subidentifiers. > > That language serves the same purpose as a SIZE constraint (which > is not allowed for RowPointer objects, i.e., OBJECT IDENTIFIERs). > > A better solution in this case (because there are multiple > variable-length index objects) might be to put something like > the following language into the pmDebuggingEntry DESCRIPTION > clause: > > Users of this table should be careful not to create entries > that would result in instance names with more than 128 > subidentifiers. That will occur if the total number of > components in pmDebuggingElement, pmDebuggingContextName, > and pmDebuggingContextEngineID exceeds 113. > > NOTE: for all above the above the OID size limits were derived from > the smilint warning messages, which are attached. There were no > smilint warnings for the stuff that follows. > > > W: f(pm.mi2), (1627,19) Row "pmTrackingPEEntry" does not have a > > consistent indexing scheme - index items must be in same order > > as used in INDEX clause for "base row" pmPolicyEntry > > This warning may indeed be indicative of a problem, but not in > this table. The thing that SMICng is beefing about is the fact > that the INDEX clause of pmPolicyEntry is > > INDEX { pmPolicyAdminGroup, pmPolicyIndex } > > and in order for pmTrackingPEEntry to be a proper extension table of > pmPolicyEntry its index clause should start with the same two items. > pmTrackingPEEntry uses pmPolicyIndex only. Now this is OK, because > pmPolicyIndex is defined to be a _unique_ policy index, i.e., > further differentiation by pmPolicyAdminGroup is not needed. But I had questioned this qith the authors. And after that they made it explicit that pmPolicyIndex is indeed to be unique. So I agree that from that point of view, there now seems to be no issue. > that brings up the question why pmPolicyAdminGroup is even in the > index clause of pmPolicyEntry. Under the circumstances it possibly > should not be. Certainly its presence makes it harder than > it otherwise would be for an application to correlate the contents > of the pmTrackingPETable, pmTrackingEPTable, and pmPolicyTable. It > might be a good idea to ask the authors of the MIB module to explain > this design decision. > I also kept saying that I find the indexing scheme weird. The first para of the description clause: "An administratively assigned string that can be used to group policies for convenience, readability or to simplify configuration of access control. kind of make me think is is OK. It then hooks up to that in the Security Considerations section, which puts yet some more justification to it... or so it seems to me. Did you see that? > > W: f(pm.mi2), (1742,19) Row "pmTrackingEPEntry" does not have a > > consistent indexing scheme - index items from current table > > must come after index items from other tables > > This warning comes from the language in RFC 2578 section 7.8.1, > i.e., SMICng interprets the text of that section to say that if > there is any relationship between tables other than a 1-for-1 > augmentation or sparse augmentation, then one "must" follow > 7.8.1(3). However, RFC 2578 section 7.8.1 only says "should" and > not "must" or "shall". If one interprets the the lower-case > "should" to mean SHOULD as defined in RFC 2119, then I would say > that it is OK to ignore this warning. The table DESCRIPTION clause > says: > > This table is indexed in order to optimize retrieval of the > status of all policies active for a given element. > > which is a valid reason for not having pmPolicyIndex appear first. > I agree. And so I think it is OK. > > W: f(pm.mi2), (1849,19) Row "pmDebuggingEntry" does not have a > > consistent indexing scheme - index items must be in same order > > as used in INDEX clause for "base row" pmPolicyEntry > > I think that this warning should be ignored. See the comments for > the previous two warnings. > I agree > > W: f(pm.mi2), (1942,19) Variable "pmCapabilitiesType" in > > notification "pmNewCapabilityNotification" is an index for a > > table > > It also happens to be the only column in the table. So this warning > should be ignored, too. > I agree. Thanks for your quick review. Let me know if you want to post about the better text (as proposed by you) to the WG list or if I should do it. Bert > //cmh >