[Int-dir] Review of draft-ietf-6man-rdnss-rfc6106bis-14

Bob Halley <Bob.Halley@nominum.com> Thu, 13 October 2016 11:32 UTC

Return-Path: <Bob.Halley@nominum.com>
X-Original-To: int-dir@ietfa.amsl.com
Delivered-To: int-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479F612970F for <int-dir@ietfa.amsl.com>; Thu, 13 Oct 2016 04:32:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.897
X-Spam-Level:
X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHtxCQJuH3kY for <int-dir@ietfa.amsl.com>; Thu, 13 Oct 2016 04:32:33 -0700 (PDT)
Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B7B01294C2 for <int-dir@ietf.org>; Thu, 13 Oct 2016 04:32:33 -0700 (PDT)
Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 0E16F74041A; Thu, 13 Oct 2016 11:32:33 +0000 (UTC)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.235.68]) by CAS-03.WIN.NOMINUM.COM ([64.89.235.66]) with mapi id 14.03.0319.002; Thu, 13 Oct 2016 04:32:32 -0700
From: Bob Halley <Bob.Halley@nominum.com>
To: "int-dir@ietf.org" <int-dir@ietf.org>, "draft-ietf-6man-rdnss-rfc6106bis@tools.ietf.org" <draft-ietf-6man-rdnss-rfc6106bis@tools.ietf.org>
Thread-Topic: Review of draft-ietf-6man-rdnss-rfc6106bis-14
Thread-Index: AQHSJUV8YXuM8z1ZkESWaCSQRwfncQ==
Date: Thu, 13 Oct 2016 11:32:31 +0000
Message-ID: <29122875-DEAB-4040-A3D5-9BF8F46DBEF7@nominum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1c.0.160927
x-originating-ip: [162.206.76.144]
Content-Type: text/plain; charset="utf-8"
Content-ID: <25B5FC12DB8F4843ADA5E707C1795C01@nominum.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-dir/C5eq4V6dEmNKpwxZx--9OK_KbDY>
Subject: [Int-dir] Review of draft-ietf-6man-rdnss-rfc6106bis-14
X-BeenThere: int-dir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This list is for discussion between the members of the Internet Area directorate." <int-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-dir>, <mailto:int-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-dir/>
List-Post: <mailto:int-dir@ietf.org>
List-Help: <mailto:int-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-dir>, <mailto:int-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Oct 2016 11:32:35 -0000

I am an assigned INT directorate reviewer for draft-ietf-6man-rdnss-rfc6106bis-14.  These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/directorate.html.

I read the document and I didn’t find any significant issues.

My only quibble is with the description of the “Domain Names of DNS Search List” in section 5.2, where the padding is done with zero octets.  The text neglects the meaning of the zero octet at the end of domain names, namely that it is the root label.  The root label is, by itself, also a valid domain name.  So it’s wrong to say

“Because the size of this field MUST be a multiple of 8 octets, for the minimum multiple including the domain name representations, the remaining octets other than the encoding parts of the domain name representations MUST be padded with zeros.”

because both the search list values and the pad values are domain name representations.  What you’re really doing here is “padding with the root name”, with the understanding that the root name would not be part of a search list.  I think that’s a reasonable restriction, as I’ve never heard of anyone using the root name on a search list.

I’m ok with this padding method, but I’ll point out another alternative, which is to pad with 0xff, which cannot be the start of a domain name.  (In theory domain names could be extended to use those bits, but experience with “binary labels” showed this doesn’t work in the real world; there’s no good way to do the transition.)

/Bob