[Gen-art] Gen-ART Telechat review of draft-ietf-avt-rtp-cnames-03.txt

Suresh Krishnan <suresh.krishnan@ericsson.com> Mon, 03 January 2011 03:28 UTC

Return-Path: <suresh.krishnan@ericsson.com>
X-Original-To: gen-art@core3.amsl.com
Delivered-To: gen-art@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F0A628C0F1 for <gen-art@core3.amsl.com>; Sun, 2 Jan 2011 19:28:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.571
X-Spam-Level:
X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 URD6vF7rlsAS for <gen-art@core3.amsl.com>; Sun, 2 Jan 2011 19:28:06 -0800 (PST)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id A4A3328C0EB for <gen-art@ietf.org>; Sun, 2 Jan 2011 19:28:06 -0800 (PST)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p033UAuU006928 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 2 Jan 2011 21:30:12 -0600
Received: from [142.133.10.113] (147.117.20.213) by eusaamw0711.eamcs.ericsson.se (147.117.20.179) with Microsoft SMTP Server id 8.2.234.1; Sun, 2 Jan 2011 22:30:09 -0500
Message-ID: <4D2141FB.1080608@ericsson.com>
Date: Sun, 02 Jan 2011 22:26:51 -0500
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20101027)
MIME-Version: 1.0
To: General Area Review Team <gen-art@ietf.org>, "draft-ietf-avt-rtp-cnames.all@tools.ietf.org" <draft-ietf-avt-rtp-cnames.all@tools.ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [Gen-art] Gen-ART Telechat review of draft-ietf-avt-rtp-cnames-03.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Jan 2011 03:28:08 -0000

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-avt-rtp-cnames-03.txt
Reviewer: Suresh Krishnan
Review Date: 2011/01/02
IESG Telechat date: 2011/01/06

Summary: This draft has addressed my comments from the previous Last 
Call review but has a new issue that needs to be fixed before 
publication as a Proposed Standard.

* Section 5 Step 2

This step describes the use of an EUI-64 identifier and how to generate 
one if it does not exists. The procedure for the creation of the EUI-64 
from a 48 bit MAC address is incorrect.

RFC4291 describes how to create a **modified EUI-64** identifier (and 
not a EUI-64 identifier) from a MAC address.

A MAC address of xx:78:90:12:34:56 will be transformed to a modified 
EUI-64 of

yy7890FFFE123456

where yy is the value of xx with the u/l bit (bit 6) flipped.

The IEEE reference for creation of an EUI-64 from a 48 bit MAC address

http://standards.ieee.org/develop/regauth/tut/eui64.pdf

would result in an EUI-64 of

xx7890FFFF123456 for the same MAC address.

I understand that there will be no interoperability issues due to this 
(since the cname is opaque) but there may be issues with testing 
compliance (since the expected hash values will be way off).

I recommend either using the term "modified EUI-64" instead of EUI-64 or 
changing the reference from RFC4291 to the IEEE document in order to fix 
this inconsistency.

Thanks
Suresh