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

From: Martin Thomson <[email-masked]>
Date: Sat, 17 Dec 2011 10:19:56 +1100

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-yevstifeyev-disclosure-relation-00
Reviewer: Martin Thomson
Review Date: 2011-12-17
IETF LC End Date: 2012-01-06
IESG Telechat date: 2012-01-05

Summary: This draft is almost ready for publication as a proposed
standard.  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.

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.

The field of applicability seems very narrow.  It would help if the
draft could better motivate the creation of a machine-readable marker
of this type.  That is, it might describe a use that a machine would
have for this relation type.

On face value, there is no reason that this should not be a standards
track document, aside from the above concerns.

Nits:
Including explanatory statements like the following:
   (The <ul> element is used to introduce an unordered, bulleted list in
   HTML.)
...is unnecessary and distracting.

In the examples, linking to a patent rather than a disclosure is
potentially misleading.  A disclosure typically includes more
information.  See <https://datatracker.ietf.org/ipr/1505/> for a
specific example.

The page header contains "<Document Title>".

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 17 Dec 2011 08:20:45 +0200

Martin,

Thanks for a review.  Please see comments in-line.

2011/12/17 Martin Thomson <[email-masked]>:
> standard.

The Intended status is Informational.

>There are some minor issues.
>
> Minor Issues:

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.

> specific use case were kept as an example, rather than the primary

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.

> track document, aside from the above concerns.

I think that Informational is Ok for this document, and that the scope
isn't limited by it in any way.

> ...is unnecessary and distracting.

I see no harm in them.

> information.  See <https://datatracker.ietf.org/ipr/1505/> for a

I will fix the examples correspondingly.

> The page header contains "<Document Title>".

Fixed as well.

Thanks for the review once more.

Mykyta Yevstifeyev

---

From: Martin Thomson <[email-masked]>
Date: Sun, 18 Dec 2011 13:46:43 +1100

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.

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

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

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

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

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Wed, 21 Dec 2011 21:10:48 +0200

> reason for why Informational was chosen over Proposed Standard.  Can

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.

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

> example only. The way the document is written it barely even hints at

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.

> harmful.  I don't think these help.

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

Mykyta Yevstifeyev

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Dec 2011 12:57:45 +1100

Mykyta,

You are, of course, entitled to your opinion.  Mine, as you can tell,
differs.  I'll let others be the judge on weight.  My opinion on that
is that it's not worth wasting effort over.

On 22 December 2011 06:10, Mykyta Yevstifeyev <[email-masked]> wrote:
> chosen Informational.

It's a new semantic, which in my experience usually equates to
standards track.  It's not a big deal, but just for reference,
argument from precedent doesn't work very well.

>> [...] the document should not focus on one single use case
> whereas not claiming it is the only possible use.

Relying on what the draft *doesn't* say is not especially effective.
Establishing a reason for the existence of the mechanism is possibly
more important than the description of that mechanism.

--Martin