Thank you Mikael for the review. Section 5 deals with operating system related issues. I rewrite Problem 8 a little, please see if it reflects your concerns. Regarding the recommendation of OS developer implementing functions to reveal IPv4 dependency, it seems to be a solution idea that can be seen as a candidate of the words "how to discover existing dependencies" in appendix A.3 (also rewrite as follows). I guess this requires the OS to have an exhaustive list of legacy IPv4-only APIs and a runtime knowledge of what APIs are currently called by what applications, and I would also like to hear the opinion of the WG if this is an implementable and rational way that OS is expected to realize.
//PROBLEM 8 OLD: Completely disabling IPv4 at runtime often reveals implementation bugs. Hard-coded dependencies on IPv4 abound, such as on the 127.0.0.1 address assigned to the loopback interface. It is therefore often operationally impossible to completely disable IPv4 on individual nodes. NEW: Completely disabling IPv4 at runtime often reveals implementation bugs. Hard-coded dependencies on IPv4 abound, such as on the 127.0.0.1 address assigned to the loopback interface, and legacy IPv4-only APIs are widely used by applications. It is hard for the administrators and users to know what applications running on the operating system have implementation problems of IPv4 dependency. It is therefore often operationally impossible to completely disable IPv4 on individual nodes. //Appendix A.3 OLD: It would be useful for the IETF to provide guidelines to programmers on how to avoid creating dependencies on IPv4, how to discover existing dependencies, and how to eliminate them. Having programs and operating systems that behave well in an IPv6-only environment is prerequisite for IPv4 sunsetting. NEW: It would be useful for the IETF to provide guidelines to programmers on how to avoid creating dependencies on IPv4, how to discover existing dependencies, and how to eliminate them. It would be useful if operating systems provide functions for users to see what applications uses legacy IPv4-only APIs, so they can know it better whether they can turn off IPv4 completely. Having programs and operating systems that behave well in an IPv6-only environment is prerequisite for IPv4 sunsetting. Best regards, Peng -----Original Message----- From: sunset4 [mailto:[email protected]] On Behalf Of Mikael Abrahamsson Sent: Monday, April 13, 2015 3:47 PM To: Mukom Akong T. Cc: [email protected] Subject: Re: [sunset4] Fwd: Review of draft-ietf-sunset4-gapanalysis-06 On Wed, 8 Apr 2015, Mukom Akong T. wrote: > I committed to reviewing this draft. I only have one suggestion for > the authors to improve legibility: itemising the specific set of > criteria for review in section 2. > > I also attach the reviewed document. > > P/S: This is my first review so I might not be aware of a proper > procedure to submit it, please point me to the right procedure if this isn't it. I also promised to review this document. I found nothing objectionable in the document, it looks useful and I support it. I had a thought though, I remember a linux kernel message I saw a long time ago regarding an soon-to-be-deprecated API, and that it gave syslog warnings that a certain process used it. Would it make sense to recommend operating system manufacturers to implement functions so admins/users could see what applications uses legacy IPv4-only-APIs? Or perhaps just say that a gap is that it's hard for the user to know what applications use ipv4-only API and thus they could be helped by understanding this better to know if they can turn off IPv4 completely or if they need to keep it running but might firewall it or something? -- Mikael Abrahamsson email: [email protected] _______________________________________________ sunset4 mailing list [email protected] https://www.ietf.org/mailman/listinfo/sunset4 _______________________________________________ sunset4 mailing list [email protected] https://www.ietf.org/mailman/listinfo/sunset4
