Subject: (FRNETMIB) Re: Comments - WG last call on draft-ietf-frnetmib-frmrelay-service-00.txt

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 19 Apr 2000 17:36:58 -0400

Tom and Erik,

It looks like I was a bit hasty in pulling the trigger.  I'm taking a short 
vacation on Thursday and Friday, so I pushed this up to the top of my todo 
list for today!

Anyway, we will work on the list to resolve Ken's comments before we can 
submit this to the IESG, so there's a non-zero probability of a -01 
appearing.  Please put my email from this morning on hold for now.

Ken,

Thanks for your comments - especially since you did make the deadline!  One 
thing I will point out for everyone's benefit is that we did discuss the 
standards track vs. experimental issue in Adelaide, and the rough consensus 
in the meeting (excluding you, of course) was for the standards track.

For the benefit of the people (like me!) that aren't keeping up with the 
policy work in the IETF, if you could point to any specific drafts 
regarding their framework to help people see how this doesn't fit that 
model, that would be a huge help.

I would also like to point out that RFC 2026 defines an experimental RFC as 
"part of some research or development effort", and is meant to be an 
archival record of the work and for the general information of the 
community.  I  really don't think that this MIB fits in with that category 
- we really are trying to produce a MIB that can be used in production 
networks.  So we should examine the MIB in the context of whether it is 
ready for PS.

If the consensus is that it is ready, then we're set.  If the consensus is 
that it is not, THEN we have a choice - improve it so that it IS ready, or 
call it research and publish it as experimental.  I much prefer the former 
to the latter.  Just my 2 cents.

Cheers,
Andy

--------

At 04:27 PM 4/19/00 -0400, Rehbehn, Kenneth wrote:
>Well - I thought I had till today to get my comments in for WG Call for the
>FR Service MIB.  Too much time out of the office to get a more timely
>response.  Here are my comments anyway (it is still April 19)!
>
>The Frame Relay Service MIB is not ready to complete WG Last Call. The
>current draft lacks sufficient detail to enable interoperable implementation
>of service monitoring for both half-duplex flows over a DLCI.  In addition,
>the current MIB structure needs less complexity. Merging the sample tables
>and providing a cleaner circuit management model will simplify the MIB and
>enable interoperability.
>
>My biggest beef is that this MIB is outside a generic policy/service
>management tracking framework that covers multiple aspects of the
>IETF-specified technology.  This MIB should not be on a standards track.
>Standards Track status should be restricted to a MIB that fits into the
>evolving framework being produced by the Policy Working Group.  This is the
>wrong time to declare a particular approach to be a "standard".  I will
>continue to urge the working group to keep this as a "Experimental" MIB.
>
>I am distressed at the silence on this mail list.  The silence indicates a
>great deal of apathy towards this particular attempt to produce a frame
>relay service MIB.  That alone should give the IESG pause.
>
>If we elect to charge ahead, then a lot more work is needed to get this MIB
>into good shape.  See my specific comments below for elaboration.
>
>Ken
>
>
>===================================================================
>
>Specific comments follow:
>
>1) Section 2.5 states that this document does not suggest or recommend a
>particular implementation.  The frsldPvcCtrlTable contains several
>configuration variables that certainly seem to imply specific
>implementations.  These configuration objects should be removed or the
>implementation details should be described.  For example:
>
>   frsldPvcCtrlPacketFreq
>   frsldPvcCtrlDelayLoc
>   frsldPvcCtrlDelayFrSize
>   frsldPvcCtrlDelayType
>   frsldPvcCtrlDelayTimeOut
>
>2) The frsldPvcDataTable is a table of free-running counters.  This means
>that the time period for the min, max, and average variables in the
>frsldPvcDataTable would be infinite, making these values meaningless.
>What's the point?
>
>3) Having separate data and availability history tables does not make sense.
>A single table is used for free running counters that populate the two
>separate tables.  Likewise, make the MIB simpler by having a single sample
>table that includes both data and availability.  Do users really have a need
>to do independent history collections of availability and DDR? Would
>someone, for example, want fifty samples at 15 minute intervals for
>availability but want only 25 samples for DDR?
>
>4) Provide index mechanisms to support the modeling of a circuit as two
>half-duplex flows so that delivery success can be reported for the
>east-to-west direction as well as the west-to-east direction.
>
>5) Add a "theory of operations" section to the introductory sections so that
>the reader can understand how to setup, tear down, and read the service
>sample sessions.  The theory should describe the operation for each of the
>permutations of data collection ("cooked" and "raw" - my terms, the current
>text uses an odd set of collection nomenclature).
>
>6) Why is the collection location distinction between
>source/destination/intermediate so important?  How does the fact that the
>collection location is "source" versus "destination" versus "intermediate"
>change how the MIB is used or interpreted?  The actions seem the same and
>each unit has to use implementation-specific mechanisms to pull together the
>data from the two endpoints.  These should all be combined into a single
>value called "cooked" - because they all share the characteristic that all
>required data has been collected, correlated, and calculated.  This is in
>contrast the "distributed" model where only information from one end is
>available.  The distributed distinction should be divided into "raw source"
>and "raw destination".  This provides the management system with clear
>indication that the data needs to be combined with another sample set.
>
>7) the second paragraph of Section 2.6, Distributed is confusing. What does
>it mean to act for separate source-destination pairs? What does this have to
>do with the concept of not having access to both source and destination sets
>of data?
>
>8) Different collection location types are allowed for delay measurement and
>delivery measurement on the SAME sample - why?  This just adds more
>complexity.
>
>9) Explicitly describe how an agent should respond if access is attempted to
>an object that is not supported by the particular implementation.
>
>10) Make sure all comments are moved into object DESCRIPTION text.
>Especially for enumerations.
>
>11) The frssldPvcDataOffered objects will wrap too quickly for high speed
>frame relay interfaces.  Use a high-capacity count.
>
>12) The indexing of the CtrlTable and the frsldPvcCtrlSrcRP and
>frsldPvcCtrlDstRP objects would imply that a single device cannot do
>measurements between multiple reference points for the same PVC. For
>example, you couldn't measure end to end and end to NNI.  Is this true?
>
>---------------------------------------------------------------
>Ken Rehbehn                              Phone: +1-301-296-2325
>Visual Networks                            Fax: +1-301-296-2302
>2092 Gaither Rd              EMail: [email-masked]
>Rockville, MD  20850              http://www.visualnetworks.com
>X-Info: To unsubscribe, email [email-masked]' with
>X-Info: 'unsubscribe frnetmib' in the body of the message.

X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe frnetmib' in the body of the message.