Document:  draft-ietf-dnsext-mdns-46.txt
Reviewer: Francis Dupont [Francis.Dupont@point6.net]
Review Date:  Thursday 7/6/2006 2:13 AM CST
IESG Telechat Date:  Thursday, 6 July 2006

Summary: Ready with nits

Some comments/suggestions (including a required fix for 5.3 [b]):
 - 2.1 page 5: the 512 octets default maximum seems a bit too conservative?
 - 2.1.1 C page 6: request -> query (IMHO the document should use only
  the pair of terms query/response)
 - 2.9 page 14: check if SIG(0) is not now RSIG(0) (PS: as far as I know
  the RFC 2931 was not updated so it is still SIG(0))
 - 3.1 pages 17 and 18: linklocal -> link-local (twice)
 - 4.1 page 19: I am not happy with "interpreted as an unsigned integer"
  as this involves an ambiguous byte order (I assume it is big endian
  but it is not specified). I strongly prefer the lexicographical order.
 - 4.2 page 20: same than the previous point.
 - 4.2 page 21: requests -> queries, and replies -> responses
 - 5 page 22: 802.11 -> IEEE 802.11
 - 5.1 page 23: silently discarding them as rapidly as possible ->
  silently discarding them (I don't know a way to slowly discard them :-)
 - 5.2 page 23: link layer security -> link-layer security (the link-xxx
  style seems fine)
 - 5.2 page 23: local-link -> local link
 - 5.3 [a] page 24: same than 2.9
 - 5.3 [b] page 24: IPsec ESP has two NULL algorithms, NULL encryption
  and NULL integrity/authentication (cf RFC 4305, the term transform comes
  from RFC 4306 but "algorithm" is better). I strongly suggest:
  null-transform -> NULL encryption algorithm.
 - 6 page 25: my dictionary has no "coincident", in particular in this
  position... (i.e., there is a possible wording/language problem)
 - 8.2 pages 26/27: many informative references are for 2002 I-Ds,
  perhaps this can become a problem?
 - Acks page 28: Van-Valkenburg -> van Valkenburg? (please check with him)
 - Open Issues page 30: should be marked as to be removed by the RFC editor.