Re: Minority opinions [Re: [dean@av8.com: Mismanagement of the DNSOP list]]

"JFC (Jefsey) Morfin" <jefsey@jefsey.com> Thu, 29 September 2005 17:04 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL1pL-00022I-2H; Thu, 29 Sep 2005 13:04:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL1pH-000225-2U for ietf@megatron.ietf.org; Thu, 29 Sep 2005 13:04:09 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22712 for <ietf@ietf.org>; Thu, 29 Sep 2005 13:04:03 -0400 (EDT)
Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL1wy-0007XP-Fl for ietf@ietf.org; Thu, 29 Sep 2005 13:12:04 -0400
Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EL1p8-0006ns-8g; Thu, 29 Sep 2005 10:03:58 -0700
Message-Id: <6.2.3.4.2.20050929170129.05c90700@mail.jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Thu, 29 Sep 2005 17:47:23 +0200
To: Brian E Carpenter <brc@zurich.ibm.com>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
In-Reply-To: <433BD0B2.5030903@zurich.ibm.com>
References: <7D5D48D2CAA3D84C813F5B154F43B15508234B12@nl0006exch001u.nl.lucent.com> <20050927101144.GA33541@verdi> <6.2.3.4.2.20050927152614.04ca08c0@mail.jefsey.com> <43397EC1.3040009@zurich.ibm.com> <6.2.3.4.2.20050928150912.0565b020@mail.jefsey.com> <433BD0B2.5030903@zurich.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: ietf@ietf.org
Subject: Re: Minority opinions [Re: [dean@av8.com: Mismanagement of the DNSOP list]]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

At 13:32 29/09/2005, Brian E Carpenter wrote:
>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.

Dear Brian,
this is why we need to find ways to help consensual standard publication first.
The problem is worst if the document claims to be a BCP.

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

We should not be here to develop non-interoperability.
However we know that competition may lead to some oddities. This is 
the theme of RFC 3869.

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

"normally" should be replaced by "SHOULD".

All what I call for is not even to engage in a dialog, but to respect 
others and not refuse the dialog. And a way to politely but clearly 
address the possible non-technical motivations. I think an Ombudsman 
can help that. And that the minority position is the way to inform 
that he has been informed and taken the issue seriously. The impact 
is only to make the things even. Disfavors no one, helps everyone.

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

The RFC 3248 approach is internal to IETF.

Other SSDOs have their own charters and agenda. We are talking of 
interoperability. When IETF disregards others, it is lucky others pay 
attention and delegate a resource they need. Forcing others to become 
more competent in a whole IETF area they are not interested in to 
publish a document so "the better win", just to prevent a lobby from 
creating a profitable interoperability conflict with other commercial 
or non-profit/publicly funded SSDO, is not the way I see global 
networking. Please consider RFC 3869.

I may be wrong though.
jfc


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf