From owner-snmpconf@seymour39.snmp.com Wed Feb 5 13:10:17 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 NAA04881 for ; Wed, 5 Feb 2003 13:10:16 -0500 (EST) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3/m.000221) id NAA26204 for snmpconf-outgoing; Wed, 5 Feb 2003 13:05:53 -0500 (EST) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155D6C9CC@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Snmpconf (E-mail)" Subject: FW: AD review of draft-ietf-snmpconf-pm-11.txt - part 2 Date: Wed, 5 Feb 2003 19:05:14 +0100 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 OK, here is part 2. I know... back on Jan 28 I promised it would come "tomorrow"... I guess that means (for most of you) just one night sleep :-() .. Oh well. The part 1 is also attached at the bottom in case anyone wants it all together. Continuing from Page 69 - sect 9.4.14 and sect 9.4.15 I get confused. A character in a UTF-8 string can be composed of multiple octets. I am sure that that is intended. But are we sure everybody understands. Specifically with the focus that a 7-bit ASCII character is the same in ASCII as in UTF-8 may confuse people. The chr() function may return a string of multiple octets length and the octets used from the str argument in ord() function may be several octets long to return an integer that will exceed 255. I'd add something to make that clear. - sect 11 MIB definitions general comments: - StorageType object MUST specify which columns are to be writable for 'permanent' entries - RowStatus objects MUST specify which columns can be modified while a row is 'active' - in front of (before) various tables you have extensive MIB comment lines. I think a lot of that would be better placed in the DESCRIPTION clause of the table. - once you want this to be considered for PS, you better change the import of experimental to mib-2 and do a ::= { mib-2 xxx } -- xxx to be assigned by IANA - pls add a copyright statement to the DESCRIPTION clause of MODULE-IDENTITY as per http://www.ietf.org/IESG/STATEMENTS/MIB-COPYRIGHT.txt - Pls change "The original version of this MIB, published as RFCXXXX." Into "The original version of this MIB, published as RFCXXXX." -- RFC-Editor assigns XXXX - 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 - I see: pmPolicyAdminGroup OBJECT-TYPE SYNTAX UTF8String (SIZE(0..8)) That size restriction makes it 1 or 2 characters in some languages, no? Is that wise? - I see: pmPolicyPrecedenceGroup OBJECT-TYPE SYNTAX UTF8String (SIZE (0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "An administratively assigned string that is used to group policies. For each element, only one policy in the same precedence group may be active on that element. If multiple policies would be active on an element (because their conditions return non-zero), the execution environment will only allow the policy with the highest value of pmPolicyPrecedence to be active." ::= { pmPolicyEntry 3 } I think this will require the use of stringprep. I discussed this use of stringprep with authors already and had an APPS AD involved as well. I'll not repeat this comment, but it potentially applies to other objects, where UTF8 strings need to be sequenced or compared. - I see various objects iwth RANGES like: pmPolicySchedule OBJECT-TYPE SYNTAX Unsigned32 (0..65535) WOuld it be better to not have a range and specify such a range in a/the MODULE-COMPLIANCE ?? But how this match to pmSchedIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) Is that not a table to which this value is a link? - pmPolicyElementTypeFilter OBJECT-TYPE SYNTAX UTF8String (SIZE (0..128)) Is this how you want to do that? WOuld it not be better to have a ptr to a table of OID entries? Now it is so limited in the number of OIDs you can put in here. In the last sentence in the DESCRIPTION clause it says "if a value is registered". WOuld you rather s/registered/included/ ?? - pmPolicyConditionScriptIndex OBJECT-TYPE SYNTAX Unsigned32 I think a range to exclude zero would be wise. Otherwise explain what special value zero means? RRef [23] is normative I think. - Similar comment for ActionScriptIndex - pmPolicyDebugging OBJECT-TYPE SYNTAX INTEGER { off(0), on(1) } we (MIB reviewers) tend to tell people to start enums at 1. I also wonder if pmPolicyDebuggingOn OBJECT-TYPE SYNTAX TruthValue would not be better here - pmPolicyAdminStatus OBJECT-TYPE SYNTAX INTEGER { disabled(0), enabled(1), enabledAutoRemove(2) start enum at 1. I wonder... do you want a OperStatus as well? - pmPolicyStorageType OBJECT-TYPE You must explain/describe in DESCRIPTION clause which objects must be writable for 'permanent' entries - pmPolicyCodeTable I see nothing about persistency of this table, nor do I see a STorageType object Should some (or all) of the comments before this table not just go into the DESCRIPTION clause? Same for other tables. - pmElementTypeRegTable Mmm... I wonder if we do not need to specify the contextName as well ?? - in DESCRIPTION clause of pmElementTypeRegOIDPrefix This object identifier value is specified down to the 'entry' component (i.e. ifEntry) of the identifier. s /i.e./e.g./ ?? A special OBJECT IDENTIFIER '0.0' can be written to this object. '0.0' represents the single instance of the system Mmmm... ? This is an INDEX object and so is not accessible. So "can be written to this object" sounds pretty weird to me - pmElementTypeRegDescription OBJECT-TYPE SYNTAX UTF8String (SIZE (0..32)) Mmm... seems only some 5 characters in some languages. Sounds short for a "descriptive label" to me - pmRoleContextName OBJECT-TYPE SYNTAX SnmpAdminString I believe that in all other mib modules that use ContextName we have a SIZE of 0..32. Might make sense here too - pmRoleContextEngineID OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..32)) Would it not be better to use (5..32) as we have defined SnmpEngineID with that size in RFC3414 ?? I also wonder about .................... If the element is on the local system this object will be the empty string." Why not use the local SnmpEngineID ?? If you do use empty string then Size could be SIZE(0 | 5..32). - pmCapabilitiesType talks about "traps", probably better to use "notifications" May need to talk about "MIB module" in stead of MIB or MIBs, Instead of "standard MIBs" I would say "MIB modules on the standards track" Talks about OIDs registered with IANA. But I don't see any IANA considerations or a registry where they can be registered. - pmCapabilitiesOverrideState OBJECT-TYPE SYNTAX INTEGER { invalid(0), valid(1) } start enums at 1, or better use TruthValue ?? - page 101 20000101T080000/20000131T120000 January 1, 2000, 0800 through January 31, 2000, noon Might want to use T130000 for 1pm to show 24hour clock? - in pmSchedEntry and pmSchedStorageType you talk about pmSchedHour and pmSchedMinute objects, but I cannot find them - pmTrackingPEContextName OBJECT-TYPE SYNTAX SnmpAdminString SIZE (0..32) ?? - pmTrackingPEContextEngineID Same questions as above for xxxContextEngineID - pmTrackingEPContextName OBJECT-TYPE SYNTAX SnmpAdminString pmTrackingEPContextEngineID OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..32)) Same questions as above - pmTrackingEPStatus OBJECT-TYPE SYNTAX INTEGER { on(0), forceOff(1) } start enum at 1. Possibly a TruthValue? - pmDebuggingTable What happens with any entries if a system reboots/restarts? - pmDebuggingContextName SnmpAdminString, pmDebuggingContextEngineID OCTET STRING, Same questions as a By the way, why is ...ContextEngineID not of TC SnmpEngineID. Probably because of the empty string ?? Another reason to not do that. - pmConformance OBJECT IDENTIFIER ::= { pmMib 20 } why the sudden jump to 20 ?? - Please check your Security COnsiderations section against the latest http://www.ops.ietf.org/mib-security.html guidelines. - Pls split references in normative and informative references as per http://www.rfc-editor.org/policy.html bove... Thanks, Bert -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: dinsdag 28 januari 2003 0:54 To: Snmpconf (E-mail) Subject: AD review of draft-ietf-snmpconf-pm-11.txt - part 1 Here is a list of NITS, admin/bureucratic comments and more or less serious concerns/questions. - on the fornt page, I would not repeat the authors/editors' names under the title. - At next revision, update copyright date - the RFC-Editor does not want the abstract to be a numbered section - Section 2, we have a new MIB boilerplate since the SNMPv3 RFCs have been published as STD 62. See: http:/www.ops.ietf.org - We also have a new MIB security guidelines at the same place. You may want to check if that means some changes to your Security Considereations section. - References need to be split in Normative and Informative See http://www.rfc-editor.org/policy.html - last para on page 4 talsk about "..this document defines standard management objects" and "... in a standard form..." The attribute of STDs track is assigned external to an RFC, so you should not state/claim that this is standard in the document itself. - First list of bullets in section 3 seems to be a marketing statement. We do not need those in RFCs. - In general, I would like the authors/editors to go through the document and to properly use the terms MIB, MIB Module. I think too often then term "MIBs" is used when you really mean "MIB Modules". I noticed it at least twice in sect 5.3 - Sect 5.5.1. s/are are/are/ - Section 6 states in 3rd para: "Some examples of the features that have been removed...." Not sure it is really "have been removed" or if it is better stated as "are not used" or "are not available" or "are not inherited" or such. - Has anyone checked the EBNF specification via a syntax checker? See http://www.ietf.org/ID-nits.html section 2 6th bullet, which also points to http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt For example, I am not sure this is correct (page 18) unary_op: '+' | '-' | ' | '!' | '++' | '--' What does that single quote between the 2nd and 3rd } mean? - sect 6.2.1 I get a bit confused when you talk about 8-bit elements for a string (in UTF-8 context). Steve tried to explain, but the current text still confuses me. I think he was going to try and add some text to unconfuse me (and possibly others). - When you use EBNF, LHS, RHS and such acronyms the first time in the document, pls expand them Thisis another RFC-Editor policy. - I had some conversation with Steve about the Library functions, on hos they are split in 4 categories and which of the "reserved words" can be used when and where. Also a question on the "which categories must be supported". I believe the answer was all. Steve is going to clarify some of this. - Sect 9.1.1 starts with a ">"... ?? I saw that at a few more places - Sect 9.1.1 I see snmp-function(...[, integer mPModel, string tDomain, string tAddress, integer secModel, string secName, integer secLevel, string contextEngineID ]) It seems to me we need to be able to express the contextName for local and for remote SNMP engines? How do we do that? I think when I look further in the document, that one of the "..." arguments is probably the contextName. Might be good to explain some of that. - when I see this snmp-function(...[, integer mPModel, string tDomain, string tAddress, integer secModel, string secName, integer secLevel, string contextEngineID ]) and if I understand it correctlym then all those extra args are positional and optional, is then not the better notation: snmp-function(...[, integer mPModel [, string tDomain [, string tAddress [, integer secModel [, string secName [, integer secLevel [, string contextEngineID ]]]]]]]) - The sample that follows getVar("sysDescr.0", "", SNMPv3, "snmpUDPDomain", "192.168.1.1/161", SNMPv3, "joe", "NoAuthNoPriv"); confuses me somewhat. I think it is a getVar for sysDescr.0, in the default contextName but it seems to list a SN MPv3 secModel. I am not aware that we have such a secmodel, do we? We have a USM secModel. We also have an SNMPv1 and SNMPv2c, or even an any secModel. But not an SNMPv3 secModel. - Sect 9.1.1 also talks about TDomain. I would suggest to consider to use terms from RFc3419, which includes values for IPv6, which is something that IESG really wants these days. - bottom of page 34. Why do we allow a trailing dot if it can case strncmp() problems? - sect 9.1.3.1 The empty (zero length) string is the default context. so I guess if one omits it that one also gets the default context. Not sure if that is clear here. At least the text If 'contextName' is not present, this element's contextName will be used. Confuses me. What does that mean? This comes back in a lot of the function descriptions - Sect 9.1.3.1 and following sections So do we realize that a "programmer" of these scripts needs to speak OID lingo as opposed to descriptors? Do we really believe that that is encouraging? - Sect 9.1.3.2 The exists() function is used to verify the existence of an SNMP MIB instance. Do you mean s/MIB/MIB object/ You cannot be meaning a complete MIB instance, do you? Similar text is used in following sections too. - I guess that exists() returns an integer cause we do not have a boolean in our language, right? - Sect 9.1.3.4 Mmm... why not rename "pattern" to "searchString" ?? And is the programmer expected to use digits to express which mode to use? Or are there reserved words for that? - Sect 9.1.3.6 I wonder how rows that have multiple integers, or octet strings or such as index, how they get created? Does the last para on page 42 agree with the code fragment on the next page? Spefically, does the if createRow() call and and checking of return code and index agree with that para? Maybe I am just confused. - page 44 talks about "noSuchName or noSuchObject" - do we still want to talk about noSuchName (SNMPv1 ??) - do we not need to talk about noSuchInstance? - sect 9.1.4.1 How about error-status and error-index? - sect 9.1.4.2 I wonder if pdu should not be prefixed with &pdu ? Can this function never return an error? - sect 9.1.4.3 and 9.1.4.4 I see int readVar(integer pdu, integer varBindIndex, and I see integer snmpSend(integer reqPDU, integer reqNumVarbinds, So I wonder, do we have both int and integer as a datatype? - sect 9.1.4.5 What if you pass a non-existing pdu handle? Will it return an error? so should it be: integer readError(integer pdu, integer numVarbinds, integer &errorStatus, integer &errorIndex, integer &hasException) to show that it can return an error? The same question for some of the other functions in sect 9.1 - sect 9.2 I wonder if this is not better sect 9.1.5 ?? It is part of the SNMP library functions, no? - sect 9.2 const integer Integer = 2; So does that potentially cause confusion for people to recognize the difference between integer with lowercase i and upprecase I ?? In fact I wonder if these could not all better be prefixed with some string like SNMP or so, e.g. const integer SNMP_Integer = 2; const integer SNMP_Integer32 = 2; etc You refer to RFC1905, better to refer to RFC3416 You also refer to RFC2571, better to use RFC3411 - sect 9.3.1 I fail to see how the function returns an indication on how the object is indexed. And does the prototype function not need arguments? - sect 9.3.4 and 9.3.5 I had asked steve if the function ev() and ec() could be better named elementValue() and elementCount(). He answered that thes function will be used a lot, similar to argv and argc in C. So.. are we happy that these are such cryptic functiuon names? Is elemv() and elemc() a better compromise. I can live with ev() and ec() if the WG says it is OK. - sect 9.3.4 and 9.3.5 I wonder if it is easy to know what "this element" means. I think it is explained in sect 7... but that is quite a few pages back. - When I see things like the roleMatch function and I know that we are in a UTF-8 environment, then I think we need to include stringprep functionality as per RFC3454. In fact Patrik Faltstrom, APPS AD has confirmed that this is needed, and he has already pointed the authors to a sample. - I guess we have another set of reserved words at the end of sect 9.3.7 Maybe we need one section that lists them all, no? - sect 9.4.6 last sentence "... twice if is an expression" ??? - sect 9.4.8 I first thought that oid needed to be &oid. But the resulting OID is returned as a string (is what Steve told me). I guess the "...replace len subids in oid1.." is what confused me. OK, part 2 comes tomorrow. Bert Thanks, Bert From owner-snmpconf@seymour39.snmp.com Sat Feb 15 10:55:46 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 KAA04334 for ; Sat, 15 Feb 2003 10:55:46 -0500 (EST) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3/m.030206) id KAA01184 for snmpconf-outgoing; Sat, 15 Feb 2003 10:50:39 -0500 (EST) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155E64F23@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Steve Waldbusser Cc: "Snmpconf (E-mail)" Subject: RE: AD review of draft-ietf-snmpconf-pm-11.txt - part 1 and part 2 Date: Sat, 15 Feb 2003 16:49:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com [ I copied the WG mailing list, instead of responding in one-on-one emails] Steve did answer some of my questions/comments and I still have concerns/questions/remarks as follows. > > - Has anyone checked the EBNF specification via a syntax checker? > > See http://www.ietf.org/ID-nits.html section 2 6th bullet, > > which also points to > > http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt > > For example, I am not sure this is correct (page 18) > > unary_op: '+' | '-' | ' | '!' | '++' | '--' > > What does that single quote between the 2nd and 3rd } mean? > > This was an nroff formatting bug and has been fixed. Nroff > eats tilde's and sometimes accompanying single quotes > (appetizers? :-). So I have to go back in and edit by hand > after it's over. I forgot the last time. > Thanks, so you fixed the one syntax error that I spotted (maybe some othres that I did not spot as well). But the question remains: Did anyone check with a tool if the SYNTAX is now correct? > > > > - sect 9.1.3.1 > > The empty (zero length) string is the default context. > > so I guess if one omits it that one also gets the default > > context. Not sure if that is clear here. > > At least the text > > If 'contextName' is not present, > > this element's contextName will be used. > > Confuses me. What does that mean? > > This comes back in a lot of the function descriptions > > > > "This element" is an important concept described earlier in the > document. This element's contextname is not necessarily the same as > the default context. I think you'll find the references to 'this > element' much more explicit now and easier to understand. > Aha. your explantion helps. So if they pass the empty string, then "this element" will be considered in the default context. I will check if text is clear now. > > - Sect 9.1.3.1 and following sections > > So do we realize that a "programmer" of these scripts needs > > to speak OID lingo as opposed to descriptors? > > Do we really believe that that is encouraging? > > > > A few paragraphs earlier it states: NMS user > interfaces are encouraged to allow humans to view object > identifiers with ASCII descriptors, but they must translate those > descriptors to dotted-decimal format before sending them in MIB > objects to policy agents. > Yes, I had seen that. But as you and I know, in the beginning (may last for a long time) there will not be (many) such interfaces. And once they show up, they may not be cheap. So I keep wondering if will "encourage operators to write scripts". > > - Sect 9.1.3.4 > > Mmm... why not rename "pattern" to "searchString" ?? > > > > I think this would conflict with the other use of 'searchString' in > the same function description. > Mm... I need to reread, cause then I did not understand it. > > > > - Sect 9.1.3.6 > > I wonder how rows that have multiple integers, or octet > > strings or such as index, how they get created? > > > > createRow is designed to make dealing with RowStatus easy. RowStatus > is designed to be associated with an index that contains an arbitrary > integer value (possibly in conjunction with other values). createRow > sets that arbitrary integer value, leaving the rest of the oid > alone. So if your index also had other components the caller of > createRow would set the other index components first and then > createRow would set just the arbitrary integer field. The caller > indicates which subid is the arbitrary integer field (with the '*'). > Well.. I am still not sure I understand this. In any event, this was not clear from the revision 11 text. Did you add any more explanation? > > > > - page 44 talks about "noSuchName or noSuchObject" > > - do we still want to talk about noSuchName (SNMPv1 ??) > > - do we not need to talk about noSuchInstance? > > I added noSuchInstance > But should you not remove noSuchName? > > > > - sect 9.1.4.1 > > How about error-status and error-index? > > > > They're don't cares. > I guess so. But I do now that in my code I always made sure that they were zero on a new PDU. Might be good to just prescribe that here too, no? > > > > - sect 9.1.4.2 > > I wonder if pdu should not be prefixed with &pdu ? > > No, we're referencing it with a handle which isn't modified > May want to make that clearer, maybe? Could have been just my first read. > > > > Can this function never return an error? > > No, only an RTE > Want to make that clear? > > > > - sect 9.1.4.5 > > What if you pass a non-existing pdu handle? > > Will it return an error? so should it be: > > > > integer readError(integer pdu, integer numVarbinds, > > integer &errorStatus, integer &errorIndex, > > integer &hasException) > > > > to show that it can return an error? > > The same question for some of the other functions in sect 9.1 > > > > Actually it should be an RTE as some of it's companion functions > already behave. I changed readVar to conform to this as well. > And made that clear I hope? > > > > - sect 9.2 > > const integer Integer = 2; > > So does that potentially cause confusion for people to > > recognize the difference between integer with lowercase i > > and upprecase I ?? > > In fact I wonder if these could not all better be prefixed > > with some string like SNMP or so, e.g. > > > > const integer SNMP_Integer = 2; > > const integer SNMP_Integer32 = 2; > > etc > > That's a pretty big change to the look and feel. I'm uncomfortable > making that change without more deliberation. > So bring it to the list so that people can debate it. I know that I would often be confused with just a capatial I for Integer > > > > - sect 9.3.1 > > I fail to see how the function returns an indication on > > how the object is indexed. > > Since I know what type of element 'this element' is, I know how the > index is set up. > Might want to explain in the text > > And does the prototype function not need arguments? > > This element is known to the execution environment > Might want to say so? > > > > - sect 9.3.4 and 9.3.5 > > I had asked steve if the function ev() and ec() > > could be better named elementValue() and elementCount(). > > He answered that thes function will be used a lot, similar > > to argv and argc in C. So.. are we happy that these > > are such cryptic functiuon names? Is elemv() and elemc() > > a better compromise. > > I can live with ev() and ec() if the WG says it is OK. > > I don't know if people have changed their mind. > So WG chairs, pls do a POLL for the WG > > - sect 9.3.4 and 9.3.5 > > I wonder if it is easy to know what "this element" means. > > I think it is explained in sect 7... but that is quite > > a few pages back. > > I made a change that I think will really help which is to enclose all > instances of 'this element' in single quotes. This makes it clear > that it is something special and the reader will be much better > acquainted with it's 'specialness' by the time they reach section 9. > Will check. May still want to say some special words about it in a few places. I know that 'this element' should be a concept that C++ people can easily pick up. But how about just C programmers, or Perl script writers. Does the concept exists there too? (I know, this shows I am not a real Perl expert) > > - 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? > Yeah... but I am sure you do not want to wait for that, do you? So if you want to keep your own, call it PmUtf8String for now, explain why you are not re-using, and since you prefix it with Pm it will be easier to migrate to a generic one in a central repository later > > > > - pmRoleContextEngineID OBJECT-TYPE > > SYNTAX OCTET STRING (SIZE (0..32)) > > Would it not be better to use (5..32) as we have defined > > SnmpEngineID with that size in RFC3414 ?? > > Since it is optional we need to include 0 > Well, then it could be (0 | 5..32) so to not cause invalid ones. > > I also wonder about > > .................... If the element is on the local system > > this object will be the empty string." > > Why not use the local SnmpEngineID ?? > > It is simpler this way. > > If you do use empty string > > then Size could be SIZE(0 | 5..32). > > OK, reluctantly - I hope deployed MIB compilers tend to be > up-to-date. We'll see. > > > Talks about OIDs registered with IANA. But I don't see any > > IANA considerations or a registry where they can be registered. > > We have no plans for a formal registry at this time. > Then you should not talk about it, should you? Or make an explicit statement that there is none yet and that formal procedures need to be specified if we ever need such a registry > > By the way, why is ...ContextEngineID not of TC SnmpEngineID. > > Probably because of the empty string ?? Another reason to not > > do that. > > Yes, because of the empty string. It doesn't make sense for this to > cause us to supply engineid in all cases when for 99% of cases an > empty string is all we need. > I need to check Bert From owner-snmpconf@seymour39.snmp.com Mon Feb 17 23:14:43 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 XAA08434 for ; Mon, 17 Feb 2003 23:14:43 -0500 (EST) Received: by seymour39.snmp.com (8.9.3/m.030206) id XAA17883 for snmpconf-outgoing; Mon, 17 Feb 2003 23:11:23 -0500 (EST) Message-ID: <001101c2d704$409f06c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: Subject: snmpconf Fw: I-D ACTION:draft-irtf-aaaarch-generic-policy-03.txt Date: Mon, 17 Feb 2003 20:14:37 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Hi - This IRTF work appears to have some similarties to http://www.ietf.org/internet-drafts/draft-ietf-snmpconf-pm-11.txt in its motivations for defining a C-like language of its own. Randy > From: > To: > Sent: Friday, February 14, 2003 3:43 AM > Subject: I-D ACTION:draft-irtf-aaaarch-generic-policy-03.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : A grammar for Policies in a Generic AAA Environment > Author(s) : A. Taal et al. > Filename : draft-irtf-aaaarch-generic-policy-03.txt > Pages : 16 > Date : 2003-2-13 > > In this document the concept of a so-called Driving Policy is pre- > sented. A Driving Policy determines the behavior of an AAA server > (Authentication, Authorization, Accounting) when it is confronted > with a specific message type of the AAA protocol. The first part > of this document defines the role of a Driving Policy and how it > fits into the AAA concept. According to the model presented, the > main task of a Driving Policy is to describe which pre-conditions > have to be checked before the corresponding actions, needed to > fulfill an incoming AAA request, can be called, and how to deal > with the post-conditions of these actions. In the second part a > grammar is proposed for these Driving Policies accompanied by the > necessary comments about the semantics. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-irtf-aaaarch-generic-policy-03.txt ... From owner-snmpconf@seymour39.snmp.com Thu Feb 20 07:44:17 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 HAA09839 for ; Thu, 20 Feb 2003 07:44:17 -0500 (EST) Received: by seymour39.snmp.com (8.9.3/m.030206) id HAA18088 for snmpconf-outgoing; Thu, 20 Feb 2003 07:39:55 -0500 (EST) Message-Id: <200302201235.HAA08882@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: snmpconf@snmp.com From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-snmpconf-pm-12.txt Date: Thu, 20 Feb 2003 07:35:29 -0500 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Configuration Management with SNMP Working Group of the IETF. Title : Policy Based Management MIB Author(s) : S. Waldbusser, J. Saperia, T. Hongal Filename : draft-ietf-snmpconf-pm-12.txt Pages : 127 Date : 2003-2-19 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP- based internets. In particular, this MIB defines objects that enable policy-based configuration management of SNMP infrastructures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-snmpconf-pm-12.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-snmpconf-pm-12.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-snmpconf-pm-12.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: <2003-2-19141820.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpconf-pm-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpconf-pm-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-19141820.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-snmpconf@seymour39.snmp.com Mon Feb 24 11:21:10 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 LAA18074 for ; Mon, 24 Feb 2003 11:21:10 -0500 (EST) Received: by seymour39.snmp.com (8.9.3/m.030206) id LAA08380 for snmpconf-outgoing; Mon, 24 Feb 2003 11:18:55 -0500 (EST) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155F7C9A3@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Snmpconf (E-mail)" Subject: snmpconf FW: [aaaarch] draft-irtf-aaaarch-generic-policy-04.txt Date: Mon, 24 Feb 2003 17:18:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com I think this WG should know this Thanks, Bert -----Original Message----- From: Arie Taal [mailto:A.Taal@phys.uu.nl] Sent: maandag 24 februari 2003 15:49 To: aaaarch@fokus.gmd.de Subject: [aaaarch] draft-irtf-aaaarch-generic-policy-04.txt I have looked at the draft http://www.ietf.org/internet-drafts/draft-ietf-snmpconf-pm-11.txt and the relation with our work might be the following. After a first glance my impression is that the material of the draft mentioned is more applicable by what we call the Application Specific Modules (ASMs). Our draft is concerned about a higher level, the policies we propose are much more limited, they describe which ASMs are needed to fulfil an AAA request. Arie Taal ----- Original Message ----- From: "Wijnen, Bert (Bert)" To: "AAAARCH (E-mail)" Sent: Tuesday, February 18, 2003 12:00 PM Subject: [aaaarch] FW: snmpconf Fw: I-D ACTION:draft-irtf-aaaarch-generic-policy-03.txt > Are you AAAARCH guys aware of this too? > Any comment? > > Thanks, > Bert > > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: dinsdag 18 februari 2003 5:15 > To: snmpconf@snmp.com > Subject: snmpconf Fw: I-D > ACTION:draft-irtf-aaaarch-generic-policy-03.txt > > > Hi - > > This IRTF work appears to have some similarties to > http://www.ietf.org/internet-drafts/draft-ietf-snmpconf-pm-11.txt > in its motivations for defining a C-like language of its own. > > Randy > > > From: > > To: > > Sent: Friday, February 14, 2003 3:43 AM > > Subject: I-D ACTION:draft-irtf-aaaarch-generic-policy-03.txt > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > > > Title : A grammar for Policies in a Generic AAA Environment > > Author(s) : A. Taal et al. > > Filename : draft-irtf-aaaarch-generic-policy-03.txt > > Pages : 16 > > Date : 2003-2-13 > > > > In this document the concept of a so-called Driving Policy is pre- > > sented. A Driving Policy determines the behavior of an AAA server > > (Authentication, Authorization, Accounting) when it is confronted > > with a specific message type of the AAA protocol. The first part > > of this document defines the role of a Driving Policy and how it > > fits into the AAA concept. According to the model presented, the > > main task of a Driving Policy is to describe which pre-conditions > > have to be checked before the corresponding actions, needed to > > fulfill an incoming AAA request, can be called, and how to deal > > with the post-conditions of these actions. In the second part a > > grammar is proposed for these Driving Policies accompanied by the > > necessary comments about the semantics. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-irtf-aaaarch-generic-policy-03.txt > ... > >