Subject: [Hubmib] I-D ACTION:draft-ietf-hubmib-rfc3636bis-05.txt

From: [email-masked]
Date: Wed, 26 Jul 2006 15:50:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Ethernet Interfaces and Hub MIB Working Group of the IETF.

	Title		: Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)
	Author(s)	: E. Beili
	Filename	: draft-ietf-hubmib-rfc3636bis-05.txt
	Pages		: 68
	Date		: 2006-7-26
	
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines objects for managing IEEE 802.3 Medium
Attachment Units (MAUs).  This memo obsoletes RFC 3636.  It amends
that specification by moving MAU type OBJECT-IDENTITY definitions and
relevant textual conventions into a separate Internet Assigned Number
Authority (IANA) maintained MIB module.  In addition, management
information is added to enable support for Ethernet in the First Mile
(EFM) and 10GBASE-CX4 MAUs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-hubmib-rfc3636bis-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-hubmib-rfc3636bis-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-hubmib-rfc3636bis-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Hubmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hubmib

---

From: "Edward Beili" <[email-masked]>
Date: Sat, 29 Jul 2006 12:02:29 +0300

Mike,
Got it. Thanks for a very informative explanation.
Regards,
-E.  

-----Original Message-----
From: C. M. Heard [mailto:[email-masked]] 
Sent: Friday, July 28, 2006 19:40
To: Edward Beili
Cc: Romascanu, Dan (Dan); [email-masked]
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-masked]]
> 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
> 
> 
>

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Sun, 30 Jul 2006 12:52:20 +0300

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

> Sent: Friday, July 28, 2006 7:40 PM
> To: Edward Beili
> Subject: RE: FW: [Hubmib] I-D 
> 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:
> 
>         [ ... ]
> 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
> 
> > I've noticed that smilint complains about some index 
> elements in the MAU-MIB being accessible:
> > 
> > Do you see a reason not to change the MAX-ACCESS clause for 
> these index elements to 'not-accessible'?
> > 
> > Regards,
> > -E.
> > 
> > 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
> > 
> > 
> > 
> 
>