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@xxxxxxxx> 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 > > > > >