Subject: Last call on GSMP MIB ended

From: avri <[email-masked]>
Date: Wed, 14 Nov 2001 09:43:04 -0500

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

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 15 Nov 2001 23:53:48 +0100

They seem editorial changes and clarifying at that.
So I would hope/think that the WG is OK with that.

Bert

Bert 

> -----Original Message-----
> From: Hans Sjostrand [mailto:[email-masked]]
> Sent: Thursday, November 15, 2001 10:11 PM
> To: [email-masked]; Wijnen, Bert (Bert); Scott Bradner
> Cc: Michael MacFaden; [email-masked];
> [email-masked]
> Subject: RE: Last call on GSMP MIB ended
> 
> 
> avri wrote:
> >
> >
> 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.
>