At 4/19/2003:07:47 PM, Dave Crocker wrote: Hi Dave, I regret that this is going to sound like I'm tooting my horn or something like that, but I'm just noting it for emphasis: I made almost exactly the same argument for an "Architectural Considerations" section on a par with "Security Considerations" in IDs and RFCs on the "problem statement" list in the early days of that list. I am hopeful that your raising it will have more impact. I seriously believe that lack of architectural coordination across the IETF's many efforts casts a pall on our work in subtle ways which have far more impact on many of the larger constituencies for our work. I would only add that the implications of your wording of your last statement -- "Any specification that creates interesting features should be required to specify its requirements on providers and its impact on consumers." -- might be a bit too optimistic...I don't think it goes quite far enough in noting that it will probably take review by members of the small cadre of IETF architecture experts to be sure that all relevant requirements and impacts have been accounted for. Many document authors (like me, for instance) might not know enough about IP-wide and Internet-wide architecture issues to do a thorough job on their own. (Of course, I guess that's true of the already mandatory "Security Considerations" section too! :-) Cheers, BobN - - - - - >Folks, > >DS> I am saddened by the fact that Tony's simple question could not be >DS> addressed. Site local addressing in IPv6 is a concept which has been >DS> mentioned in RFC 1884, 2373 and 3513, the progression of Proposed >DS> Standards. This is a string of documents dating back to 1995. For eight >DS> years this concept was apparently considered a good thing. > >The problem appears to have been that no one bothered to draw the >necessary implications and circulate them for explicit consideration. So >folks scanned a spec, didn't see anything that looked egregious, and >only now are realizing how extensive the impact is. > >We have a very basic, very serious problem with coordination among >different parts of the IETF. Our tendency is to task various folks with >doing a better "monitoring" job. > >My guess is that, instead, we *all* need to do a better job of noticing >when we are specifying something that has an architectural impact, by >which I mean something that affects other parts of the Internet service. > >Once upon a time, the Security Considerations section was pro forma. >These days, it is taken seriously, and specifications are required to >develop this section carefully. > >More recently we have added IANA Considerations sections, to make sure >that administrative issues are handled more easily. > >Perhaps it is time to require specifications to make explicit statements >about the impact the spec's features will have on architectural >providers and consumers. That is, the features of a specification draw >on system Internet services "below" and give services to parts of the >system "above". > >Any specification that creates interesting features should be required >to specify its requirements on providers and its impact on consumers. > >d/ >-- > Dave Crocker <mailto:dcrocker@brandenburg.com> > Brandenburg InternetWorking <http://www.brandenburg.com> > Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301> > > >_______________________________________________ >This message was passed through ietf_censored@carmen.ipv6.cselt.it, which is a sublist of ietf@ietf.org. Not all messages are passed. Decisions on what to pass are made solely by Raffaele D'Albenzio.