RE: I-D Action:draft-kawamura-ipv6-text-representation-01.txt

["HUANG, ZHIHUI (JERRY), ATTLABS" <jhuang1@att.com>]

Seiichi, 
  Your draft (section 2.2, near bottom of page 5) references RFC4291
section 2.2 on using '::' "to compress leading or trailing zeros in an
address". The example followed in your text doesn't really have either
leading or trailing zeros (2001:db8::aaaa:0:0:1, and
2001:db8:0:0:aaaa::1). My reading of RFC4291 text above points to
compressing, for example, the IPv6 loopback address to '::1' (leading
zeros), but doesn't say about how to deal with multiple "compressible"
chunks of zeros. The same paragraph in RFC4291 also says that  "The '::'
can only appear once in an address". Perhaps that's a better reference
for your intention here where one is forced to and has the flexibility
to choose only one of the compressible zero strings.

  Section 4.1,  should we say "Handling Leading Zeros in a 16 bit Field"
instead of "Handling Leading Zeros" which might also mean "leading zeros
of an IPv6 address".

  Section 4.2.1 and 4.2.3, could we be more explicit and combine these
two to say "Use '::' to replace/compress the longest string of zero
chunks in an address, where there are two such strings of the same
length, the first string is replaced.".

Thanks,
Jerry
--
Jerry Huang, AT&T Labs, +1 630 810 7679
-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
Behalf Of Seiichi Kawamura
Sent: Tuesday, April 21, 2009 10:34 PM
To: Brian E Carpenter
Cc: draft-kawamura-ipv6-text-representation@tools.ietf.org; IPv6
Operations
Subject: Re: I-D Action:draft-kawamura-ipv6-text-representation-01.txt

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Brian, All

Thanks for the comment!

> As I understand it, this draft defines a canonical form
> of address representation and recommends that it be used
> to minimise human confusion.

yes. exactly.

> That isn't a bad idea, but IMHO we need a clear statement
> that humans and algorithms SHOULD generate this format,
> and that all implementations MUST accept any legitimate
> RFC4291 format.

That was sort of my intention with the phrase
"The recommendation in this document is one that,
complies fully with RFC 4291..." (Section 4.)
but maybe I was a bit vague.

It would be nice to hear more thoughts on the draft.

Thanks,
Seiichi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)

iD8DBQFJ7pAfcrhTYfxyMkIRAvXSAJ9m7igwzO/j7YwI3UgxcsBFzgtjZACgjctC
jN+gU6+P2pvILCdtdnLvCs8=
=Fggu
-----END PGP SIGNATURE-----