Re: [Gen-art] GenART review of draft-yevstifeyev-disclosure-relation-00

Mykyta Yevstifeyev <> Wed, 21 December 2011 19:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 027C721F8496 for <>; Wed, 21 Dec 2011 11:11:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aYuzeu3nXDeQ for <>; Wed, 21 Dec 2011 11:11:09 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 24A0721F8495 for <>; Wed, 21 Dec 2011 11:10:51 -0800 (PST)
Received: by obcuz6 with SMTP id uz6so3901830obc.31 for <>; Wed, 21 Dec 2011 11:10:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lqGcrTJWG3lbpR7WPisOJuSvVDycVS+VRRUMPcj3QhM=; b=rFSPJt+4Gp8eqFomv8PfpOZGWGYleLN9+eMLQOYMwyb6FLYSlHCr/mPRAXZugYKEAs RpxbigtyfPbWcD8E6jVhGEMfybHmIFOAS90np7a4nWvk2IczvBlaUYpjGneu2RtBFVvx abGggSTieW5+lRMfNyqB9VE3CVIOxPGGHbfOw=
MIME-Version: 1.0
Received: by with SMTP id rw7mr6679405obc.70.1324494648806; Wed, 21 Dec 2011 11:10:48 -0800 (PST)
Received: by with HTTP; Wed, 21 Dec 2011 11:10:48 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Wed, 21 Dec 2011 21:10:48 +0200
Message-ID: <>
From: Mykyta Yevstifeyev <>
To: Martin Thomson <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Gen-art] GenART review of draft-yevstifeyev-disclosure-relation-00
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Dec 2011 19:11:11 -0000

2011/12/18 Martin Thomson <>:
> My concerns over motivation could be addressed by changing the
> introduction to remove the dependency on [W3C-PUBRULES] and providing
> a generic motivation.
> More inline.
> On 17 December 2011 17:20, Mykyta Yevstifeyev <> wrote:
>> The Intended status is Informational.
> That much is clear from the first page of the draft.  I can't see any
> reason for why Informational was chosen over Proposed Standard.  Can
> you share one?

Well, I don't see enough motivation for Standards Track, so I've
chosen Informational.  Moreover, there are 2 other relation types
documents which bear Informational status, and so does RFC 5829.  With
the exception of RFC 5988 itself, which is the base specification and
populates the registry with initial entries (and the previous Atom
spec, but a base spec anyway), there haven't been any St. Tr. doc on
this topic.  So I think Informational is optimal.

>>>There are some minor issues.
>>> Minor Issues:
>>> The semantics of the relation type are quite clear, though the
>>> introduction does not make a particularly compelling case for an RFC.
>>> The registration requirements of RFC 5988 require little more than the
>>> creation of a specification; that specification could be created
>>> anywhere (say, in [W3C-PUBRULES]).  I find the motivations described
>>> in the introduction to be not compelling.
>> Publishing an RFC is an ideal way to accomplish RFC 5226 requirements
>> for Specification Required, I think; additionally, whereas it is easy
>> to initiate this work in IETF, it is not so easy to do this in W3C.
> "It is easy" is not an especially good reason.

If we need a spec, and it's easy to be prepared in IETF, it is the
reason to prepare it here.

>>> A more generic description would help.  A superficial reading might
>>> infer that the W3C is the only potential customer of this work,
>>> although it's clear that any organization that concerns itself with
>>> IPR rights (IETF included) might use it. It would be better if the
>>> specific use case were kept as an example, rather than the primary
>>> motivation.
>> I provide the description of W3C use to demonstrate the current use of
>> relation type, and this description in no way means that other
>> organizations cannot use it.
> My point is that the document should not focus on one single use case
> in one document. It should establish the usefulness of the relation
> type for a class of use cases and use the specific instance as an
> example only. The way the document is written it barely even hints at
> other uses.

I think my document now does, providing W3C use as an only example
whereas not claiming it is the only possible use.  The overall use is
spelled out in Section 2, while Introduction is in no way normative.
I think it's OK.

>>> Nits:
>>> Including explanatory statements is unnecessary and distracting.
>> I see no harm in them.
> Extra words that don't contribute to understanding the message are
> harmful.  I don't think these help.

They do contribute to technical accuracy.  So I am convinced I
shouldn't remove them.

Mykyta Yevstifeyev