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

[Myung-Ki Shin <mkshin@pec.etri.re.kr>]

Chirayu,
Thanks for your review.

I will keep all of these comments.

Regards,
Myung-Ki.

Chirayu Patel wrote:

> 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.