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

Hi,

I have asked the editor to start addressing the easy-to-resolve
comments.
I have comments, inline. 

John, would you be willing to review the -smiv2- draft with the same
attention to detail so we can get that one done?

David Harrington
[email protected]

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of John Flick
> 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.

It seems some references need to refer to 1D-1998; some might be
better referencing 1D-2004.
Can you review each reference in the text and suggest replacement
text?

> 
> 2. References to RFC 1493 should refer to the updated version
>     in draft-ietf-bridge-bridgemib-smiv2-07.txt.

I believe that is not true in all instances. Please review each and
make specific recommendations.

> 
> 3. Separate references to 802.1t are unnecessary, as .1t is now
>     included in D-2004.

This work started before 1D-2004 was approved. We are not trying to
update to the latest state of IEEE documents, but to finalize work
that was started three years ago, so we can get it into a stable state
before transitioning responsibility for updates to the IEEE. 
> 
> 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.)

This work started before 1Q-2003 was approved. We are not trying to
update to the latest state of IEEE documents, but to finalize work
that was started three years ago, so we can get it into a stable state
before transitioning responsibility for updates to the IEEE. 

> 
> 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.)

This should be corrected. I believe we can simply drop the reference
text, e.g. [RFC2578], since the introductory sections will have the
references.

> 
> 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.

The IEEE can update it.

> 
> 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"

Agreed.

> 
> 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."

Agreed.

> 
> 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.

We should finish this document to refer to the 1D-1998 and let the
IEEE obsolete the objects later if they choose.

> 
> 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.

I agree the first paragraph seems archaic, and could be removed, even
the part that lists the TCs used in the document. 
PIB has no reference, so either it should be removed or an informative
reference added.

> 
> 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?

RFC3418 appends new objects to the RFC1213 system group. This mib
module has dependencies on the RFC1213 portion of the system group,
but not to the RFC3418 additions, so I believe it is accurate to say
that we "assume that a brdge implementing this MIB will also implement
(at least) the system group defined in MIB-II. 

We can try to tighten up the language when we're in fixing
"implementing this MIB" to being "implementing this MIB module".

> 
> 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.

I agree this should be dealt with in the IETF. We need to come to a
consistent recommendation for all virtual interfaces.
It is rather important that RFC1493-compliant agents not be made
non-compliant by any change we make.

> 
> 13. Much of the text in section 3.4.3 is about to be rendered
obsolete
>      by draft-ietf-bridge-bridgemib-smiv2-07.txt.

I think we should consider writing a formal compliance statement for
the original RFC1493 in its update or in a separate document. That
would also solve open issue #1 in the update document.

> 
> 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

The unavailability of the editors of this draft has been a major
reason for its delay. 
The rfc-editor has proposed that a "contact information" section be
included in rfcs rather than "author's addresses" so the original
authors and subsequent authors addresses can be listed to help readers
contact somebody that knows why the document was written as it was.

Since mib modules often are distributed without the surrounding text,
maybe we need to make sure we have an editor's name in the
module-identity, but putting the mailin glist there might be a better
way to get them some help. Maybe we should put an alternate address -
the "mibs" mailing list.


> 
> 2. REFERENCE clauses should point to currently published IEEE 
> document,
>     not to an old IEEE draft.
> 
Ideally, the mib module should be specified at the same time as the
technolgy it is meant to manage. That is why we are transitioning the
responsibility to the IEEE. I suggest that the document can be updated
by the IEEE to bring it up-to-date with current IEEE documents. I
think we will never be able to match the current IEEE documents at the
glacial rate of this WG, so I would rather publish this and transition
the responsibility so the IEEE can synchronize the mib and the
technology specs.

In the meantime, our job is to finalize the work started three years
ago, not to try to synchronize to currrent IEEE documents.
 
> 3. Several formatting oopses throughout See
>     dot1dPortPriorityT
> able
>     for an example.  There were more spurious line feeds like this
>     scattered throughout the document.

I believe the internet-draft publication process introduced these
spurious characters. They are aware of the problem and have fixed it.
The next revision will resolve these, hopefully.

> 
> 4. Description of dot1dPortOutboundAccessPriority seems wrong 
> - outbound
>     definition talks about received frame instead of 
> transmitted frame.

Do you have access to ISO.IEC 15802-3 Table 7-3? What language do they
use?

> 
> 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.

I believe the way we should proceed to be compatible with RFC2580 is
this (please correct me if I'm wrong):
We need to copy the old group definition and old module compliance
into this document.
We should define a new group with the new object
Then we should define a new MODULE-compliance that includes the old
group and the new group.
We do not need to deprecate the old group and old module-compliance
(although we may want to).

> 
> Q-BRIDGE-MIB comments:
> 
> 1. MODULE-IDENTITY has the same problems listed 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.

I agree, with the wording modified to 
	VlanIdOrAny: "a MIB object that is defined using this textual
convention should clarify the meaning
 	of 'any VLAN' in its DESCRIPTION clause."
	VlanIdOrNone: "a MIB object that is defined using this textual
convention should clarify the meaning
 	of 'no VLAN' in its DESCRIPTION clause."
	VlanIdOrAnyOrNone: "a MIB object that is defined using this
textual convention should clarify the meaning
 	of 'any VLAN' and 'no VLAN' in its DESCRIPTION clause."
> 
> 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.

Can you provide suggested text?

> 
> 4. The description of dot1qPortAcceptableFrameTypes is no longer
>     accurate with protocol VLANs.

Was this in scope three years ago?

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

To be corrected during publication.

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

To be corrected.

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

To be corrected.

> 
> 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.

To be checked and corrected I fnecessary.

> 
> Thanks,
> John

Thanks for the thorugh review of the document, 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
>