Subject: I-D Action:draft-ietf-6man-text-addr-representation-07.txt

From: [email-masked]
Date: Thu, 25 Feb 2010 18:30:02 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance Working Group of the IETF.

	Title           : A Recommendation for IPv6 Address Text Representation
	Author(s)       : S. Kawamura, M. Kawashima
	Filename        : draft-ietf-6man-text-addr-representation-07.txt
	Pages           : 14
	Date            : 2010-02-25

As IPv6 deployment increases there will be a dramatic increase in the
need to use IPv6 addresses in text.  While the IPv6 address
architecture in RFC 4291 section 2.2 describes a flexible model for
text representation of an IPv6 address this flexibility has been
causing problems for operators, system engineers, and users.  This
document defines a canonical textual representation format.  It does
not define a format for internal storage, such as within an
application or database.  It is expected that the canonical format is
followed by humans and systems when representing IPv6 addresses as
text, but all implementations must accept and be able to handle any
legitimate RFC 4291 format.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-6man-text-addr-representation-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Seiichi Kawamura <[email-masked]>
Date: Fri, 26 Feb 2010 12:20:56 +0900

I have committed the changes.
Thanks to everyone that helped.
All issues raised should be clear now.

Regards,
Seiichi

[email-masked] wrote:
> ------------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Doug Barton <[email-masked]>
Date: Fri, 26 Feb 2010 14:06:09 -0800

> 	Filename        : draft-ietf-6man-text-addr-representation-07.txt

At the risk of being redundant I'm including a diff that consists only
of a few minor nits. I'm still supportive of the draft moving forward
with or without these changes.

Regards,

Doug

-- 

	... and that's just a little bit of history repeating.
			-- Propellerheads

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/

--- draft-ietf-6man-text-addr-representation-07.txt-orig	2010-02-26 13:44:35.000000000 -0800
+++ draft-ietf-6man-text-addr-representation-07.txt	2010-02-26 14:02:03.000000000 -0800
@@ -214,9 +214,9 @@
       field.'
 
    Conversely it is also not necessary to omit leading zeros.  This
-   means that, it is possible to select from such as the following
-   example.  The final 16 bit field is different, but all these
-   addresses represent the same address.
+   means that it is possible to select from any of the following
+   examples.  The final 16 bit field is different, but all of these
+   examples represent the same address.

@@ -238,14 +238,14 @@
       'A special syntax is available to compress the zeros.  The use of
       "::" indicates one or more groups of 16 bits of zeros.'
 
-   It is possible to select whether or not to omit just one 16 bits of
+   It is possible to select whether or not to omit just one 16 bit field of
    zeros.
 
       2001:db8:aaaa:bbbb:cccc:dddd::1
 
       2001:db8:aaaa:bbbb:cccc:dddd:0:1
 
-   In case where there is more than one zero fields, there is a choice
+   In cases where there is more than one field of only zeros there is a choice
    of how many fields can be shortened.
 
       2001:db8:0:0:0::1
@@ -305,7 +305,7 @@
 
 3.1.2.  Searching Spreadsheets and Text Files
 
-   Spreadsheet applications and text editors on GUI systems, rarely have
+   Spreadsheet applications and text editors on GUI systems rarely have
    the ability to search for a text using regular expression.  Moreover,
    there are many non-engineers (who are not aware of case sensitivity
    and regular expression use) that use these application to manage IP
@@ -346,7 +346,7 @@
 3.1.4.  Searching for an Address in a Network Diagram
 
    Network diagrams and blueprints often show what IP addresses are
-   assigned to a system devices.  In times of trouble shooting there may
+   assigned to system devices.  In times of trouble shooting there may
    be a need to search through a diagram to find the point of failure
    (for example, if a traceroute stopped at 2001:db8::1, one would
    search the diagram for that address).  This is a technique quite

---

From: Роман Донченко <[email-masked]>
Date: Sat, 27 Feb 2010 01:53:20 +0300

Doug Barton <[email-masked]> писал в своём письме Sat, 27 Feb 2010  

> with or without these changes.

Since we seem to go over small nits now, I'll submit a couple of my own:

--- draft-ietf-6man-text-addr-representation-07.txt.old	2010-02-26  
22:36:32 +0000
+++ draft-ietf-6man-text-addr-representation-07.txt	2010-02-26 22:47:37  
+0000
@@ -603,7 +603,7 @@
     o  2001:db8::1#80

     The situation is not much different in IPv4, but the most ambiguous
-   case with IPv6 is the second bullet.  This is due to the "::"usage in
+   case with IPv6 is the second bullet.  This is due to the usage of "::"  
in
     IPv6 addresses.  This style is NOT RECOMMENDED for its ambiguity.
     The [] style as expressed in [RFC3986] SHOULD be employed, and is the
     default unless otherwise specified.  Other styles are acceptable when
@@ -648,7 +648,7 @@
     starting this document.  We also would like to thank Brian Carpenter,
     Akira Kato, Juergen Schoenwaelder, Antonio Querubin, Dave Thaler,
     Brian Haley, Suresh Krishnan, Jerry Huang, Roman Donchenko, Heikki
-   Vatiainen ,Dan Wing, and Doug Barton for their input.  Also a very
+   Vatiainen, Dan Wing, and Doug Barton for their input.  Also a very
     special thanks to Ron Bonica, Fred Baker, Brian Haberman, Robert
     Hinden, Jari Arkko, and Kurt Lindqvist for their support in bringing
     this document to the light of IETF working groups.
@@ -702,7 +702,7 @@
     these rules.  For example, the usage of getnameinfo() with flags
     argument NI_NUMERICHOST in FreeBSD 7.0 will give a conforming output,
     except for the special addresses notes in Section 5.  The function
-   inet_ntop() of FreeBSD7.0 is a good C code reference, but should not
+   inet_ntop() of FreeBSD 7.0 is a good C code reference, but should not
     be called directly.  See [RFC4038] for details.

Roman.