Re: IETF-54 meeting

Mike, thanks for your comments on draft-ietf-bridge-bridgemib-smiv2-03.txt.  I
shall try to respond to your first issue on dot1dStpPortEnable.

> 1) dot1dStpPortEnable
>    I believe there needs to be some text added to the front matter
>    to describe the relationship between ifAdminStatus and dot1dStpPortEnable.
>    What is the relationship between ifAdminStatus and dot1dStpPortEnable?
>      a) none,
>      b) represent same value (as embodied in cisco catalyst implementation)
>      c) represent different layers (port level, vs protocol level) (kzm
expectation?)
>
>    background info: http://www.macfaden.com/ietf/bridge-test-results.txt
When you raised this before, there did not seem to be a consenus for a
definition that would satisfy everyone.  One of the original authors of RFC1493,
Anil Rijsinghani, indicated that c) was the correct answer, but did not
elaborate on how this affects things like handling of STP BPDUs, or forwarding
of traffic.

My own interpretation is as follows:

  If dot1dStpPortEnable is set to enabled(1) the port should participate
  normally in Spanning Tree and in forwarding traffic.

  If dot1dStpPortEnable is set to disabled(2) the port should not
  participate in Spanning Tree, received BPDUs should be discarded, and
  the port should not participate in Layer 2 forwarding of traffic,
  although it may participate in Layer 3 forwarding.

I think we all agree on the interpretation of enabled(1), but your test
results show that disabled(2) has been interpreted differently by each vendor.
This highlights the need for clarification, as you said.  So I am offering the
above interpretation as a suggested resolution, to be added to the DESCRIPTION
of dot1dStpPortEnable.

I would like to hear the views of the group, to see if they agree or disagree
with this interpretation.  I would particularly like to hear the views of the
original authors of RFC1493.

Les...