MIB Transfer from the IETF to the IEEE 802.3 WG
draft-ietf-opsawg-mibs-to-ieee80231-01

[Ballot discuss]
This strictly a DISCUSS to make sure I understand the process going forward.  Will any of the RFCs listed in section 2 need to have their status changed to Historic?  Can we mark an RFC as being obsoleted by an IEEE spec?

[Ballot comment]
As I can't find anything to complain about in this most straightforward of documents, I'll have to whine about stuff in the shepherd writeup.

  The feedback received was integrated and the
  feedbacker (sic) states he is happy with the changes.

That should be "feederbackerer".  And who you calling sic?

  Nope. No one cared

What does Scott Bradner have to do with this?

  It's also in my favorite font...

Wingdings?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-opsawg-mibs-to-ieee80231-01, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Transferring MIB Work from IETF Ethernet Interfaces and Hub MIB WG to IEEE 802.3 WG) to Informational RFC


The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document:
- 'Transferring MIB Work from IETF Ethernet Interfaces and Hub MIB WG to
  IEEE 802.3 WG'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-11-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document records the transfer of responsibility for the
  Ethernet-related MIB modules DOT3-OAM-MIB, SNMP-REPEATER-MIB, POWER-
  ETHERNET-MIB, DOT3-EPON-MIB, EtherLike-MIB, EFM-CU-MIB, ETHER-WIS and
  MAU-MIB from the IETF to the IEEE 802.3 Working Group.  This document
  also describes the procedures associated with the transfer, in a
  similar way as RFC 4663 which records the transfer of the IETF Bridge
  MIB work to the IEEE 802.1 Working Group.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-opsawg-mibs-to-ieee80231/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-opsawg-mibs-to-ieee80231/ballot/


No IPR declarations have been submitted directly on this I-D.

Document: draft-ietf-opsawg-mibs-to-ieee80231
WG: OpsAWG.
Shepherd: Warren Kumari

This version of the writeup is dated 24 February 2012.

(1) Informational - this document provides information for the Internet
community. It documents that the IETF transitioned some MIBs to the IEEE.
No muss, no fuss.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:
  This document records the transfer of ownership of the Ethernet-
  related MIB modules DOT3-OAM-MIB, SNMP-REPEATER-MIB, POWER-ETHERNET-
  MIB, DOT3-EPON-MIB, EtherLike-MIB, EFM-CU-MIB, ETHER-WIS and MAU-MIB
  from the IETF to the IEEE 802.3 Working Group.  This document also
  describes the procedures associated with the transfer, relying
  heavily on RFC 4663 (which records an earlier transfer to the IEEE
  802.1 Working Group) as the primary source.

Working Group Summary:
This documents transfers that have already occurred.

Document Quality:

The document is well written and clear. The large majority of document
is simply a list / table of the IETF source document, the IEEE name and
location of MIBs that we transitioned to the IEEE.

Personnel:

Warren Kumari will be the document shepherd.
Benoit Claise will be the AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd:
I read the document and followed the links. There isn't much else that could
be checked.
There was a missing 't' at the end of a URL, which has been addressed.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
There was (as expected) not very much feedback on this document. It
is basically administrivia.

Dan Romascanu (one of the authors) forwarded this to David Law (Chair
of IEEE 802.3) and the ieee_ietf coordination list. David who
"reviewed the document and have no comments" -
http://comments.gmane.org/gmane.ietf.opsawg/3566


We see no need
for more review on a factual documentation of history.

(5) Do portions of the document need review from a particular or from
broader perspective?
Nope.


(6) Describe any specific concerns or issues that the Document
Shepherd has with this document.
None.


(7) Has each author confirmed all appropriate IPR disclosures?
Yup!


(8) Has an IPR disclosure been filed that references this document?
Nope!


David Harrington said:
-------
I reviewed this document.
This document references a lot of the material in RFC4663.
As the author of RFC4663, from my perspective, it is good to go.

The IESG write-up should probably include discussion about copyright and
IPR.
RFC4663 discusses legal concerns about copyright and IPR for the bridge MIB
modules; this document merely references RFC4663.
I believe this is adequate, given what we found when considering the
transfer documented in RFC4663.
1) The IETF retains the original copyrights granted by the authors, for both
publication of the IETF versions of the document and any derivative works
done within the IETF standards process.
The IEEE needs to get permission from the authors to develop derivative
works.
This is between IEEE and the authors and does not involve the IETF.
2) Any IPR claimed against the IETF version remains relative to the IETF
versions.
The IEEE has its own rules for declaring IPR related to IEEE documents, and
the need to declare IPR related to the IEEE versions is between IEEE and the
IPR holders.

David Harrington
ietfdbh@comcast.net
-------
(http://www.ietf.org/mail-archive/web/opsawg/current/msg03559.html)

Figured I should mention this to y'all.

(9) How solid is the WG consensus behind this document?
There was almost no discussion on this document. Due to the nature
of the document this is to be expected.
The feedback received was integrated and the
feedbacker (sic) states he is happy with the changes.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?
Nope. No one cared


(11) Identify any ID nits the Document Shepherd has found in this
document.
None.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Nope. It references a bunch of MIBs that we transfered to the IEEE. If you
*really* want, you could go check those and heap derision upon them if
you find any errors, but that feels like it would end badly for all...


(13) Have all references within this document been identified as
either normative or informative?
Sure have. They are all informative...


(14) Are there normative references to documents that are not ready
for advancement?
Nope, Not a single one...


(15) Are there downward normative references?
Nope.


(16) Will publication of this document change the status of any
existing RFCs?
Nope.


(17) Describe the Document Shepherd's review of the IANA
considerations section.
The document requires no actions from the IANA. This section is really short,
well written and all the words are correctly spelt.
It's also in my favorite font...


(18) List any new IANA registries that require Expert Review for
future allocations.
None.