FW: prequeal to WG lat call om the LSR mib module

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Can some people chime in here (on MPLS mailing list?)
The issue is with MplsIndexType in 
draft-ietf-mpls-ldp-mib-10.txt

I actually doubt that the below "conclusion" and proposed
resolution is so great .... 

But I will be on vcation 9as I announced) and I won't be able
to comment on their stuff over the next two weeks. Their WG
Last Call ends end of next week and then they want to
go to IETF Last Call (assuming it will just pass).

Thanks,
Bert 

-----Original Message-----
From: Adrian Farrel [mailto:afarrel@movaz.com]
Sent: donderdag 12 juni 2003 18:23
To: 'mpls@uu.net'
Cc: Thomas D. Nadeau; Wijnen, Bert (Bert)
Subject: Re: prequeal to WG lat call om the LSR mib module


Talking with Tom about this off-line we arrived at the following (startling?)
conclusion.

> It would, however, appear that we have reached the nub of the matter. The
> problem with the unformatted octet string aproach is in providing write
access,
> and (I'm guessing) the reason why this has become a hot debate is that I have
> been looking to provide write access and you have not been very bothered by
> whether that function works or not.
>
>
> So, there's an easy answer...
> People who use complex formatting of the octet string don't care about write
> access.
> People who use write access don't care about complex formatting of the octet
> string.

The suggestion we have is to add text (somewhere) to highlight this point.
For example...

>      In systems that provide write access to the LSR MIB, the mplsIndexType
>      SHOULD be used as a simple multi-digit integer encoded as an octet
string.
>      No further overloading of the meaning of an index SHOULD be made. The
>      mplsGetNextInSegmentIndex and similar objects should provide a
>      monotonic increasing value of indexes.
>
>      In systems that do not offer write access to the LSR MIB, the
>      mplsIndexType may contain implicit formatting that is specific to the
>      implementation to convey additional information such as interface index,
>      physical card or device, or application id. The interpretation of this
>      additional formatting is implementation dependent and not covered in this
>      document. Such formatting MUST NOT impact the basic functionality of
>      read-only access to the LSR MIB by management applications that are
>      not aware of the formatting rules.

This would address all of the issues about formating of the "index string".

Adrian