Skip to main content

Early Review of draft-ietf-6man-rdnss-rfc6106bis-14
review-ietf-6man-rdnss-rfc6106bis-14-intdir-early-halley-2016-10-17-00

Request Review of draft-ietf-6man-rdnss-rfc6106bis
Requested revision No specific revision (document currently at 16)
Type Early Review
Team Internet Area Directorate (intdir)
Deadline 2016-10-17
Requested 2016-10-06
Authors Jaehoon Paul Jeong , Soohong Daniel Park , Luc Beloeil , Syam Madanapalli
I-D last updated 2016-10-17
Completed reviews Intdir Early review of -14 by Bob Halley (diff)
Genart Last Call review of -14 by Christer Holmberg (diff)
Secdir Last Call review of -14 by Derek Atkins (diff)
Opsdir Last Call review of -14 by Tim Chown (diff)
Assignment Reviewer Bob Halley
State Completed
Request Early review on draft-ietf-6man-rdnss-rfc6106bis by Internet Area Directorate Assigned
Reviewed revision 14 (document currently at 16)
Completed 2016-10-17
review-ietf-6man-rdnss-rfc6106bis-14-intdir-early-halley-2016-10-17-00
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