[sunset4] Fwd: Review of draft-ietf-sunset4-gapanalysis-06

[Mukom Akong T.]

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.

Regards.
--
Mukom Akong T.

http://about.me/perfexcellence | twitter: @perfexcellent
------------------------------------------------------------------------------------------------------------------------------------------
“When you work, you are the FLUTE through whose lungs the whispering of the
hours turns to MUSIC" - Kahlil Gibran
-------------------------------------------------------------------------------------------------------------------------------------------

[Mikael Abrahamsson]

Post by Mukom Akong T.
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?

[Fan, Peng]

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:sunset4-***@ietf.org] On Behalf Of Mikael
Abrahamsson
Sent: Monday, April 13, 2015 3:47 PM
To: Mukom Akong T.
Cc: ***@ietf.org
Subject: Re: [sunset4] Fwd: Review of draft-ietf-sunset4-gapanalysis-06

Post by Mukom Akong T.
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]

Hi,

these changes look good to me! Thanks.

Post by Fan, Peng
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
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.
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
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.
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-----
Abrahamsson
Sent: Monday, April 13, 2015 3:47 PM
To: Mukom Akong T.
Subject: Re: [sunset4] Fwd: Review of draft-ietf-sunset4-gapanalysis-06

Post by Mukom Akong T.
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?
--
_______________________________________________
sunset4 mailing list
https://www.ietf.org/mailman/listinfo/sunset4

[Fan, Peng]

Thank you Mukom for the review. Your comments will be incorporated in the next revision of the draft.



Best regards,

Peng



From: sunset4 [mailto:sunset4-***@ietf.org] On Behalf Of Mukom Akong T.
Sent: Wednesday, April 08, 2015 7:00 AM
To: ***@ietf.org
Subject: [sunset4] Fwd: Review of draft-ietf-sunset4-gapanalysis-06



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.



Regards.
--
Mukom Akong T.

http://about.me/perfexcellence | twitter: @perfexcellent
------------------------------------------------------------------------------------------------------------------------------------------
“When you work, you are the FLUTE through whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran
-------------------------------------------------------------------------------------------------------------------------------------------