![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
At 19:17 27/09/2005, Brian E Carpenter wrote:
...
My proposition would be to create a "minority position" system. Where such groups could be accepted as opposing without having to be fighting.
There is a perfectly civilised way of handling minority opinions already.
Please see RFC 3246 and RFC 3248 for an example I was personally involved in. 3246 is the consensus and 3248 is the minority opinion.
Unfortunately not. RFC 3246 is Standard Track, RFC 3248 is informational. RFC 3246 is published.
They are both published, and obviously the consensus document is the one on the standards track. It exactly an example of the IETF publishing a minority opinion. Obviously, we couldn't publish two standards for the same bits.
This case is when two IETF groups have different opinions.
The case I refer to is when an SSDO consensus opposes an IETF-WG consensus,
That doesn't affect what the IETF publishes. The IETF publishes the documents that it reaches consensus on, after considering all contributions. Liaisons from other SDOs are considered. That doesn't mean we take them as instructions or have any obligations.
When we become aware of another SDO working on an alternative solution, we normally attempt to engage in dialogue, but there is no algorithm for how that dialogue will terminate.
while the Internet is no more a place where one can consider that an erroneous RFC supported by market leaders will quickly deprecate and not hurt.
The resources of the other SSDO are dedicated to its own business. It may however make the effort of a QA delegate to the Internet standard process. Experience shows that without an MoU a conflict may quickly develop (as if two foot-ball teams met, but one team would, in addition to be a challenger, have only one player present. This is all the more true if the results of the match counts for the world cup).
The "minority position" would avoid to enter into an SSDO/IETF complex MoU and liaison committee (I feel you are not found of anyway). All the more than the problem may be purely occasional and the solution be to politely pay attention to mutual needs rather than to ban the SSDO liaison. This can only be detrimental to a final common solution and would resolve nothing since the SSDO has human resources a plenty.
If people from another SDO wish to submit a draft for publication as an RFC, I can't see any reason why the "RFC 3248 approach won't work. I can't see any need to add more process than we already have.
Brian
_______________________________________________ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.