RE: FW: I-D ACTION:draft-ietf-hubmib-rfc3636bis-05.txt

Right. This is exactly the reason for which we have the following
comment in the DESCRIPTION clauses of the respective objects:

-- read-only since originally an
-- SMIv1 index

BTW - I am preparing the submission of the document to the AD for
consideration as Proposed standard. 
 
Regards,

Dan


> -----Original Message-----
> From: C. M. Heard [mailto:[email protected]] 
> Sent: Friday, July 28, 2006 7:40 PM
> To: Edward Beili
> Cc: Romascanu, Dan (Dan); [email protected]
> Subject: RE: FW: [Hubmib] I-D 
> ACTION:draft-ietf-hubmib-rfc3636bis-05.txt 
> 
> Edward,
> 
> Please DO NOT change the MAX-ACCESS clause for these index elements.
> 
> Both RFC 2578 and the MIB review guidelines do not allow the 
> MAX-ACCESS value to be decreased because doing so could spoil 
> on-the-wire interoperability between a manager implementation 
> based on an the old version of the MIB module and an agent 
> implementation based on the new version of the MIB module.
> 
> As you know, the MAU-MIB was originally (in RFC 1515) an 
> SMIv1 MIB module, which required index elements to be 
> read-only.  When such a MIB module is translated to SMIv2, 
> the MAX-ACCESS value is generally required to be the same as 
> the ACCESS value in the SMIv1 definition (see RFC 3584 2.1.1. 
> (5) for details).  That is why the index elements listed 
> below have a MAX-ACCESS value of read-only.  And in each case 
> there is an ASN.1 comment adjacent to the MAX-ACCESS clause 
> that notes this fact:
> 
>         [ ... ]
>         MAX-ACCESS  read-only  -- read-only since originally an
>                                -- SMIv1 index
>         [ ... ]
> 
> If we were making new definitions these would be 
> not-accessible but since the original SMIv1 definitions were 
> read-only we leave them that way to ensure backward 
> compatibility and live with the complaints from smilint.
> 
> Thanks,
> 
> Mike
> 
> On Fri, 28 Jul 2006, Edward Beili wrote:
> > Mike/Dan,
> > I've noticed that smilint complains about some index 
> elements in the MAU-MIB being accessible:
> > 
> > rfc3636bis.mib:173: [5] {index-element-accessible} warning: index 
> > element `rpMauGroupIndex' of row `rpMauEntry' should be 
> not-accessible 
> > in SMIv2 MIB
> > rfc3636bis.mib:173: [5] {index-element-accessible} warning: index 
> > element `rpMauPortIndex' of row `rpMauEntry' should be 
> not-accessible 
> > in SMIv2 MIB
> > rfc3636bis.mib:173: [5] {index-element-accessible} warning: index 
> > element `rpMauIndex' of row `rpMauEntry' should be 
> not-accessible in 
> > SMIv2 MIB
> > rfc3636bis.mib:482: [5] {index-element-accessible} warning: index 
> > element `ifMauIfIndex' of row `ifMauEntry' should be 
> not-accessible in 
> > SMIv2 MIB
> > rfc3636bis.mib:482: [5] {index-element-accessible} warning: index 
> > element `ifMauIndex' of row `ifMauEntry' should be 
> not-accessible in 
> > SMIv2 MIB
> > rfc3636bis.mib:1253: [5] {index-element-accessible} warning: index 
> > element `broadMauIfIndex' of row `broadMauBasicEntry' should be 
> > not-accessible in SMIv2 MIB
> > rfc3636bis.mib:1253: [5] {index-element-accessible} warning: index 
> > element `broadMauIndex' of row `broadMauBasicEntry' should be 
> > not-accessible in SMIv2 MIB
> > 
> > Do you see a reason not to change the MAX-ACCESS clause for 
> these index elements to 'not-accessible'?
> > 
> > Regards,
> > -E.
> > 
> > -----Original Message-----
> > From: C. M. Heard [mailto:[email protected]]
> > Sent: Thursday, July 27, 2006 15:51
> > To: Romascanu, Dan (Dan)
> > Cc: Edward Beili
> > Subject: Re: FW: [Hubmib] I-D 
> > ACTION:draft-ietf-hubmib-rfc3636bis-05.txt
> > 
> > On Thu, 27 Jul 2006, Romascanu, Dan (Dan) wrote:
> > > Can you please confirm that you are happy with this version and 
> > > whether you feel that the document can be submitted to the IESG?
> > 
> > Hello Dan,
> > 
> > Indeed, as far as I am concerned this document is ready to 
> go.  It addresses all the issues I had with -03 and -04.
> > 
> > Mike
> > 
> > 
> > 
> 
>