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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi.

While I'm highly sympathetic to Thomas Roessler's position which
I interpret as this needing (as a matter of courtesy and
cooperation, if nothing else) affirmative signoff from the
relevant parties in W3C, I would settle for any clear set of
comments from them.

But I think this also needs some examination in terms IETF
relationships and process independent of the W3C-related issues.

It is, IMO, entirely appropriate to publish a specification as
Informational when it precisely describes some existing practice
for the information of the community.  We have a long history of
doing that in what is now called the Independent and, when the
specification bears some direct relationship to other IETF work,
in the IETF stream.  But this document, in the -00 version
circulated for Last Call, is not such a precise, factual,
description: it contains errors or misstatements (examples
below) and it contains extensions beyond the existing practice
that are not clearly identified and that, as far as I can tell,
have not been deployed or tested.    While I see no reason why
they would not "work", experience is the proper test of whether
some particular approach or syntax is adequate.

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

	(3) There is no analysis at all of whether the compound
	use of this relation identifier (within a <ul> element)
	might confuse any existing implementations and, if so,
	how that confusion would play itself out.  For example,
	we have learned the hard way in other   areas that, when
	multiple instances of the same information-label appear
	with different values and without that being explicitly
	provided for in the specification, some implementations
	will use the first one and ignore the others, others
	will pick the last one and ignore the others, some will
	reject the construct entirely, and still others will try
	to somehow combine the fields.  If we know what would
	happen here, the document doesn't say so.   Without such
	an analysis, the statement of true belief in Security
	Considerations may be a little bit optimistic.

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

I think this document could be cleaned up and made ready for
publication by using any of the following three options:

(i) Formally ask W3C if the document cited as "[W3C-PUBRULES]"
is an appropriate specification of this relation type or if some
other document exists or can be constructed within a reasonable
(and fixed) period of time.  If so, reference it normatively,
producing an RFC only if the current state of the Link Relation
registry requires that.  Forget about extensions except insofar
as they come through the process that produced this
specification.

(ii) Prepare and publish an Informational RFC that strictly
describes the existing practice and says so.  Publish a separate
document, probably as Experimental, that proposes and argues for
the extension.

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

If IETF publication as an RFC is anticipated for any of those
three options, the inconsistent language should be cleaned up;
the Acknowledgments section completed; and evidence that the
author, the shepherd, and/or the sponsoring AD were in a bit too
much of a hurry to get the document into Last Call as "<Document
Title>" in the page headers should be fixed.

regards and happy new year to all,
    john

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]