Re: Make it a Proposed Method rather than Proposed Standard [Re: When is

Hi Hector,

The most importance is its use, or practice. So could it be a less
than a BCP, as a proposed practice (PIP), so we can use it as an
initial-proposal-BCP or an initial-proposal-standard. As we seen the
draft-farrell-perpass-attack-04 draft that SHOULD be an informational
or SHOULD be less than a BCP but still not in the right submission
path (because as we see there is a missing path).

The IETF needs to focus more on proposed used standards, best
practices, and real use cases. That will focus ideas and proposals in
the right directions.

AB

On 1/28/14, Hector Santos <hsantos(_at_)isdg(_dot_)net> 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