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

From: "C. M. Heard" <[email-masked]>
Date: Wed, 31 Aug 2005 22:51:24 -0700 (PDT)

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

> -----Original Message-----
> 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:
> > 
> > - 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.
> > 
> > - 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"
> > 
> > - 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.
> > 
> > 
> > 
> > > -----Original Message-----
> > > 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
> > 
> 

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

---

From: "Parker, Jeff" <[email-masked]>
Date: Thu, 01 Sep 2005 11:25:03 -0400

I agree with the suggestion about AdminState.  Will change

If I can pick up the TCs for Uint8 and Uint16, I would be happy to do so.
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

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.

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

- jeff

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 1 Sep 2005 11:08:02 -0700 (PDT)

Jeff,

A MIB module can't IMPORT from a PIB module, so I suggest renaming
Unsigned16TC to IsisUnsigned16TC and Unsigned8TC to IsisUnsigned8TC.

Mike

---

From: Jeff Parker <[email-masked]>
Date: Thu, 01 Sep 2005 18:11:31 -0400

Thanks for the comments.

>>>>>   I know there is already an Unsigned16TC in an IPSP PIB.

Made these IsisXxx

>>>>>   it is for "enabling or disabling a row"
 
Made this IsisAdminState
 
>>>>> and/or WG at all. And I wonder what your opinion is on

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.

I have respun.  Will be happy to resubmit or send out for review.  I will
wait until early next week, and upload to IETF again.

- jeff parker

myrmidon:~/MIB jeff$ diff mib.22 mib
118c118
<     AdminState ::= TEXTUAL-CONVENTION
---
>     IsisAdminState ::= TEXTUAL-CONVENTION
247c247
<     Unsigned16TC ::= TEXTUAL-CONVENTION
---
>     IsisUnsigned16TC ::= TEXTUAL-CONVENTION
256c256
<     Unsigned8TC ::= TEXTUAL-CONVENTION
---
>     IsisUnsigned8TC ::= TEXTUAL-CONVENTION
282c282
< -- table row's variable of type AdminState is in state on."
---
> -- table row's variable of type IsisAdminState is in state on."
365c365
<         SYNTAX Unsigned16TC (1..65535)
---
>         SYNTAX IsisUnsigned16TC (1..65535)
378c378
<         SYNTAX Unsigned16TC (1..65535)
---
>         SYNTAX IsisUnsigned16TC (1..65535)
391c391
<         SYNTAX AdminState
---
>         SYNTAX IsisAdminState
412c412
<         SYNTAX Unsigned16TC (350..65535)
---
>         SYNTAX IsisUnsigned16TC (350..65535)
425c425
<         SYNTAX Unsigned16TC (1492..16000)
---
>         SYNTAX IsisUnsigned16TC (1492..16000)
920c920
<                 Unsigned16TC,
---
>                 IsisUnsigned16TC,
957c957
<         SYNTAX Unsigned16TC (1..65535)
---
>         SYNTAX IsisUnsigned16TC (1..65535)
1111c1111
<                 AdminState,
---
>                 IsisAdminState,
1161c1161
<         SYNTAX AdminState
---
>         SYNTAX IsisAdminState
1366c1366
<                 Unsigned16TC,
---
>                 IsisUnsigned16TC,
1510c1510
<         SYNTAX Unsigned16TC (1..65535)
---
>         SYNTAX IsisUnsigned16TC (1..65535)
2104c2104
<                 Unsigned16TC,
---
>                 IsisUnsigned16TC,
2211c2211
<         SYNTAX Unsigned16TC (1..65535)
---
>         SYNTAX IsisUnsigned16TC (1..65535)
2453c2453
<                 AdminState,
---
>                 IsisAdminState,
2496c2496
<         SYNTAX AdminState
---
>         SYNTAX IsisAdminState
2719c2719
<                 AdminState,
---
>                 IsisAdminState,
2831c2831
<         SYNTAX AdminState
---
>         SYNTAX IsisAdminState
2836c2836
<              object follows the AdminState and ManualOrAutomatic
---
>              object follows the IsisAdminState and ManualOrAutomatic
2944c2944
<                 Unsigned16TC,
---
>                 IsisUnsigned16TC,
2946c2946
<                 Unsigned16TC,
---
>                 IsisUnsigned16TC,
2948c2948
<                 Unsigned16TC,
---
>                 IsisUnsigned16TC,
2950c2950
<                 Unsigned8TC
---
>                 IsisUnsigned8TC
2987c2987
<         SYNTAX Unsigned16TC
---
>         SYNTAX IsisUnsigned16TC
2995c2995
<         SYNTAX Unsigned16TC
---
>         SYNTAX IsisUnsigned16TC
3004c3004
<         SYNTAX Unsigned16TC
---
>         SYNTAX IsisUnsigned16TC
3012c3012
<         SYNTAX Unsigned8TC
---
>         SYNTAX IsisUnsigned8TC
3057c3057
<                 Unsigned16TC,
---
>                 IsisUnsigned16TC,
3059c3059
<                 Unsigned8TC,
---
>                 IsisUnsigned8TC,
3061c3061
<                 Unsigned8TC,
---
>                 IsisUnsigned8TC,
3084c3084
<         SYNTAX Unsigned16TC
---
>         SYNTAX IsisUnsigned16TC
3092c3092
<         SYNTAX Unsigned8TC
---
>         SYNTAX IsisUnsigned8TC
3100c3100
<         SYNTAX Unsigned8TC
---
>         SYNTAX IsisUnsigned8TC
3160c3160
<         SYNTAX Unsigned8TC
---
>         SYNTAX IsisUnsigned8TC
3168c3168
<         SYNTAX Unsigned8TC
---
>         SYNTAX IsisUnsigned8TC
3177c3177
<         SYNTAX Unsigned8TC
---
>         SYNTAX IsisUnsigned8TC
3195c3195
<         SYNTAX Unsigned16TC (0..16000)
---
>         SYNTAX IsisUnsigned16TC (0..16000)
3206c3206
<         SYNTAX Unsigned16TC (0..16000)
---
>         SYNTAX IsisUnsigned16TC (0..16000)