Subject: RE: Last call on GSMP MIB ended: from Hans Sjostrand <[email-masked]>

From: avri <[email-masked]>
Date: Fri, 16 Nov 2001 00:51:01 -0500

Not sure why this bounced.
It shouldn't have.

a.
-------- Original Message --------
Subject: BOUNCE [email-masked]:    Non-member submission from [Hans 
Sjostrand <[email-masked]>]
Date: Thu, 15 Nov 2001 16:11:04 -0500

avri wrote:
 >
 >
 > The latest WG last call on draft-ietf-gsmp-mib-06.txt
 > ended on 9 Nov without comments.
 >
 > To the ADs, please consider this draft for PS status.
 >
 > Thanks
 > a.
 > --
 > Avri Doria
 > co-chair

It's true that there has been no comments on the list, but there
has also been a review done by the "snmp-guys" where I have received
comments privatly. Those has been more general and not focused on the
changes that the mib has undergone due to the IESG review by Bert.

While in the same time try to minimize change and not introduce new
functionality at this (to) late stage I think that the mib benafits
from making some clarifications that was proposed by Michael MacFaden.

I paste in en excerpt (quite edited though not to bore you) from our
discusion where we agreed to change. If there is no objection posted
to the list I will make a new rev before November 21st Cutoff of the
mib addressing the below comments and the mib should then be ready to
progress.

Regards
/// Hasse

Michael MacFaden [mailto:[email-masked]] wrote:
 >
 > 2) gsmpControllerPort, is not defined well. This object
 > will lead to implementations which are not
 > interoperable. If it is defined in the underlying GSMP
 > protocol, then add a REFERENCE to it.

I could agree that it would be good with a reference, the best
descripption of port numbers are found in "3.  Common Definitions
and Procedures"  of the GSMP spec. Also, after reading it a second
time I also think that I make the text less specific. I don't want
to write on the nose of the vendors their internal port
numbering scheme.

 >
 > 4) Non of the counters are tied back to the underlying protocol
 > via REFERENCE. This may lead to interoperability problems.

 > The reality is most counters in protocol MIB
 > modules are not well specified and do not exist in the underlying
 > technology RFC where they would be defined precisely with all
 > exceptional cases (when to count as well as when not to and
 > what to do in error cases). Hence
 > most IP counters are not interoperable across vendors or a
 > single vendor's gear.

I see your point, and more text and references could be added for more
clarity, e.g. that failiure responce messages should also be counted
in the total number of mesasges counter etc. I'll see what I could do.

 > 1) I would not recommend putting such comments in a MIB module.
 > StorageType, TEXTUAL-CONVENTION
 >                FROM SNMPv2-TC                               -- RFC2579

 > The RFC number may change over time and the information is easily
 > discernable
 > from the RFC number when published.

Well I've found it very useful, every mib has
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
           Rose, M., and S. Waldbusser, "Textual Conventions for
           SMIv2", STD 58, RFC 2579, April 1999

Yes, the rfc number may change, but everyone implementing this knows about
obsoleted rfc etc. The above reference numbering scheme
is perfectly accepted. But I could add square brackets around the reference
to emphasize that it a reference and not a RFC hard pointer.