[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

Hi Jerry

Thanks!

>   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.

I agree. Bad choice of words on my part. This, we'll have to fix.

>   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".

Good idea.

>   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.".

I understand.
In 4.2.1, I was trying to explicitly say that
one should take the longest string of zeros and compress it fully.
There's one router I know that takes 2001:db8:1:1:1::
and shows it as 2001:db8:1:1:1::0
Let me think about this one.

Regards,
Seiichi


HUANG, ZHIHUI (JERRY), ATTLABS wrote:
> 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
> 
> 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

- --
##########################################
NEC BIGLOBE Ltd.
   Platform Systems Division
   Seiichi Kawamura <kawamucho@mesh.ad.jp>
   TEL   : 03-3798-6085 (FAX: 03-3798-6029)
   Mobile: 090-1547-4791
##########################################
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)

iD8DBQFJ7+W6crhTYfxyMkIRAtb5AJ4xFo7lN234s+BxvHFAwZ84ZxWVXwCggEHI
hqkuDWfXaSvCwVmVlF1aRF0=
=A87N
-----END PGP SIGNATURE-----