Application Aspects of IPv6 Transition
draft-ietf-v6ops-application-transition-03
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
03 | (System) | post-migration administrative database adjustment to the No Objection position for Scott Hollenbeck |
2012-08-22
|
03 | (System) | post-migration administrative database adjustment to the No Objection position for Steven Bellovin |
2012-08-22
|
03 | (System) | post-migration administrative database adjustment to the No Objection position for Ted Hardie |
2004-08-30
|
03 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2004-08-27
|
03 | Amy Vezza | IESG state changed to Approved-announcement sent |
2004-08-27
|
03 | Amy Vezza | IESG has approved the document |
2004-08-27
|
03 | Amy Vezza | Closed "Approve" ballot |
2004-08-26
|
03 | David Kessens | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by David Kessens |
2004-07-02
|
03 | Ted Hardie | [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Discuss by Ted Hardie |
2004-07-01
|
03 | Scott Hollenbeck | [Ballot Position Update] Position for Scott Hollenbeck has been changed to No Objection from Discuss by Scott Hollenbeck |
2004-07-01
|
03 | Steven Bellovin | [Ballot Position Update] Position for Steve Bellovin has been changed to No Objection from Discuss by Steve Bellovin |
2004-06-24
|
03 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2004-06-24
|
03 | (System) | New version available: draft-ietf-v6ops-application-transition-03.txt |
2004-06-11
|
03 | (System) | Removed from agenda for telechat - 2004-06-10 |
2004-06-10
|
03 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
2004-06-10
|
03 | Alex Zinin | [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin |
2004-06-10
|
03 | Scott Hollenbeck | [Ballot discuss] Section 5.1 seems to be in conflict with sections 2.2 and 2.3 of RFC 3513. A reference to 3513 should be included, … [Ballot discuss] Section 5.1 seems to be in conflict with sections 2.2 and 2.3 of RFC 3513. A reference to 3513 should be included, and if there's something wrong about the formats described there should be text added to explain why those formats won't work. |
2004-06-10
|
03 | Scott Hollenbeck | [Ballot discuss] Section 5.1 seems to be in conflict with sections 2.2 and 2.3 of RFC 3513. A reference to 3513 should be included, … [Ballot discuss] Section 5.1 seems to be in conflict with sections 2.2 and 2.3 of RFC 3513. A reference to 3513 should be included, and if there's something wrong about the formats described there there should be text added to explain why those formats won't work. |
2004-06-10
|
03 | Scott Hollenbeck | [Ballot Position Update] Position for Scott Hollenbeck has been changed to Discuss from Undefined by Scott Hollenbeck |
2004-06-10
|
03 | Scott Hollenbeck | [Ballot comment] I don't really buy the assertion that applications are either "IPv4 applications" or "IPv6 applications". A well designed application will rely on things … [Ballot comment] I don't really buy the assertion that applications are either "IPv4 applications" or "IPv6 applications". A well designed application will rely on things like APIs to lower software layers (as described in section 6) to avoid such low-level dependencies. I can, however, see user interface issues when there's a need to enter and display IP addresses, for example, but this document doesn't describe UI issues at all. DNS applications, such as resolvers, are of course another matter. The document does a good job of explaining the transition issues facing client-side DNS implementations, but the title seems to imply that the scope extends beyond DNS clients. A title change may make the scope more clear. |
2004-06-10
|
03 | Scott Hollenbeck | [Ballot Position Update] New position, Undefined, has been recorded for Scott Hollenbeck by Scott Hollenbeck |
2004-06-10
|
03 | David Kessens | [Ballot Position Update] New position, Yes, has been recorded for David Kessens by David Kessens |
2004-06-10
|
03 | Bill Fenner | [Ballot comment] No further objection - Steve and Ted cover my concerns. |
2004-06-10
|
03 | Bill Fenner | [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner |
2004-06-09
|
03 | Steven Bellovin | [Ballot discuss] 3.2 advocates service names in the DNS. Is this our official position, as opposed to SRV records? I thought we wanted to discourage … [Ballot discuss] 3.2 advocates service names in the DNS. Is this our official position, as opposed to SRV records? I thought we wanted to discourage such things. If SRV records are meant, this should be clarified. 3.3: Does the word "users" mean "people who want to run applications on the local machine", or does it mean "remote clients who want to do something on some machine"? I confess I'm not sure I believe in the wrappers -- in fact, I'm quite certain I don't believe in them. Anything that does a getpeername() (or equivalent) can't work properly via a wrapper, because the function will return 127.0.0.1. Anything that does less will just work, via inetd (or equivalent), and needs no wrapper. Anything that does complex things with IP addresses, such as FTP, will require a very complex wrapper. This last point is noted, though without supporting detail. In short, I'm not convinced that it's feasible to provide the "reasonable logic". (I note that the problem is even worse on the client side. That should be discussed in the draft, too.) The last sentence of the third paragraph of 4.1 is ambiguous and should be reworded -- it sounds like the source code availability prevents misuse, which is clearly not what's intended. 5.4.2 appears to be suggesting application awareness of the results of PMTU discovery. That's a gross layering violation and can't be our advice. 6.1 does not lead to simpler code -- the application will simply check sock.sa_family instead of the socktype parameter. Worse yet, it leads to questions about incompatibility between the length passed in the second version versus the length implied by sa_family. The text alludes to security problems from IPv4-mapped addresses. Section 8 should explain exactly what the problem is. The current text just speaks of "difficulty" and "legitimate use" without explaining the threat or the threat environment. |
2004-06-09
|
03 | Steven Bellovin | [Ballot Position Update] New position, Discuss, has been recorded for Steve Bellovin by Steve Bellovin |
2004-06-09
|
03 | Ted Hardie | [Ballot comment] Bump in the Stack and bump in the api should be spelled out at first use. I think it would be useful to … [Ballot comment] Bump in the Stack and bump in the api should be spelled out at first use. I think it would be useful to include the DNS resolver explicitly in the diagrams in Section 2. Its behavior is important enough to the set that inclusion would be useful If the authors disagree, however, I will not press the point. I also believe that this text: It is bad practise to add an AAAA record for a node that does not support all the services using IPv6 (rather, an AAAA record for the specific service name and address should be used). However, the application cannot depend on "good practise", and this must be handled. is somewhat confusing. It might be useful to rephrase this as "system administrators should associate v6-specific names with v6 interfaces when nodes having both v4 and v6 interfaces offer some services only over v6 or v4". |
2004-06-09
|
03 | Ted Hardie | [Ballot discuss] The document gives this advice for v6 literals: Prefix/len format should be also considered if surrounding brackets are … [Ballot discuss] The document gives this advice for v6 literals: Prefix/len format should be also considered if surrounding brackets are used. In order to avoid ambiguity, the format, like [2001:db8::]/64 is recommended. As the document notes above, there are some contexts like URIs where there is an established way to handle IPv6 literals, and this format actually would introduce confusion into those. http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]/128 is a perfectly legal URI, but the /128 is the resource at that host, not a prefix/len marker. I believe that this recommendation should be modified to note that the prefix/len mechanism should be used only when there are sufficient cues available to ensure that it does not get carried over into a URI (or similar context) without transformation. |
2004-06-09
|
03 | Ted Hardie | [Ballot Position Update] Position for Ted Hardie has been changed to Discuss from Yes by Ted Hardie |
2004-06-09
|
03 | Ted Hardie | [Ballot Position Update] New position, Yes, has been recorded for Ted Hardie |
2004-06-09
|
03 | Ted Hardie | Ballot has been issued by Ted Hardie |
2004-06-09
|
03 | Ted Hardie | Created "Approve" ballot |
2004-06-03
|
03 | David Kessens | State Changes to IESG Evaluation from Waiting for Writeup by David Kessens |
2004-06-03
|
03 | David Kessens | Placed on agenda for telechat - 2004-06-10 by David Kessens |
2004-05-24
|
03 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
2004-05-13
|
03 | Michelle Cotton | IANA Last Call Comments: We understand this document to have NO IANA Actions. |
2004-05-10
|
03 | Amy Vezza | Last call sent |
2004-05-10
|
03 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2004-05-01
|
03 | Margaret Cullen | [Note]: 'Participant in PROTO Team pilot: Working Group Chair Followup of DISCUSS Comments http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-discuss-pilot-01.txt' added by Margaret Wasserman |
2004-04-20
|
03 | David Kessens | Last Call was requested by David Kessens |
2004-04-20
|
03 | David Kessens | State Changes to Last Call Requested from Publication Requested by David Kessens |
2004-04-20
|
03 | (System) | Ballot writeup text was added |
2004-04-20
|
03 | (System) | Last call text was added |
2004-04-20
|
03 | (System) | Ballot approval text was added |
2004-04-01
|
03 | Dinara Suleymanova | Draft Added by Dinara Suleymanova |
2004-03-31
|
02 | (System) | New version available: draft-ietf-v6ops-application-transition-02.txt |
2004-02-13
|
01 | (System) | New version available: draft-ietf-v6ops-application-transition-01.txt |
2003-12-10
|
00 | (System) | New version available: draft-ietf-v6ops-application-transition-00.txt |