I do not support approval of this experiment. I opine that most
of the "publication delay" is due to WG/author choice, not the
downref rule. I also offer an alternative cure which keeps in place
the downref rule in published RFCs.
If a WG or individual is pursuing publication of a Standard Track
RFC, they should consider the impact of normatively referencing
documents of lessor maturity in the Standard Track on their document's
progression.
Consider the case where authors are revising an existing Standard
Track protocol and their document normatively references a specification
currently at Proposed. Today, authors have three choices:
1) Submit their document for Propose - no ref wait,
2) Submit their document for Draft - wait on
the downref to reach Draft
3) Submit their document at Draft with a request for
variance from the downref rule - no ref wait.
Authors can avoid the downref wait simply by requesting publication
at a lower maturity (option 1). When the reference is promoted,
the authors can request a promotion of their document.
Now, what might be interesting is to establish a (experimental)
practice that an I-D (the target) is approved at Draft Standard
that normatively references existing Proposed Standards can initially
be published as a Proposed Standard. When the referenced RFCs are
approved and announced at Draft, the target will be automatically
announced at Draft. That is, no need to seek a separate IESG action.
(Likewise for Internet Standard approved documents referencing
Proposed and/or Draft Standards (published at the lessor maturity
of the normative references).)
I do not support allowing RFCs (on or off the standard track) to
normatively reference Internet-Drafts and/or works in progress. As
the proposal excludes all but approved I-Ds from the experiment, I
will limit my comments to approved I-Ds (or 'RFC-to-be's).
I believe the RFC-to-be (the target) wait on another RFC-to-be is
not so great as to risk that a change to a referenced RFC-to-be
negatively impacts implementor of the target RFC-to-be. There is,
I believe (based on my experience in making last minute changes to
RFC-to-bes), significant risk. I also believe the wait is minimal.
It appears the practice of the RFC Editor to schedule work on
referenced RFC-to-be based upon the queue position of the target
RFC-to-be. For instance, the revised LDAP TS (over a dozen documents
submitted over many months (years?)) was processed soon after the
last normative reference was approved. But more important, if we
would have published the early RFC-to-be as soon as the later
RFC-to-be had been approved, we would have many bad section cites
in these documents. This would have lead to significant reader
confusion. The wait is not without purpose.
I also do not support an experiment allowing Standard Track RFCs
to normatively reference non-Standard Track RFCs (or other non-standard
documents). I believe the RFC 3978 practice and the RFC 2026
variance process provides adequate means publishing documents with
such references.
I believe the RFC-to-be (the target) wait on another
RFC-to-be is not so great as to risk that a change to
a referenced RFC-to-be negatively impacts implementor
of the target RFC-to-be. There is, I believe (based on
my experience in making last minute changes to RFC-to-bes),
significant risk. I also believe the wait is minimal.
It appears the practice of the RFC Editor to schedule
work on referenced RFC-to-be based upon the queue
position of the target RFC-to-be. For instance, the
revised LDAP TS (over a dozen documents submitted over
many months (years?)) was processed soon after the last
normative reference was approved. But more important,
if we would have published the early RFC-to-be as soon
as the later RFC-to-be had been approved, we would have
many bad section cites in these documents. This would
have lead to significant reader confusion. The wait
is not without purpose.
I also do not support an experiment allowing Standard
Track RFCs to normatively reference non-Standard Track
RFCs (or other non-standard documents). I believe the
RFC 3978 practice and the RFC 2026 variance process provides
adequate means publishing documents with such references.
Regards, Kurt
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf