Subject: Comments on drafi-shin-v6ops-application-transition-02.txt

From: "Chirayu Patel" <[email-masked]>
Date: Mon, 27 Oct 2003 17:18:43 +0530

Hello,

Just finished going through the draft, and am sending comments. The
document seems to be in good shape. 

CP

Comments
--------

 1. Section 2. 1st paragraph

s/first step/first case/

 2. Section 3.3 5th paragraph

"on how to the" is not grammatically correct.

My suggestion is to rephrase the first sentence as:

"Nevertheless, there should be some reasonable logic to enable the users
to use the applications with any supported protocol version."

 3. Section 4.2 2nd paragraph

s/applications interoperate/applications to interoperate/

 4. Section 4.2 5th paragraph.

Rephrase the first sentence to:

"Some implementations of dual-stack do not support IPv4 mapped IPv6
addresses."

Note: My understanding might be incorrect here. I have posed a question
      on this one below.

 5. Section 4.2 9th paragraph

Remove the reference to section 3.2

 6. Section 5 8th paragraph

s/Next, the problems/In the following sub-sections, the problems/

 7. Section 5.3 2nd paragraph

Rephrase: "However, the recommendation is that all configured IP
addresses should be go to allow applications to work to every kind of
node"

 8. Section 2

Transition will include one more case

      +-------------------+
      |     appv4/v6      | (appv4/v6 - applications supporting
      +-------------------+             both IPv4 and IPv6)
      |     TCP / UDP     | (transport protocols)
      +-------------------+
      |       IPv6        | (IP protocols supported/enabled in the OS)
      +-------------------+

Add section 4.5 to explain this case.

 9. Section 3.3 4th paragraph.

The text says: "However, as noted above..." in the context of
complexities in wrapper application. I am not sure where "above" refers.
The above paragraphs do not seem to contain the required information.
IMHO, new text is needed to explain the complexities.

10. Section 4.1 2nd paragraph

Text about the scenario where it is difficult to use BIA/BIS can be added
here. "It is difficult to use these mechanisms with applications that
embed IP addresses."

11. Section 4.1 3rd paragraph

Give a reference to the section number where the "previous problem" is
described. Are you referring to the problem defined in section 3.2?

12. Section 4.2 5th paragraph

It is mentioned that there are some implementations of dual-stack that do
not allow IPv4-mapped IPv6 addresses to be used. I assume that some
implementations do not *support* these addresses.

Can you give examples here? In addition, can you state reasons/references
for not supporting IPv4 mapped addresses? Even though there is no
explicit requirement in draft-ietf-ipv6-node-requirements-05.txt to
support RFC2133, I think all implementations will support it.

13. Section 4.2 Last two points

I think the first point is not necessary as the section is written
with the assumption that the IPv6 applications will be used on dual-
stack nodes.

14. Section 4.2 Last sentence

The reference to "next section" in the last sentence is incorrect.

15. Section 4.3. 3rd paragraph

Remove the third paragraph. It is redundant. It is a rehash of the 2nd
paragraph.

16. Section 4.3 5th paragraph

Can you explain what local protocol ordering means in "... but the
applications themselves typically need not be aware of the local protocol
ordering [RFC 3484]"?

17. Section 5.1 6th paragraph

I agree that applications need not parse the zone identifier. It wasn't
that obvious immediately (maybe because I am not very familiar with the
API's). A small code snippet to show the same will help.

18. Section 5.1 last paragraph

Usage of address literals is strongly discouraged for general purpose
direct input. Can you provide with reasons, and references. One reason I
can think of is - "length of the IPv6 address makes it difficult to
remember, and use"

19. Section 5.2 4th paragraph

s/applications can use multicast address/applications can use link-local
  scope all-nodes multicast address/

20. Section 5.2 Point "Communication API functions"

You mention "Their signatures". Is this common terminology? What do they
mean? Function Prototypes?

21. Section 5.3

Can you provide function names as examples in this section? I got
confused while reading "However, these functions use IP address
structures, which are protocol independent" because I did not know which
functions were you referring to.

The same comment applies to the next paragraph, and 2nd paragraph
section 5.4.

22. Section 5.4.3

I am not familiar with collaborative applications. Can you give few
examples? Also, what are registry keys? Is this Windows specific?

23. Section 6.1

Set the value of sslen in the example.

---

From: Myung-Ki Shin <[email-masked]>
Date: Tue, 28 Oct 2003 09:18:45 +0900

Chirayu,
Thanks for your review.

I will keep all of these comments.

Regards,
Myung-Ki.