Re: Last Call: <draft-yevstifeyev-disclosure-relation-00.txt> (The 'disclosure' Link Relation Type) to Informational RFC

John C Klensin <john-ietf@jck.com> Wed, 04 January 2012 02:21 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB6421F857B; Tue, 3 Jan 2012 18:21:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.572
X-Spam-Level:
X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeHQj2vKF4Uy; Tue, 3 Jan 2012 18:21:43 -0800 (PST)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 30E0F21F8575; Tue, 3 Jan 2012 18:21:42 -0800 (PST)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1RiGU1-000NSZ-WF; Tue, 03 Jan 2012 21:21:42 -0500
Date: Tue, 03 Jan 2012 21:21:41 -0500
From: John C Klensin <john-ietf@jck.com>
To: Mykyta Yevstifeyev <evnikita2@gmail.com>
Subject: Re: Last Call: <draft-yevstifeyev-disclosure-relation-00.txt> (The 'disclosure' Link Relation Type) to Informational RFC
Message-ID: <D11CC5F5273B80FD222E1E42@PST.JCK.COM>
In-Reply-To: <CADBvc9-=pjdWLA2KFYhvgZSWusPnu13e=c-4aOTfMxkN5igOTQ@mail.gmail.com>
References: <4EFC88F5.4070106@gmx.de> <CADBvc9-qjHWRVpkTxU76gv7zjPRstwFMM4tDWWzgh6ChDjvhMQ@mail.gmail.com> <4F006633.1040800@gmx.de> <CADBvc983dM+qqz6fHYG4Ng2mydnK=VVHA8nVPHgEF5eZwrEAeQ@mail.gmail.com> <ABBF6695-5C12-4CAB-95F2-A686BCFB74DE@w3.org> <d1s0g7p7cmf0haj40q1jg9cimhp5u6m1rn@hive.bjoern.hoehrmann.de> <DF610683-C3D3-42D7-8E5A-32C3CF687E34@w3.org> <4tu0g7d98h4st9ejgs32son1tldca2p0l9@hive.bjoern.hoehrmann.de> <A5625951-8077-42CA-B151-571028D69B8C@w3.org> <ic51g71h41j1lcl7ogl9m7qk0fca2i9pjv@hive.bjoern.hoehrmann.de> <4F00A5DF.3090605@gmx.de> <75C7A8A2BD7D3D528DF8DF0C@192.168.1.128> <CADBvc9-=pjdWLA2KFYhvgZSWusPnu13e=c-4aOTfMxkN5igOTQ@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Cc: ietf@ietf.org, iesg <iesg@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Jan 2012 02:21:47 -0000

--On Monday, January 02, 2012 09:36 +0200 Mykyta Yevstifeyev
<evnikita2@gmail.com> wrote:

>...
>> I believe that the IESG ought to take exceptional care with
>> individual submissions, precisely because they are published
>> in the IETF stream, requiring significant expertise or careful
>> reading to determine whether they actually represent informed
>> and competent IETF consensus.  Against that test, this
>> document is not ready for approval and RFC publication.  
>> Specific examples:
>> 
>>        (1) The second sentence of the Introduction begins
>> "This        document specifies a new type of such
>> relationship...".        But this is not "new": it has
>> been around for years, as        the next paragraph (and
>> comments on the IETF list)        indicate.
> 
> It's "new" in context of being formally registered.

Then say that it specifies a registration for something that has
been around for a while, not that it is "new".

>>        (2) The last paragraph of the Introduction reads:
>> "This        document is to formally register the
>> 'disclosure' Link        Relation Type with IANA and
>> provide a permanent record        on it for the Internet
>> community.  Additionally, it        expands the sphere
>> of this relation type to allow its        use when
>> referring to separate patent disclosures."  So        it
>> registers the type (good, IMO); makes a permanent and    
>>    public record --which the author believes W3C has failed
>>        to do (good, IMO); documents the existing practice
>> (also        good, IMO); and creates an untested
>> extension (outside        the scope of Informational
>> publication of an existing        practice, IMO).

> So do you propose dropping the semantics for separate
> disclosures and leaving the original W3C's?

I propose that you figure out what you want to do, that you be
very explicit about what (if anything) is new and what is
existing practice, and that you get out a new I-D that says
whatever you intend.   If you are asking me the substantive
question, I think that, if you are going to propose an
extension, you are obligated to be very clear what the extension
is and to do a careful review of what issues might arise with
it.  I'm not sure I have an opinion about whether the extension
is a good idea -- I need that information to figure it out and I
think it is your obligation to supply it.

I think what I'm saying here is consistent in general
principles, if not in detail, with Peter's recent note -- making
what you are proposing clear is your responsibility.  Please
don't ask the community to spend time on review until you have a
very specific and clear proposal with which you are satisfied.

>...
>>        (4) While it is not unusual for Acknowledgments
>> sections        to be updated during or after Last Call,
>> an entry of        <TBD> for the only contributors to the
>> document make it        impossible for the community to
>> verify that the BCP78        requirements have been
>> followed.
> 
> <TBD> occurred because there were no comments received before
> LC; but now, I hope, this may be corrected.

Then get a new I-D posted (see Peter's note).

>> I think this document could be cleaned up and made ready for
>> publication by using any of the following three options:
>...
>> (iii) Modify this document to be _extremely_ clear about what
>> is existing practice and what is the author's suggestion
>> about an extension.  For the latter, the change being made,
>> the justification for it, and a risk analysis should be
>> present and explicit.
> 
> While that was me who proposed the change to semantics, I tend
> more and more to agree with documenting the existing practice;
> but let's wait a response from W3C community first to see
> what's their attitude towards the proposal.

Documenting the existing spec would work for me (but so would
doing so and adding a well-vetted and well-documented
extension).  I do suggest that you not "wait" for a response
from W3C but that you try to actively engage with them, seeking
help from Thomas, Julian, Mark, or others as appropriate.

best,
    john