----- Original Message ----- From: "Spencer Dawkins" <spencerdawkins.ietf@xxxxxxxxx> To: "Brian E Carpenter" <brian.e.carpenter@xxxxxxxxx> Cc: "IETF discussion list" <ietf@xxxxxxxx> Sent: Wednesday, January 29, 2014 3:45 PM > I'm replying to Brian and to Scott here ... > > On 01/28/2014 05:11 PM, Brian E Carpenter wrote: > > Hi Spencer, > > > > I think there's a bit more to be said, though. > > > > The goal is to make the Internet work better, not to make > > private networks work better. Actually RFC 3935 defines > > the IETF's scope as: "protocols and practices for which > > secure and scalable implementations are expected to have > > wide deployment and interoperation on the Internet, or to > > form part of the infrastructure of the Internet." > > > > So if there are two ways of doing something, one of which > > works globally and one of which only works locally, the choice > > is a no-brainer. If a local-only solution comes up to the IESG, > > I couldn't agree with Brian and Scott more. I'm focusing on "comes up to > the IESG". > > My point is that the sooner someone asks "so, is this really intended > for deployment on the global Internet?", the better. If working groups > and authors thought about that before, or even during, WGLC time, I > would like to think that we would have fewer cases where the question is > asked for the first time in AD review, or in directorate reviews, or in > IETF Last Call. Spencer By this criterion, would MPLS ever have entered the Standards Track? It is a protocol that works supremely well within the private network of an ISP; extending it to work across the Internet worldwide is more of a challenge and, from what I recall, was not contemplated at the time of RFC3031. Tom Petch > > I don't think it's controversial at all that the IETF does better when > documents don't encounter Late Surprises (tm). If the first time someone > says "but this is only intended to be used when $whatever" is in an > email exchange during IETF Last Call, that's a Late Surprise, and the > chances that the best outcome will happen aren't going up at that point. > > As I said in my note, this is my personal suggestion. I'm not asking for > an Applicability Statement as a mandatory section in all IDs, precisely > because of Brian's point that the default is "this proposal is suitable > for deployment on the global Internet". I'm asking working groups and > authors to consider whether that's true for their proposals, or if I > should be reviewing with something else in mind. > > And as always, I encourage people to Do The Right Thing. > > Spencer > > > I think the first question is "Why isn't there a globally > > applicable solution to this problem?". Then the second question > > is "Why is this on the standards track, rather than being an > > informational document for the record?". And the third question > > is "Why is this better as an IETF document rather than an > > Independent Submission?". > > > > There may be perfectly good answers to those questions, but > > IMHO they need to be asked. > > > > Regards > > Brian > > > > On 29/01/2014 09:14, 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 > >> > >