Security Considerations: bad split

John C Klensin klensin at jck.com
Tue Nov 25 20:13:13 CET 2008



--On Wednesday, 19 November, 2008 18:08 -0800 Mark Davis
<mark at macchiato.com> wrote:

> Security ConsiderationsD4. Security ConsiderationsR12.
> Security Considerations
> 
> I think it is a really bad idea to split the Security
> Considerations between Defs and Rationale. There doesn't seem
> to be any particular reason for the split. They should all be
> in one place, preferably in Protocol, since that is the core
> document.

Actually, while I believe that an argument about whether Defs or
Protocol is "the core document" would be a massive waste of time
--at least as much so as an argument about whether we now need
to change "IDNA2008" into "IDNA2009" because we won't have RFCs
published until 2009 (or longer, if those sorts of debates keep
up)-- there is intended to be a logic in the split of Security
Considerations between Defs and Rationale.  

That logic brings us back to the reason for having Defs at all,
which has been discussed many times on this list.  There is a
difference in audience between Rationale and Protocol, with the
latter being oriented toward protocol implementers and
containing only normative material for them and the former being
addressed to those who need to get an overview of what is going
on and to make policy decisions about IDNs (such as
specification of registry restrictions).  The Security
Considerations material should follow that split, with material
in Defs that, like the definitions, apply to all of the
documents or a major subset of them; material in Protocol that
applies to the normative protocol specification; material in
Tables that applies to table use and stability; material in Bidi
that is specific to Right to Left Scripts; and material in
Rationale that is specific to the guidance and advice to zone
administrators, etc., given there.

That breakdown is consistent with general IETF approaches to
Security Considerations sections, IMO, but others may disagree.

    john



More information about the Idna-update mailing list