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

From: [email-masked]
Date: Fri, 19 Feb 2010 02:00:01 -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-06.txt
	Pages           : 14
	Date            : 2010-02-19

As IPv6 network grows, there will be more engineers and also non-
engineers who will have the need to use an IPv6 address in text.
While the IPv6 address architecture RFC 4291 section 2.2 depicts a
flexible model for text representation of an IPv6 address, this
flexibility has been causing problems for operators, system
engineers, and users.  This document will describe the problems that
a flexible text representation has been causing.  This document also
recommends a canonical representation format that best avoids
confusion.  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
RFC4291 format.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-6man-text-addr-representation-06.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: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Feb 2010 17:15:08 +1300

Hi,

I'm generally happy with the changes.

However, I am slightly bothered by this:

   For URIs, [RFC3986] MUST be followed.

RFC 3986 allows any syntax that conforms to its BNF, and for
IPv6 literals, that BNF implements RFC 3513 (the predecessor
of RFC 4291). If you strictly obey the sentence quoted above,
URIs are therefore not limited to the new canonical form.
I think the sentence needs to be a bit more explicit:

   For URIs containing IPv6 address literals, [RFC3986] MUST
   be followed, as well as the rules in this document.

Nit: [RFC3986] needs to be moved to the Normative References.

   Brian

---

From: Doug Barton <[email-masked]>
Date: Sat, 20 Feb 2010 19:24:10 -0800

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

I've reviewed the draft and am supportive of it moving forward. I've
attached a diff with some edits that I hope are useful. Whether the
edits are included or not I am still supportive of the draft.

My suggested changes are almost all of the "wordsmithing" variety. In
rough order of frequency:
1. Removed a lot of commas. (I have a tendency to add too many commas
myself so I'm particularly sensitive to this when reading other people's
work.) :)
2. Removed a lot of lines of the nature "Examples of this are below."
These lines did not add clarity to the text (as it was already clear
that the examples were examples).

There are two "substantive" changes. First, in section 3.1.2 I thought
that the duplicate address example was weak and unnecessary, so I
deleted it. (Wouldn't DAD handle this?)

The more substantive change is the section I added:

4.2.4.  Exception to the "::" Shortening Rule

  When it is necessary to record an address with consecutive 16 bit 0
  fields without the use of the "::" symbol, for example in a database,
  each such field SHOULD be represented with one, and only one zero. For
  example 2001:db8:0:0:0:0:0:1. However when the address is written out
  for human consumption the "::" MUST be used as described in the sections
  above.

I realize that this idea has complications, not the least of which is
that it seems to be creating an exception to the idea of a "canonical"
text representation. However in just the little bit of work that I've
done with recording, comparing, etc. IPv6 addresses I've already run
into situations where this is useful, and I think that it would be
beneficial to document the concept so that people who face the same
issue will have some guidance in how to proceed. If the group does not
agree that this is useful I have no problem with it not being included.

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-06.txt.orig	2010-02-20 15:14:38.000000000 -0800
+++ draft-ietf-6man-text-addr-representation-06.txt	2010-02-20 19:21:55.000000000 -0800
@@ -13,10 +13,10 @@
 
 Abstract
 
-   As IPv6 network grows, there will be more engineers and also non-
-   engineers who will have the need to use an IPv6 address in text.
-   While the IPv6 address architecture RFC 4291 section 2.2 depicts a
-   flexible model for text representation of an IPv6 address, this
+   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 will describe the problems that
    a flexible text representation has been causing.  This document also
@@ -24,7 +24,7 @@
    confusion.  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
-   RFC4291 format.
+   RFC 4291 format.
 
 Status of this Memo
 
@@ -171,8 +171,7 @@
 
 1.  Introduction
 
-   A single IPv6 address can be text represented in many ways.  Examples
-   are shown below.
+   A single IPv6 address can be text represented in many ways:
 
       2001:db8:0:0:1:0:0:1
 
@@ -190,11 +189,10 @@
 
       2001:DB8:0:0:1::1
 
-   All the above represent the same IPv6 address.  This flexibility has
+   All of the above examples represent the same address.  This flexibility has
    caused many problems for operators, systems engineers, and customers.
-   The problems will be noted in Section 3.  Also, a canonical
-   representation format to avoid problems will be introduced in
-   Section 4.
+   The problems are noted in Section 3.  Also, a canonical
+   representation format to avoid problems is introduced in Section 4.
 
 1.1.  Requirements Language
 
@@ -213,10 +211,9 @@
       'It is not necessary to write the leading zeros in an individual
       field.'
 
-   In other words, 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 mean the same.
+   Conversely it is not necessary to omit leading zeros. 
+   The final 16 bit field is different, but all of these
+   examples represent the same address:

@@ -238,15 +235,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
-   zeros.
+   Whether or not to omit just one 16 bit field of zeros is optional.
 
       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
-   of how many fields can be shortened.  Examples follow.
+   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
 
@@ -260,8 +256,8 @@
 
       'The "::" can only appear once in an address.'
 
-   This gives a choice on where, in a single address to compress the
-   zero.  Examples are shown below.
+   This gives a choice of where in a single address to compress the
+   zeros.
 
       2001:db8::aaaa:0:0:1
 
@@ -269,8 +265,8 @@
 
 2.3.  Uppercase or Lowercase
 
-   [RFC4291] does not mention about preference of uppercase or
-   lowercase.  Various flavors are shown below.
+   [RFC4291] does not mention any preference of uppercase or
+   lowercase.

@@ -294,40 +290,35 @@
 
 3.1.1.  General Summary
 
-   A search of an IPv6 address if conducted through a UNIX system is
-   usually case sensitive and extended options to allow for regular
-   expression use will come in handy.  However, there are many
-   applications in the Internet today that do not provide this
-   capability.  When searching for an IPv6 address in such systems, the
-   system engineer will have to try each and every possibility to search
+   On Unix systems while searches are generally case sensitive
+   options exist to deal with this. 
+   However, there are many
+   applications on the Internet today that do not provide this
+   capability.  When searching for an IPv6 address on these systems the
+   operator will have to try each and every possible representation
    for an address.  This has critical impacts especially when trying to
    deploy IPv6 over an enterprise network.
 
 3.1.2.  Searching Spreadsheets and Text Files
 
-   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
-   addresses.  This has worked quite well with IPv4 since text
-   representation in IPv4 has very little flexibility.  There is no
-   incentive to encourage these non-engineers to change their tool or
-   learn regular expression when they decide to go dual-stack.  If the
-   entry in the spreadsheet reads, 2001:db8::1:0:0:1, but the search was
-   conducted as 2001:db8:0:0:1::1, this will show a result of no match.
-   One example where this will cause problem is, when the search is
-   being conducted to assign a new address from a pool, and a check was
-   being done to see if it was not in use.  This may cause problems to
-   the end-hosts or end-users.  This type of address management is very
-   often seen in enterprise networks and also in ISPs.
+   Spreadsheet applications and text editors on GUI systems rarely have
+   the ability to search using regular expression.  Moreover
+   there are many users that use these application to manage IP
+   addresses who are not aware of case sensitivity and regular expression
+   use.
+   These limitations have not created problems with IPv4 since text
+   representation for those addresses has very little flexibility.
+   To the extent possible non-technical users should be able to use
+   the same tools with IPv6 addresses that they are already familiar
+   with for IPv4 addresses.
 
 3.1.3.  Searching with Whois
 
-   The "whois" utility is used by a wide range of people today.  When a
-   record is set to a database, one will likely check the output to see
+   The "whois" utility is used by a wide range of people today.  When
+   the response is received one will likely check the output to see
    if the entry is correct.  If an entity was recorded as 2001:db8::/48,
    but the whois output showed 2001:0db8:0000::/48, most non-engineers
-   would think that their input was wrong, and will likely retry several
+   would think that their input was wrong and likely retry several
    times or make a frustrated call to the database hostmaster.  If there

@@ -341,31 +332,31 @@
    each system showed a different text representation, this would
    confuse people even more.  Although this document focuses on
    addresses rather than prefixes, this is worth mentioning since
-   problems encountered are mostly equal.
+   the problems encountered are mostly equal.
 
 3.1.4.  Searching for an Address in a Network Diagram
 
-   Network diagrams and blue-prints often show what IP addresses are
-   assigned to a system devices.  In times of trouble shooting, there
+   Network diagrams and blueprints often show what IP addresses are
+   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 often in use in enterprise networks and managed services.
+   failure. For example if a traceroute stopped at 2001:db8::1 one
+   would search the diagram for that address.  This is a technique
+   quite often used in enterprise networks and managed services.
    Again, the different flavors of text representation will result in a
-   time-consuming search, leading to longer MTTR in times of trouble.
+   time-consuming search leading to longer MTTR in times of trouble.
 
 3.2.  Parsing and Modifying
 
 3.2.1.  General Summary
 
-   With all the possible text representation ways, each application must
+   With all the possible methods of text representation each application must
    include a module, object, link, etc. to a function that will parse
    IPv6 addresses in a manner that no matter how it is represented, they
    will mean the same address.  Many system engineers who integrate
-   complex computer systems to corporate customers will have
+   complex computer systems for corporate customers will have
    difficulties finding that their favorite tool will not have this
    function, or will encounter difficulties such as having to rewrite
-   their macro's or scripts for their customers.
+   their macros or scripts for their customers.
 
 3.2.2.  Logging
 
@@ -373,17 +364,17 @@
    address in full (such as 2001:0db8:0000:0000:1111:2222:3333:4444),
    the output would be highly unreadable compared to the IPv4 output.
    The address would have to be parsed and reformed to make it useful
-   for human reading.  Sometimes, logging for critical systems is done
+   for human reading.  Sometimes logging for critical systems is done
    by mirroring the same traffic to two different systems.  Care must be
-   taken that no matter what the log output is, the logs should be
+   taken so that no matter what the log output is the logs should be
    parsed so they will mean the same.
 
 3.2.3.  Auditing: Case 1
 
    When a router or any other network appliance machine configuration is
-   audited, there are many methods to compare the configuration
-   information of a node.  Sometimes, auditing will be done by just
-   comparing the changes made each day.  In this case, if configuration
+   audited there are many methods to compare the configuration
+   information of a node.  Sometimes auditing will be done by just
+   comparing the changes made each day.  In this case if configuration
    was done such that 2001:db8::1 was changed to 2001:0db8:0000:0000:

@@ -395,19 +386,19 @@
 
    0000:0000:0000:0001 just because the new engineer on the block felt
    it was better, a simple diff will show that a different address was
-   configured.  If this was done on a wide scale network, people will be
+   configured.  If this was done on a wide scale network people will be
    focusing on 'why the extra zeros were put in' instead of doing any
-   real auditing.  Lots of tools are just plain 'diff's that do not take
+   real auditing.  Lots of tools are just plain diffs that do not take
    into account address representation rules.
 
 3.2.4.  Auditing: Case 2
 
    Node configurations will be matched against an information system
-   that manages IP addresses.  If output notation is different, there
+   that manages IP addresses.  If output notation is different there
    will need to be a script that is implemented to cover for this.  The
-   result of an SNMP GET operation, converted to text and compared to a
+   result of an SNMP GET operation converted to text and compared to a
    textual address written by a human is highly unlikely to match on
-   first try.
+   the first try.
 
 3.2.5.  Verification
 
@@ -437,7 +428,7 @@
 
 3.3.2.  Customer Calls
 
-   When a customer calls to inquire about a suspected outage, IPv6
+   When a customer calls to inquire about a suspected outage IPv6
    address representation should be handled with care.  Not all
    customers are engineers nor have the same skill in IPv6 technology.
    The network operations center will have to take extra steps to
@@ -456,7 +447,7 @@
 
 3.3.3.  Abuse
 
-   Network abuse is reported along with the abusing IP address.  This
+   Network abuse reports generally include the abusing IP address.  This
    'reporting' could take any shape or form of the flexible model.  A
    team that handles network abuse must be able to tell the difference
    between a 2001:db8::1:0:1 and 2001:db8:1::0:1.  Mistakes in the
@@ -481,7 +472,7 @@
 
 3.4.2.  Preference in Documentation
 
-   A document that is edited by more than one author, may become harder
+   A document that is edited by more than one author may become harder
    to read.
 
 3.4.3.  Legibility
@@ -494,7 +485,7 @@
 
    A recommendation for a canonical text representation format of IPv6
    addresses is presented in this section.  The recommendation in this
-   document is one that, complies fully with [RFC4291], is implemented
+   document is one that: complies fully with [RFC4291], is implemented
    by various operating systems, and is human friendly.  The
    recommendation in this section SHOULD be followed by systems when
 
@@ -508,7 +499,7 @@
    generating an address to represent as text, but all implementations
    MUST accept and be able to handle any legitimate [RFC4291] format.
    It is advised that humans also follow these recommendations when
-   spelling an address.
+   writing an address.
 
 4.1.  Handling Leading Zeros in a 16 Bit Field
 
@@ -520,7 +511,7 @@
 
 4.2.1.  Shorten As Much As Possible
 
-   The use of symbol "::" MUST be used to its maximum capability.  For
+   When used the "::" symbol MUST be used to its maximum capability.  For
    example, 2001:db8::0:1 is not acceptable, because the symbol "::"
    could have been used to produce a shorter representation 2001:db8::1.
 
@@ -540,6 +531,15 @@
    bits MUST be shortened.  For example 2001:db8::1:0:0:1 is correct
    representation.
 
+4.2.4.  Exception to the "::" Shortening Rule
+
+   When it is necessary to record an address with consecutive 16 bit 0
+   fields without the use of the "::" symbol, for example in a database,
+   each such field SHOULD be represented with one, and only one zero. For
+   example 2001:db8:0:0:0:0:0:1. However when the address is written out
+   for human consumption the "::" MUST be used as described in the sections
+   above.
+
 4.3.  Lower Case
 
    The characters "a", "b", "c", "d", "e", "f" in an IPv6 address MUST
@@ -587,8 +587,7 @@
 6.  Notes on Combining IPv6 Addresses with Port Numbers
 
    When IPv6 addresses and port numbers are represented in text combined
-   together, there are many different ways to do so.  Examples are shown
-   below.
+   together, there are many different ways to do so.
 
    o  [2001:db8::1]:80
 
@@ -602,8 +601,8 @@
 
    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
+   The situation is not much different from IPv4 but the most ambiguous
+   case with IPv6 is the second bullet.  This is due to the "::" usage 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
@@ -623,13 +622,13 @@
 7.  Prefix Representation
 
    Problems with prefixes are just the same as problems encountered with
-   addresses.  Text representation method of IPv6 prefixes should be no
+   addresses.  The text representation method for IPv6 prefixes should be no
    different from that of IPv6 addresses.

 8.  Security Considerations
 
-   This document notes on some examples where IPv6 addresses are
+   This document notes some examples where IPv6 addresses are
    compared in text format.  The example on Section 3.2.5 is one that
    may cause a security risk if used for access control.  The common
    practice of comparing X.509 data is done in binary format.

---

From: Antonio Querubin <[email-masked]>
Date: Sat, 20 Feb 2010 20:30:31 -1000 (HST)

>  for human consumption the "::" MUST be used as described in the sections

If the field in the database is text-based, then I think we really should 
adhere to the same rule.  If the field uses anything other than text, then 
I think it's out of scope.

Antonio Querubin
808-545-5282 x3003
e-mail/xmpp:  [email-masked]

---

From: Doug Barton <[email-masked]>
Date: Sat, 20 Feb 2010 22:38:45 -0800

On 02/20/10 22:30, Antonio Querubin wrote:
> If the field in the database is text-based, then I think we really
> should adhere to the same rule.  If the field uses anything other than
> text, then I think it's out of scope.

If the address is stored in one chunk I'm sympathetic to your line of
reasoning, and as I said in my post I realize that including the section
I wrote isn't a slam dunk. However I'm also concerned about the scenario
where each 16-bit field is stored in its own database field. If that
qualifies as out of scope by your definition above, that's Ok too.

Doug

--

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 22 Feb 2010 08:01:22 +1300

> qualifies as out of scope by your definition above, that's Ok too.

I think it's out of scope of a *protocol* standard. However, I think Doug
has a valid point, so maybe we should add an explicit statement that
the document defines what should be transmitted and presented to humans,
but does not define internal storage within an application or database.

    Brian

---

From: Doug Barton <[email-masked]>
Date: Sun, 21 Feb 2010 12:58:37 -0800

> but does not define internal storage within an application or database.

That would be ok with me, thank you for suggesting it.

Doug

--

---

From: Seiichi Kawamura <[email-masked]>
Date: Mon, 22 Feb 2010 16:16:15 +0900

Hi Doug

I'm willing to take Brian's
suggestions on this one.

Thank you very much for the suggestion though,
and also the editorial tips.

Regards,
Seiichi

---

From: Seiichi Kawamura <[email-masked]>
Date: Mon, 22 Feb 2010 16:25:21 +0900

Hi Brian

>    be followed, as well as the rules in this document.

Couldn't be put any more clear than this.
Thank you.

Regards,
Seiichi

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

---

From: Antonio Querubin <[email-masked]>
Date: Wed, 24 Feb 2010 22:10:47 -1000 (HST)

> but does not define internal storage within an application or database.

The abstract and introduction seemed to already imply this but how about

s/This document also recommends a canonical representation format that 
best avoids confusion./To avoid confusion this document recommends a 
canonical text presentation format but does not define internal storage 
formats within an application or database./

Antonio Querubin
808-545-5282 x3003

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Feb 2010 08:56:25 +1300

> formats within an application or database./

Sure

    Brian

---

From: Doug Barton <[email-masked]>
Date: Thu, 25 Feb 2010 13:21:18 -0800

> formats within an application or database./

I like the idea, but IMO it's a little too redundant and repetitive. :)
I thought some of Brian's wording was good, and some of yours, and I
think that mentioning explicitly what IS first is a good idea. Something
like:

This document defines a representation format for transmission and
presentation to humans. It does not define a format for internal
storage, such as within an application or database.

Sound good?

Doug

--

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Feb 2010 23:29:38 +0100

> storage, such as within an application or database.

Adding one more to the beauty contest:

  This document defines a canonical textual representation format. It
  does not define a format for internal storage, such as within an
  application or database.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Doug Barton <[email-masked]>
Date: Thu, 25 Feb 2010 14:30:56 -0800

>   does not define a format for internal storage, such as within an

That's fine with me.

Doug

--

---

From: Seiichi Kawamura <[email-masked]>
Date: Fri, 26 Feb 2010 09:16:11 +0900

Brian, Doug, Antonio

Thanks for the text idea.
So the final fix will probably look like this.

   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.

I'm also going to change the MUST phrase in Section 6 to

as suggested by Brian.

I'll also take some of the editorial fixes suggested by Doug.

Regards,
Seiichi

---

From: Doug Barton <[email-masked]>
Date: Thu, 25 Feb 2010 16:22:03 -0800

>    implementations must accept and be able to handle any legitimate

This looks great!

> I'll also take some of the editorial fixes suggested by Doug.

No worries, I'll be pleased to know that you find any of it useful. :)

Doug

--