|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
Thanks for the reference to RFC 7282. It was an interesting read, as are most IETF documents of this type. My conclusion was it said in more words what the ISO definition attempted to boil down to a single sentence. Both approaches are valuable.
The question of SIGs is a tough one. On one hand, I don’t believe IEEE 802 should attempt to restrict free association or private discussions, either at the bar or in a more formal SIG setting. On the other hand, I would really like to know about the details of any discussions between other parties if they are going impact consensus building in IEEE 802.
So I looked for a pragmatic “happy medium” that allows free association, but requires the existence of the association to be known, at least at a level consistent with current practice related to affiliations . The best I can come up with is that:
· (status quo) IEEE 802 operates a consensus building process as described in RFC 7282, or as defined by ISO
o This should mean anyone who has good technical arguments has any issues addressed by the group
· (status quo) Participants are required to reveal affiliations as a mechanism to avoid the worst excesses of domination
o Those participants who are unwilling to reveal affiliations are technically required to withdraw from the discussion; this is usually of most relevance to consultants who have signed an NDA
o Note: we do not require participants to reveal the details of discussion with their affiliations
· (extension to the status quo) Participants are required to reveal participation in formal SIGs to avoid the worst excesses of domination, similar to affiliations
o Those participants who are unwilling to reveal affiliations should be required to withdraw from the discussion; this will be of most relevance to participants in SIGs where there are signed NDAs
o We should not require participants to reveal the details of discussions within the SIGs, although in many cases they will want to do so to make a technical case as part of discussions towards consensus
o Note: I would define a “formal SIG” as any organisation based on any “formal (written or verbal) agreement”
You noted a potential problem if participants do not reveal their participation in a SIG because they do not speak at the microphone. I agree that this is a potential problem. However, as you also note, we have various mechanisms to deal with this if necessary in the context of affiliations, including recorded votes . I also note that in the 802.11 O&M (and probably others too) , a requirement of attendance credit is that one records their affiliations. We could extend this requirement to include participation in SIGs.
On 4/12/17, 6:41 PM, "Andrew Myles (amyles)" <firstname.lastname@example.org> wrote:
I think we will agree that the goal of IEEE-SA is forming consensus. It is worthwhile at this point quoting the definition of consensus (ISO defn)
General agreement, characterized by the absence of sustained opposition to substantial issues by any important part of the concerned interests and by a process that involves seeking to take into account the views of all parties concerned and to reconcile any conflicting arguments
My (our!) personal experience with ISO makes it somewhat less of an authority to appeal to. I'd
rather point to RFC 7282 which I invite you to read, but the actual definition of consensus is not
germane to this.
The nice thing about this definition is that it means the achievement of consensus by IEEE 802 is completely independent of any discussions that occur outside IEEE 802. The key for consensus from IEEE 802’s perspective is that as long as individuals within the IEEE 802 have an opportunity to express sustained opposition to substantial issues and there is a process that involves seeking to take into account the views of all parties concerned and to reconcile any conflicting arguments, there is no need to worry about any decision making processes outside the IEEE 802. The bottom line is that IEEE 802 doesn’t need to worry about agreements like NDAs between companies, it just needs to make sure the processes within the IEEE 802 promote consensus as defined above.
The issue about NDAs is that there is something secretive going on there and there is no reason
consensus building needs secrecy. So the fact that there's an NDA means that something else
besides consensus building is going on and that is the problem. So I would emphatically disagree
with you that "IEEE 802 doesn't need to worry about agreements like NDAs." Yes they do. They
most certainly do.
The fact that there's an NDA between companies in a formal SIG means that IEEE 802 cannot
ensure the process promotes consensus!
That said, I believe IEEE-SA has already established a precedent by requiring individual to declare affiliations, presumably as a way of guarding against the risk of block voting. I note that IEEE 802 does not require individuals to reveal details of any discussions with their affiliations. Using this as an analogy, there might be a case to require individuals to declare any association, either directly or through their affiliations, with organisations that have at least a partial purpose of discussing or influencing IEEE 802 standards developments. An organisation could be defined as any entity formed by formal agreement of any sort.
Affiliation only needs to be declared when speaking at the mic or if there is a recorded vote.
Voting in IEEE 802.11 (other TGs mileage may vary) is generally, "those in favor raise your voting
tokens…those opposed raise your voting tokens…those abstaining raise your voting tokens" with
no affiliation mentioned.
Interestingly, this would probably include the Wi-Fi Alliance, and many other similar ITAs, which just makes the whole idea of declarations incredibly complex and unwieldy. Maybe we shouldn’t bother and just focus on making sure IEEE 802 (or IEEE-SA) provides an environment that encourages true consensus. Hmmmm!
Actually, no, it would not include Wi-Fi Alliance because Wi-Fi Alliance is not in the business of
amending IEEE 802 standards. It takes the IEEE 802.11 standard and certifies implementations,
and sometimes it develops its own protocols which use IEEE 802.11 in the manner defined in
the standard. Completely different.
Since you are defending the use of NDAs in order to achieve consensus maybe you could explain
why this process needs to be done in secret, hmmmmm?
I think the key is NDAs. Two guys meeting in the bar to solve a problem is not the issue. An ad
hoc meeting of members outside of an 802 meeting to discuss how to reach consensus should
not be a problem. Neither of these would really involve NDAs. Problems arise when the activities
of the members of this group are secret.
We want to encourage consensus forming but If the goal of a group is consensus forming then
NDAs and secrecy have no place. Bad things happen in secret.
Regarding a need to declare if you are participating in a SIG, if we were to make that requirement, we would also need a definition of a SIG. Does anybody want to propose one?
IMHO this is not trivial, as there is a continuum of formality and inter-dependency, that goes from one extreme of two people meeting in a bar to solve a problem raised in a task group earlier that day to the other extreme of an incorporated legal entity with NDAs and member agreements.
And, please remember, what we care about is (potential) dominance. Two people meeting in a bar are unlikely to dominate unless there are three in their task group. Two people meeting secretly under NDA likewise.
So perhaps any definition should not relate to the character of the SIG, but its potential impact on a task group, which can be measured in size of membership relative to the activity they are contributing to.
IEEE 802.11 Working Group Chair
Phone: +1 (971) 203-2032
Mobile: +1 (210) 268-6451 (when in USA)
Mobile: +44 7342178905 (when in the UK)
On 2017-04-12 00:49, Andrew Myles (amyles) wrote:
---------- This email is sent from the 802 Executive Committee email reflector. This list is maintained by Listserv.