A Recommendation for IPv6 Address Text Representation
draft-ietf-6man-text-addr-representation-07

Section 1

I found the Introduction rather terse. I suggest reproducing some of 
the text from the Abstract.

The section would benefit from a reference (presumably to RFC 4291) to 
show on what you base your address representations

OLD
All the above point to the same IPv6 address
NEW
All the above represent the same IPv6 address

---

Section 4

The rules in section 4 could be clarified somewhat with examples of
good representation and their meaning as full addresses.

---

Nit

Section 2.2

In case where there are more than one zero fields

s/are/is/

1. If the recommendations in the document apply to prefixes and not only to addresses as section 7 seems to indicate this needs to be said in the introduction, maybe even in the title. 

2. in section 4.2.1 - 'is not considered as clean representation' does not sound good as a normative sentence - probably better say 'is not recommended' (or 'is NOT RECOMMENDED').

3. Security considerations - one can make the argument that following the recommendations in this document leads to an increase in the security of the network, by increasing the efficiency of the abuse handling activities as described in 3.3.3, and by eliminating some of the ambiguities in expressing addresses in various formats, which could potentially be exploited for attacks.

Language & grammar are rough.

Section 3 is trivial and much too long. Suggest to summarize into 1-2 paragraphs and move the long version to an appendix.

I am supporting Lars and Ralphs discusses. 

I think specifying a true canonical form at PS level is a good thing. However, the users of this form need to select it themselves.

Support Lars' discuss

In section 4.2.3, these two sentences are particularly hard to parse:
  "One idea to avoid any confusion, is for the
   operator to not use 16 bit field 0 in the first 64 bits.  By nature
   IPv6 addresses are usually assigned or allocated to end-users from a
   prefix of 32 bits or longer (typically 48 bits or longer)."

Please consider making it clear that the first sentence is an observation about existing practices, not a recommendation or requirement. I'm not sure what the second sentence is trying to accomplish.

  I support the DISCUSS position posted by Lars.

I would prefer to see a single unambiguous representation for display, although I acknowledge 
that may be difficult to achieve consensus.