I'm not sure more categories is what we want. I have observed all of the following (not at the same time, though some were) from people not familiar with the IETF and RFCs, although invested in or using RFCs: - Assuming that all RFCs are standards. - Assuming that only Standards matter, that Proposed Standards and Draft standards aren't important. - Assuming that Draft Standard is a category below Proposed Standard. - Recognising that there are standards and not-standards, but not distinguishing in any way between Standard, Draft Standard and Proposed Standard (calling all of them Standards). - Just plain confused. (And the concept of BCP is probably completely unknown to anyone thinking any of the above.) Another category isn't going to help here. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@xxxxxxxxxxxxxx | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: ietf [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Hector Santos Sent: 28 January 2014 21:53 To: Spencer Dawkins Cc: IETF discussion list Subject: Make it a Proposed Method rather than Proposed Standard [Re: When is an idea a good idea?] ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Consider carefully whether you should click on any links, open any attachments or reply. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- 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 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ********************************************************************