I am very strongly opposed to this "proposal".
It takes the WG in the wrong direction, and attempts explicitly to undo
the work that led to RFC4794, which eliminated some of the time-wasting
requirements that served only to further extend the already slow IETF
process.
The right time to preserve a specification in an archived form (such as
an RFC) is when the specification has stabilized. Implementation and
deployment sometimes do not occur for years afterward, at which time the
the original authors and/or editors of the specification might have
moved on to other pursuits. In WGs that do have implementation
requirements, specification that were implemented years ago often sit
around as internet-drafts for extended periods of time, just because no
one is available to restart the standardization process. Often the
drafts expire, and sometimes remain expired for years after they've been
deployed. This creates considerable confusion about whether the drafts
have been abandoned.
There is also the point that Andy has raised, that delaying publication
may also delay deployment.
I believe it is improper for the IETF to be demanding details about
implementations, release cycles, and release dates. It should be noted
that it becomes quite difficult to gather this sort of information about
a draft that has been sitting around for years, especially if that draft
has has been implemented and deployed piecemeal.
There are also some process issues to discuss.
[Martin] the point of our e-mail is to continue the discussion on the
list. We explicitly say that this is a proposal and that we are open
to comments.
The email in question certainly suggests that the WG chairs have already
made a decision to impose a new requirement, but are allowing two weeks
(during what is a holiday season for many) for "discussion" before they
announce that there is a consensus in favor of their proposal. This
does not seem like an appropriate approach, and imho would be worthy of
appeal.
The routing area used to have more implementation requirements, but
after extensive discussion in 2006 (discussion lasting more than two
weeks), these requirements were eliminated by RFC4794. The reason is
clear enough. Quoting RFC4794:
"Today, one of the big problems the IETF faces is timeliness.
Applying additional rules to a certain class of protocols hurts the
IETF's ability to publish specifications in a timely manner."
I don't think anything has changed since the topic was discussed in
2006. We should be looking for ways to speed up the process, not
looking for even more ways to slow it down.
[Adrian] To be clear, the WG is allowed to make a decision to do
this. http://datatracker.ietf.org/doc/rfc4794/
Are you referring to the following paragraph:
Some working groups within the Routing Area have developed
procedures, based on RFC 1264, to require implementations before
forwarding a document to the IESG. This action does not prevent
those working groups from continuing with these procedures if the
working group prefers to work this way. We encourage working groups
to put measures in place to improve the quality of their output.
I don't see that this gives individual WGs (not to mention WG chairs)
any right to impose arbitrary new rules. It only allows them to keep
existing rules. The most it says about allowing the creation of new
rules is:
that does not prohibit the Routing Area Directors from requiring
implementation and/or operational experience
though this presumably would also be subject to appeal if it were
applied arbitrarily.
[Martin] The basic motivation for this is simply to avoid
(over)loading the iesg with documents that have no (and could
possibly never have an) implementation.
I don't think the problem of AD workload can be addressed by having a
single WG add more delay to its process. Certainly I don't agree that
the IESG workload problem should be addressed by having the IETF do less
work.
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
