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(_at_)brandenburg(_dot_)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(_at_)carmen(_dot_)ipv6(_dot_)cselt(_dot_)it, which is a sublist
of ietf(_at_)ietf(_dot_)org(_dot_) Not all messages are passed. Decisions on
what to pass are made solely by Raffaele D'Albenzio.