Subject: (IPng 7271) draft-ietf-ipngwg-icmp-name-lookups-03.txt

From: Robert Elz <[email-masked]>
Date: Fri, 05 Mar 1999 21:18:40 +1100

A few nits ...

In section 4 ..

   If the Queried Address was anycast, the source adderss for the Reply should
   be one belonging to the interface on which the Query was received.

Is it not possible for a request to be sent to an anycast address and
arrive via an interface which has no address of its own (or have we
deprecated addressless interfaces in IPv6 and I just failed to notice) ?

In section 5.3 ..

    FQDN        The fully-qualified domain name of the Responder which
                corresponds to the Queried Address, as a sequence of
                NameLen US-ASCII octets, with periods between the
                labels, and no period after the last label.

That's inadequate.   First, there is a (very slow, perhaps almost comatose)
gradual motion towards UTF-8 being allowed for names.  US-ASCII is a retrograde
step here (further, there doesn't seem to be any real reason for that).

Second, whether the name is restricted to ascii or not, using periods as
separators limits the names more than the DNS does.   There are three
conceivable solutions to this one ... limit the names even more, by
prohibiting '.' as a character in a label (the DNS does not do that),
add an escaping mechanism (the way the DNS does in text files) to allow
the '.' to appear (and the escape character itself as well of course)
as a literal, rather than as a separator (or escape).  Doing that would
mean that an 8 bit length field would be inadequate though, at least 8
bits would be required to cope with the worst case.   Or, simply encode
the name the way the DNS encodes names (ignoring DNS name compression), as
a series of length counted labels (with count bytes replacing the dots,
more or less).   I prefer the third, it is by far the cleanest way.

I am not sure I quite believe that the TTL field in the FQDN query
is quite being used the right way.   The TTL of an address->name binding
doesn't necessarily have much at all to do with the TTL of the associated
name->address binding, much less the TTL on a lease granting that address
to a particlar need.  (Sure, in some, perhaps even many, cases they're
related, but not by necessity).   At the very least I'd like to see some
kind of justification for the TTL definition being the way it is.

Last in 5.3.1.1 (which I would guess was really intended to be 5.4) ..

    T   Defined in a Reply only, indicates that the set of addresses is
        inclomplete for space reasons.

Is there to be any hint as to what "space reasons" might be sanely applied
here?   That is, is returning no addresses, and setting the T bit instead
acceptable?   Or is it intended that the T bit be set only when the
reply would be greater than the max payload (65536 since I don't think we
permit jumbogram ICMP messages)?   Or perhaps it can/should be set if the
reply would otherwise need to be fragmented?

kre

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Robert Elz <[email-masked]>
Date: Fri, 05 Mar 1999 21:38:28 +1100

A couple of typos in my message...

  | as a literal, rather than as a separator (or escape).  Doing that would
  | mean that an 8 bit length field would be inadequate though, at least 8
  | bits would be required to cope with the worst case.

Which should read, of course ...

    as a literal, rather than as a separator (or escape).  Doing that would
    mean that an 8 bit length field would be inadequate though, at least 9
    bits would be required to cope with the worst case.

And ...

  |  The TTL of an address->name binding doesn't necessarily have much at
  | all to do with the TTL of the associated name->address binding, much
  | less the TTL on a lease granting that address to a particlar need.

"to a particular node"...    (sigh).

kre