Re: [iucg] IETF IPR

JFC Morfin <jefsey@jefsey.com> Wed, 04 August 2010 22:46 UTC

Return-Path: <jefsey@jefsey.com>
X-Original-To: iucg@core3.amsl.com
Delivered-To: iucg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 071303A683F for <iucg@core3.amsl.com>; Wed, 4 Aug 2010 15:46:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.619
X-Spam-Level:
X-Spam-Status: No, score=-101.619 tagged_above=-999 required=5 tests=[AWL=1.121, BAYES_20=-0.74, GB_I_LETTER=-2, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvvk6HuCQpaR for <iucg@core3.amsl.com>; Wed, 4 Aug 2010 15:46:19 -0700 (PDT)
Received: from montage2.altserver.com (montage2.altserver.com [72.34.52.22]) by core3.amsl.com (Postfix) with ESMTP id EDE563A6407 for <iucg@ietf.org>; Wed, 4 Aug 2010 15:46:18 -0700 (PDT)
Received: from 29.179-225-89.dsl.completel.net ([89.225.179.29]:51657 helo=jfcmsc.jefsey.com) by montage2.altserver.com with esmtpa (Exim 4.69) (envelope-from <jefsey@jefsey.com>) id 1OgmjU-0005N5-Cp; Wed, 04 Aug 2010 15:46:45 -0700
Message-Id: <7.0.1.0.2.20100804214416.0574d4a0@jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Thu, 05 Aug 2010 00:46:42 +0200
To: Russ Housley <housley@vigilsec.com>
From: JFC Morfin <jefsey@jefsey.com>
In-Reply-To: <4C596C38.9000101@vigilsec.com>
References: <7.0.1.0.2.20100803125135.0723c4e0@jefsey.com> <4C596C38.9000101@vigilsec.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 - montage2.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-Source:
X-Source-Args:
X-Source-Dir:
Cc: "olaf M. Kolkman" <olaf@NLnetLabs.nl>, workon@idna2010.org, iucg@ietf.org, Marshall Eubanks <tme@americafree.tv>
Subject: Re: [iucg] IETF IPR
X-BeenThere: iucg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: internet users contributing group <iucg@ietf.org>
List-Id: internet users contributing group <iucg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/iucg>, <mailto:iucg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/iucg>
List-Post: <mailto:iucg@ietf.org>
List-Help: <mailto:iucg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iucg>, <mailto:iucg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Aug 2010 22:46:21 -0000

Dear Russ,
comments/responses embedded in the tetx.

At 15:33 04/08/2010, Russ Housley wrote:
>I do not think that this accurately describes the letter from Marshall.
>  I believe the issue is that you have made a derivative of the IETF logo.

Correct. And as I explained,  IMHO this derivative work abides by the 
fair-use rules.

>Further, the logo issue and IETF Trust copyright on RFCs have nothing to
>do with each other. The logo issue has to do with trademark protection.
>The IETF logo has been registered, and the IETF Trust has received
>legal guidance on the steps that must be taken to protect that trademark.
>
>Contributions to the IETF follow the rules as described in the NOTE
>WELL. See: http://www.ietf.org/about/note-well.html
>
>The NOTE WELL is not long, and it points all IETF contributors to the
>rules for making contributions to the IETF.

The NOTE WELL is not precise enough. We are interested in the IETF 
Trust copyright inbound/outbound rules from RFC and TLP. Marshall's 
position shows that "fair-use" is not enough for him.  His suggestion 
to formally concert over the IUCG logo, is for us a good 
example/warning that we should also formally concert over the copyright issues.

>As a member of the IAB, this is the first indication that you are
>considering work outside the four existing RFC streams.  If this is your
>desire, I suggest that you formally approach the IAB very promptly.

I did. The response to my appeal will tell us if this is necessary or not.

> > The first practical issue is the IETF RFC rigidity and lack of clear and
> > comprehensive content structure, while everyone can use and modify a
> > public domain document. We are not so much interested in specific RFCs,
> > but in a constantly tuned or updated, and stably structured, how-to/user
> > guide.
>
>RFCs are freely available to all.  The IETF standards process must be
>followed to make changes to Standards-Track documents.  That is
>necessary to manage a consensus process.  I find it very had to believe
>that the Internet community would be served by flexible modification
>structures.

We are talking here of the Internet Users community. A question 
technically raised by IDNA2008, the IESG has not addressed and the 
IAB will answer (in addressing it or in failing to address it) is to 
know if the IETF considers that the Internet and IETF deliverables 
Users Community and the Internet Community are the same community or not.

Basically, if they may have or not the same reading of what the 
Internet (down to the last bit) is.

> > The second one is the "IETF RFC 1958/RFC 3439/IDNA2008 Internet"
> > architectural border as it is now to be perceived according to the IAB.
> > So far, we believe that IDNA2008 deals with the "inbound",  that
> > IDNA2010 should address the "outbound", and that IDNA2012 should cover
> > its "roundbound" issues of the IUI (Internet Use Interface)
>
>I have no idea what "roundbound" means.

The "roundbound" neologism tries to refer to all what 
"inbound"  (towards internal system designers) and "outbound" 
(towards external users) do not refer to: what is specific 
(internally circular) to the peripheral smart IUI (Internet Use 
Interface). Please note that I make a difference between IUI which is 
implied by IDNA2008 and the Interplus as an architecture for that IUI.

>I have told you in the past, and I repeat it here, that your use of
>"IDNA" to mean something different than it means to the IETF community
>is making it far more difficult for you to communicate.  I strongly
>encourage you to select a name without that baggage for your activities.

Russ, I will refer to the IETF Journal. "The IAB is working on a 
document about internationalization-draft-iab-idn-encoding-that 
inspired the discussion led by John Klensin, Stuart Cheshire, and 
Dave Thaler. - Internationalization "is understood moderately well by 
a fairly small number of experts, most of whom end up realizing how 
little we actually understand," John said at the beginning of the 
talk. "But it affects a large number of protocols, a large number of 
people, and it should affect virtually everything we're doing in the IETF."

Let permit me to disagree with your statement. I do not know what 
IDNA means: this is up to the IAB to document it. I am interested in 
supporting the Intersem. All I know for sure from the reason why we 
reached the IDNA2008 consensus, from Lisa's questions, and from the 
expectations one may have from the current IAB Draft I certainly 
support, is that the IDNA moderately well understood by a small 
number of experts most of whom end up realizing how little they 
actually understand has certainly nothing to do with anything the 
IETF community has ever discussed.

The question precisely is: "does the IDNA area - i.e. the connection 
between DNS and users applications - belongs or not to the IETF 
scope?".  The IESG answered "no" in not wanting Lisa's questions to 
be addressed and in not responding/commenting my ITLD Manager 
questions/solutions. Namely, how two quasi orthogonal architectures 
like IDNA2003 and IDNA2008 should be  jointly used.

The ML-DNS is the response to the users needs, I announced I will 
document as 100% interoperable with IDNA2008. This was at the very 
beginning of the WG/IDNABIS once Vint officially answered that he did 
wanted to stay within the limits of the Charter and did not consider 
the WG/IDNABIS had to go that far, or even to consider its 
preparation. We disputed when I opposed that the WG could block the 
further ML-DNS. This eventually lead to the "Mapping" consensual document.

The WG/IDNABIS documents are 100% ML-DNS ready.

> > If we would like all of this to be technically, architecturally, and
> > technologically clear, it must first be organizationally clear. As you
> > have observed, TLR and RFCs have established the IAB as the focal point
> > where these issues are consistently and coherently addressed. This is
> > why we need to give them the possibility of an efficient (better
> > Internet/better Internet use) freeride strategy on the matter. This is
> > the prerquisite for us to knowledgeably investigate what may result in
> > the best return for ourselves and our fellow users.
>
>I have no idea what "freeride strategy" means.

IDNA2008 means a dramatic change in the understanding of the Internet 
as a component of the world digital ecosystem. This is equivalent to 
the switch from the heliocentric (networkcentric) to the cosmocentric 
(personcentric - more than user because of the permitted support of 
the semantic stratum) vision of the universe. It means that the 
development priority of the "Internet/Intersem" has switched from 
"growth" (larger and larger) to "multiplication" (more and more 
diversified). This did exist in the architecture but was considered 
at the fringe, not in the fringe. This has now clarified because in 
one of the typical area we freed from outside (Unicode) and from 
inside (mapping in the protocol). The "Mapping" WG/IDNABIS 
illustration document is the reason why we were bluntly able to 
switch from different determined oppositions to Vint Cerf, to a full 
consensus.

IESG accepted the WG consensus. Lisa did not posed too many questions 
and killed the "Mapping" document. Now the RFCs have been expedited 
and published - with no disclaimer. This is great because it means a 
definitive no return point for IDNA2008. This also is bad because 
this rigidify the situation, the IESG probably constraining the IAB 
decision. This leaves IAB to document the fundamental change in IDNA 
through their IDNA RFC or find a smart way out. The only thing I know 
is that they are on rough grounds in terra incognita. This is 
http://www.freerideworldtour.com/en/ like. For all of us, now RFCs 
are published.

jfc