Subject: RE: [Isis-wg] Re: TC name issues in draft-ietf-isis-wg-mib-22.txt

From: "Parker, Jeff" <[email-masked]>
Date: Thu, 1 Sep 2005 20:37:21 -0400

Bert -
    Those look like valid points.  I will do some wordsmithing and report back.
    I could address some of the points now, but perhaps it would be better to save my thoughts for an editing session, and see if I can make the text speak for itself
 
- jeff

	-----Original Message----- 
	From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
	Sent: Thu 9/1/2005 6:56 PM 
	To: Jeff Parker; C. M. Heard; Parker, Jeff 
	Cc: Christian Hopps; ISIS WG 
	Subject: RE: [Isis-wg] Re: TC name issues in draft-ietf-isis-wg-mib-22.txt

	Inline
	
	> -----Original Message-----
	> From: Jeff Parker [mailto:[email-masked]]
	> Sent: Thursday, September 01, 2005 19:12
	> To: C. M. Heard; Jeff Parker
	> Cc: Wijnen, Bert (Bert); Christian Hopps; ISIS WG
	> Subject: Re: [Isis-wg] Re: TC name issues in
	> draft-ietf-isis-wg-mib-22.txt
	>
	>
	> Thanks for the comments.
	>
	> >>>>> - Is it wise to define Unsigned8TC and Unsigned16TC
	> >>>>>   with those generic names) in this MIB module?
	> >>>>>   I know there is already an Unsigned16TC in an IPSP PIB.
	>
	> Made these IsisXxx
	>
	Thanks
	
	> >>>>> - Is it wise to have a AdminState TC with that genetic
	> >>>>>   name in this MIB module? Specifically since it says
	> >>>>>   it is for "enabling or disabling a row"
	> 
	> Made this IsisAdminState
	> 
	Thanks
	
	> >>>>> - I see quite some text in comments in the MIB modules and
	> >>>>>   wonder if it would not be better to advise them to move
	> >>>>>   it into DESCRIPTION clauses as appropriate?
	> >>>>> 
	> >>>>> -  various DESCRIPTION clauses are pretty terse.
	> >>>>>
	> >>>>> I do not think any of the above is a showstopper,
	> >>>>> I just wonder if you had discussed that with the author(s)
	> >>>>> and/or WG at all. And I wonder what your opinion is on
	> >>>>> these sort of things.
	>
	> I understand that one man's terse is another man's prolix,
	> but I'm not sure
	> which modules are being discussed.  I skimmed through the
	> whole MIB and
	> didn't find that much relevant in comments outside the
	> DESCRIPTION clauses.
	>
	> I will be happy to move text around or wordsmith if there is
	> an obscure
	> clause, but I think the list already has been pretty frank
	> about objects
	> they found obscure.  I don't see a systemic problem and I
	> didn't spot any
	> problematic object.
	>
	> Bottom line: give me a reference and I will fix it.
	>
	
	OK, as I said in a previous email, the last thing is not anything
	to hold the doc hostage over. But if you want examples, here are a few:
	
	    IsisSystemID ::= TEXTUAL-CONVENTION
	        STATUS current
	        DESCRIPTION
	            "A system ID."
	        SYNTAX OCTET STRING (SIZE(6))
	
	I am sure that IS-IS people know what "A system ID" is.
	But all I can tell is that it is 6 octets. I have no idea
	how it is created/configured, what the format is... etc.
	I see no REFERENCE clause either, which might point me to
	the proper IS-IS document that describes the format and
	semantics of "A system ID".
	
	Now I see that when you use the TC in isisSysID that you
	add a lot of text there. And that is strange. The idea of a
	TC is that the semantics are described in the TC so that you
	do not have to repeat it umty times every time you use
	the same TC. Oh well.
	
	Same story for:

	    IsisLinkStatePDUID ::= TEXTUAL-CONVENTION
	        STATUS current
	        DESCRIPTION
	            "A Link State PDU Identifier."
	        SYNTAX OCTET STRING (SIZE(8))
	
	In fact I think many of your TCs could use a REFERENCE clause.
	
	Further, On page 12 I see:
	  -- Behavior Definitions
	
	  -- ResettingTimer behavior definition
	  -- "This object specifies the interval between certain events in
	
	So what is "This object" ??
	I see no other occurence of ResettingTimer
	So where does this belong?
	
	  -- the operation of the protocol state machine. If the value of
	  -- this object is set to a new value while the protocol state
	  -- machine is in operation, the implementation shall take the
	  -- necessary steps to ensure that for any time interval which
	  -- was in progress when the value of the corresponding object
	  -- was changed, the next expiration of that interval takes place
	  -- the specified time after the original start of that interval,
	  -- or immediately, whichever is later. The precision with which
	  -- this time shall be implemented shall be the same as that
	  -- associated with the basic operation of the timer object."
	
	  -- ReplaceOnlyWhileDisabled behavior definition
	  -- "This object may not be modified while the corresponding
	  -- table row's variable of type AdminState is in state on."
	
	Same questions
	  -- ManualOrAutomatic behavior definition
	  -- "The access of this object is read-write if the row to which
	  -- it belongs is manual (i.e. is being or was created manually)
	  -- otherwise (i.e. was created automatically) it is read-only."
	
	Same questions
	
	Further I See that for several of your read-write objects,
	you do not define what the persistency behaviour is or should
	be. So what can a management application expect after a
	restart of the agent? Some of the objects I found this for:
	
	  isisSysLevelType
	  isisSysID
	  isisSysMaxPathSplits
	  isisSysMaxLSPGenInt
	
	and probably more objects.
	That is by the way a type of "blocking" issue.

	On Page 16 I see:
	
	-- The Level 1 Manual Area Address Table
	-- contains the set of area addresses manually configured
	-- for this Intermediate System.
	-- At least one row in which the value of isisManAreaAddrExistState
	-- is active must be present. The maximum number of rows
	-- in this table for for which the object
	-- isisManAreaAddrExistState has the value active is 3.
	--     An attempt to create more 3 rows of isisManAreaAddrEntry
	-- with state 'active' in one instance of the IS-IS protocol
	-- should return inconsistentValue.
	
	    isisManAreaAddrTable OBJECT-TYPE
	        SYNTAX SEQUENCE OF IsisManAreaAddrEntry
	        MAX-ACCESS not-accessible
	        STATUS current
	        DESCRIPTION
	            "The set of manual area addresses configured on this
	             Intermediate System."
	        REFERENCE "{ISIS.aoi manualAreaAddresses (10)}"
	    ::= { isisSystem 2 }
	
	So I wonder why the commented text (all lines starting with --)
	are not just put into the DESCIPTION clause.
	
	That is the sort of things that I wonder about.
	
	Bert

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 1 Sep 2005 20:02:00 +0200

Inline

> From: Parker, Jeff [mailto:[email-masked]]
> Sent: Thursday, September 01, 2005 12:25
> To: C. M. Heard; ISIS WG; Christian Hopps
> Cc: Wijnen, Bert (Bert)
> Subject: Re: TC name issues in draft-ietf-isis-wg-mib-22.txt
> 
> 
> I agree with the suggestion about AdminState.  Will change
> 
Good

> If I can pick up the TCs for Uint8 and Uint16, I would be 
> happy to do so.

There currently are none that are in an RFC (I believe)

> Since this is in last call, I don't see how I could replace 
> names chosen now in a later version.  I will
>     Look for the IPSP PIB.  Pointers welcome
>     Rename the Uint8 TC as IsisXxxx
> 

Don't pick up the one from the IPSP PIB. It is unclear if/when
that document will move to RFC-Editor, so you do not want to
become dependent on it. I just used that one as an example where
we can run into a conflict in the future.

If we (MIB doctors and the rest of the IETF) could decide soon 
(but I am not sure we can), then you could import from there.
But I would not recommend to do so either.

So for now... what I suggested is:

- maybe best you name them IsisUnsigned16TC and IsisUnsigned8TC
- that way you prevent name clashes
- that way hopefully people will not so easily import them from this
  doc (cause they would have a totally illogical dependency on
  an isis document)
- if we ever get to do generic Unsigned16TC and Unsigned8TC, then
  whenever you do a new rev of your doc, you can obsolete your
  TCs and replace the SYNTAX of IsisUnsigned16TC to Unsigned16TC
  because sematically and on the wire they are the same (or so
  I assume, but we can never be sure till we see both TCs of
  course).

> I can look at the descriptions and move text around.  This is a larger
> change, and I'd like to consult with Chris before starting 
> down this road. If there are particularly opaque objects,
> I'd be happy to make a small set of changes.
> 

Don't go out of your way to do so.
In general, I like to see explanantions/semantics described in the
proper DESCRIPTION clauses as opposed to in comments outside
the DESCRIPTION clauses. But it is not a show stopper.

> Classes start in two weeks, so I will try to wrap up a new 
> version before that.
> 
Bert

> - jeff
> 
> 
> On 9/1/05 1:51 AM, "C. M. Heard" <[email-masked]> wrote:
> 
> > Jeff and ISIS WG,
> > 
> > Bert Wijnen (the OPS AD for Network Management) had some questions
> > about the naming of three of the TEXTUAL-CONVENTION definitions in
> > draft-ietf-isis-wg-mib-22.txt, and he asked if I had discussed that
> > with you.  Since I have not, I am forwarding the following comments
> > for your consideration.
> > 
> > Thanks,
> > 
> > Mike Heard
> > 
> > ---------- Forwarded message ----------
> > Date: Wed, 31 Aug 2005 18:33:56 +0200
> > From: "Wijnen, Bert (Bert)" <[email-masked]>
> > To: C. M. Heard <[email-masked]>, "Wijnen, Bert (Bert)" 
> <[email-masked]>
> > Subject: RE: I-D ACTION:draft-ietf-isis-wg-mib-22.txt
> > 
> > I agree with what you are answering, so feel free to ocpy
> > the WG list. I want to do a more extensive check though.
> > 
> > Now w.r.t. the TC names
> > - AdminState, can in my view best be named IsisAdminState
> > 
> > But I am not sure about the other 2. renaming them to be
> > Isis-prefixed would be OK. They are somewhat generic though,
> > and we have allowed such generic names in some other MIB modules.
> > But this is a real strange MIB module to have such generic TCs.
> > If they do name them IsisXxxx, then of course if we ever do
> > such TCs in a more generic place, then they can easily 
> replace theirs
> > in a later revision and import from our generic MIB module.
> > 
> > Again it seems time that we start a IANA Maintained GENERIC-TC-MIB
> > module or some such, which extends RFC2579. Maybe we should just
> > do a document that picks up RFC2579 MIB and then add a set of TCs
> > we allready agree on, and then at the same time hand it over to
> > IABA for further maintenenace.?
> > 
> > Bert
> > 
> > 
> >> From: C. M. Heard [mailto:[email-masked]]
> >> Sent: Tuesday, August 30, 2005 22:57
> >> To: Wijnen, Bert (Bert)
> >> Subject: RE: I-D ACTION:draft-ietf-isis-wg-mib-22.txt
> >> 
> >> 
> >> Bert,
> >> 
> >> I did indeed send e-mail to the author and WG stating
> >> that I think the ISIS-MIB is ready for the next step
> >> in the process.  However, it is always good to get an
> >> independent set of eyes -- I did not discuss any of
> >> the issues noted below with the author.  As it happens
> >> I just overlooked the problems with the TC names
> >> Unsigned8TC, Unsigned16TC, and AdminState, and that
> >> was a mistake on my part.  Since RFC 2578 specifically
> >> bans name collisions in "standard" MIB modules, and
> >> names cannot be changed after publication, I think
> >> that these names should be fixed.  The rest of the
> >> stuff I would be inclined to leave, since it can be
> >> fixed in a subsequent revision of the MIB module if
> >> implementation experience indicates that it is necessary.
> >> 
> >> I haven't cc:'d the author and WG, but I'll do so if you
> >> agree with my assessment (or you can convey your comments
> >> directly).
> >> 
> >> Thanks,
> >> 
> >> Mike
> >> 
> >> On Wed, 31 Aug 2005, Wijnen, Bert (Bert) wrote:
> >>> Mike, I am getting asked if this MIB is now ready for
> >>> IESG review (I guess that also means IETF Last Call).
> >>> 
> >>>> From the below email from you, I am pretty confident it is
> >>> in good shape.
> >>> A quick check of ev 22 document though makes me wonder:
> >>> 
> >>>> From: C. M. Heard [mailto:[email-masked]]
> >>>> Sent: Tuesday, July 12, 2005 04:19
> >>>> To: ISIS WG
> >>>> Cc: Wijnen, Bert (Bert)
> >>>> Subject: Re: I-D ACTION:draft-ietf-isis-wg-mib-22.txt
> >>>> 
> >>>> 
> >>>> On Mon, 11 Jul 2005 [email-masked] wrote:
> >>>>> A New Internet-Draft is available from the on-line
> >>>>> Internet-Drafts directories.  This draft is a work item of the
> >>>>> IS-IS for IP Internets Working Group of the IETF.
> >>>>> 
> >>>>> Title  : Management Information Base for IS-IS
> >>>>> Author(s) : J. Parker
> >>>>> Filename : draft-ietf-isis-wg-mib-22.txt
> >>>>> Pages  : 101
> >>>>> Date  : 2005-7-11
> >>>> ...
> >>>>> A URL for this Internet-Draft is:
> >>>>> 
> > http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-22.txt
> >>> 
> >>> All of the outstanding MIB Doctor issues have been addressed.  As
> >>> far as I am concerned it's ready to be forwarded to the IESG.
> >>> 
> >>> Mike Heard
> >>> 
> >> 
> > 
> > 
> > 
>

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 2 Sep 2005 00:56:27 +0200

Inline

Thanks

Thanks

Same story for:

Same questions

Same questions

  isisSysLevelType
  isisSysID
  isisSysMaxPathSplits
  isisSysMaxLSPGenInt

On Page 16 I see:

Bert