Security Considerations: bad split

[Mark Davis]

I believe that is more confusing to users than a unified security
considerations section. Most people that care about security want a
comprehensive discussion of the security impact of IDNA2008, and splitting
it up into separate sections only confuses the poor reader.
The use of IDNA2008 is also just pointlessly confusing. Three years from
now, it will just look dumb to use the name IDNA2008 for something that
actually came out in 2009. And it would be just so very simple to fix;
taking each of the authors 5 minutes with search&replace to make the change
in their next version, so I just don't understand the objection.

But if the rest of the wg doesn't care, I won't push this any further.

Mark


On Tue, Nov 25, 2008 at 11:13, John C Klensin <klensin at jck.com> wrote:

>
>
> --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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20081205/36712d8c/attachment.htm