Re: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt

["ietfdbh" <[e-mail]>]

Hi,

a) re: copyright. I believe you have handled that appropriately. That is
consistent with the way the bridge MIB transfers were handled, after
significant discussion with the legal advisors for both SDOs. I do not think
that significant contributors must be consulted to grant permission for this
transfer. Scott, of course, is an expert in the RFC3978/9 requirements, so I
would defer to his expertise (or Jorge's) on this matter.

b) I think part of the problem relating to "renaming" is terminology. If the
OID assignments used in IEEE8023-EFM-CU-MIB are different than those used in
EFM-CU-MIB, then these are different MIB modules, according to SMI rules. It
is inappropriate to say that the MIB module has been moved or renamed; it is
a different MIB module, with different OID assignments and different object
descriptors. 

The two MIB modules can co-exist without a problem. As a result, equipment
that supports EFM-CU-MIB and equipment that supports IEEE8023-EFM-CU-MIB can
be managed using the same management application with no confusion about the
objects or the MIB module being supported. A managed device can implement
both MIB modules without ambiguity or interoperability issues with regard to
those management applications that access the device. (It will probably be
important that the device implementations be consistent across the two
module implementations, so a counter in one matches the equivalent counter
in the other, unless there is a reason to make them different.)

c) Since these are technically different MIB modules, and existing devices
are expected to continue supporting the EFM-CU-MIB, I don't see a pressing
need to do anything regarding the status of the EFM-CU-MIB. Per RFC4663, we
did not change the status of the Bridge-MIB modules.


David Harrington
[e-mail]
[phone]

-----Original Message-----
From: Edward Beili [mailto:[e-mail]] 
Sent: Friday, February 15, 2013 8:29 PM
To: ietfdbh; 't.petch'; 'Scott O Bradner'
Cc: [e-mail]
Subject: RE: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt

David, Tom,
I tend to agree with you on the "Updates" vs. "Obsoletes" argument.

The main reason for this I-D was to let people who read IETF documents know
about the move of the responsibility for further EFM-CU-MIB evolution from
the IETF HUBMIB WG to the IEEE 802.3 and let them be aware of the new
IEEE8023-EFM-CU-MIB module, which incorporated the old EFM-CU-MIB in its
entirety (duplicating and renaming all the object definitions from the
EFM-CU-MIB).

You are correct that there are existing implementations of the EFM-CU-MIB
that would not be upgraded to IEEE8023-EFM-CU-MIB any time soon. In my
opinion most equipment and NMS vendors, my company included, would not spend
the effort of supporting the new MIB, unless the IEEE would introduce some
amazing new functionality, which I highly doubt. Currently the
IEEE8023-EFM-CU-MIB is an exact replica of the EFM-CU-MIB, with the
exception of the naming prefixes. It is because of this reason I would
prefer not to deprecate the EFM-CU-MIB.

I'm not that familiar with the Updates clause though. If we leave the
RFC5066 valid can't we also leave the IF-CAP-STACK-MIB still defined there,
having only some explanatory text in the rfc5066bis, letting the readers
know about the IEEE document?


Now, with respect to your comment about the copyright:
1. I am the author of RFC 5066 and I can assure you that the phrase "greatly
advanced" was a polite way of saying "commented and reviewed" as opposed to
"co-authored".
2. The IEEE sought my sole permission already in Nov 2010 to grant the IEEE
the right to include the RFC 5066 in the IEEE P802.3.1, here's a quote from
the original communication:

"The IEEE 802.3 working group wishes to incorporate portions of IETF RFC
5066 as part of IEEE Draft Standard IEEE P802.3.1 Ethernet MIBs and to
develop, modify and evolve such portions as part of the IEEE standardization
process.
The IETF Trust has recently informed us that under the Intellectual Property
provisions of IETF RFC 3978 'IETF Rights in Contributions', the IETF Trust
does not possess all rights needed for the IEEE to make derivative works of
IETF RFC 5066 outside the IETF Standards Process.
Instead such rights are retained by the original authors, and that the IEEE
has to therefore obtain such rights by contacting the original authors.
Since you are the author of IETF RFC 5066, the IEEE hereby requests that you
kindly agree to submit your contributions in IETF RFC 5066 to the IEEE for
inclusion in IEEE P802.3.1. Please note that IETF IESG is aware of this
request.
Attached hereto, please find a copyright permission letter template that we
ask you kindly complete, sign and return, granting the aforementioned rights
to the IEEE."

Since the IEEE has already obtained my permission with the IESG "blessing"
and published the first version of the IEEE8023-EFM-CU-MIB, I don' think we
should demand more than that for the rfc5066bis, which simply documents the
current state of affairs.

Regards,
-E.

-----Original Message-----
From: ietfdbh [mailto:[e-mail]]
Sent: Thursday, January 10, 2013 22:13
To: 't.petch'; 'Scott O Bradner'
Cc: [e-mail]; Edward Beili
Subject: RE: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt

Hi,

I agree Obsoletes is not accurate.
I think Updates might be accurate.

However, I think the text is inaccurate:
"That MIB module will be part of a separate
   document, maintained by the Institute of Electrical and Electronics
   Engineers (IEEE) 802.3 working group."
I disagree with this statement.

The EFM-CU-MIB is being frozen as is, and a NEW MIB module is being created,
called IEEE8023-EFM-CU-MIB.
RFC2578 does not allow renaming of a MIB module:
" Note that any definition contained in an information module is
   available to be IMPORT-ed by any other information module, and is
   referenced in an IMPORTS clause via the module name.  Thus, a module
   name should not be changed.  Specifically, the module name (e.g.,
   "FIZBIN-MIB" in the example of Section 5.7) should not be changed
   when revising an information module (except to correct typographical
   errors), and definitions should not be moved from one information
   module to another.

   Also note that obsolete definitions must not be removed from MIB
   modules since their descriptors may still be referenced by other
   information modules, and the OBJECT IDENTIFIERs used to name them
   must never be re-assigned."

So claiming that the EFM-CU-MIB is being renamed is inaccurate because that
would violate SMIv2 rules.
All the object definitions in EFM-CU-MIB will also need to be renamed and
duplicated under IEEE8023-EFM-CU-MIB.
Otherwise NMS applications that import EFM-CU-MIB and IEEE8023-EFM-CU-MIB
would not be able to easily distinguish which OID is appropriate.

Since EFM-CU-MIB cannot be legally "moved" to IEEE8023-EFM-CU-MIB, and
existing devices and applications may continue to support it, I recommend
the existing MIB module should retain its current status.
If we want to recommend that people utilize IEEE8023-EFM-CU-MIB, we can
provide an Updates clause to update the RFC5066 status, but since it
contains an active MIB it really should not be Obsoleted.
If we want to deprecate the EFM-CU-MIB and recommend IEEE8023-EFM-CU-MIB,
then I think the EFM-CU-MIB MIB module would need to be published again with
an SMIv2 deprecated status (and all the objects would presumably need to be
deprecated as well).
If we deprecate the EFM-CU-MIB module and its objects, the "relationship to
other MIB modules" would need some serious updating to discuss the impact of
the deprecation on other modules (including proprietary MIB modules) that
depend on EFM-CU-MIB.


David Harrington
[e-mail]
[phone]
-----Original Message-----
From: t.petch [mailto:[e-mail]]
Sent: Thursday, January 10, 2013 5:19 AM
To: ietfdbh; 'Scott O Bradner'
Cc: [e-mail]; 'Edward Beili'
Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt

---- Original Message -----
From: "ietfdbh" <[e-mail]>
To: "'t.petch'" <[e-mail]>; "'Scott O Bradner'"
<[e-mail]>
Cc: <[e-mail]>; "'Edward Beili'" <[e-mail]>
Sent: Tuesday, January 08, 2013 10:07 PM

> Hi,
>
> I would be careful with assumptions about the existing IETF
standards-track
> MIB vanishing, even if IEEE is going to maintain comparable
definitions
> under an IEEE subtree going forward.
>
> Existing devices and managers might support the RFC5066 EFM-CU-MIB,
and
> those devices may never be updated to the new IEEE version.
> The IETF standards-track EFM-CU-MIB should still be considered a valid
MIB
> module; it just should not be modified going forward.
> The IEEE version should replace it for new implementations, and the
IEEE
> version could supplement the IETF EFM-CU-MIB in new and updated 
> implementations, to support continued interoperability.

David

So in practical terms, what would you do?  Currently the I-D has an
'Obsoletes 5066' which I think wrong, since the new I-D omits the vast mass
of 5066; and, as you rightly point out, the EFM-CU-MIB module could well be
with us for a long time (and we have no change control over the IEEE module
that one day may replace it).

Leave 5066 as Standards Track with this as an Updates (which it isn't, its a
reproduce a small part thereof unchanged as far as I can see)?

I will go on objecting to Obsoletes even if I cannot see what the
alternative should be:-)

Tom Petch

> David Harrington
> [e-mail]
> [phone]
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
Behalf Of
> t.petch
> Sent: Tuesday, January 08, 2013 5:18 AM
> To: Scott O Bradner
> Cc: [e-mail]; Edward Beili
> Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt
>
> ---- Original Message -----
> From: "Scott O Bradner" <[e-mail]>
> To: "t.petch" <[e-mail]>
> Cc: "Romascanu, Dan (Dan)" <[e-mail]>; "Edward Beili"
> <[e-mail]>; <[e-mail]>
> Sent: Saturday, January 05, 2013 2:25 PM
>
> On Jan 5, 2013, at 7:45 AM, t.petch <[e-mail]> wrote:
>
> > I wonder if this I-D should really supersede RFC5066.  I would
rather
> > see RFC5066 become Historic with this as an Updates.
>
> a historic document does not exist (standards track wise) so there
would be
> nothing to update -
>
> also- an update would not be a complete replacement (i.e. some of the
old
> document would still be in force) - is that the case here (i.e.
> do you think that this is not a full replacement?)
>
> Scott
>
> As Dan said,
> "RFC 5066 defines two MIB modules. One (this one) continues to be
maintained
> by the IETF. There is no need for a change. The other
> (EFM-CU-MIB) goes to the IEEE, and will be relocated with new names
under
> the IEEE802 subtree. That document is now in Sponsor Ballot by the
IEEE-SA."
>
> so the vast majority of RFC5066 vanishes into IEEE and is transformed 
> therein.
>
> The bit that is left, ifCapStackMIB, is unaltered from RFC5066 (hence
the
> reuse of the number in the mib tree).
>
> I do not know what the best way to describe this in our documentation
is!
>
> As to Copyright, RFC5066 has one editor but the work was "greatly
advanced
> by the contributions of the following people"
> which lists eight such people, so no, I do not think that the editor
of
> RFC5066bis can make the necessary grant.
>
> RFC5066 predates the change of rules, increasing the grants, by a
year.
>
> Tom Petch
>
> >
> > Should the Copyright carry the caveat about old material for which
the
> > current rules may not apply?  Since this MIB Module is going to see 
> > extensive use by another SDO, this seems particularly relevant.
>
> the author of the old doc is the author of the new doc and is
submitting the
> new doc under the current rules (and gave himself permission to do
that)
>
> Scott
>
>
> > Tom Petch
> >
> >
> > ----- Original Message -----
> > From: "Romascanu, Dan (Dan)" <[e-mail]>
> > To: "Edward Beili" <[e-mail]>; <[e-mail]>
> > Cc: <[e-mail]>
> > Sent: Thursday, January 03, 2013 6:00 PM
> >
> >> Hi Ed,
> >>
> >>> 3. You probably meant "No action is required from IANA ..."
> >>
> >> Of course, thanks for catching this.
> >>
> >>
> >>> 4. Shall I wait for other comments or should I just issue the next 
> >>> version of the draft?
> >>>
> >>
> >> Let us wait for a couple of days. Hopefully we will get an answer
> from
> > Howard concerning a better reference for the IEEE 802.3.1a Rev 2
> draft,
> > and maybe other comments from the OPSAWG or the IEEE folks.
> >>
> >> Please issue a revised version by the start of the next week, as I
> > plan to enter my Sponsor Ballot comment on the IEEE document, and I
> need
> > a reference to the best IETF I-D available at that moment.
> >>
> >> Thanks and Regards,
> >>
> >> Dan
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Edward Beili [mailto:[e-mail]]
> >>> Sent: Thursday, January 03, 2013 7:55 PM
> >>> To: Romascanu, Dan (Dan); [e-mail]
> >>> Cc: [e-mail]
> >>> Subject: RE: comments on draft-ietf-opsawg-rfc5066bis-00.txt
> >>>
> >>> Dan,
> >>> Thank you for the comments, I agree with everything, except for
the
> >>> following:
> >>>
> >>> 2. I will leave the IEEE 803.2.1-2011 reference for now, until
IEEE
> >>> 802.3 would provide a publically accessible link.
> >>>
> >>> 3. You probably meant "No action is required from IANA ..."
instead
> > of
> >>> "New action is required form IANA ...", i.e. the correct paragraph
> > would
> >>> be:
> >>>
> >>> OLD:
> >>>
> >>>   Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have
> > been
> >>>   allocated by IANA in the MIB-2 sub-tree.
> >>>
> >>> NEW:
> >>>
> >>>   No action is required from IANA as the OID for ifCapStackMIB
> > MODULE-
> >>> IDENTITY
> >>>   was already allocated in [RFC5066].
> >>>
> >>> 4. Shall I wait for other comments or should I just issue the next 
> >>> version of the draft?
> >>>
> >>> Regards,
> >>> -E.
> >>>
> >>> -----Original Message-----
> >>> From: [e-mail] [mailto:[e-mail]] On
> > Behalf
> >>> Of Romascanu, Dan (Dan)
> >>> Sent: Thursday, January 03, 2013 17:59
> >>> To: [e-mail]
> >>> Cc: [e-mail]
> >>> Subject: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt
> >>>
> >>>
> >>> Thanks to Ed Beili for undertaking this work.
> >>>
> >>> A few comments:
> >>>
> >>> 1. In the Abstract you are making the statement that this
> > specification
> >>> moves the EFM-CU-MIB module to an IEEE document. In fact the IETF
> > does
> >>> not have the rights to do such a move alone, this document should
> > rather
> >>> just recognize this move.
> >>>
> >>> Suggested change:
> >>>
> >>> OLD:
> >>>
> >>>   It amends that specification by moving the entire EFM-CU-
> >>>   MIB module along with the relevant descriptive text, to a
> > separate
> >>>   document, maintained by the Institute of Electrical and
> > Electronics
> >>>   Engineers (IEEE) 802.3.1 working group.
> >>>
> >>> NEW:
> >>>
> >>>   It amends that specification by taking out the entire EFM-CU-
> >>>   MIB module along with the relevant descriptive text. That MIB
> > module
> >>>   will be part of a separate document, maintained by the Institute
> > of
> >>>   Electrical and Electronics Engineers (IEEE) 802.3 working group.
> >>>
> >>> Also in Section 1:
> >>>
> >>> OLD:
> >>>
> >>>   This
> >>>   version moves the entire EFM-CU-MIB module along with the
> > relevant
> >>>   descriptive text, to a separate document, maintained by the
> > Institute
> >>>   of Electrical and Electronics Engineers (IEEE) 802.3.1 working
> > group.
> >>>
> >>> NEW:
> >>>
> >>>   This version
> >>>   removes the entire EFM-CU-MIB module along with the relevant 
> >>> descriptive
> >>>   text. That MIB module will be part of a separate document,
> > maintained
> >>> by
> >>>   the Institute of Electrical and Electronics Engineers (IEEE)
> > 802.3.
> >>>   working group.
> >>>
> >>> 2. In Section 3.1:
> >>>
> >>>   The EFM-CU-MIB module defined in the previous version of this
> >>>   document, along with the relevant descriptive text, is now moved
> > to a
> >>>   separate, IEEE maintained document, IEEE Std 802.3.1-2011
> > [802.3.1],
> >>>   which also renamed the EFM-CU-MIB to IEEE8023-EFM-CU-MIB.
> >>>
> >>> - Instead of 'the previous version of this document' we should
just
> > say
> >>> [RFC5066].
> >>> - We should provide a more updated version of the IEEE standard
> > which
> >>> contains the IEEE-EFM-CU-MIB - the document now in Sponsor Ballot
> > would
> >>> be fine, but the access is restricted. I suggest to ask advice
from
> >>> Howard Frazier.
> >>>
> >>> 3. I suggest that Section 7 mentions that no (new) IANA actions
are
> >>> required because it's the same root already allocated in RFC 5066.
> >>>
> >>> OLD:
> >>>
> >>>   Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have
> > been
> >>>   allocated by IANA in the MIB-2 sub-tree.
> >>>
> >>> NEW:
> >>>
> >>>   New action is required from IANA as the OID for ifCapStackMIB
> > MODULE-
> >>> IDENTITY
> >>>   was already allocated in [RFC5066].
> >>>
> >>> Regards,
> >>>
> >>> Dan
> >>>
> >>>
> >>> _______________________________________________
> >>> OPSAWG mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/opsawg
> >> _______________________________________________
> >> OPSAWG mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/opsawg
> >>
> >
> >
> > _______________________________________________
> > OPSAWG mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/opsawg
>
>
>
> _______________________________________________
> OPSAWG mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsawg
>
>