Re: Review requested: draft-kawamura-ipv6-text-representation-02

Suresh Krishnan <suresh.krishnan@ericsson.com> Tue, 19 May 2009 15:51 UTC

Return-Path: <suresh.krishnan@ericsson.com>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FAF83A6F5A for <ipv6@core3.amsl.com>; Tue, 19 May 2009 08:51:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.245
X-Spam-Level:
X-Spam-Status: No, score=-6.245 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCYzZqyoIGLG for <ipv6@core3.amsl.com>; Tue, 19 May 2009 08:51:37 -0700 (PDT)
Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id AD4EC3A6FA4 for <ipv6@ietf.org>; Tue, 19 May 2009 08:51:29 -0700 (PDT)
Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n4JG3fN8002744; Tue, 19 May 2009 11:03:41 -0500
Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 May 2009 10:52:36 -0500
Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 May 2009 10:52:35 -0500
Message-ID: <4A12D57E.8020605@ericsson.com>
Date: Tue, 19 May 2009 11:51:26 -0400
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
User-Agent: Thunderbird 2.0.0.21 (X11/20090318)
MIME-Version: 1.0
To: Seiichi Kawamura <kawamucho@mesh.ad.jp>
Subject: Re: Review requested: draft-kawamura-ipv6-text-representation-02
References: <4A09523C.2090109@innovationslab.net> <4A0D7667.2060902@ericsson.com> <4A0D90C1.3010805@mesh.ad.jp>
In-Reply-To: <4A0D90C1.3010805@mesh.ad.jp>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 May 2009 15:52:35.0895 (UTC) FILETIME=[D43A3470:01C9D899]
Cc: Brian Haberman <brian@innovationslab.net>, IPv6 WG Mailing List <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 May 2009 15:51:38 -0000

Hi Seiichi,
   Please find responses inline.

On 15/05/09 11:56 AM, Seiichi Kawamura wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Suresh
> 
>>   I like the idea of this draft. Thanks for writing this. It would
>> simplify things a lot for debugging purposes. 
> 
> and thank you for taking the time to read and comment!
> 
>> * It is not clear WHO needs to comply with the recommendations in the
>> draft. i.e. who is the targeted audience?
> 
> Section4. states
> 
>    recommendation in this document SHOULD be followed by humans and
>    systems when generating an address to represent as text, but all
>    implementations MUST accept any legitimate [RFC4291] format.
> 
> this was advised to me by Brian Carpenter that it was needed.
> Does this answer your question?

Sounds good. I would like such text to be present in the abstract 
section as well.

> 
>> * I think recommendations 2 and 3 are redundant and can be merged into one.
> 
> I assume you are talking about the conclusion.
> Do you think that it should read something like this?
> 
>  (2) "::" used to their maximum extent where shortens address the most

I will try to come up with some text for the recommendations.

> 
> I got a similar comment on v6ops BTW.
> 
>> * I see a missing requirement that states that an occurrence of 2 or
>> more zero 16-bit groups MUST be compressed. So an address like
>> 2001:0:0:0:0:0:0:1 is still valid according to the current draft.
> 
> You may be right.
> I thought '(2) "::" used to their maximum extent whenever possible'
> did enough to clarify, but a little rewording might be needed.
> Thanks.

OK.

> 
>> * I think Appendix D is completely out of place in this document and
>> should preferably be removed. (I also agree with Dave's comment about
>> Appendix A)
> 
> Appendix A, yes I would go with dot-decimal also.
> Appendix D, I don't know. I thought it would be informative
> to other operators (since we have to pronounce addresses fairly
> often over the phone)...

I prefer removing it altogether but I am not opposed to having it in the 
document.

Thanks
Suresh