Subject: RE: I-D ACTION:draft-parker-isis-wg-mib-00.txt

From: Jeff Parker <[email-masked]>
Date: Wed, 9 Dec 1998 11:29:48 -0500

Summing up responses to several mails under this topic...

I will restore the passwords (L1 & L2, and 
Tx in System and Rx Table)  

Peter has also pointed out that the original Rx
Table used the passwords as an Index: I'll fix that.    

We will need to add a new an "authType" variable 
for the Tx passwords to select Text, MD5, or TBD.   

Peter H, Jim Halpin, and I had a brief chance to discuss 
some of the other changes in his mail: I will rev the draft,
using the changes suggested on the list, 
and run it by Peter for editorial review before posting
a new version to the list.  If there are others that
would like to see that version when I send it to Peter,
drop me a line.  

Peter raises the issue of table numbering: I have
been "filling in the holes" when remove an object
or group.  This makes the MIB clearer, but breaks
interoperation with older versions.  If this is an
issue to anyone, please speak up now.

Other Open issues on my list include 
	Size of CircIndex - 8 bits is not enough.
	Status of the other 3 metrics 
Comments welcome.

I agree that a best practices document is an excellent
thing.  Are you offering to write it, Tony?

- jparker
- nexabit.com

> -----Original Message-----
> From:	Antoni Przygienda [SMTP:[email-masked]]
> Sent:	Tuesday, December 08, 1998 12:10 AM
> To:	Peter Higginson
> Cc:	[email-masked]
> Subject:	Re: I-D ACTION:draft-parker-isis-wg-mib-00.txt
> 
> > page 10 - I'd like to understand the rationale for leaving the
> AuthXxxPwd
> > entries out. I thought that there were implementations that used
> simple
> > passwords - or are these only on circuits.
> 
> I hope I follow here, there should be 2 types of passwords, one which
> is 
> specific to the domain/area, the other to the circuit. Different
> things
> are 
> getting validated using different passwords as described in the ISO
> spec. And as far I remember last MIB did not have it ...
> 
> > It has always concerned me that some timers could be set to silly
> values
> 
> I would say however that we need a kind of "best-current practices"
> document
> that would contain the things deployed today & deemed usefull (e.g.
> the
> timer per 
> level is one of those) first & the MIB should align with that [which
> is
> specifically
> in our charter]  (as I mentioned earlier today). Using the MIB itself
> as 
> the vehicle of such an undertaking seems to me to be the wrong tool
> for
> this 
> specific kind of task ...
> 
> 		thank you
> 
> 		--- tony

---

From: Antoni Przygienda <[email-masked]>
Date: Wed, 09 Dec 1998 23:23:55 -0500

>         Status of the other 3 metrics

yes, I confused the Ifindex with a circuit index. If everyone's ok 
with that we could expand the 8 bits but then the problem of
non-uniqueness
still exists. 

> thing.  Are you offering to write it, Tony?

From all I know it should be forthcoming from more competent parties
than
I am ...

BTW, on the MIB, I see that you rely that the user is setting the
metrics
for L2 aggregates in the MIB which is not necessarily what the 1195
describes.
Actually, funny enough, 1195 describes something else (in terms how to
compute
this metric) from what's currently used (min vs. max). I don't think
computing 
these metrics in an inconsistent manner will lead to routing loops but
it would be 
nice to agree on either the min or max of the summarized prefixes ? 

		thank you

		--- tony