Subject: [ieee-ietf-coord] FW: Call for Review of draft-iab-rfc4441rev-04.txt, "The IEEE 802 / IETF Relationship"

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 6 Jun 2013 10:56:16 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of IAB Chair
Sent: Wednesday, June 05, 2013 9:50 PM
To: IETF Announce
Cc: IAB; IETF
Subject: Call for Review of draft-iab-rfc4441rev-04.txt, "The IEEE 802 / IETF Relationship"

This is a call for review of "The IEEE 802 / IETF Relationship"
prior to potential approval as an IAB stream RFC.

The document is available for inspection here:
https://datatracker.ietf.org/doc/draft-iab-rfc4441rev/

The Call for Review will last until 20 June 2013.
Please send comments to [email-masked]<mailto:[email-masked]>.

On behalf of the IAB,
  Russ Housley
  IAB Chair

---

From: "Norman Finn (nfinn)" <[email-masked]>
Date: Thu, 6 Jun 2013 20:14:28 +0000

Dan,

Looking good!  Detailed comments:

Section 3.1.1, IEEE 802  organization

To the end of the paragraph starting, "Participation in IEEE 802 Working Groups is at the level of …" I would add, 'Appeal procedures are available to prevent an organization from "packing" a Working Group.'

Section 3.1.4, Consensus:

In the first part, on IETF, I think it would be worth mentioning that "consensus" is determined by the chair, but my participation in IETF meetings has not been extensive enough to offer that as more than a suggestion.

On the other hand, I don't think that the last sentence, "IEEE 802 consensus is usually based on percentage of voting approval." conveys a useful picture.  I'd suggest:

Although IEEE Working Groups ultimately relay on voting for decision making, they vary widely in their use of consensus versus voting in the course of a meeting, and in their attention to Robert's Rules.

Section 3.1.4, Voting:

I'm not crazy about the simple distinction, "Both organizations use voting as a decision-making tool, but IEEE 802 uses voting within working groups, while IETF working groups do not use voting."  I'd suggest:

Both organizations using voting as a decision-making tool.  IEEE 802 Working Groups vary in their reliance upon voting versus consensus, and in the breadth of coverage of an individual motion, but ultimately, all rely upon a 75% vote to decide technical issues, and a 50%+1 vote to decide other issues.  <IETF explanation follows>

Section 3.4.1 and Section 3.4.2: <editorial> Headers are not boldface.

I think a new section 3.4.1.4 is needed, titled, "Ballot resolution", perhaps as follows:

At each level, the relevant group (Task Group for TG ballots, Working Group for WG and Sponsor ballots) examines the ballot comments and determines their disposition.  The editor (or editorial team) may prepare proposed dispositions.  Task Group procedures vary, but at the Working Group level, the Working Group must vote 75% to approve the final ballot disposition in order to advance the document.

-- Norm

From: <Romascanu>, Dan Romascanu <[email-masked]<mailto:[email-masked]>>
Date: Thursday, June 6, 2013 03:56 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [ieee-ietf-coord] FW: Call for Review of draft-iab-rfc4441rev-04.txt, "The IEEE 802 / IETF Relationship"

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of IAB Chair
Sent: Wednesday, June 05, 2013 9:50 PM
To: IETF Announce
Cc: IAB; IETF
Subject: Call for Review of draft-iab-rfc4441rev-04.txt, "The IEEE 802 / IETF Relationship"

On behalf of the IAB,
  Russ Housley
  IAB Chair

---

From: "Riegel, Maximilian (NSN - DE/Munich)" <[email-masked]>
Date: Sun, 16 Jun 2013 12:26:16 +0000

Hi Dan,

Thanks for making us aware of the call for review. Overall it is a well-written documents, which provides plenty of insights into each other organization's operation.

However I have the feeling that we are still missing essential information for the cooperation between the two organization. I would like to add an 'object-oriented' view in addition to the procedural view of the document.

The objects in our organizations are the contributions, draft specifications and standards, but also down to a more fine grain level the information elements in the protocols.

In the IETF submissions (I-Ds) may be individual or by WG, and they all expire after 6 months. There is no defined expiry date for submissions in IEEE 802, and type of submissions is much more diverse and depends on WG level decisions - how can IEEE 802 reference an IETF submission, when the submission does not exist anymore after 6 months?

Standards in IETF stay forever, however standards in IEEE 802 have a limited life time, but often they are revised before expiry - what is happening when an IETF RFC makes a reference to an IEEE 802 standard, which is expired?
Also IETF revises standards and obsoletes the superseded ones. How can IEEE 802 learn about the standards revisions in the IETF, and how should IEEE 802 treat references to 'obsolete' RFCs? At least, due to the limited lifetime of IEEE 802 standards, the inconsistency would not last forever.

IETF has a classification of its RFCs (standards) into 'informational', 'experimental', 'standards track', 'BCP'. IEEE 802 does not have such strict classification of its standards, but has similar possibilities to denote specifications when the content is less normative.

The current text does not contain much information on the 'objects' structures and lifecycles. Only providing hints how to retrieve the documents does not seem to be sufficient to me.

An even more complicated domain are the attributes of the technology of one organization carried within protocols of the other organization, e.g. IEEE 802 link layer status or configuration values within IETF IP protocols. Appendix A provides two current examples without giving guidance for other cases.
As it touches an important aspect of OmniRAN ECSG, I will shortly submit an I-D providing a more comprehensive view on the issues, and I will create a couple of slides for the upcoming IEEE 802 session.

Some smaller issues I found in the document:

n  1. Introduction and Scope

"This document is non-normative, and is intended to improve practices for cooperation between the two organizations that are already in place"
Why limited to 'that are already in place'? I would propose to remove this limitation.

n  2. Why Cooperate?
I miss a very basic statement here that the two organizations are making extensive use of the other organization's results.

n  3.3.1.2 Access to internal IEEE 802 Working Group Documents
No links nor pointers provided for IEEE 802.3. At least a pointer to the IEEE 802.3 home page on www.ieee802.org<http://www.ieee802.org> would be required.

n  6.3 IEEE 802 Registration at IEEE 802 working group level
It would be good to provide more details on the existence and access to the IEEE 802 WG RACs. Just pointing to the WG chairs for further information is IMHO somewhat weak for an open standardization organization.

Bye
Max

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Romascanu, Dan (Dan)
Sent: Thursday, June 06, 2013 12:56
To: [email-masked]
Subject: [ieee-ietf-coord] FW: Call for Review of draft-iab-rfc4441rev-04.txt, "The IEEE 802 / IETF Relationship"

On behalf of the IAB,
  Russ Housley
  IAB Chair