A Recommendation for IPv6 Address Text Representation
RFC 5952

Note: This ballot was opened for revision 07 and is now closed.

(Cullen Jennings) Discuss

Discuss (2010-02-04 for -** No value found for 'p.get_dochistory.rev' **)
I'd like to reread the next version of this document.

(Jari Arkko) Yes

Alexey Melnikov Yes

(Ron Bonica) (was Discuss) No Objection

(Ralph Droms) (was Discuss) No Objection

(Lars Eggert) (was Discuss) No Objection

Comment (2010-02-02)
No email
send info
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.

(Pasi Eronen) No Objection

(Adrian Farrel) (was Discuss) No Objection

Comment (2010-02-01)
No email
send info
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/

(Russ Housley) No Objection

Comment (2010-02-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  I support the DISCUSS position posted by Lars.

(Tim Polk) (was No Record, Discuss) No Objection

Comment (2010-02-03)
No email
send info
I would prefer to see a single unambiguous representation for display, although I acknowledge 
that may be difficult to achieve consensus.

(Dan Romascanu) (was Discuss) No Objection

Comment (2010-02-04)
No email
send info
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.

(Robert Sparks) No Objection

Comment (2010-02-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

Magnus Westerlund No Objection

Comment (2010-02-04 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.