Dynamic Configuration of IPv4 Link-Local Addresses
draft-ietf-zeroconf-ipv4-linklocal-17

2.6.2 says

   ...if the destination address is in the
   169.254/16 prefix (including the 169.254.255.255 broadcast address),
   then the sender MUST ARP for the destination address and then send
   its packet directly to the destination on the same physical link.

This sounds like it's saying that 169.254.255.255 is not to be treated as a broadcast address, but it describes it as "the .. broadcast address".  Potentially confusing.

This is not a DISCUSS because this is a relatively minor issue in a document that I don't want to prevent from moving forward, but if it is going to be spun for something else (or even if this can be handled in AUTH48) I'd be happier.

It's good to see this document finished.
I'm happy with the document as written - it has addressed all the concerns I remember from the last time the IESG considered it.

The draft has the following text in section 1.4:

  a. Routable addresses should be used within applications whenever
   they are available.

   b. Names that are globally resolvable to routable addresses should be
   used within applications whenever they are available.  Names that are
   resolvable only on the local link (such as through use of protocols
   such as Link Local Multicast Name Resolution [LLMNR]) MUST NOT be
   used in off-link communication.   IPV4 addresses and names which can
   only be resolved on the local link SHOULD NOT be forwarded, they
   SHOULD only be sent when a Link-Local address is used as the source
   address.  This strong advice should hinder limited scope addresses
   and names from leaving the context in which they apply.

   c. Link-Local IPv4 addresses MUST NOT be configured in the DNS.

A & B seem to contain contrary advice (Use routable addresses in applications vs.
use names resolvable to routable addresses in applciations); this is probably
because the authors see an "instead" in here that isn't stated.  I'd suggest rephrasing
A.  I'd also suggest reversing the order so that C is first (it is the MUST here),
B's advice is next (It is the SHOULD), and then the current A is "If names resolvable 
to globally routable addresses are not available, but the globally routable addresses are,
they should be used instead of link-local addresses".

Section 2.9 says:

2.9.  Higher-Layer Protocol Considerations

   Similar considerations apply at layers above IP.

I think it would be valuable to say "Consideration similar to those in Section XX apply
at layers above IP", in case this text is excerpted or the Higher-layer protocol consideration
reader does not follow.  I'm also uneasy at the SHOULDs in this, and I have called out one
conflict in the text on the DNS front as a DISCUSS.  Basically, though, the APPs layer should 
not need to know which interface is being used for a specific operation, and that may not
be the case here. There are  actually two risks here:  that a reference to a link-local address
 by an application will break because the entity dereferencing it will not have access to that 
link-local address and that an application will receive the wrong data because it can 
dereference *something* at that address (possibly on a different interface), but it is not 
the intended referent.  This is implied  in Sections 3.2 and 6.3, and forward references to 
those section here would be useful in addition to the other references.

NIT:  IPv4ll used initially without expansion.  Style point:  it looks like "IP version four-one-one"
in a typical RFC font, which is confusing.