review of snmpconf--pm-10

From owner-snmpconf@seymour39.SNMP.COM Mon May 6 16:42:02 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05644 for ; Mon, 6 May 2002 16:42:02 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id QAA28941 for snmpconf-outgoing; Mon, 6 May 2002 16:35:27 -0400 (EDT) Message-ID: <0BF8B32B723ED5119E0B0002A551748B0305479B@corp-exc3.ctron.com> From: "Harrington, David" To: "snmpconf@snmp. com (E-mail)" Subject: review of snmpconf--pm-10 Date: Mon, 6 May 2002 16:31:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F53D.03DB7A10" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com 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_01C1F53D.03DB7A10 Content-Type: text/plain; charset="iso-8859-1" Hi, I have chosen this week to try to get caught up on some IETF review work, including following up on huge documents that I previously reviewed, which due to their size I have not had time to re-review. In my last review of the policy mib document series, I identified 103 items I felt needed addressing. I have gone over those 103 items to see if they had been addressed in the -10- revision. I find that 75 of the 103 items were not addressed. The bulk of the 28 that were addressed were spelling and grammar corrections, with some rewordings for clarity. 24 of the items not addressed were merely suggested rewordings that weren't terribly important to resolve, or they were questions about the language and expression evaluation. I'll igonore those items, even though I still feel the language is a weak spot in this proposal. 51 of the items not addressed dealt with document clarity that could impact interoperability. Many of the still unresolved 51 items were concerns that a management application could not rely on multiple implementations to provide consistent support of a feature. Some were requests for examples to help make the intent clearer to help implementors not do it wrong. Some were requests for re-ordering the document to help eliminate some of the need for so many forward references. When will the remaining issues that were raised be addressed? Thanks, dbh David Harrington Network Management Architect Office of the CTO Enterasys Networks ------_=_NextPart_001_01C1F53D.03DB7A10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable review of snmpconf--pm-10

Hi,

I have chosen this week to try to get caught up on = some IETF review work, including following up on huge documents that I = previously reviewed, which due to their size I have not had time to = re-review.

In my last review of the policy mib document series, = I identified 103 items I felt needed addressing. I have gone over those = 103 items to see if they had been addressed in the -10- revision. I = find that 75 of the 103 items were not addressed.

The bulk of the 28 that were addressed were spelling = and grammar corrections, with some rewordings for clarity.

24 of the items not addressed were merely suggested = rewordings that weren't terribly important to resolve, or they were = questions about the language and expression evaluation. I'll igonore = those items, even though I still feel the language is a weak spot in = this proposal.

51 of the items not addressed dealt with document = clarity that could impact interoperability. Many of the still = unresolved 51 items were concerns that a management application could = not rely on multiple implementations to provide consistent support of a = feature. Some were requests for examples to help make the intent = clearer to help implementors not do it wrong. Some were requests for = re-ordering the document to help eliminate some of the need for so many = forward references.

When will the remaining issues that were raised be = addressed?

Thanks,
dbh

David Harrington
Network Management Architect
Office of the CTO
Enterasys Networks

------_=_NextPart_001_01C1F53D.03DB7A10-- From owner-snmpconf@seymour39.SNMP.COM Tue May 7 07:47:00 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03300 for ; Tue, 7 May 2002 07:47:00 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id HAA28508 for snmpconf-outgoing; Tue, 7 May 2002 07:43:26 -0400 (EDT) Content-Type: text/plain; charset="iso-8859-1" From: Jon Saperia To: snmpconf@snmp.com, "Harrington, David" , "snmpconf@snmp. com (E-mail)" Subject: Re: review of snmpconf--pm-10 Date: Tue, 7 May 2002 07:43:31 +0000 X-Mailer: KMail [version 1.3.1] References: <0BF8B32B723ED5119E0B0002A551748B0305479B@corp-exc3.ctron.com> In-Reply-To: <0BF8B32B723ED5119E0B0002A551748B0305479B@corp-exc3.ctron.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: <102077176501@mx04.gis.net> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit Hi David (H) David thanks for the posting. As you know last call has closed and the document has been passed to the IESG. That said, we want to make sure that any issues that you feel have been missed get looked at again. David Partain and I would like for you to identify which of the 51 are of concern as soon as you can. We will take these and go over them again with Steve and either propose a change or explain why we think there should be no change. If you could send us the 51 items by the end of the week, that would be a big help. We will do the review as quickly as possible. Based on the results we hope to be able to update the document with any clarifications without another last call. The clarifications will of course be sent to the list. Thanks David and Jon On Monday 06 May 2002 08:31 pm, Harrington, David wrote: > Hi, > > I have chosen this week to try to get caught up on some IETF review > work, including following up on huge documents that I previously > reviewed, which due to their size I have not had time to re-review. > > In my last review of the policy mib document series, I identified 103 > items I felt needed addressing. I have gone over those 103 items to see > if they had been addressed in the -10- revision. I find that 75 of the > 103 items were not addressed. > > The bulk of the 28 that were addressed were spelling and grammar > corrections, with some rewordings for clarity. > > 24 of the items not addressed were merely suggested rewordings that > weren't terribly important to resolve, or they were questions about the > language and expression evaluation. I'll igonore those items, even > though I still feel the language is a weak spot in this proposal. > > 51 of the items not addressed dealt with document clarity that could > impact interoperability. Many of the still unresolved 51 items were > concerns that a management application could not rely on multiple > implementations to provide consistent support of a feature. Some were > requests for examples to help make the intent clearer to help > implementors not do it wrong. Some were requests for re-ordering the > document to help eliminate some of the need for so many forward > references. > > When will the remaining issues that were raised be addressed? > > Thanks, > dbh > > David Harrington > Network Management Architect > Office of the CTO > Enterasys Networks -- Jon Saperia saperia@jdscons.com Phone: 617-744-1079 Fax: 617-249-0874 http://www.jdscons.com/ From owner-snmpconf@seymour39.SNMP.COM Tue May 7 13:14:05 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16554 for ; Tue, 7 May 2002 13:14:04 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id NAA07246 for snmpconf-outgoing; Tue, 7 May 2002 13:08:15 -0400 (EDT) Message-ID: <0BF8B32B723ED5119E0B0002A551748B030547B1@corp-exc3.ctron.com> From: "Harrington, David" To: "'saperia@jdscons.com'" , snmpconf@snmp.com, "Harrington, David" Subject: RE: review of snmpconf--pm-10 Date: Tue, 7 May 2002 13:05:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F5E9.5D0CF580" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com 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_01C1F5E9.5D0CF580 Content-Type: text/plain; charset="iso-8859-1" Hi, The items are from my review of draft-ietf-snmpconf-pm-08. The section numbers in my mail and in the -10- document may vary slightly, but not much. I have separated items according to my percieved severity, to help you deal with them quickly. I moved some into "completed" that really weren't addressed, but I could accept as is. You might need to look up preceding items (in different lists) for the context they provide. Issues of clarity or conflict that could impact useability or interoperability: 8) The last paragraph of section 5.2 about the impact of bad OID formation could use examples. 10) section 5.3 seems self-conflicting: "no state is remembered from the previous invocation" and ""it had not matched that condition the last time it was checked" 11) section 5.3.1 "policy conditions are scheduled" - confusing and ambiguous. There has been no discussion of scheduling yet. There are two types of scheduling involved in this document - the mib-controlled schedule of evaluation/action, and the underlying implementation scheduling of the execution of evaluation/action processes. 12) section 5.4.1 same issue as 5.3.1 39) 6.3.1 - are all variables in the same scope? what about scratchpad variables? 42) the return value of a PolicyAction script is ignored. Why? why not use the return value to indicate whether the script ran to completion or not? 43) if the return value is ignored, why set it to zero as the result of an RTE or indication of a fail()? 49) "Arguments without the '&' character cannot be modified by the function." see item#38 52) "identified by the security credentials of the last entity to modify" - is this spelled out clearly somewhere? (I haven't finished the whole document, so it might be a forward reference. if so, can we specify the section?) 55) It might be worthwhile mentioning that if contextEngineID is not provided, and a managed environment supports dynamic addressing or network address translation, it may not be possible to reach the entity at the specified address. 56) 9.1.2 enum_decimal - are enums required to start with a letter? How would ToInteger( 3Com(12) ) be evaluated? is the processing clearly defined to prevent mis-interpretation? 57) can unsigned64 types with the high bit set be converted reliably using ToInteger()? 63) searchColumn() - "or returns an error without finding a match" - what are the error conditions? Since a zero means both endofView and error, how can a programmer determine that they have reached the end of the table without error? 79) 9.1.4.4 is snmpSend() synchronous or asynchronous? This is important to know for off-box queries. 81) 9.2 Are the HC datatypes supported? What does counterRate() return for a 64-bit counter delta? 83) Constants for SnmpMessageProcessingModel and SnmpSecurityModel - if additional security models are defined, can they be supported in snmpconf? A reference to the official definition of these values would be better than "hard-coding" the list here. Ditto for SNMP operation types, SNMP errors, and other constants. It's ok to include the constants here, but there should be a disclaimer that the official list is found in [wherever]. 86) SnmpMessageProcessingModel and SnmpSecurityModel is assigned enumerations in an inconsistent way in RFC2571. The constants here assume the values are consistent between ProcessingModels and SecurityModels, so these constants are incorrect. 89) ec() - "the number index subidentifiers exist" - obviously missing "of", but also not as clear as it could be. 'the number of suboids in the OID index for "this element".' I think there is a danger that implementers will count the subids in the complete OID, not just the index portion of the OID. An example showing an elementName OID and the OID index portion of the elementName and what ec() counts would help. 90) elementContext() is provided, and elementAddress() is provided, but elementContextEngineID() is missing, which is especially notable given that roleMatch() uses contextEngineID rather than the address. 91) roleMatch() ues contextEngineID and doesn't permit using the address, but nonLocalArgs favors the address over contextEngineID (the contextEngineID in nonLocalArgs can be not-present, and commands will be sent to the address specified, which is in keeping with SNMPv3 engineID discovery). 94) I think the texet in section 5.3 was written before the scratchpad was added, and they seem to be in conflict about remembering state. 95) PolicyElement scope discusses the fate-sharing with policies, but not with elements. What happens if the current element goes away? 96) can storageType be changed for an existing variable? 99) I am unclear on how to specify a modifiable parameter in a function call - is it the C-style (&val), where the address of the variable is provided, or the C++-style (val), where the reference is defined in the prototype? 100) Is it an RTE if I specify getScratchpad(Global,"foo", "55")? The string "55" is associated with a memory location, just as val is, but the memory location for "55" may be read-only memory. Writing to it might cause a core dump. Alternately, a manifest constant string might be modified, making the rest of hte program malfunction. 103) signalError() - the clarity of the sentence starting "This bit is initially cleared" could be improved. It may be enough just to stop the sentence at "This bit is cleared at the beginning of each execution." Are all the bits in pmTrackingPEInfo cleared at the start of each execution? How do I know whether conditionUserSignal or actionUserSignal will be set? Assuming it gets set depending on whether a condition or action is being evaluated, does the conditionUserSignal get cleared when the action is evaluated, or when the next condition is evaluated? 105) defer() - the discussion that preceds the prototype talks about gold is appropriate but isn't possible. It doesn't say anything about hitting a RTE. But the description in the prototype is dependent on hitting an RTE. Is it always true, and a restriction that any future library developers must be aware of, that an RTE MUST be triggered if it isn't possible to do something? Questions the document doesn't answer that could impact interoperability: 18) "Some examples of the features that have been removed" - is the language likely to change based on what happens in SMING? For example, if SMING adds floating point to mib defintions, how will PolicyScript handle this in a backwards compatible way? 38) 6.3.1 - can accessor functions change the value of arguments that are not &references? 22) Does the postfix_expr rule allow ++A++, or A++++++, or A++--++? 23) How does the expression rule work with a comma? (A=0,B=1) evaluates as what? Am I allowed to specify A[A=2, B=3]? 24) iteration statement - what is the evaluation order in a for clause? 25) "PolicyScript: statement*" is a script with no statements a valid script? 26) Is the index specification ($*) included in the EBNF? 27) "inside of" can be just "in" 28) 6.2.1 "The policy script runtime" discusses conversion operators that are not part of the language. See item #17 above. 29) type conversion rules - the format of the rules isn't defined; users can figure it out, but it could have been made more obvious. 30) type conversion rules - are these in precedence order? It doesn't say so. What is the precedence order of operators? 31) If I understand correctly, the following will result in a RTE. { J="J"; K="K"; J=K } Is that correct? the intent? 32) If I read this correctly, A+B and A 1 + "2" --> "1" + "2" --> "12" A 1 < "2" --> 1 < 2 --> true Is this desirable? Is this consistent with C, C++, perl, etc? 45) section 7 - if SMING changes addressing to use non-OIDs, will snmpconf be able to be updated in a backwards compatible way? 53) "the agent" - must it be an agent? does it apply to mid-level managers as well? 70) is there a way to tell how many samples have been kept? 71) is there a way to access the samples? their timestamps? 78) newPDU() - can a PDU that is received in a trap be read using the functions described here? Obviously, an implementation could read the information from the PDU, then create a newPDU() and write the info into the new PDU, but is there any way to "overlay" a newPDU() on an existing PDU to make the data accessible to the script? And would such a thing be allowed, given the stricture in 9.1.4 - "It is an RTE to read a varbind that has not been previously written."? 82) "local" errors - when acting as a MLM, are these local errors or remote errors? Do we have remote errors? Editorial Suggestions - not important to interoperability, just document quality. 2) the initial paragraph "This is an Internet-draft..." differs from the template. I think the template changed slightly. 3) the table of contents should be on page 2. 4) In the running footer, why not list the authors' names rather than "various authors"? 9) Throughout the document, the phrase "Note that ..." is used. This adds no value to most of the sentences where it is used. Upon first encountering this, I expected it to point out something especially important to note, but it seldom does, and is so overused it is very ineffective. 17) section 6. "however it was desirable to have access to C++'s operator overloading (solely to aid in documenting the language - operator overloading is not a feature of PolicyScript" - huh? how do we have access to it if it isn't part of the language? how are you using it to document the language? 19) "For example, it is expected" doesn't need the "For example" 20) "This is done because while" - you only need "While" 35) section 6.3 - I understand the intent is that programmers that know other langauges could pick this up quickly, but the guide references all sorts of things that have not been discussed - function calls, library routines, etc. Forward references to inSubtree(), ev(), WriteVar(), etc. I think the Quickstart Guide might be better placed after the language elements and library routines have been described (or in an appendix). 36) on a related note, "$*" indexing has not yet been discussed, but is used in the Quickstart guide. Many programmers that know, say, C won't know this langauge element. 37) on a related note, "Because Policy Script is a least common denominator" isn't quite true. It contains elements, like $*, that are not in all the languages referenced. 40) 6.3.1 - doesn't mention the addition of $* 44) 6.4 - discusses access functions, the defer attribute, and lower precedence scripts, before there has been any discussion of access functions, the library functions or script precedence. 46) "must be as appropriate" --> "must be appropriate" 48) "this coercion will cauae an RTE (in particular ..." The whole phrase in parentheses isn't needed. 51) There are a number of parameters that are based on enumerations defined in other documents, but the reference isn't specified here. Most notably, SNMPv3 documents define some, and SNMPv3 documents are already referenced for the boilerplate, so there isn't much reason not to specify the reference here. 58) "unencoded" "encoded" - what does this mean? not ASN.1 encoded? 59) subid: '0' | decimal_constant - why not use digit? 60) "never used in these encodings over the wire" - can we replace "these encodings" with "the scripts"? 62) searchColumn - POSIX 1003.2 isn't mentioned in the References section 65) "There may be no MIB compiler (or MIB) available on the policy MIB agent" - The MIB is the virtual database containing managed objects (hasn't Jeff Case gotten that through your heads yet?! ;-). Obviousy this needs work; I don't have a strong suggestion. It might be easier to say that the entity has no capability for translating from descriptors to object identifiers. 66) "available on the policy MIB agent." might be better as "available on the entity containing the policy MIB." (containing might also be changed to enforcing.) 67) "too short" and "too much" - remove the "too" 72) The description of the minInterval parameter is spread among multiple paragrpaghs. It really should have its own paragragh. 76) There are three examples for this call. The third is labeled "Policy which executes every 60 seconds", but the example shows a retrieval of the current delta. It is immaterial how frequently it executes. 77) 9.1.4 The paragraph starting "Note that in the preceding example," really isn't needed. This has already been discussed. 80) It is my impression that developers think of varbinds as being name-type-value rather than name-value-type. I cannot find any text that explicitly states this ordering for a varbind, except that ASN.1 works as type-length-value order. It might be easier to remember which parameter is which if reordered to match the ASN.1 ordering. In a language with defines or named constants, this wouldn't be a problem, since a call would be readVar(ifType, ethernet(6), Integer32), but these scripts must use the integer value of the datatype and (for an integer) the integer value. So the script will be readVar(1.3.6.1.2.1.2.2.1.3, 6, 4). People writing or reading scripts will need to keep these two parameters straight. Putting them in ASN.1 order might make it easier to remember the order. 88) throughout the descriptions, the context argument is described in three states: present, not-present, present but empty. I think there is a matter of degree here, and the descriptions should be ordered as: present, present but empty, and not-present. 101) 9.3.9 defines constants for use with the scratchpad functions. Shouldn't these constants be defined with the other constants? Completed in -10- 1) the format of the first page header doesn't follow rfc2223, and seems different than most. 5) in section four, there is discussion of context and execution context, and it is a bit confusing. I think it would help to clearly label SNMP contexts as SNMP contexts, or to use contextName to disambiguate this. 6) section 5.1 defines "terminology" but it uses a whole range of terms that are undefined, such as PolicyScript, accessor functions, policyCondition, and so on. 7) section 5.2, the paragraph starting "The Element Type Registration" has some text about determining the index portion. I think it would benefit from an example. 13) section 5.5 contains Definitions - i.e. another section for terminology. It would seem reasonable to merge 5.1 and 5.5. 14) section 5.5 is entitled Definitions. So is section 11 (which contains the MIB Module). 15) section 5.5. contains terminology definitions that use lots of forward references to other undefined terms. For example, "Ready Policy" has to with scheduling, but scheduling hasn't been discussed yet. 16) "If their are multiple" s/b there 21) "One subset is not expressible" - this could use a better definition of scope. 33) while(A): needs a closing parenthesis. 34) "getvar("ifSpeed.$*") < 128000" - why are the outer quotes needed in the example? 41) 6.4 - "If a expression" 47) "Any failure on this coercion" - should this be of rather than on? 50) section 9.1.1 - text starts with a '>' 54) "to direct this operation at." ain't good English. 61) getVar(...context...) - should this be contextName? also other places. 64) searchColumn() - "This sends a getnext ... and continues to walk the tree until a value matching is found ..." and "In a loop, this looks simply like: while(searchColumn("ifType", oid, "6", 0)) ..." The nested iteration makes this seem to be ambiguous about who handles iteration. I recommend the text read "In a loop to determine all the ethernet interfaces,". Can this script be written as while(searchColumn("ifType", oid, ethernet(6), 0)) ? 68) createRow() - "The '*' must replace any integer index item that may be set to some random value." - this is a bit unclear. each integer index is not really set to some random value. A random value is selected, then each of the specified integer indexes is set to the same selected value. 69) counterRate() - somewhat ambiguous about how many, and which, timestamped values must be kept. The paragraph starting "counterRate retrieves" says it keeps "values" so it can calculate over a longer period than since the last invocation. The paragraph that starts "The implementation will need" says it must retain one value older than minInterval seconds. So, if I have a minInterval of 5 seconds, do I need to keep the last read (less than 5 seconds ago) and one more read? What are the interoperability issues if I set two boxes to have minIntervals of 5 seconds, and vendor A keeps the most current and the most current + 5, but vendor B keeps the most current and the most current + 15 (discarding the current+5 and current+10 samples?). 73) "Otherwise, this delta will be dividied by the number of seconds elapsed between the two retrievals ..." assumes there are two retrieveals. What if an implementation keeps more than two? how will the value be calculated? 74) "the integer-valued result will be returned." is this rounded up or down? 75) could discMethod be specified as an enum in this text, or could the text be formatted in bullets, to simplify reading the description? 84) RFC1905 defines the error codes using standard SNMP naming practice for capitalization. That practice isn't followed here, at least not consistently. Undofailed should be undoFailed, and so on. 85) Even if the WG decides not to be concerned with matching RFC1905, they should at least try to be internally consistent - compare Undofailed and InconsistentName. 87) 9.3.1 through 9.3.6 could be reordered to be easier on the reader. The first functon described depends on the function descriptions that follow it, but none of them depend on releMatch. I suggest reordering in this order: elementName(), elementAddress(), elementContext(), then ev() and ec(), then roleMatch(). 92) 9.3.7 The whole scratchpad discussion would benefit from being put into a separate section that includes a discussion of the various scopes, rather than doing it as part of the function definition. 93) setScratchpad() - I recommend that the sentence starting "The value of 'scope' " begin a new paragraph. 97) "Contents of the scratchpad are erased on reboot." - doesn't this contradict the purpose of storageType? 98) 9.3.8 The examples ar einconsistent with the definitions. getScratchpad(Global, "foo", val) == 55 will never be true because getScratchpad only returns a 0 or 1 value. 102) 9.3.10 "used to by" 104) defer() - In the description, the order of discussion is default behavior, defer(1), then defer(0). is the default behavior and defer(0) equivalent? if so, they should be discussed together. 106) Can a script writer choose to voluntarily, as part of their logic, fail() and defer()? Is that an RTE, or just returning a false condition? 107) there has been no prior discussion of precedence groups. 108) 9.3.13 text starts with a '>' 109) getParameters() - given no knowledge of the MIB module, or any discussion which follows this text, this description is close to incomprehensible. "These parameters may be installed with the script in this object" - huh? what object? installed? with the script? what are you talking about? Obviously, the description from the object was cut and pasted here. ------_=_NextPart_001_01C1F5E9.5D0CF580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: review of snmpconf--pm-10
Hi,

The items are from my review of = draft-ietf-snmpconf-pm-08.
The section numbers in my mail and in the -10- = document may vary slightly, but not much.
I have separated items according to my percieved = severity, to help you deal with them quickly.
I moved some into "completed" that really = weren't addressed, but I could accept as is.
You might need to look up preceding items (in = different lists) for the context they provide.

Issues of clarity or conflict that could impact = useability or interoperability:

8) The last paragraph of section 5.2 about the impact = of bad OID formation could use examples.
10) section 5.3 seems self-conflicting:
"no state is remembered from the previous = invocation" and ""it had not matched that condition the = last time it was checked"

11) section 5.3.1 "policy conditions are = scheduled" - confusing and ambiguous. There has been no discussion = of scheduling yet. There are two types of scheduling involved in this = document - the mib-controlled schedule of evaluation/action, and the = underlying implementation scheduling of the execution of = evaluation/action processes.

12) section 5.4.1 same issue as 5.3.1
39) 6.3.1 - are all variables in the same scope? = what about scratchpad variables?
42) the return value of a PolicyAction script is = ignored. Why? why not use the return value to indicate whether the = script ran to completion or not?

43) if the return value is ignored, why set it to = zero as the result of an RTE or indication of a fail()?
49) "Arguments without the '&' character = cannot be modified by the function." see item#38
52) "identified by the security credentials of = the last entity to modify" - is this spelled out clearly = somewhere? (I haven't finished the whole document, so it might be a = forward reference. if so, can we specify the section?)

55) It might be worthwhile mentioning that if = contextEngineID is not provided, and a managed environment supports = dynamic addressing or network address translation, it may not be = possible to reach the entity at the specified address.

56) 9.1.2 enum_decimal - are enums required to start = with a letter? How would ToInteger( 3Com(12) ) be evaluated? is the = processing clearly defined to prevent mis-interpretation?

57) can unsigned64 types with the high bit set = be converted reliably using ToInteger()?
63) searchColumn() - "or returns an error = without finding a match" - what are the error conditions? Since a = zero means both endofView and error, how can a programmer determine = that they have reached the end of the table without error?

79) 9.1.4.4 is snmpSend() synchronous or = asynchronous? This is important to know for off-box queries.
81) 9.2 Are the HC datatypes supported? What does = counterRate() return for a 64-bit counter delta?
83) Constants for SnmpMessageProcessingModel and = SnmpSecurityModel - if additional security models are defined, can they = be supported in snmpconf? A reference to the official definition of = these values would be better than "hard-coding" the list = here. Ditto for SNMP operation types, SNMP errors, and other constants. = It's ok to include the constants here, but there should be a disclaimer = that the official list is found in [wherever].

86) SnmpMessageProcessingModel and SnmpSecurityModel = is assigned enumerations in an inconsistent way in RFC2571. The = constants here assume the values are consistent between = ProcessingModels and SecurityModels, so these constants are = incorrect.

89) ec() - "the number index subidentifiers = exist" - obviously missing "of", but also not as clear = as it could be. 'the number of suboids in the OID index for "this = element".' I think there is a danger that implementers will count = the subids in the complete OID, not just the index portion of the OID. = An example showing an elementName OID and the OID index portion of the = elementName and what ec() counts would help.

90) elementContext() is provided, and = elementAddress() is provided, but elementContextEngineID() is missing, = which is especially notable given that roleMatch() uses contextEngineID = rather than the address.

91) roleMatch() ues contextEngineID and doesn't = permit using the address, but nonLocalArgs favors the address over = contextEngineID (the contextEngineID in nonLocalArgs can be = not-present, and commands will be sent to the address specified, which = is in keeping with SNMPv3 engineID discovery).

94) I think the texet in section 5.3 was written = before the scratchpad was added, and they seem to be in conflict about = remembering state.

95) PolicyElement scope discusses the fate-sharing = with policies, but not with elements. What happens if the current = element goes away?

96) can storageType be changed for an existing = variable?
99) I am unclear on how to specify a modifiable = parameter in a function call - is it the C-style (&val), where the = address of the variable is provided, or the C++-style (val), where the = reference is defined in the prototype?

100) Is it an RTE if I specify = getScratchpad(Global,"foo", "55")? The string = "55" is associated with a memory location, just as val is, = but the memory location for "55" may be read-only memory. = Writing to it might cause a core dump. Alternately, a manifest constant = string might be modified, making the rest of hte program malfunction. =

103) signalError() - the clarity of the sentence = starting "This bit is initially cleared" could be improved. = It may be enough just to stop the sentence at "This bit is cleared = at the beginning of each execution." Are all the bits in = pmTrackingPEInfo cleared at the start of each execution? How do I know = whether conditionUserSignal or actionUserSignal will be set? Assuming = it gets set depending on whether a condition or action is being = evaluated, does the conditionUserSignal get cleared when the action is = evaluated, or when the next condition is evaluated?

105) defer() - the discussion that preceds the = prototype talks about gold is appropriate but isn't possible. It = doesn't say anything about hitting a RTE. But the description in the = prototype is dependent on hitting an RTE. Is it always true, and a = restriction that any future library developers must be aware of, that = an RTE MUST be triggered if it isn't possible to do something? =

Questions the document doesn't answer that could = impact interoperability:

18) "Some examples of the features that have = been removed" - is the language likely to change based on what = happens in SMING? For example, if SMING adds floating point to mib = defintions, how will PolicyScript handle this in a backwards compatible = way?

38) 6.3.1 - can accessor functions change the value = of arguments that are not &references?
22) Does the postfix_expr rule allow ++A++, or = A++++++, or A++--++?
23) How does the expression rule work with a comma? = (A=3D0,B=3D1) evaluates as what? Am I allowed to specify A[A=3D2, = B=3D3]?
24) iteration statement - what is the evaluation = order in a for clause?
25) "PolicyScript: statement*" is a script = with no statements a valid script?
26) Is the index specification ($*) included in the = EBNF?
27) "inside of" can be just = "in"
28) 6.2.1 "The policy script runtime" = discusses conversion operators that are not part of the language. See = item #17 above.

29) type conversion rules - the format of the rules = isn't defined; users can figure it out, but it could have been made = more obvious.

30) type conversion rules - are these in precedence = order? It doesn't say so. What is the precedence order of = operators?

31) If I understand correctly, the following will = result in a RTE.
{ J=3D"J"; K=3D"K"; J=3DK } Is = that correct? the intent?
32) If I read this correctly, A+B and A<B might = use different conversion rules, if A=3D1 and B=3D"2".
A+B --> 1 + "2" --> "1" + = "2" --> "12"
A<B --> 1 < "2" --> 1 < 2 = --> true
Is this desirable? Is this consistent with C, C++, = perl, etc?
45) section 7 - if SMING changes addressing to use = non-OIDs, will snmpconf be able to be updated in a backwards compatible = way?

53) "the agent" - must it be an agent? does = it apply to mid-level managers as well?
70) is there a way to tell how many samples have = been kept?
71) is there a way to access the samples? their = timestamps?
78) newPDU() - can a PDU that is received in a trap = be read using the functions described here? Obviously, an = implementation could read the information from the PDU, then create a = newPDU() and write the info into the new PDU, but is there any way to = "overlay" a newPDU() on an existing PDU to make the data = accessible to the script? And would such a thing be allowed, given the = stricture in 9.1.4 - "It is an RTE to read a varbind that has not = been previously written."?

82) "local" errors - when acting as a MLM, = are these local errors or remote errors? Do we have remote = errors?

Editorial Suggestions - not important to = interoperability, just document quality.
2) the initial paragraph "This is an = Internet-draft..." differs
from the template. I think the template = changed slightly.
3) the table of contents should be on page 2.
4) In the running footer, why not list the authors' = names rather than
"various authors"?
9) Throughout the document, the phrase "Note = that ..." is used. This adds no value to most of the sentences = where it is used. Upon first encountering this, I expected it to point = out something especially important to note, but it seldom does, and is = so overused it is very ineffective.

17) section 6. "however it was desirable to have = access to C++'s operator overloading (solely to aid in documenting the = language - operator overloading is not a feature of PolicyScript" = - huh? how do we have access to it if it isn't part of the language? = how are you using it to document the language?

19) "For example, it is expected" doesn't = need the "For example"
20) "This is done because while" - you = only need "While"
35) section 6.3 - I understand the intent is that = programmers that know other langauges could pick this up quickly, but = the guide references all sorts of things that have not been discussed - = function calls, library routines, etc. Forward references to = inSubtree(), ev(), WriteVar(), etc. I think the Quickstart Guide might = be better placed after the language elements and library routines have = been described (or in an appendix).

36) on a related note, "$*" indexing has = not yet been discussed, but is used in the Quickstart guide. Many = programmers that know, say, C won't know this langauge = element.

37) on a related note, "Because Policy Script is = a least common denominator" isn't quite true. It contains = elements, like $*, that are not in all the languages referenced. =

40) 6.3.1 - doesn't mention the addition of $*
44) 6.4 - discusses access functions, the defer = attribute, and lower precedence scripts, before there has been any = discussion of access functions, the library functions or script = precedence.

46) "must be as appropriate" --> = "must be appropriate"
48) "this coercion will cauae an RTE (in = particular ..." The whole phrase in parentheses isn't = needed.
51) There are a number of parameters that are based = on enumerations defined in other documents, but the reference isn't = specified here. Most notably, SNMPv3 documents define some, and SNMPv3 = documents are already referenced for the boilerplate, so there isn't = much reason not to specify the reference here.

58) "unencoded" "encoded" - what = does this mean? not ASN.1 encoded?
59) subid: '0' | decimal_constant - why not use = digit?
60) "never used in these encodings over the = wire" - can we replace "these encodings" with "the = scripts"?
62) searchColumn - POSIX 1003.2 isn't mentioned in = the References section
65) "There may be no MIB compiler (or MIB) = available on the policy MIB agent" - The MIB is the virtual = database containing managed objects (hasn't Jeff Case gotten that = through your heads yet?! ;-). Obviousy this needs work; I don't have a = strong suggestion. It might be easier to say that the entity has no = capability for translating from descriptors to object = identifiers.

66) "available on the policy MIB agent." = might be better as "available on the entity containing the policy = MIB." (containing might also be changed to enforcing.)

67) "too short" and "too much" - = remove the "too"
72) The description of the minInterval parameter is = spread among multiple paragrpaghs. It really should have its own = paragragh.

76) There are three examples for this call. The third = is labeled "Policy which executes every 60 seconds", but the = example shows a retrieval of the current delta. It is immaterial how = frequently it executes.

77) 9.1.4 The paragraph starting "Note that in = the preceding example," really isn't needed. This has already been = discussed.

80) It is my impression that developers think of = varbinds as being name-type-value rather than name-value-type. I cannot = find any text that explicitly states this ordering for a varbind, = except that ASN.1 works as type-length-value order. It might be easier = to remember which parameter is which if reordered to match the ASN.1 = ordering. In a language with defines or named constants, this wouldn't = be a problem, since a call would be readVar(ifType, ethernet(6), = Integer32), but these scripts must use the integer value of the = datatype and (for an integer) the integer value. So the script will be =

readVar(1.3.6.1.2.1.2.2.1.3, 6, 4). People writing or = reading scripts will need to keep these two parameters straight. = Putting them in ASN.1 order might make it easier to remember the = order.

88) throughout the descriptions, the context argument = is described in three states: present, not-present, present but empty. = I think there is a matter of degree here, and the descriptions should = be ordered as: present, present but empty, and not-present.

101) 9.3.9 defines constants for use with the = scratchpad functions. Shouldn't these constants be defined with the = other constants?

Completed in -10-
1) the format of the first page header doesn't = follow rfc2223, and seems different than most.
5) in section four, there is discussion of context = and execution context, and it is a bit confusing. I think it would help = to clearly label SNMP contexts as SNMP contexts, or to use contextName = to disambiguate this.

6) section 5.1 defines "terminology" but it = uses a whole range of terms that are undefined, such as PolicyScript, = accessor functions, policyCondition, and so on.

7) section 5.2, the paragraph starting "The = Element Type Registration" has some text about determining the = index portion. I think it would benefit from an example.

13) section 5.5 contains Definitions - i.e. another = section for terminology. It would seem reasonable to merge 5.1 and = 5.5.

14) section 5.5 is entitled Definitions. So is = section 11 (which contains the MIB Module).
15) section 5.5. contains terminology definitions = that use lots of forward references to other undefined terms. For = example, "Ready Policy" has to with scheduling, but = scheduling hasn't been discussed yet.

16) "If their are multiple" s/b = there
21) "One subset is not expressible" - this = could use a better definition of scope.
33) while(A): needs a closing parenthesis.
34) "getvar("ifSpeed.$*") < = 128000" - why are the outer quotes needed in the example?
41) 6.4 - "If a expression"
47) "Any failure on this coercion" - = should this be of rather than on?
50) section 9.1.1 - text starts with a '>'
54) "to direct this operation at." ain't = good English.
61) getVar(...context...) - should this be = contextName? also other places.
64) searchColumn() - "This sends a getnext ... = and continues to walk the tree until a value matching is found = ..." and "In a loop, this looks simply like: = while(searchColumn("ifType", oid, "6", 0)) = ..."

The nested iteration makes this seem to be ambiguous = about who handles iteration. I recommend the text read "In a loop = to determine all the ethernet interfaces,".

Can this script be written as
while(searchColumn("ifType", oid, = ethernet(6), 0)) ?
68) createRow() - "The '*' must replace any = integer index item that may be set to some random value." - this = is a bit unclear. each integer index is not really set to some random = value. A random value is selected, then each of the specified integer = indexes is set to the same selected value.

69) counterRate() - somewhat ambiguous about how = many, and which, timestamped values must be kept. The paragraph = starting "counterRate retrieves" says it keeps = "values" so it can calculate over a longer period than since = the last invocation. The paragraph that starts "The implementation = will need" says it must retain one value older than minInterval = seconds. So, if I have a minInterval of 5 seconds, do I need to keep = the last read (less than 5 seconds ago) and one more read?

What are the interoperability issues if I set two = boxes to have minIntervals of 5 seconds, and vendor A keeps the most = current and the most current + 5, but vendor B keeps the most current = and the most current + 15 (discarding the current+5 and current+10 = samples?).

73) "Otherwise, this delta will be dividied by = the number of seconds elapsed between the two retrievals ..." = assumes there are two retrieveals. What if an implementation keeps more = than two? how will the value be calculated?

74) "the integer-valued result will be = returned." is this rounded up or down?
75) could discMethod be specified as an enum in this = text, or could the text be formatted in bullets, to simplify reading = the description?

84) RFC1905 defines the error codes using standard = SNMP naming practice for capitalization. That practice isn't followed = here, at least not consistently. Undofailed should be undoFailed, and = so on.

85) Even if the WG decides not to be concerned with = matching RFC1905, they should at least try to be internally consistent = - compare Undofailed and InconsistentName.

87) 9.3.1 through 9.3.6 could be reordered to be = easier on the reader. The first functon described depends on the = function descriptions that follow it, but none of them depend on = releMatch. I suggest reordering in this order: elementName(), = elementAddress(), elementContext(), then ev() and ec(), then = roleMatch().

92) 9.3.7 The whole scratchpad discussion would = benefit from being put into a separate section that includes a = discussion of the various scopes, rather than doing it as part of the = function definition.

93) setScratchpad() - I recommend that the sentence = starting "The value of 'scope' " begin a new = paragraph.
97) "Contents of the scratchpad are erased on = reboot." - doesn't this contradict the purpose of = storageType?
98) 9.3.8 The examples ar einconsistent with the = definitions.
getScratchpad(Global, "foo", val) =3D=3D = 55 will never be true because getScratchpad only returns a 0 or 1 = value.
102) 9.3.10 "used to by"
104) defer() - In the description, the order of = discussion is default behavior, defer(1), then defer(0). is the default = behavior and defer(0) equivalent? if so, they should be discussed = together.

106) Can a script writer choose to voluntarily, as = part of their logic, fail() and defer()? Is that an RTE, or just = returning a false condition?

107) there has been no prior discussion of precedence = groups.
108) 9.3.13 text starts with a '>'
109) getParameters() - given no knowledge of the MIB = module, or any discussion which follows this text, this description is = close to incomprehensible. "These parameters may be installed with = the script in this object" - huh? what object? installed? with the = script? what are you talking about? Obviously, the description from the = object was cut and pasted here.
------_=_NextPart_001_01C1F5E9.5D0CF580-- From owner-snmpconf@seymour39.SNMP.COM Tue May 7 13:16:21 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16667 for ; Tue, 7 May 2002 13:16:21 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id NAA07487 for snmpconf-outgoing; Tue, 7 May 2002 13:12:30 -0400 (EDT) Content-Type: text/plain; charset="iso-8859-1" From: Jon Saperia To: snmpconf@snmp.com, "Harrington, David" Subject: Re: review of snmpconf--pm-10 Date: Tue, 7 May 2002 13:12:42 +0000 X-Mailer: KMail [version 1.3.1] References: <0BF8B32B723ED5119E0B0002A551748B030547B1@corp-exc3.ctron.com> In-Reply-To: <0BF8B32B723ED5119E0B0002A551748B030547B1@corp-exc3.ctron.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: <102079151601@mx05.gis.net> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit On Tuesday 07 May 2002 05:05 pm, Harrington, David wrote: > Hi, > > The items are from my review of draft-ietf-snmpconf-pm-08. > The section numbers in my mail and in the -10- document may vary > slightly, but not much. I have separated items according to my percieved > severity, to help you deal with them quickly. I moved some into > "completed" that really weren't addressed, but I could accept as is. You > might need to look up preceding items (in different lists) for the > context they provide. > > Issues of clarity or conflict that could impact useability or > interoperability: Thanks very much for the quick reply. I am sure we will have some questions as we go through this. /jon -- Jon Saperia saperia@jdscons.com Phone: 617-744-1079 Fax: 617-249-0874 http://www.jdscons.com/ From owner-snmpconf@seymour39.SNMP.COM Mon May 13 12:54:22 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19581 for ; Mon, 13 May 2002 12:54:21 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id MAA09621 for snmpconf-outgoing; Mon, 13 May 2002 12:47:14 -0400 (EDT) Message-Id: <5.1.0.14.0.20020513122710.02cedf50@mail.goldwiretech.com> X-Sender: wayne-pop@mail.goldwiretech.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 13 May 2002 12:44:08 -0400 To: snmpconf@snmp.com From: "Wayne F. Tackabury" Subject: snmpconf BCP Version -08 posted Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com 'confers: I have just posted version -08 of the illustrious draft-ietf-snmpconf-bcp series ("Configuring Networks and Devices With SNMP") to the internet-drafts editor. Given that I'm not doing my usual just-before-IETF-cutoff-beat-the-clock routine here for once, this should get fairly timely arrival in the i-d repository. However, for anybody seeking a sneak peek, you can find the entire -08 menagerie (nroff, txt, diffs, etc) along with the archived remnants of -07 at http://www.tiac.net/users/wayne/snmpconf/. I find I don't make enemies of your network admins if I don't try to attach these things to list mail. :) Primary wg input for this rev came from Bert Wijnen, Randy Preshun, David Harrington (I think), Andy Bierman and David Partain. Apologies to anybody I'm forgetting. That web site cited above has the very diff summary I'm about to give you, but I'll put this here anyways. The biggest change is we've taken on a new co-author, David Partain. Aside from that, it mostly reads like... BCP Document ------------ * Removed section "Order of varbinds in a SET PDU" and discussion on indexing columnar items from one (1) rather than zero (0). Both based on delayed reaction to comments received from Dave Perkins and Andy Bierman. * Removed prior section 5.1, "Designing Configuration Management Software" intro. Retitled section 5.2 (previously "Protocol Operations") "Configuration Application Interactions with Managed Systems" (this was to address issues Bert had with the whole flow of Sec. 5). * Linguistic tightening of sections at Bert's request, and a number of related changes to sentence structure and emphasis without changes to semantic meaning. Clarification generally introduced by deletion of that which wasn't clear or necessarily useful, particularly through Chapters 4 and 5. * Hyphenation behavior in nroff turned off. Now all lines in text should not end with hyphens (unless they're hyphenated words). * Section headers now in mixed case INSTEAD OF ALL CAPS. * Bibliographical document references added where appropriate and not already present. * Example on HVAC MIB usage provided after the HVAC MIB. * David Partain added as editor (buy the man a drink! :) * Various NROFF errors fixed. * References to INET-ADDRESS-MIB objects updated to use those from most recent revision. HVAC MIB -------- * A number of changes done as suggested by Bert to bring MIB into compliance with current SMI and practices: e.g., all INTEGER SYNTAX object types changed to Unsigned32, SnmpAdminString used where appropriate, read-create used instead of read-write for ACCESS of modifiable and creatable table objects * More explanatory text added throughout MIB description clauses. * StorageType TC-derived object types added to HVAC MIB tables. * Indices in tables which were inappropriately set with an ACCESS of read-only are now not-accessible. * Other references in HVAC MIB intro which were incorrectly specifying what they referenced fixed. Comments and input welcome. Regards, Wayne -------- Wayne F. Tackabury Internet: wayne@goldwiretech.com Gold Wire Technology Phone: (781) 398-8819 411 Waverley Oaks Rd., Ste 331 Waltham, MA 02452 Cell: (617) 699-6156 From owner-snmpconf@seymour39.SNMP.COM Tue May 14 08:04:57 2002 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14506 for ; Tue, 14 May 2002 08:04:56 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id IAA16695 for snmpconf-outgoing; Tue, 14 May 2002 08:01:01 -0400 (EDT) Message-Id: <200205141200.IAA14065@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-bcp-08.txt Date: Tue, 14 May 2002 08:00:14 -0400 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 : Configuring Networks and Devices with SNMP Author(s) : M. MacFaden, D. Partain, J. Saperia, W. Tackabury Filename : draft-ietf-snmpconf-bcp-08.txt Pages : 82 Date : 13-May-02 This document is written for readers interested in the Internet Standard Management Framework and its protocol, the Simple Network Management Protocol (SNMP). In particular, it offers guidance in the effective use of SNMP for configuration management. This information is relevant to vendors that build network elements, management application developers, and those that acquire and deploy this technology in their networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-snmpconf-bcp-08.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-bcp-08.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-bcp-08.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: <20020513141900.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpconf-bcp-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpconf-bcp-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020513141900.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-snmpconf@seymour39.snmp.com Tue May 21 08:43:30 2002 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07800 for ; Tue, 21 May 2002 08:43:30 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3/m.000221) id IAA18131 for snmpconf-outgoing; Tue, 21 May 2002 08:37:35 -0400 (EDT) Date: Tue, 21 May 2002 14:36:50 +0200 From: David Partain Subject: Another WG Last Call on the BCP (draft-ietf-snmpconf-bcp-08.txt) In-reply-to: <0GNM00CCNF76DZ@mbb1.ericsson.se> To: snmpconf@snmp.com Message-id: <200205211436.50288.David.Partain@ericsson.com> MIME-version: 1.0 X-Mailer: KMail [version 1.4] Content-type: text/plain; charset=iso-8859-15 Content-transfer-encoding: 8bit References: <0GN9001CXCKAUR@mbb1.ericsson.se> <0GNM00CCNF76DZ@mbb1.ericsson.se> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit Hi all, Note: this is for the BCP (again).... This mail is to announce the beginning of a WG Last Call period on http://www.ietf.org/internet-drafts/draft-ietf-snmpconf-bcp-08.txt The WG Last Call period will end at 17:00 May 28, 2002, Stockholm time. I'll leave it as an exercise to the reader what time that is where you live. :-) The WG members are strongly urged to review this document as soon as possible, and express any concerns, or identify any errors, in e-mail sent to the SNMPCONF WG mailing list. Unless there are strong objections, published on the SNMPCONF WG mailing list by the end of this WG last call, this document will be forwarded to the OPS Area Directors for consideration by the IESG as a Best Current Practice document. Please send all comments to the WG mailing list at snmpconf@snmp.com. Cheers, David and Jon From owner-snmpconf@seymour39.snmp.com Fri May 24 08:24:56 2002 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25343 for ; Fri, 24 May 2002 08:24:56 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3/m.000221) id IAA11108 for snmpconf-outgoing; Fri, 24 May 2002 08:18:58 -0400 (EDT) Message-ID: <3CEEA633.2E56EAD8@verio.net> Date: Fri, 24 May 2002 15:44:35 -0500 From: "Carl W. Kalbfleisch" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-31 i686) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Comments on draft-ietf-snmpconf-bcp-08.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit I just read over the lastest snmp conf BCP. This document is *very* useful. We will be able to make use of this informationin some work that we are doing now. Good work!!! I have a couple comments. There is a ">" at the beginning of this sentence: 5.1. Configuration Application Interactions with Managed Systems >From the point of view of the design of the management application, This section is a little unclear... > 5.1.3. Tracking Configuration Changes > > As previously described in Section 3.3.5 (Summary Objects and State > Tracking), agents should provide the capability for notifications to be > sent to their configured management systems whenever a configuration > operation is attempted or completed. The management application must be > prepared to accept these notifications so that it knows the current > configured state of the devices under its control. Some configuration > management applications may consume data from the managed devices that This is a little unclear to me. Consume makes it sound like the data comes in the notification. But what is meant is that the notification starts a process of gathering data. Instead of the sentence starting with "Some configuration...", I would suggest something like "Upon receipt of the notification, the management application should use get-bulk or get-next to retrieve the configuration from the agent and store it (in a database). Thanks again for this piece of work. I am sure it will prove useful. Carl -- Carl W. Kalbfleisch NTT/VERIO www.nttverio.com From owner-snmpconf@seymour39.snmp.com Fri May 24 09:04:24 2002 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26776 for ; Fri, 24 May 2002 09:04:23 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.snmp.com (8.9.3/m.000221) id JAA11969 for snmpconf-outgoing; Fri, 24 May 2002 09:01:43 -0400 (EDT) Content-Type: text/plain; charset="iso-8859-1" From: Jon Saperia To: snmpconf@snmp.com, "Carl W. Kalbfleisch" Subject: Re: Comments on draft-ietf-snmpconf-bcp-08.txt Date: Fri, 24 May 2002 09:02:26 +0000 X-Mailer: KMail [version 1.3.1] References: <3CEEA633.2E56EAD8@verio.net> In-Reply-To: <3CEEA633.2E56EAD8@verio.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: <102224526401@mx03.gis.net> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit On Friday 24 May 2002 08:44 pm, Carl W. Kalbfleisch wrote: > I just read over the lastest snmp conf BCP. This document is *very* > useful. We will be able to make use of this informationin some work > that we are doing now. Good work!!! > > I have a couple comments. > > There is a ">" at the beginning of this sentence: > 5.1. Configuration Application Interactions with Managed Systems > > >From the point of view of the design of the management application, > > This section is a little unclear... > > > 5.1.3. Tracking Configuration Changes > > > > As previously described in Section 3.3.5 (Summary Objects and State > > Tracking), agents should provide the capability for notifications to > > be sent to their configured management systems whenever a > > configuration operation is attempted or completed. The management > > application must be prepared to accept these notifications so that it > > knows the current configured state of the devices under its control. > > Some configuration management applications may consume data from the > > managed devices that > > This is a little unclear to me. Consume makes it sound like the data > comes in the notification. But what is meant is that the notification > starts a process of gathering data. Instead of the sentence starting > with "Some configuration...", I would suggest something like "Upon > receipt of the notification, the management application should use > get-bulk or > get-next to retrieve the configuration from the agent and store it (in a > database). > > Thanks again for this piece of work. I am sure it will prove useful. > > Carl Carl, thanks for the read and the comments. Assuming that there are no objections, we can incorporate your revision in the version we pass on to our ADs. /jon -- Jon Saperia saperia@jdscons.com Phone: 617-744-1079 Fax: 617-249-0874 http://www.jdscons.com/ From owner-snmpconf@seymour39.snmp.com Thu May 30 16:44:00 2002 Received: from seymour39.snmp.com (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19629 for ; Thu, 30 May 2002 16:43:59 -0400 (EDT) Received: by seymour39.snmp.com (8.9.3/m.000221) id QAA22348 for snmpconf-outgoing; Thu, 30 May 2002 16:36:56 -0400 (EDT) Message-Id: <5.1.0.14.0.20020530162520.02b087c8@mail.goldwiretech.com> X-Sender: wayne-pop@mail.goldwiretech.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 30 May 2002 16:32:42 -0400 To: snmpconf@snmp.com From: "Wayne F. Tackabury" Subject: snmpconf BCP last call? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com I was just noticing that the last call for the BCP draft (which was, I think, 11:59 PM Western European time 5/28, if that's the correct time zone for Stockholm :) has passed. All ashore who's going ashore in terms of comments? We currently have a typo caught and request for two non-content-changing clarifications from Carl Kalbfleisch, which we will address (specific changes were identified), but nothing that would warrant another wg reissue/last call. Regards, Wayne