Subject: LSR MIB WG Last Call

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 14 Mar 2000 17:49:12 -0500

Since we have not received any additional comments
on the current version of the LSR MIB, we would like
to raise the document to WG Last Call.

	--Tom

---

From: "Tim Mancour" <[email-masked]>
Date: Wed, 15 Mar 2000 12:18:51 -0500

Tom,

I think it is a little premature for a last call on this MIB.
I only had a chance to print-out the -02 version yesterday 
and have the following comments:

	1. There is no mention in the MIB regarding the 
	LSP type/style (e.g. E-LSP or L-LSP). Perhaps 
      an object should be added to the cross-connect table?

	2. I'm confused about the COS object in the XC table.
	Section 4 references the COS information in the [LblStk] 
	I-D but there is no mention of COS in this I-D. From the 
	mplsXCCOS description, I assume that this value should be 
	used to overwrite the EXP bits. If this is true then there 
	needs to be a way to disable overwriting the EXP bits. 

	3. Why is the syntax of all of the get next index objects
	(e.g. mplsXCIndexNext) read-only? Shouldn't the TestAndIncr
	textual convention be followed?

	4. There are a number of typos regarding indexes. For example,
	mplsInSegmentXCIndex has a syntax of "Integer32 (1..2147483647)"
	but the description states that 0 is a valid value. It may be 
	advisable to create textual conventions to avoid these problems;
	something like MplsIndex and MplsIndexOrZero.

	5. There are also problems with bandwidth units and descriptions.
	As I understand it, all bandwidths should be in kilobits per 
	second. In some places, the UNIT is "bits per second". In other 
	places the description contains "kilobits per second (Kbps/sec)" 
	which should be either "kilobits per second (Kbps)" or "kilobits 
	per second (Kb/sec)".

	6. Section 6.2 mentions a mplsInterfaceResTable but no table
	exists.

	7. The syntax for the mplsInSegmentNPop is Integer32(1..2147483647).
	It should be Integer32(0..2147483647) or even INTEGER(0..255); 
	since popping 255 labels is still a very large range.

Best regards.
TimM
	
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Thomas D.
Nadeau
Sent: Tuesday, March 14, 2000 5:49 PM
To: [email-masked]; [email-masked]; Vijay Srinivasan
Cc: Cheenu Srinivasan; [email-masked]
Subject: LSR MIB WG Last Call

	--Tom

---

From: "James V. Luciani" <[email-masked]>
Date: Wed, 15 Mar 2000 13:03:00 -0500

Tim,

My $0.02 ($0.04 according to AMT :-))

   I also find it premature to do a last call on this mib.  You are not the
only person to raise the objection that he/she has not had sufficient time
to look at the LSR MIB and absorb the full impact of the changes which have
been made.  I know I have not.  I certainly have not had sufficient time to
comment.  Further, I find it exceedingly disturbing that this MIB seems to
have grown in scope by leaps and bounds without sufficient scrutiny by those
who would instrument it; let alone without receiveing working group
consensus (as fuzzy as the term 'working group conensus' may be in
practice).

   It would seem prudent to wait atleast until after Adelaide to make a
decision on whether to go to last call.  The high bandwidth interactions
that occur at face to face meetings may be the precise catalyst by which to
advance this MIB which might otherwise languish for months without attention
like it did after the first draft.  And yes, I know that the progress in
MPLS has not been at the rate that we all would like but we certainly don't
want to be guilty of advancing a MIB which is either incorrect or
irrelevant.  Note, I am not suggesting that the MIB is either incorrect or
irrelevant but rather I making the point that several others have made which
is that "I simply don't know" because I have not had adequate time to do due
dilligence after some major changes have occurred in the MIB.

--JIm

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 15 Mar 2000 13:25:16 -0500

Hi Tim,

         Thanks for your comments. We will look into them
and get back to you.

         --Tom