Subject: [Bridge-mib] Review comments on draft-ietf-bridge-bridgemib-smiv2-07.txt

From: John Flick <[email-masked]>
Date: Fri, 17 Dec 2004 18:43:33 -0800

Hi,

I had only a few comments on this draft:

1. In Section 3, bullet 4, says: "Limit the total of objects.", which
    should be "Limit the total number of objects."

2. Section 3.1: the term "group" has a more specific meaning in SMIv2
    than it did in SMIv1.  It seems like most MIB doctor reviews have
    been discouraging the use of the term "group" for meanings other
    than "OBJECT-GROUP".  Perhaps "subtree" would be better here
    (and a few other places in the document).

3. Section 3.1.3: Should we have an Informative reference to the
    SR Bridge MIB RFC here (RFC 1513)?  It did not exist yet when
    RFC 1493 was written, but it does now, so we could get rid
    of the vague "a separate document" wording.

4. Section 3.3 seems unnecessary - we shouldn't have to describe
    what a textual convention is.

5. The forward reference in the MODULE-IDENTITY {dot1dBridge 8}
    is known to cause problems with some broken MIB compilers.
    It is a problem with the MIB compilers, but customers typically
    don't care - they complain to the equipment vendor that
    provided them with the copy of the MIB module.  We had the
    same problem with the MAU-MIB.  We would save ourselves,
    vendors, and customers alot of grief by registering the
    MODULE-IDENTITY directly below mib-2.

6. The big comment blocks around the T-Cs seem unnecessary.  Again,
    it should not be necessary to describe what a textual convention
    is here.  Text specific to the textual convention should be in
    the DESCRIPTION clause, not in a comment.

7. Is the BridgeId description still correct, or did 802.1t change
    this?

8. On page 12 where we list registrations defined in other modules,
    should we also list rstpMIB?

9. I would suggest changing bridgeCompliance and bridgeCompliance2
    to bridgeCompliance1493 and bridgeCompliance (or some better
    name for the new compliance) and making both current, to avoid
    deprecating support for 1493-compliant bridges.  Not sure if
    we should be deprecating dot1dStpPortPathCost...I can see
    valid arguments either way.  Reporting 65535, and stating
    that PortCost32 should be examined for the real path cost when
    PathCost reports 65535, would be compatible with what we did
    for ifSpeed/ifHighSpeed in the IF-MIB.

10. Open issues 1: I think this has been discussed on the mailing
     list - PortCost32 is necessitated by higher speed links, not
     RSTP.  Can we steal some text from 802.1t Table 8.5 and the
     following Note 2 to explain this issue.  Place it in the
     Overview text, or better yet, in the Description clauses of
     PortCost and PortCost32.

11. Open issues 3: We return bytes here.  The comment above the
     object about how it would have been nice if we could have used
     ifMtu seems to imply it should be bytes.  I agree we should
     say so exlicitly.

Hope this helps,
John

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 29 Dec 2004 00:34:19 +0100

> I had only a few comments on this draft:

Thanks very much for the comments. Please see my response to your
comments below. Note that there are some questions where I like to
have more input.

>    should be "Limit the total number of objects."

fixed
 
>    (and a few other places in the document).

fixed
 
>    of the vague "a separate document" wording.

makes sense - done
 
>    what a textual convention is.

well, ok - removed

>    MODULE-IDENTITY directly below mib-2.

I have replaced { dot1dBridge 8 } with { mib-2 dot1dBridge(17) 8 }.
Does that address you concern? Note that we have more module identities
below dot1dBridge so using { dot1dBridge 8 } is at least consistent
with the other registrations. Let me know if you are happy with
{ mib-2 dot1dBridge(17) 8 } or have other proposals.
 
>    the DESCRIPTION clause, not in a comment.

removed TC explanation and moved semantics into DESCRIPTION clauses

> 7. Is the BridgeId description still correct, or did 802.1t change

I have no clue - someone familiar with 802.1t must provide input or
the description stays as it is now.
 
>    should we also list rstpMIB?

I have added a comment. However, I am not sure what the status and
future of draft-ietf-bridge-rstpmib-05.txt is. Dave, can you tell
me what to do here?
 
>    for ifSpeed/ifHighSpeed in the IF-MIB.

I think it does not make sence to have a current compliance statement
which refers to a deprecated object. I do like the proposal to rename
the compliance statements and I do agree that the bridgeCompliance1493
should be current given the actual deployment of this module. So I
tend to make dot1dStpPortPathCost current and to add language similar
to the ifSpeed/ifHighSpeed objects in the IF-MIB.
 
>     Overview text, or better yet, in the Description clauses of

Since I do not have 802.1t, can you please draft some text to put 
in place?

>     ifMtu seems to imply it should be bytes.  I agree we should

I have added UNITS "bytes" and I have closed this issue.

/js

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

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 29 Dec 2004 12:24:41 -0500

Hi,

I have opened issues for some of the items John raised that may
require discussion.
My comments inline reflect the RT Ticket Numbers for opened issues.
I did not open tickets for the editorial tweaks.

David Harrington
[email-masked]
co-chair, IETF Bridge WG
 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen 
> Schoenwaelder

> >    of the vague "a separate document" wording.

This should be RFC 1525, not RFC 1513.
 
------------------------------------------
> { mib-2 dot1dBridge(17) 8 } or have other proposals.

I have concerns that this change will impact OTHER broken MIB
compilers. I suspect many compilers that broke as the result of the
forward reference in SMIv2 will have already been fixed for this
problem. I believe some compilers may have a problem with the new
proposed syntax, and don't want to make this a moving target. Let's
keep the forward reference approach that is legal SMIv2 and common in
other IETF standard MIB modules. If a MIB compiler still breaks as the
result of the (legal) forward reference, then the broken compiler
should be fixed.

------------------------------------------
> removed TC explanation and moved semantics into DESCRIPTION clauses

Makes sense to me.
------------------------------------------
> the description stays as it is now.

We are not changing this document to be up-to-date with the most
recent IEEE documents. Such an update can be done by the IEEE 802.1
WG.
Changing the BridgeID semantics might alter the semantics of a number
of objects and require that we deprecate and redefine such objects.
We should not change BridgeId if it changes the semantics of any
objects in the MIB module.

------------------------------------------
> future of draft-ietf-bridge-rstpmib-05.txt is. Dave, can you tell

I personally find it bad practice to predefine subtrees that are not
actually used within a document, and I discourage the practice.
I object to adding this registration here.

------------------------------------------
> to the ifSpeed/ifHighSpeed objects in the IF-MIB.
------------------------------------------

> Since I do not have 802.1t, can you please draft some text to put 

Keep in mind we are not trying to update this document to the current
IEEE documents, but simply to update the original 1493 MIB module.
We have added this object (a decision I sorely regret now) but any
changes we make now should not impact the semantics of the original
objects or require any other updates to the document, if possible.

John can you propose some text for the description clause?

------------------------------------------
> I have added UNITS "bytes" and I have closed this issue.

As co-chair, I will consider this issue closed if there are no
objections.

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 29 Dec 2004 12:43:10 -0500

Updated contact info:

Andrew Smith
[email-masked]
FAX 415 345 1827

Anil Rijhsinghani
Accton Technology Corporation
5 Mount Royal Ave
Marlboro, MA 01752
USA

we have no updated contact info for Paul Langille or E.Decker.

David Harrington
[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 30 Dec 2004 01:14:08 +0100

> FAX 415 345 1827

Is not an author of RFC 1493 as far as I can tell.
 
> Accton Technology Corporation

Already in the document.
 
> we have no updated contact info for Paul Langille or E.Decker.

This is what I need.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 30 Dec 2004 01:40:20 +0100

> This should be RFC 1525, not RFC 1513.

Fixed.

I have reverted back to the original format. But see below.

We can't change the pBridgeMIB and qBridgeMIB registration anymore.
We can of course move the bridgeMIB MODULE-IDENTITY registration to 
{ mib-2 xxx } (which also addresses issue #757) and we can remove the 
comments that refer to the srMIB, dot1dPortPair, rstpMIB. We probably
want to add a note saying the usage of the dot1dBridge subtree by 
other MIB modules is strongly discouraged. Any objections against
this approach?
 
/js

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 29 Dec 2004 19:32:39 -0500

Unless they respond with updated info, we can do without.

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

> From: Juergen Schoenwaelder [mailto:[email-masked]] On 
> Behalf Of Juergen Schoenwaelder
> Sent: Wednesday, December 29, 2004 7:14 PM
> To: David B Harrington
> Cc: 'John Flick'; 'Congdon, Paul T'; [email-masked]
> Subject: Re: Bridge#764: smiv2-07: add original authors as contacts
>

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 30 Dec 2004 14:36:06 -0500

Hi,

Comments inline.

dbh

> Sent: Wednesday, December 29, 2004 7:40 PM
> To: David B Harrington
> Subject: Re: [Bridge-mib] Review comments 
> ondraft-ietf-bridge-bridgemib-smiv2-07.txt
> 

Thanks.

> other MIB modules is strongly discouraged. Any objections against

For the SMI experts amongst us, can we legally register the
MODULE-IDENTITY in the following way?

dot1dBridge MODULE-IDENTITY
	...
	::= { mib-2 17 }

RFC1493 registered dot1dbridge using "dot1dbridge OBJECT IDENTIFIER
::= { mib-2 17 }"
Juergen pointed out that the SMIv2-to-SMIv1 translation of a
MODULE-IDENTITY is simply an OID, so this might be legal.

If we can do this, it would move the mib up under mib-2, and eliminate
the forward reference (issue #757). 
It would also place the object and notification subtrees under the
dot1dBridge MODULE-IDENTITY, approximating the recommended practices
from draft-ietf-ops-mib-review-guidelines Suggested OID layout. 

We would want to remove the comment showing the assignment of
bridgeMIB to { dot1dBridge 8 }
And change dot1dConformance from { bridgeMIB 1 } to { dot1dBridge ##
}, where ## is an unused subtree, possibly { dot1dBridge 8 }

It is unfortunate that the MODULE-IDENTITY dot1dBridge would not
mirror the BRIDGE-MIB name, and pBridge and qBridge MODULE-IDENTITIES
are under dot1dBridge MODULE-IDENTITY, but we cannot change that now
without great pain.

Dbh

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 31 Dec 2004 10:48:40 -0800 (PST)

> MODULE-IDENTITY is simply an OID, so this might be legal.

This is legal.  The effect is to associate a registration, as well as
an OID value, with the descriptor dot1dBridge, but the semantics
remain unchanged, and any MIB module that imports the descriptor will
continue to compile, and all subordinate OIDs will resolve to the same
value as before.  Note that RFC 2578 Section 3.6 explicitly allows the
same descriptor to be associated with a registration and an assignment:

   A descriptor is allowed to be associated with both a registration and
   an assignment, providing both are associated with the same OBJECT
   IDENTIFIER value and semantics.

For some precedents, the following definition in RFC 1406

   ds1 OBJECT IDENTIFIER ::= { transmission 18 }

has been translated to

   ds1 MODULE-IDENTITY
   ...
   ::= { transmission 18 }

in RFCs 2495 and 3895 and the following definition in RFC 1407

   ds3  OBJECT IDENTIFIER ::= { transmission 30 }

has been translated to

   ds3 MODULE-IDENTITY
   ...
   ::= { transmission 30 }

in RFCs 2496 and 3896.

> from draft-ietf-ops-mib-review-guidelines Suggested OID layout. 

All of these sound to me like Good Things.

Mike Heard