Skip to main content

Shepherd writeup

Document: draft-ietf-opsawg-mibs-to-ieee80231 
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-
   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.


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

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?

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

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

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

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

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
Nope. No one cared <sob>

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

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

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

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