--On Monday, January 02, 2012 09:36 +0200 Mykyta Yevstifeyev
<evnikita2(_at_)gmail(_dot_)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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf