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

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: [email protected] [mailto:[email protected]] 
Sent: Friday, November 19, 2004 9:40 PM
To: [email protected]
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.

Introductory text comments:

1. Throughout the document, references to 802.1D-1998 should be
    updated to refer to 802.1D-2004.
DBL> Waiting for results of discussion on the mailing list before 
DBL> changing this.

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 references 
DBL> 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 an 
DBL> RFC.

3. Separate references to 802.1t are unnecessary, as .1t is now
    included in D-2004.
DBL> Waiting for results of discussion on the mailing list before 
DBL> changing this.

4. Separate references to 802.1u and 802.1v are unnecessary, as
    they are included in 802.1Q-2003.  (Note, I realize we are
    just trying to ship what we have and let IEEE deal with
    maintaining this, but it does seem unwise to approve a document
    for the IETF standards track that references obsolete versions
    of an IEEE specification, or that references an RFC that we are
    about to obsolete.)
DBL> Waiting for results of discussion on the mailing list before 
DBL> changing this.

5. The RFC editor does not allow references in the Abstract.  (Again,
    I realize the goal is to just ship it, but the RFC Editor will not
    publish this as is.)
DBL> I took out the references from the abstract.

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?

7. Section 2.1 begins with "This MIB includes...".  This should
    be replaced with "This document includes" or "The MIB modules
    defined in this document include"
DBL> Fixed.

8. In the Historical note in 2.1, bullet 4 says "Limit the total
    of objects.", which should probably be "Limit the total number
    of objects."
DBL> Fixed.

9. I'm not sure what we should do with section 3.1.1, since
    802.1D-2004 no longer defines the managed objects that we refer
    to here.
DBL> Waiting for results of discussion on the mailing list before 
DBL> changing this.

10. Section 3.3, first paragraph seems like an archaic leftover from
     SMIv1.  Do we really need to define what a T-C is here?  End of
     second paragraph talks about PIB modules, which I thought were dead.
DBL> Removed the first paragraph, and the statement about PIB modules.

11. Section 3.4 and 3.4.1 refer to MIB-II and RFC 1213 for the system
     group.  Shouldn't we be referring to RFC 3418 for the system group?
DBL> Fixed.

12. In section 3.4.2.1, second paragraph, the recommendation that VLANs
     are not represented in the ifTable conflicts with SMON.  Not sure
     what to do about this one, and I'm not sure IEEE is the right place
     to deal with it.
DBL> I changed this to Dan's 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?

P-BRIDGE-MIB comments:

1. There are several problems with the MODULE-IDENTITY:

    - LAST-UPDATED and REVISION dates need updating
    - Need to keep the original REVISION clause from 2674 and just add
      another revision for this version
    - DESCRIPTION needs the required copyright boilerplate
    - REVISION DESCRIPTION needs to identify changes made to this module
      since 2674 (one of Bert's favorite IESG Discusses...)
    - CONTACT-INFO normally has editor's contact info
DBL> Fixed LAST-UPDATED field, restored original REVISION, and added new
DBL> REVISION.  Restored the CONTACT-INFO from RFC 2674.

2. REFERENCE clauses should point to currently published IEEE document,
    not to an old IEEE draft.
DBL> Waiting for results of discussion on the mailing list before 
DBL> changing this.

3. Several formatting oopses throughout See
    dot1dPortPriorityT
able
    for an example.  There were more spurious line feeds like this
    scattered throughout the document.
DBL> These problems seem to have occurred after I submitted the last draft.
DBL> The originals I have here don't have these formatting problems.  I'm
DBL> not sure how to address this.

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 is
DBL> the same as was in RFC 2674.

5. pBridgePortGmrpGroup adds a new object to an existing group from
    2674, which is forbidden by the SMI.  We will need to deprecate
    the existing group and define a new group that includes the new
    object.  Note that this will also mean defining a new
    MODULE-COMPLIANCE that includes the new group.
DBL> Fixed.

Q-BRIDGE-MIB comments:

1. MODULE-IDENTITY has the same problems listed above.
DBL> Fixed as described above.

2. VlanIdOrAny, VlanIdOrNone, VlanIdOrAnyOrNone: The statement in
    section 3.3 that says: "Notre that a MIB object that is defined
    using one of these textual conventions should clarify the meaning
    of 'any VLAN' and/or 'no VLAN' in its DESCRIPTION clause." should
    be included in the DESCRIPTION clauses of these T-Cs.
DBL> Added text to the DESCRIPTIONs.

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?

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

5. There are several formatting glitches in this module, like in
    P-BRIDGE-MIB.  Note that these make the module uncompilable.
DBL> Same comment as above.

6. Again, qBridgePortGroup was modified from RFC 2674, which the
    SMI does not allow.
DBL> Fixed.

7. qBridgeCompliance was also modified to add the two new OBJECT-GROUPs
    which is also not allowed by the SMI.
DBL> Fixed.

8. 802.1Q says that support for management configuration of the
    protocol group database is optional.  An implementation that
    implements a fixed set of database entries is fully compliant.
    Therefore, the new MODULE-COMPLIANCE must allow
    dot1vProtocolGroupId and dot1vProtocolGroupRowStatus to be
    implemented read-only, otherwise we are taking something that is
    optional in 802.1Q and making it mandatory to comply with the
    MIB defintion.
DBL> Fixed.



Thanks,
John

David B Harrington wrote:
> Hi,
> 
> This starts the WG last call for the update to RFC2674.
> We missed the IETF61 publication deadline, so the document can be 
> found at:
>  
> http://www.ibr.cs.tu-bs.de/users/schoenw/draft-ietf-bridge-ext-v2-03.t
> xt
> 
> The WG last call will end November 23.
> This date has been chosen to ensure that 
> 	1) IETF61 attendees have two weeks to perform reviews, 
> 	2) attendees of the IEEE meeting the following week have two weeks
to
> perform reviews,
> 	3) the ID publication lockout is lifted and the document becomes 
> available in the normal repository If anybody has objection to this 
> date, please post your concerns to [email protected].
> If anybody has comments on the draft, please post them to
> [email protected]
> 
> Thanks,
> David Harrington
> [email protected]
> Bridge-mib co-chair
>  
> 
> 
> 
> 
> _______________________________________________
> Bridge-mib mailing list
> [email protected] https://www1.ietf.org/mailman/listinfo/bridge-mib
> 


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

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