(Sorry for not getting back to this issue sooner, but I just got home after some touring at Tahoe and lengthy flights home.)
This is my exact point about this spec.
It seems if this will continue without a focus as Kurtis says below and I have stated previously we will need a serious applicability statement.
Because it is BCP I am backing off a little as most of the market don't care about our BCPs. But there needs to be applicability statement.
Jim,
Charter says Informational and I believe that is could be acceptable to you as well?
If by "without a focus" you mean that we are not describing the requirements for IPv6-enabled servers flying in helichopters, then I agree. That is, we do not describe what IPv6 features should be used in specific applications. And yes, there should be an applicability statement to this effect. Perhaps you'd be willing to submit some text?
However, I still feel strongly that we MUST describe what "components" IPv6 has and what their mandatory/optional status is. Not the need in a specific application, but whether something is *always* needed. And a directory of optional components. (In some specific subset of cases we can also give a rule when the optional component becomes mandatory.)
I believe this is very useful for ensuring the interoperability and success of IPv6, and I'm a bit surprised that you seem to disagree. I've heard a number of counter arguments to this kind of specifications and I would like to take this opportunity to discuss them:
* "Its obvious". Right. So why we are debating the keywords for DHCP and MIPv6...?
* "Its in the other RFCs already". Probably so, at least in some cases. If you dig up the information by reading all RFCs, that is. And I know for a fact that some specifications explicitly left the decision out; at least MIPv6 does this in expectation of IPv6 saying something about it its specifications.
* "We can't agree anyway what the mandatory components are". So, we shift our problem to the customers and end-users? No, let the buck stop here. Not in IESG, vendors, or customers.
* "All this depends on the applications." Some things depend on the applications. But not all. And even if some things are needed on a per application basis, wouldn't it be useful to document that so that no one mistakes something for mandatory?
* "Market place decides anyway." Yeah. But in my experience the rules in IETF specifications still have a lot of weight.
* "The set of requirements for any specific application is going to be much different or more extensive than this". I agree. But no one claimed this was all you had to do to protect the flying servers.
* "Maybe you can list the mandatory components, but I don't see a need to look at the optional ones." Well, how do I know that if RFC nnnn isn't listed, its (a) optional or (b) forgotten? I say we should be explicit and list the optional components too.
* "Early IPv4 RFCs were so bad that we needed a lot of explanations, but it doesn't apply to IPv6 anymore". I agree, but if you look at the node requirements document, it doesn't follow the IPv4 host requirements style at all. We only list specific RFCs. There's a small number of cases where large RFCs contain a number of independent pieces (such as MIPv6) that we have also listed. But I agree, we shouldn't be explaining and patching existing RFCs. Fortunately, we are not doing that.
Jari
-------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
