|
Re: Make it a Proposed Method rather than Proposed Standard [Re: When is an idea a good idea?]
2014-01-28 16:34:50
Just to be clear, I'm certainly not opposed to exploring this question,
but I do think it's orthogonal to my post ("how do we review
specifications that might not be applicable everywhere?" as opposed to
"how do we get some deployment experience before deciding something is a
proposed standard?").
So definitely, thanks for changing the subject line, and perhaps you
could knock out an Internet-Draft proposing Proposed Methods?
Spencer
On 01/28/2014 03:52 PM, Hector Santos wrote:
I think the IETF needs a new status for document submissions.
Something more advanced than experimental and informational but less
than a Proposed Standard (PS) perhaps called Proposed Method (PM). A
PM will need towards an IM (Internet Method).
When something is written as a "standard" there tends to be a higher
bar to do something different. It provides a sense of final closure
and resolution and this is where many debates, conflict of interest,
are based, where IETF Appeals are more probable. Who cares if a
proposal is informational or experiment? Not really strong enough and
too risky for adoption. A "standard" has a higher bar to reach but
also to change as well.
I believe a PM will help with the acceptance of proposals that may fit
in this in between category where it may not be considered a standard
material, yet, it offers some level of technology that is beyond being
informational or experimental, i.e. a segment of the market place is
using it, technology leader wishes to document a proprietary method as
an open and public domain method.
I believe a PM may also help alleviate the "good vs bad" debates,
allow for greater adoption explorations. It tells the industry that
we found something useful, already used in practice, try it yourself,
but its still not something the IETF to be the "standard" method.
Anyway, the PM idea seems to come back more and more as you see more
of these "half-baked" proposed standards when they seems to be more
experimental or informational in nature. You have good ideas out
there that do need to be documented. But you don't need to make them
Proposed Standards which has a tremendously high bar and higher source
for major debates, especially when there are conflicts.
--
HLS
On 1/28/2014 3:14 PM, Spencer Dawkins wrote:
Disclaimer - I'm one of the ADs who will be balloting your documents
until at least March 2015, but I'm only one of 15 ADs, and haven't
talked about this with the rest of the IESG.
The past week has brought me yet another example of an idea that could
be a good idea, but not under every possible set of conditions, being
evaluated as if we had to decide whether it was a good idea in all
cases, or a bad idea. This might sound familiar to you, but if it
does, let's not talk about that specific case.
The longer (and more painfully) we talk during Last Call, the more
details we unearth that help me to understand what document
authors/working groups are thinking, and that's good, but if it was
less painful, that would be even better.
http://tools.ietf.org/html/rfc2026#section-3.2 describes Applicability
Statements, as distinct from Technical Specifications, and says (among
other things):
An Applicability Statement specifies how, and under what
circumstances, one or more TSs may be applied to support a
particular
Internet capability.
...
An AS may describe particular methods of using a TS in a restricted
"domain of applicability", such as Internet routers, terminal
servers, Internet systems that interface to Ethernets, or datagram-
based database servers.
Speaking only for myself, I don't expect Proposed Standards to be
perfect, and to work perfectly in every situation, but if a
specification doesn't describe any limits on applicability, I'm going
to be evaluating it as if it will be used on the open Internet (that's
what the "I" in "IETF" stands for).
If a draft says it's only intended to be used within an IP subnet, I'd
evaluate it differently. I might ask that the authors/working group
consider what the TTL should be set to, so that what starts out within
an IP subnet stays within an IP subnet, but (to use one actual
example) we wouldn't be arguing about whether it's OK to send 32K
max-length packets over an arbitrary Internet path at line rate
without getting any feedback about path capacity - there are probably
paths where that would work, and there are definitely paths where it
would not.
If a draft says it's only intended to be used on provisioned, managed
internetwork links subject to SLA monitoring, I'd evaluate it
differently.
If a draft says "this is a hack, intended for use on old hardware that
can't do $X", I'd evaluate it differently.
There are other limited-use scenarios that would make me evaluate a
draft differently.
None of this is a guaranteed pass, but it would help me a lot. It
would likely help other reviewers, too.
So, if you don't intend for your draft to be used on the global
Internet, please say so! As per
http://tools.ietf.org/html/rfc2026#section-3.3, it's not necessary to
put an Applicability Statement in a different draft; just a section
that says (another actual example) "this has been tested using these
parameters on a lightly-loaded LAN, and it works there", that is more
helpful than a tug of war(*) about whether something is a good idea or
a bad idea in all situations, in front of a live studio audience.
Thanks to Alia Atlas for nudging me to think about this more.
Spencer
p.s. If you have feedback about what I'm thinking, I'd love for you to
share it, whether on this list, privately to me, to the 2015 Nomcom,
or to other Nomcom-eligible IETF participants when you're asking them
to to sign the recall petition ;-)
(*) http://en.wikipedia.org/wiki/Tug_of_war
|
|