Re: [secdir] secdir review of draft-ietf-dnsext-axfr-clarify-13

[Alfred Hönes <[e-mail]>]

Chris,
thanks for your detailed review.  See detailed responses inline.

> Hi,
>
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
> Overall, I found no problems with the document.  It is well written and
> very explanatory.  The following notes and suggestions are editorial.

Thanks for this former judgement in particular.
It deemed specifically important for a topic that some years ago
had caused controversies to be as clear and logically consistent
as possible and to explain therein the reasons to write that
document -- the very cursory text in STD 13 that essentially had
laid the grounds for diverging exegesis.

>
> It would be nice to reference the security considerations of RFCs 1034
> and 1035 just to say that this specification doesn't add any new
> considerations, however those documents don't have any security
> considerations sections.  Would the authors then consider something
> like the following (which would be the first paragraph in Section 8):

>     This document is a clarification of a mechanism outlined in RFCs 1034
>     and 1035 and as such does not add any new security considerations.
>     The security considerations relevent to the deployment of this
>     specification are noted in RFC 4033.

Unless someone opposes, such text can be added, sure.
But in that case, wouldn't RFC 3833 be a better choice than RFC 4033?
RFC 4033 indeed contains considerations that go beyond DNSSEC, but
the more generic security considerations for the DNS in general are
in RFC 3833.  I suggest to add the following text:

|  This document is a clarification of a mechanism outlined in RFCs 1034
|  and 1035 and as such does not add any new security considerations.
|  RFC 3833 [RFC3833] is devoted entirely to security considerations for
|  the DNS; its Section 4.3 delineates zone transfer security aspects
|  from the security threats addressed by DNSSEC.

[ + add an entry [RFC3833] to Section 12.2 (Informative References). ]

Does that make sense to you?


> In my first reading of the document, I was unfamiliar with the term
> "mbz".  I'd suggest expanding the acronym in one place.

The first appearance of "mbz" is in Section 2.1.1, enclosed in (single)
quotes, and tagged with "-- see Note c)", where Note c) (at the bottom
of page 9) contains the explanation:

   c) 'mbz' -- The client MUST set this bit to 0, the server MUST ignore
      it.

'mbz' is used more as a user-friendly symbol -- at first glance similar
to "MUST be 0", but actually quite different -- for the classification
of fields than a literal acronym (and hence also written on lowercase),
and the common expansion "must be zero" deliberately has been omitted
because of anecdotal evidence that implementors have understood that as
an encouragement, or even requirement, to check for value 0 on receipt,
which is contrary to what we want.

Note: Similar considerations apply to 'n/a' ( same section, Note b) ).


> Thanks,
> Chris
>


Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+