[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft minutes from the sming interim:
>>>>> Durham, David writes:
Dave> Preview of the minutes. Comments welcome. -Dave
Despite some editorial fixes (see diff below), I have two points where
I either disagree with the minutes are where I have changed my mind
since early June:
1) I have problems with the following statement:
Other attendees disagreed with this assertion, clearly the
sample set of NW workshop operator's complain bitterly.
First, I did not get the impression that operators are so unhappy
with SNMP for monitoring and control. Regarding monitoring, they
had some problems with the accuracy of data - not with the way of
getting the data. Anyway, I believe this is not important for the
minutes since the sentence before this statement is clearly marked
as an opinions of individuals. So I suggest to just remove this
sentence.
2) Regarding comments:
We have gone back to a syntax which is close to the SMIv2 and when
I wrote an SMIv3 output driver for smidump and looked at the
output, the old comment style does not look that bad anymore. (--
seems to align well with ALLCAPS.) No, I am serious here. I prefer
to keep -- now but to just change the rules so that a comment
always extends to the end of the line.
I have rarely seen a -- comment -- in a MIB module other in places
where it was necessary to have real contents between the end of the
-- comment -- and the end of the line.
Below are my editorial fixes.
/js
--- /tmp/notes.txt.orig Wed Jun 26 21:25:47 2002
+++ /tmp/notes.txt Wed Jun 26 21:30:48 2002
@@ -46,7 +46,7 @@
technology is desired. Attendees wanted the ability to convert from SMIv2 to
SMIng (a requirement), and converting SMIng to SMIv2 only where possible
(not a requirement). The other question concerned the SPPI. As this topic
-has been addressed I the past, the chair repeated that this working group
+has been addressed in the past, the chair repeated that this working group
will not be constrained or concerned with backward compatibility with SPPI.
COPS-PR supporters are responsible for writing a translation if they desire
it.
@@ -64,9 +64,9 @@
tools to view new structures anyway. Ideally there shouldn't be any changes
that result the wire protocol, but adding new base types is clearly an
exception. Juergen ended by suggesting that it was the lack of high-level
-operations that was the main problem, and using a SoA RPC mechanism would be
+operations that was the main problem, and using an RPC mechanism would be
a good thing. Andy agrees that having clear elements of procedure/use cases
-for those thing people typically do would be beneficial. Overall, people
+for those things people typically do would be beneficial. Overall, people
wanted to improve readability and clarify the syntax of the language. Two
clear non-requirements was the idea of making it easier on the tool writers
(who are a minority) as well as providing annotations to the language. It
@@ -77,7 +77,7 @@
to the majority of people out there. There is no language out there that has
the concept of a leaf. Randy agrees that what we do in the smi is different
than what most cs students are familiar with since we use different
-terminology. Andy doesn't believe it is SYNTAX or MAX-ACCESS is the problem,
+terminology. Andy doesn't believe that SYNTAX or MAX-ACCESS is the problem,
it is the lack of data modeling and data structure. Clearly, however, OBJECT
in the smi is not what people think it is.
@@ -131,7 +131,7 @@
Next was a discussion about the merits of having a hierarchical oid
namespace. Hierarchical oids provide aggregates and aggregate information
-even at a protocol level. They also enable we the individual items of the
+even at a protocol level. They also enable the individual items of the
aggregate to be addressable. The difference between SMI-DS and SMIng
documents is at what stage during the definition process are the oids
associated with the datastructure. Consensus is that we want to explicitly
@@ -173,7 +173,7 @@
specified where the prefix and index were for any given oid. Conclusion was
there needs to be sufficient meta data available to figure out where each of
the indicies are. But we should keep the naming the same as it is today. It
-was also suggestion to use the meta data to encode the oid textual name, and
+was also suggested to use the meta data to encode the oid textual name, and
other mib information so that mibs can be more self-describing (like XML
documents). Other more radical suggestions were to move away from oids
altogther, being that they seem to be the root of all evil. Needless to say,
@@ -301,9 +301,9 @@
Consensus was this is OK and base types should not be imported. While
derived types must be imported. The reason for the change: Make the type
-system consistent with up-to-date languages, also there is no spaces which
-make parsing a pain, and finally this gives us a consistent syntax for
-types.
+system consistent with up-to-date languages, also there are no spaces in
+keywords which make parsing a pain, and finally this gives us a consistent
+syntax for types.
- [1] OctetString vs OCTET STRING and [2] (SIZE (1..20)) vs (1..20) and
[3] '0a0f'h vs 0x0a0f. Group consensus was:
@@ -349,8 +349,8 @@
- Enumeration vs INTEGER and syntax of enumerated values. What about things
that have been coming up such as status for enumerated values or
-descriptions for enumerated values? Group consensus was this is OK but do
-not add more stuff for named numbers.
+descriptions for enumerated values? Group consensus was that using
+Enumeration is OK but do not add more stuff for named numbers.
- Bits vs BITS and format of Bits named numbers. The group consensus was to
use the smiv2 { ... } format. This is not broken.
@@ -364,8 +364,8 @@
Group consensus was mixed, rough consensus was to change to // because the
reasoning was that more people are familiar with it (DavidH says -- comments
often confuse readers). Others suggested using # for comments though this
-would confuse ansi compilers. Unless there are significant objections on
-mailing list, consensus is to change to //.
+would confuse preprocessors. Unless there are significant objections on
+the mailing list, consensus is to change to //.
- CAPITALIZE all KEYWORDS for improved SMIv2 look & feel? The group
consensus was yes, keeps things similar to smiv2 look & feel.
@@ -396,7 +396,7 @@
With or without semicolons? The group consensus was to get rid of the
semicolon. The group was also comfortable with having an IMPORT for every
-keyword. This makes cut-copy-paste operations a easier.
+module. This makes cut-copy-paste operations easier.
- Remove the extension statement? The group consensus was YES.
@@ -517,7 +517,7 @@
- SMIng does not distinguish anymore between OBJECT-GROUPs and
NOTIFICATION-GROUPs. They are just GROUPs. Is this useful? The group
-consensus as that the distinction is not useful.
+consensus was that the distinction is not useful.
- SMIng removes the common
@@ -525,7 +525,7 @@
construction as the same effect can be achieved in other ways.
- Seems to be an odd construction, the group consensus as to either require
+ Seems to be an odd construction, the group consensus was to either require
the module name or get rid of it, making it optional helps nothing.
- Would be nice to be able to define GROUPs for foreign definitions imported