Wijnen, Bert (Bert | 3 Jan 13:36 2005
Picon

RE: Review comments on draft-ietf-bridge-bridgemib-s miv2-07.txt


> -----Original Message-----
> From: bridge-mib-bounces <at> ietf.org 
> [mailto:bridge-mib-bounces <at> ietf.org]On
> Behalf Of C. M. Heard
> Sent: Friday, December 31, 2004 19:49
> To: bridge-mib <at> ietf.org
> Subject: RE: [Bridge-mib] Review comments on
> draft-ietf-bridge-bridgemib-smiv2-07.txt
> 
> 
> On Thu, 30 Dec 2004, David B Harrington wrote:
> > 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

I think Dave meant "dot1dBridge"  (i.e. capital B) in the above

> > ::= { 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.
> 

Seems fine to me too.

(Continue reading)

David B Harrington | 5 Jan 19:22 2005
Picon
Picon

Draft-ietf-bridge-bridgemib-smiv2 Issues Resolution

Hi,

I have reviewed the -08- revision to see which WG Last Call issues
were resolved. Here is a summary of the issues and their resolution.
These issues have been discussed on the mailing list, and I believe
the changes reflect consensus.
If nobody raises a serious objection to any change, I will close these
issues. 
We have only one issue remaining from the WG Last Call.

-----------------------
EDITORIAL ISSUES

#758: smiv2-07: Is the BridgeId description still correct? it is not
clear that the definition is wrong. The question has been posed
publicly and nobody, including the co-chair of 802.1, responded that
it was in fact wrong. I would only like to see corrected text
submitted if this is in fact WRONG. Issue closed.

#759: rstpMIB registration. This issue is purely editorial, and the
presence or non-presence of the comment in this document is
immaterial. Editor's choice. Issue closed.

#761 portPathCost32 description - The inaccuracy is editorial, and
immaterial to the functionality of the object. No improved text has
been provided. Issue closed. 

#762: smiv2-07: unit of dot1dTpPortMaxInfo; done. Issue closed

#764 add original authors in contact information. Publicly requested
(Continue reading)

David Levi | 6 Jan 16:52 2005

RE: WG Last Call:dratf-ietf-bridge-ext-v2-03.txt

John,

>> 2. References to RFC 1493 should refer to the updated version
>>     in draft-ietf-bridge-bridgemib-smiv2-07.txt.
>> DBL> I don't think it makes sense to change this, since these
>> DBL> references will just need to be updated to the new RFC number for
>> DBL> draft-ietf-bridge-bridgemib-smiv2-07.txt when it is published as
>> DBL> an RFC.
>
>Making this change would help the RFC editor find the places that need to be updated to refer
>to the new RFC when published, as well as alerting the RFC editor to the dependency between
>these two drafts in case one gets approved by the IESG before the other.

I still don't like the idea of changing references to an RFC into references to an ID.
How about if we just change 1493 to XXXX throughout the doc, and add a note to the
RFC editor somewhere that these XXXX's need to be changed to the appropriate RFC #
after the -smiv2- draft is published as an RFC?

-Dave

_______________________________________________
Bridge-mib mailing list
Bridge-mib <at> ietf.org
https://www1.ietf.org/mailman/listinfo/bridge-mib
David Levi | 6 Jan 17:17 2005

RE: WG Last Call:dratf-ietf-bridge-ext-v2-03.txt

Hi John,

A few more comments below . . .

-Dave

-----Original Message-----
From: John Flick [mailto:john.flick <at> hp.com]
Sent: Friday, December 17, 2004 10:15 PM
To: Levi, David [SC100:323:EXCH]
Cc: bridge-mib <at> ietf.org; Congdon, Paul T; dbharrington <at> comcast.net
Subject: Re: [Bridge-mib] WG Last Call:dratf-ietf-bridge-ext-v2-03.txt


See inline.

Thanks,
John

David Levi wrote:
> Hi All,
>
> I've fixed some of these items, as described below, in the nroff
> sources, so we'll have the changes in the next draft when/if it is
> submitted.
>
> -Dave
>
> -----Original Message-----
> From: bridge-mib-bounces <at> ietf.org [mailto:bridge-mib-bounces <at> ietf.org]
> Sent: Friday, November 19, 2004 9:40 PM
> To: bridge-mib <at> ietf.org
> Cc: Congdon, Paul T
> Subject: Re: [Bridge-mib] WG Last Call:dratf-ietf-bridge-ext-v2-03.txt
>
>
> Hi,
>
> I have the following comments on this draft.  I have divided my
> comments
> into introductory text, P-BRIDGE-MIB, and Q-BRIDGE-MIB.
>



> 6. In Section 2, the following sentence:
>
>     "IEEE 802.1Q defined port-based Virtual LANs where membership
>     is determined by the bridge port on which data frames are
>     received"
>
>     should be updated for protocol VLANs.
> DBL> Can you suggest some text?

"IEEE 802.1Q defines port-based Virtual LANs where membership is determined by the bridge port on which data frames are received, and port-and-protocol-based Virtual LANs where membership is determined by the bridge port on which frames are received and the protocol identifier of the frame."

Note: I picked on consistency with protocol VLANs in my comments because we define MIB objects in this document for managing protocol VLANs.  This is not so much an issue of alignment with the latest version of 802.1Q as it is an issue of internal consistency of this document.

DBL>  Fixed, I added your suggested text.

> 13. Much of the text in section 3.4.3 is about to be rendered obsolete
>      by draft-ietf-bridge-bridgemib-smiv2-07.txt.
> DBL> Is there anything in this section that will *not* be rendered
> DBL> obsolete, and so should not be removed?

A minimal change would be to remove the note about compliance statements not existing because the MIB uses SMIv1.

DBL>  I think minimal change is what we want, so I just removed the statement SMIv1.

> P-BRIDGE-MIB comments:

> 4. Description of dot1dPortOutboundAccessPriority seems wrong - outbound
>     definition talks about received frame instead of transmitted
> frame.
> DBL> Can others on the mailing-list verify this?  The current wording
> DBL> is the same as was in RFC 2674.

We may want to leave this for IEEE to fix.  802.1D-1998 seems a bit inconsistent here - the text in section 7.5.1 suggests that the outbound access priority should be mapped from the regenerated user priority, but the text in 7.7.5 seems to say that it should be mapped from the user_priority in the receive data indication, which would be the receive user_priority before the regenerated user priority mapping is applied.

DBL>  Okay, so no change.


> Q-BRIDGE-MIB comments:

> 3. dot1qForwardAllStaticPorts description talks about non-EFS behaviour,
>     but the acronym EFS has not been defined, and does not appear
>     anywhere else in this document.
> DBL> What would you suggest we change?  Perhaps adding a REFERENCE to
> DBL> this object?

EFS probably means "extended filtering services", but the acronym is never defined in either this document or in 802.1D.  This description talks about non-EFS behavior.  802.1D refers to 802.1D-1990 filtering behavior as "basic filtering services".  We should just replace "non-EFS behavior" with "basic filtering services behavior".

DBL>  I changed the text to:
DBL>       to indicate the standard behaviour of using basic filtering services


> 4. The description of dot1qPortAcceptableFrameTypes is no longer
>     accurate with protocol VLANs.
> DBL> Can you suggest how to change the text?

In the first paragraph of the description, replace "assigned to the PVID for this port" with "assigned based on the PVID and VID Set for this port".

DBL>  Your suggested text doesn't indicate to what the frame is being assigned.
DBL>  The old text did indicate this.  How about 'assigned to a VID based on the
DBL>  port's PVID and VID settings'?


_______________________________________________
Bridge-mib mailing list
Bridge-mib <at> ietf.org
https://www1.ietf.org/mailman/listinfo/bridge-mib
Juergen Schoenwaelder | 6 Jan 23:28 2005
Picon

Re: Review comments on draft-ietf-bridge-bridgemib-smiv2-07.txt

On Fri, Dec 31, 2004 at 10:48:40AM -0800, C. M. Heard wrote:

> > 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. 
> 
> All of these sound to me like Good Things.

I have applied the changes. Here is the current tree structure:

  --dot1dBridge(1.3.6.1.2.1.17)		# MODULE-IDENTITY
    +--dot1dNotifications(0)
    +--dot1dBase(1)
    +--dot1dStp(2)
    +--dot1dSr(3)
    +--dot1dTp(4)
    +--dot1dStatic(5)
    +--dot1dConformance(8)
       +--dot1dGroups(1)
       +--dot1dCompliances(2)

And this is the relevant part of the MIB module:

  -- ---------------------------------------------------------- --
  -- subtrees in the Bridge MIB
  -- ---------------------------------------------------------- --

  dot1dNotifications  OBJECT IDENTIFIER ::= { dot1dBridge 0 }

  dot1dBase           OBJECT IDENTIFIER ::= { dot1dBridge 1 }
  dot1dStp            OBJECT IDENTIFIER ::= { dot1dBridge 2 }

  dot1dSr             OBJECT IDENTIFIER ::= { dot1dBridge 3 }
  -- documented in RFC 1525

  dot1dTp             OBJECT IDENTIFIER ::= { dot1dBridge 4 }
  dot1dStatic         OBJECT IDENTIFIER ::= { dot1dBridge 5 }

  -- Subtrees used by Bridge MIB Extensions:
  --      pBridgeMIB  MODULE-IDENTITY   ::= { dot1dBridge 6 }
  --      qBridgeMIB  MODULE-IDENTITY   ::= { dot1dBridge 7 }
  -- Note that the practice of registering related MIB modules
  -- below dot1dBridge has been discouraged since there is no
  -- robust mechanism to track such registrations.

  dot1dConformance    OBJECT IDENTIFIER ::= { dot1dBridge 8 }

/js

--

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany
Juergen Schoenwaelder | 6 Jan 23:39 2005
Picon

Re: Draft-ietf-bridge-bridgemib-smiv2 Issues Resolution

On Wed, Jan 05, 2005 at 01:22:58PM -0500, David B Harrington wrote:

> UNRESOLVED ISSUES:
> 
> #543: smiv2-06: semantic changes; the following objects changed
> semantics of an existing object: dot1dPortPriority,
> dot1dStpTimeSinceTopologyChange, and dot1dStaticAllowedToGoTo. These
> objects were modified to support 802.1t semantics. Since 802.1t
> implementations have been fielded before this mib becomes available,
> the behavior of current agent implementations might be non-compliant
> with the updated definitions. Even an implementation that claims
> compliance to bridgeCompliance1493 will be impacted because the
> semantics of objects from RFC 1493 have been changed. 

dot1dStpPriority:
dot1dStpPortPriority:

I think the change is really a clarification that only a subset of
the original value range is allowed for bridges that comply to IEEE
802.1t or IEEE 802.1w so I do not see a real problem here for _agent_
implementations. Bridges supporting IEEE 802.1t or IEEE 802.1w likely
reject values which are outside the set of legal values and I would
guess that this is exactly what is currently implemented and deployed.
Can someone confirm my guess?

dot1dStpTimeSinceTopologyChange:

Can't really judge the difference since I do not know enough about
RSTP and tcWhile timers. Can someone explain what the impact of this
change might be?

dot1dStaticAllowedToGoTo:

I am not sure what the issue here is. Did this semantically chance
at all?

/js

--

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany
David B Harrington | 7 Jan 18:18 2005
Picon
Picon

RE: Review comments ondraft-ietf-bridge-bridgemib-smiv2-07.txt

Hi,

I recommend that the RSTP-MIB be positioned directly under mib-2 as
well, rather than under dot1dbridge. 

David Harrington
dbharrington <at> comcast.net
co-chair, IETF Bridge WG

> -----Original Message-----
> From: bridge-mib-bounces <at> ietf.org 
> [mailto:bridge-mib-bounces <at> ietf.org] On Behalf Of Juergen 
> Schoenwaelder
> Sent: Thursday, January 06, 2005 5:28 PM
> To: bridge-mib <at> ietf.org
> Subject: Re: [Bridge-mib] Review comments 
> ondraft-ietf-bridge-bridgemib-smiv2-07.txt
> 
> On Fri, Dec 31, 2004 at 10:48:40AM -0800, C. M. Heard wrote:
>  
> > > 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. 
> > 
> > All of these sound to me like Good Things.
> 
> I have applied the changes. Here is the current tree structure:
> 
>   --dot1dBridge(1.3.6.1.2.1.17)		# MODULE-IDENTITY
>     +--dot1dNotifications(0)
>     +--dot1dBase(1)
>     +--dot1dStp(2)
>     +--dot1dSr(3)
>     +--dot1dTp(4)
>     +--dot1dStatic(5)
>     +--dot1dConformance(8)
>        +--dot1dGroups(1)
>        +--dot1dCompliances(2)
> 
> And this is the relevant part of the MIB module:
> 
>   -- ---------------------------------------------------------- --
>   -- subtrees in the Bridge MIB
>   -- ---------------------------------------------------------- --
> 
>   dot1dNotifications  OBJECT IDENTIFIER ::= { dot1dBridge 0 }
> 
>   dot1dBase           OBJECT IDENTIFIER ::= { dot1dBridge 1 }
>   dot1dStp            OBJECT IDENTIFIER ::= { dot1dBridge 2 }
> 
>   dot1dSr             OBJECT IDENTIFIER ::= { dot1dBridge 3 }
>   -- documented in RFC 1525
> 
>   dot1dTp             OBJECT IDENTIFIER ::= { dot1dBridge 4 }
>   dot1dStatic         OBJECT IDENTIFIER ::= { dot1dBridge 5 }
> 
>   -- Subtrees used by Bridge MIB Extensions:
>   --      pBridgeMIB  MODULE-IDENTITY   ::= { dot1dBridge 6 }
>   --      qBridgeMIB  MODULE-IDENTITY   ::= { dot1dBridge 7 }
>   -- Note that the practice of registering related MIB modules
>   -- below dot1dBridge has been discouraged since there is no
>   -- robust mechanism to track such registrations.
>   
>   dot1dConformance    OBJECT IDENTIFIER ::= { dot1dBridge 8 }
> 
> /js
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 
> 28725 Bremen, Germany
> 
> _______________________________________________
> Bridge-mib mailing list
> Bridge-mib <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/bridge-mib
> 
Juergen Schoenwaelder | 7 Jan 21:02 2005
Picon

Re: Review comments ondraft-ietf-bridge-bridgemib-smiv2-07.txt

On Fri, Jan 07, 2005 at 12:18:39PM -0500, David B Harrington wrote:

> I recommend that the RSTP-MIB be positioned directly under mib-2 as
> well, rather than under dot1dbridge. 

Yes. In fact, I hacked some code into libsmi yesterday so that it will 
warn in cases where a module identity is somewhere in the internet.mgmt
subtree and not directly below mib-2, transmission or snmpModules. The
idea is that MIB authors get a warning early in the process.

/js

--

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany
John Flick | 8 Jan 04:59 2005
Picon

Re: WG Last Call:dratf-ietf-bridge-ext-v2-03.txt

Dave,

Your changes look fine except for one nit.

David Levi wrote:
>  > 4. The description of dot1qPortAcceptableFrameTypes is no longer
>  >     accurate with protocol VLANs.
>  > DBL> Can you suggest how to change the text?
> 
> In the first paragraph of the description, replace "assigned to the PVID 
> for this port" with "assigned based on the PVID and VID Set for this port".
> 
> DBL>  Your suggested text doesn't indicate to what the frame is being 
> assigned.
> DBL>  The old text did indicate this.  How about 'assigned to a VID 
> based on the
> DBL>  port's PVID and VID settings'?

I think I would put change this to "assigned to a VID based on the PVID
and VID Set for this port."  The "VID Set" term is the protocol VLAN
term I was trying to pull in here.

John
John Flick | 8 Jan 05:01 2005
Picon

Re: WG Last Call:dratf-ietf-bridge-ext-v2-03.txt

Dave,

Whatever format makes it easiest for the RFC Editor to Do The Right
Thing is fine by me.

Thanks,
John

David Levi wrote:
> John,
> 
>  >> 2. References to RFC 1493 should refer to the updated version
>  >>     in draft-ietf-bridge-bridgemib-smiv2-07.txt.
>  >> DBL> I don't think it makes sense to change this, since these
>  >> DBL> references will just need to be updated to the new RFC number for
>  >> DBL> draft-ietf-bridge-bridgemib-smiv2-07.txt when it is published as
>  >> DBL> an RFC.
>  >
>  >Making this change would help the RFC editor find the places that need 
> to be updated to refer
>  >to the new RFC when published, as well as alerting the RFC editor to 
> the dependency between
>  >these two drafts in case one gets approved by the IESG before the other.
> 
> I still don't like the idea of changing references to an RFC into 
> references to an ID.
> How about if we just change 1493 to XXXX throughout the doc, and add a 
> note to the
> RFC editor somewhere that these XXXX's need to be changed to the 
> appropriate RFC #
> after the -smiv2- draft is published as an RFC?
> 
> -Dave
> 

Gmane