Joel Bion wrote: > I have a hunch if IPv4 isn't declared historic now, that a year from now > you'll > be in exactly the same place w.r.t. people saying "not yet" > > "Directionally historic" etc describes the truth of IPv4 for 20 years now - so > declaring such a thing is the equivalent of me saying "I will die someday" - > not > news, and nobody's behavior changes as a result of me saying this.
I certainly agree that statements like that are not particularly useful, but I'm not sure that the direct goal from the IETF perspective is trying to change the behavior of operators, at least in this context. The question of whether or not the specification should be historic seems oriented more at where the IETF should focus its efforts developing specifications and how those specifications impact developers and product manufacturers. > The goal of declaring IPv4 historic is not to report on an already achieved > truth but to create behavioral change. To make it so that it is harder to do > new v4 things and well near impossible to do new v4 only things. I've spent a fair amount of time thinking about this topic, especially in light of the comments at the sunset4 session. Despite what I thought were some pretty clearly expressed distinctions expressed by Lee, a fair number of the comments still seemed to approach this as an effort to "turn v4 off" or to somehow control usage or deployment of v4. Most of the rest of the comments focused on how it impacted where the IETF would or would not focus its time and effort. And that's a lot more accurate, but the directly impacted "customers" (an over-used, but perhaps accurate term in this context) of the work the IETF does with its specifications are the companies and individuals who implement those specifications in products. So, then, what is the impact to that group if the IETF publishes two Internet Protocol specifications as full standards, one of which clearly states it is the successor to the other in its specification with no other guidance (a declaration of IPv4 as the historic specification or otherwise)? Since there is no defined relationship or restriction and the IETF developed and published a new or modified required or recommended feature in the IPv4 specification, doesn't that mean they would all need to implement that new or changed specification? By keeping both specifications as full standards, the IETF is actually, in a way, signaling implementers that they have to meet two different Internet Protocol specifications if they truly want to be considered interoperable on the Internet. That doesn't look desirable to me. So I went back and reread some of the process documentation more closely, especially RFC2026, and spent some time thinking about this section. 6.3 Revising a Standard A new version of an established Internet Standard must progress through the full Internet standardization process as if it were a completely new specification. Once the new version has reached the Standard level, it will usually replace the previous version, which will be moved to Historic status. However, in some cases both versions may remain as Internet Standards to honor the requirements of an installed base. In this situation, the relationship between the previous and the new versions must be explicitly stated in the text of the new version or in another appropriate document (e.g., an Applicability Statement; see section 3.2). While moving the previous version to Historic status is the normal process, if that doesn't occur, then somehow the relationship between the two versions of the standard (including, I would think, the expectations placed on implementers) needs to be clearly outlined. The text of the new version states that it is the successor to the old version, so that's not particularly helpful. Perhaps the intent would be that the IPv6 specification must be met for IP interoperability while the IPv4 specification may optionally also be employed? While the IETF could still work on the IPv4 specification if the need arose, perhaps some specific guidance on the scope of such work could be set. At a minimum, I don't think any such updates to the specification could be considered required. I'll say that I believe the normal course of action declaring the IPv4 specification historic as Lee proposed would work just fine. The IESG retains the ability to authorize work on the specification if it's really needed but the status of the specification at that point seems well-defined and understood. I also don't have any issues with an alternative process as long as it's also well-defined. I think it would be a problem for the IETF to publish two different versions of the IP specification as full standards without also trying to clearly define what that meant. If the older specification is not historic, what is it? What must be implemented in a product for it to have met all the required elements for IP interoperability. If both are full standards with no other guidance, then wouldn't a product have to implement the required elements of both to be considered to have met the IP specification? The normal process would be to declare v4 historic when its successor specification is promoted to full standard status. Lee simply started a conversation about that process. Admittedly, changing the specification for the Internet Protocol (IP) itself is a pretty big deal, so something other than the normal process may be warranted. Personally, I didn't find any of the arguments at the session against moving the specification to historic status (as defined within the context of the IETF) particularly compelling, but I also don't object to defining a different relationship. I do object to simply making both specifications a requirement across the board in order to achieve IP interoperability. Sure, in practice most products will implement both. But in a contained environment with constrained resources, a new product (say a network of factory sensors) may decide the v6 version of the IP specification best meets its needs and implement only that protocol in its sensors. I'm sure such an implementer would not feel constrained by the way the IETF labeled its specifications, but the relationship should be defined so that is explicitly supported. Moreover, if v6 is the successor specification, then a v4 only implementation cannot be considered to have met the interoperability requirements of the IP specification. Again, an implementer will do whatever they want, but that choice should not be supported by the specification. Of course, if I understand the process correctly, if the IETF does nothing to define the relationship and leaves both versions of the specification as full standards, by default that means the required elements of both versions of the specification are always just that -- required for any IP implementation. Those are my thoughts, such as they are. I support following the normal process, but if that's not done, then an AS or something else should be published explicitly defining what having two active IP specification versions means in practice. Scott _______________________________________________ sunset4 mailing list [email protected] https://www.ietf.org/mailman/listinfo/sunset4
