Subject: Re: [Bridge-mib] Re: Draft-iet-bridge-bridgemib-smiv2-09.txt

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 28 Jan 2005 08:49:20 +0100

On Thu, Jan 27, 2005 at 08:34:14PM -0500, David B Harrington wrote:

[...]
 
> --- comments on Juergen's proposed text:
> Section 3.2.1: I believe Juergen's proposed text that says
> 'Implementation of the BRIDGE-MIB module requires
> that at least ... are implemented' is inaccurate; this mib module can
> be implemented without those objects if desired, but you will miss
> some of the objects recommended by 802.1-D, and the functionality they
> provide (but then even if you implement this mib module plus those
> objects, you'll still be missing some objects listed in 802.1-D and
> the functionality they provide, as described in 3.1).

Obviously there is no common view what RFC 1493 was trying to say in
section 3.2.* and this is why I orginally liked to keep some rather
vague text. In practical terms, I have never seen a bridge which did
not implement the seven system scalars so from a practical perspective,
this whole debate is really a mood point and a waste of time.
 
> Section 3.2.2: I believe Juergen's proposed ext that says
> 'Implementation of the BRIDGE-MIB module requires that the following
> objects of the IF-MIB module are implemented' is inaccurate in its
> list, as I describe above.

It boils down to how you read the first paragraph in 3.2.2. My reading 
is that it says segments are considered subnetworks from the interfaces 
point of view and that the interfaces group is mandatory for all systems. 
Again, I have never seen a bridge which did not implement the full 
interfaces group.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

_______________________________________________
Bridge-mib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bridge-mib

---

From: "David B Harrington" <[email-masked]>
Date: Fri, 28 Jan 2005 08:26:11 -0500

Hi Juergen,

Personally, I thought the original vague text was fine, as was the
original reference to RFC1213.
I agree that most implementations would simply do all seven system
objects, and similarly for interfaces.

But we have competing interests. You and Bert want to get rid of
references to RFC1213. Mike wants to get rid of inaccurate statements
about relationships to other mibs. I would like to keep the RFC1213
reference because compatibility with RFC1493 has been the primary
goal, but unless others in the WG speak up and say that such
compliance is the consensus and that RFC1213 is fine, as co-chair, I
need to try to adjudicate the competing consensuses.

One consensus is that we shouldn't use a reference to RFC1213. This is
the view of you and Bert; we have two persons, one being an O&M AD.
Mike and I are willing to accept that using it is undesirable, but not
critical.
Mike tells us that the OPS AD insists on accurate cross-document
dependencies; again, we have two persons, one being an AD. (We haven't
heard David actually say this however). 

Unfortunately, these two views are hard to reconcile; if you point to
RFC3418 and RFC2863 instead of RFC1213, the statements become
inaccurate; if you point to the available confirmance clauses, the
document becomes inaccurate; if you list all seven system objects and
the many interfaces objects as dependencies, the document becomes
inaccurate.

Me, I want see the document finished so we can move on to other
documents in the WG charter, and move toward WG closure. What I see is
a debate between two entrenched positions, neither of which helps an
operator manage a device. This debate is all about IETF publication
process and neither way of specifying the relationship between mib
modules offers anything substantive to an operator.

Will you yield on your insistence to not use RFC1213? Bert, will you
yield on this point? If so, consensus could move to "while we are
referenceing RFC1213, and that may be undesirable, using RFC1213 in
the statement of relationships between mib modules is in fact the
closest we can get to accurately portraying the original intent, and
therefore its usage should be acceptable."

David Harrington
[email-masked]
co-chair, IETF Bridge WG

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> Sent: Friday, January 28, 2005 2:49 AM
> To: David B Harrington
> Cc: 'Wijnen, Bert (Bert)'; 'C. M. Heard'; 'Bridge-Mib (E-mail)'
> Subject: Re: [Bridge-mib] Re:
Draft-iet-bridge-bridgemib-smiv2-09.txt

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 28 Jan 2005 18:31:20 +0100

> need to try to adjudicate the competing consensuses.

I don't think RFC1213 is the issue. The confusion I think is more on
the interpretation of the following paragraph:

   In MIB-II, the 'system' group is defined as being mandatory for all
   systems such that each managed entity contains one instance of each
   object in the 'system' group.  Thus, those objects apply to the
   entity as a whole irrespective of whether the entity's sole
   functionality is bridging, or whether bridging is only a subset of
   the entity's functionality.

I think it is clear what 'system' group in RFC1213 stands for. What is
less clear is whether the text conveys a requirement that the 'system'
group in RFC1213 is mandatory to implement for bridges. The other
interpretation I have heard is that only the sys* objects listed in
section 3.1 are mandatory if you want to comply to the IEEE 802.1d
definition while the BRIDGE-MIB does not require any of them to be
implemented. This is what I tried to capture in my latest proposal.

Once we agree what RFC 1493 section 3.2 really wants to say, we should
be able to phrase that same thing in terms of the SNMPv2-MIB and the
IF-MIB. I have posted two concrete proposals trying to cover the two
interpretations I have identified above. I am happy with either one.
If both don't work, someone should post another one and then we need 
to determine concensus which one is the correct one to choose.

/js

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 28 Jan 2005 18:19:50 +0100

I am content with references to RFC1213.

But then I don't read sections 3.1 and 3.2 as creating a dependency; rather they
explain why certain objects from the 1993 IEEE definition are not included;
normative reference? may be.  You could, but I think it would be wrong to do so,
create a much bigger 3.1 and 3.2 explaining why objects from 2002 IEEE
definition are not included:-)

I also think the reference to RFC1213 is the more accurate since for me, the
later MIB modules, particularly IF-MIB, bring in a lot more baggage which
RFC1213 never
had.  RFC1213 has a view of an interface that was right for its time, wrong now,
and I think what we have got (apart from SMIv2) is mostly a MIB module of that
era.

So I would leave RFC1213 in 3.1 and 3.2 adding a statement pointing out that
(yes, we do know that:-) these objects have been refined by later MIB modules
and making the later ones normative.

Tom Petch

----- Original Message -----
From: "David B Harrington" <[email-masked]>
To: <[email-masked]>
Cc: "'C. M. Heard'" <[email-masked]>; "'Wijnen,Bert (Bert)'"
<[email-masked]>; "'Bridge-Mib (E-mail)'" <[email-masked]>
Sent: Friday, January 28, 2005 2:26 PM
Subject: RE: [Bridge-mib] Re: Draft-iet-bridge-bridgemib-smiv2-09.txt