Hi,
these changes look good to me! Thanks.
On Wed, 15 Apr 2015, Fan, Peng wrote:
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
--
Mikael Abrahamsson email: [email protected]
_______________________________________________
sunset4 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sunset4
