Re: [Ianaplan] [IAB] one final last call comment on, etc.

Jefsey <jefsey@jefsey.com> Mon, 22 December 2014 00:12 UTC

Return-Path: <jefsey@jefsey.com>
X-Original-To: ianaplan@ietfa.amsl.com
Delivered-To: ianaplan@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C131A0053; Sun, 21 Dec 2014 16:12:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.231
X-Spam-Level:
X-Spam-Status: No, score=0.231 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6, MISSING_MID=0.497] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54RyuzPjjZX2; Sun, 21 Dec 2014 16:12:12 -0800 (PST)
Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A5B01A005D; Sun, 21 Dec 2014 16:12:12 -0800 (PST)
Received: from 180.102.176.95.rev.sfr.net ([95.176.102.180]:32758 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.84) (envelope-from <jefsey@jefsey.com>) id 1Y2qbX-0005d6-Q2; Sun, 21 Dec 2014 16:12:08 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 22 Dec 2014 01:11:57 +0100
To: Andrew Sullivan <ajs@anvilwalrusden.com>, ianaplan@ietf.org
From: Jefsey <jefsey@jefsey.com>
In-Reply-To: <20141219055901.GA40629@mx1.yitter.info> <20141219061357.GB40629@mx1.yitter.info>
References: <548E9814.1090208@cisco.com> <20141215114537.3FEAE1A1B5E@ietfa.amsl.com> <20141215165037.GH29830@mx1.yitter.info> <20141217031325.9A3DD1A1B25@ietfa.amsl.com> <5491AB6E.2040109@qti.qualcomm.com> <20141219055901.GA40629@mx1.yitter.info> <548E9814.1090208@cisco.com> <20141215114537.3FEAE1A1B5E@ietfa.amsl.com> <20141215165037.GH29830@mx1.yitter.info> <20141217031323.D28661A1B12@ietfa.amsl.com> <20141219061357.GB40629@mx1.yitter.info>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host.presenceweb.org
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/w-mh68EbPXCV2sUZTMIIKrnva9M
Cc: "Leslie Daigle (TCE)" <ldaigle@thinkingcat.com>, Eliot Lear <lear@cisco.com>, Pete Resnick <presnick@qti.qualcomm.com>, Marc Blanchet <Marc.Blanchet@viagenie.ca>, IAB <iab@iab.org>, iesg@ietf.org, Adrian Farrel <adrian@olddog.co.uk>
Subject: Re: [Ianaplan] [IAB] one final last call comment on, etc.
X-BeenThere: ianaplan@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IANA Plan <ianaplan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ianaplan/>
List-Post: <mailto:ianaplan@ietf.org>
List-Help: <mailto:ianaplan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Dec 2014 00:12:15 -0000
X-Message-ID:
Message-ID: <20141222001221.10263.30138.ARCHIVE@ietfa.amsl.com>

At 06:59 19/12/2014, Andrew Sullivan wrote:
>M Morfin,
>
>On Fri, Dec 19, 2014 at 02:10:02AM +0100, JFC Morfin wrote:
> > - Andrew is honestly speaking for his business community 
> (<http://dyn.com/blog/andrew-sullivan-ietf-iab-internet-architecture-board-dns/>http://dyn.com/blog/andrew-sullivan-ietf-iab-internet-architecture-board-dns/)
> > and the people who entrusted him with their livenood.
>
>For the record, I am not, and I thank you to stop promoting falsehoods
>about my intentions.


Dear Andrew,
I thank you for this clarification.

- I was, therefore, wrong in presuming that you were technically 
trustworthy in the way that ***I*** understand technical 
trustworthiness in the RFC 6852 paradigmatic wake.
- rather than in the RFC 3935 you seem to consider as the reference 
and ***I*** read as no longer fully appropriate.

This means that I definitely did not understand you: my sincere 
apologies. No offense was intended. To the contrary.

At 07:13 19/12/2014, Andrew Sullivan wrote:
>[many cc:s trimmed]
>
>M. Morfin,
>
>I will not dignify your unsubstantiated smears about me with a
>response.

Again no offense intended.

Things only get to be tuned when adjusting to a cultural transition 
from a doxa formation open process by "rough consensus" (RFC 3935) to 
an omnistakeholder emergence by "broad consensus" (RFC 6852).

>   But a couple items in your note do require a reply.

This is more interesting indeed as it concerns this very cultural transition.

>On Wed, Dec 17, 2014 at 04:13:05AM +0100, Jefsey wrote:
>
> > Unfortunately, you accepted to be the shepherd of a document 
> making the IETF
> > decision on a point you disagree we should agree.
>
>I'm sorry, but the shepherd does not make any "IETF decision".  The
>shepherd runs the document through the process.  Consensus is still
>determined by the chairs.

You are absolutely correct. I wrote that the ***document*** makes the 
IETF decision, after a rough consensus process. You are both the 
shepherd who runs the document through that process but at the same 
time one of the parties. This puts you in an unfortunate position. 
This is something that may now happen more often in a permissionless 
omnistakeholder context. The IAB should take this as an experience 
and avoid that kind of COI in the future.

> > This seems to be in contradiction with the RFC 4858 letter and spirit.
>
>I don't know why you say that, but perhaps indicating specific text in
>RFC 4858 that I have violated would help me.

The preceding point means that RFC 4858 should be one of the many 
RFCs to adapt to the modern paradigm for standards.

> > >Some participants said they didn't understand it.  Others
> > >said it was irrelevant to the WG's work.
> >
> > I hope this was intended to purposely hurt Libre's contributors.
>
>[I read your "not" from the other message in this.]  It was not, of
>course.  I am sorry if it is hurtful to people who worked on that
>contribution, but I believe it is my responsibility to report the
>remarks from the WG as I understand them.  I think the archives will
>indicate that what I said is true.

Again, there is nothing personal.

What is concerned is the now inadequate IETF standardization process 
in the post RFC 6852 and post March 14, 2014 announcement context 
required by that RFC. Moreover since the matter at hand is the way 
the IETF is adapting to the change.

I note that this can only be a recursive process since you cannot 
document something you have not fully experienced yet and you do not 
fully agree with (yet?).

> > >The shepherd write-up does not have to mention everything anyone ever
> > >said about a document, because if an observation did not produce any
> > >appreciable effect on the WG's discussion then it cannot be taken to
> > >be a point of serious consideration by the WG.  The IESG knows where
> > >the WG archives are; if they want a blow-by-blow review of the WG's
> > >discussions, they can read those archives.
> >
> > OK. Now you are laughing at IESG.
>
>I am not laughing at the IESG; I am rather trying to make their burden
>lighter.

I was trying to take it lightly. Do you fully realize that, since 
their burden is to decide, it means that one way or another you are 
actually trying to influence their decision?

>I do not believe I misrepresented anything that occurred in
>the WG, and if you think I did I should like very much to know what it
>is.

I told about this already. You did not indicate that I intended to 
file an appeal. Jari did not hide it. However, I fully understand 
that explaining it and stating why is not that easy since it concerns 
a new standardization general paradigm, the document you are 
shepherding, is attempting to adapt the IETF to via … a status quo.

>I have stated why I did not include a reference to your
>particular comment.  I _also_, note, did not include any reference to
>particular comments I made during the WG efforts; that includes not
>mentioning any of the times where I did not agree with the WG's
>conclusions.  The shepherd report does not include every single thing
>that anyone ever disagreed with, but only those cases about which
>there was substantial disagreement.  Your contribution -- which
>admittedly might have got rather more attention if it had been
>submitted to the I-D repository in the usual way

This IS a VERY good point.

1. my initial move was to submit one, actually two, I-Ds. This was 
blocked by the cut-off.
2. then my Libre group made the point that I was introducing our 
competing permissionless innovation and that using an IETF I-D was 
putting it under the BCP 78 terms, i.e. not a Libre CC license.

This shows that the "IETF usual way" is not adapted to a multi-SDO 
omni-stakeholder permissionless innovation coopetition. A non-IETF 
Trust stream should be considered.

>  -- had for practical
>purposes no effect on the WG's discussions.  I don't see why it needs
>to be mentioned at all in any report.

Because what is actually discussed through the I-D is the why you 
should see the need/or not to mention it.

I did not contribute in order to influence the WG's position. I did 
so in order to be able to question ISOC: is an IETF culture where my 
kind of contribution has no influence, the kind of culture they wish 
for the IETF to have, in our new post-6852/NTIA announcement context?

Again, there is nothing personal here. There is a cultural 
fundamental evolution: this I-D in the RFC 6852 and NTIA announcement 
wake is creating an IETF fork. This fork is between the RFC 3935 IETF 
and the post RFC 6852/Dubai/NTIA announcement/NMI RFC 3935bis IETF.

There are many other implied stakeholders who would like/need to 
understand about the RFC 3935bis propositions. Otherwise, the 
technical concertance (see above) that will emerge will take more 
time and will not directly include the IAB/IETF, clean room 
redesigning/morphing that the internet has engaged.

We both are bound by the Chairs' decision to read the Charter as the 
mission to address that fork in changing nothing. This risks 
transforming a regular evolution into a stupid conflict. IMHO, this 
is what the NTIA asked the ICANN to help prevent.

I am sorry again for the misreading. I see that you have removed the 
Dyn Inc. quote I gave the URL. IMHO all this was perfectly correct; 
we live in a real world and as the internet becomes more and more a 
key part of this word, the IETF MUST adapt to this world, not the 
world to the IETF.

jfc