[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: AD review of draft-ietf-snmpconf-pm-11.txt - part 1 and part 2
[ 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 18.104.22.168
> > 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 22.214.171.124 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 126.96.36.199
> > 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 188.8.131.52
> > 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 184.108.40.206
> > 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 220.127.116.11
> > 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 18.104.22.168
> > 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
> > - 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
> They're not admin strings
> They're often too long for AdminString's 255 octet limit
> 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
> 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
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
> > - 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