Security considerations breakdown (was: Re: Security considerations breakdown and names of the specs (was: Re: Security Considerations: bad split))

[John C Klensin]

--On Wednesday, 10 December, 2008 15:35 +0100 Harald Alvestrand
<harald at alvestrand.no> wrote:

>> Harald (not to pick on him) also wrote "Having re-read the
>> security  considerations on -bidi, I fail to see how it's
>> possible to comprehend  these few paragraphs without just
>>...
> Despite not being picked on, I choose to pick back.
> 
> Again, we are discussing this text:
> 
>    This modification will allow some strings to be used in
> Stringprep
>    contexts that are not allowed today.  It is possible that
> differences
>    in the interpretation of the specification between old and
> new
>    implementations could pose a security risk, but it is
>...
> For some of the strings allowed (the ZWNJ in particular), it
> is extremely easy to envision how the difference in
> implementation could pose a security risk, so the statement is
> false for the whole IDNABIS suite. It is, however, true for
> -bidi.
> 
> There are no other places in IDNABIS where the difference
> between display order and network order matters, so the second
> paragraph is meaningless in any other context than -bidi.
> 
> I think we agree that the third paragraph is -bidi specific.
> 
> I stand by my judgment: All three paragraphs are -bidi
> specific, and are best kept in -bidi.

Having heard from Pasi (one of the security ADs) who expressed a
slight preference for consolidation, but mostly wanted to be
sure that the cross references are correct and normative, and
finding the above persuasive, I propose the following:

	(1) We consolidate the security considerations material
	from Defs, Protocol, Tables, and Rationale into Defs,
	with copious cross-references, including a reference to
	Bidi and a brief comment about why its issues are
	separate.  As noted earlier, that will require some
	textual tuning.  I expect the WG, and especially those
	who seem to think that this issue is important, to
	carefully check that changed/tuned text as soon as it
	appears.
	
	(2) We leave the Bidi discussion where it is, both for
	the reasons Harald identified in his note and as a
	logical consequence of the reasons we decided to keep
	the Bidi document separate.  We should, IMO, get the
	Stringprep reference out of that discussion, but that is
	almost a separate issue.

And, FWIW, I again ask that people keep their eyes on the target
of getting the substantive issues right and getting this work
done, and done soon, rather than debating moving text around for
aesthetic reasons that do not really affect the underlying
specifications.

     john