[Internal-cg] Proposal finalization process v4
jari.arkko at piuha.net
Wed Dec 10 09:31:56 UTC 2014
I think this version looks OK. I did have two observations, however. The first one is related to establishing community opinions:
In Section 1 you mention “obtained consensus”, and I wanted to point out that the various communities have more fine-grained concepts relating to their decision processes. The obvious example is IETF’s rough consensus model. I expect that this is recognised by the ICG despite the brief reference of the consensus term. I think the real question is whether the proposals achieved consensus as defined in those community’s processes. Which probably includes both the actual (rough) consensus in the community but also some formal steps (like at the IETF, we have last calls, steering group approvals and so on). Actually if you can make the change s/obtained consensus/obtained consensus (as defined in that community’s process)/ this would probably be clearer to everybody.
In Section 2, you say "Do they suggest any arrangements that are not compatible with each other”. As I think I’ve said in the past somewhere, it is not necessary to have alignment on everything under the sun, what matters is alignment on aspects that have an interaction. For instance, does IETF and naming communities agree on the handling of special purpose names, which is one of the areas where there is an interaction. However, compatibility is not required on other things. As a trivial example, the allocation of new TLDs and the allocation of port numbers are very different processes, and do not need to be aligned. I’d s suggest a change, e.g., s/not compatible with each other/not compatible with each other (but need to be)/.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Internal-cg