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

[Vint Cerf]

1. I think we need to stick with IDNA2008 because too much material  
has been written using that reference as the successor to IDNA2003.
2. There are arguments on both sides relative to the security section  
of each standards RFC. It is a required section but the content is  
not further specified by RFC formatting rules. I would have thought  
that a single section might suffice but credible arguments may be  
made to keep the security specifics that are germane to each document  
with that document. In the Rationale document, the security section  
might specifically guide readers to the other security sections in  
the remaining documents to reinforce the importance of reading all  
documents (if indeed we conclude to retain the present split). I  
await response from the ADs on this question.
3. I think the WG in general would like to finish work and get on  
with implementation. In the waning days of 2008, I will attempt to  
provide terse consensus suggestions in the hope of reaching consensus  
and last call soon.

vint


NOTE NEW BUSINESS ADDRESS AND PHONE
Vint Cerf
Google
1818 Library Street, Suite 400
Reston, VA 20190
202-370-5637
vint at google.com




On Dec 7, 2008, at 11:54 AM, John C Klensin wrote:

>
>
> --On Sunday, 07 December, 2008 16:29 +0900 Martin Duerst
> <duerst at it.aoyama.ac.jp> wrote:
>
>> +1 on all points.
>>
>> [and if there are a few more +1 on the second point, then
>> the facts for the third point change, and my +1 for the
>> third point won't stay anymore]
>
> For whatever it is worth...
>
> * The organization of the Security Considerations section(s), as
> distinct from what is in them, is ultimately an IETF stylistic
> matter, not a substantive one.  I am not convinced that one
> organzational style or another is significantly harmful.  I just
> believe that spending a lot of time debating the issue and
> reorganizing text so that it can be reorganized again _is_
> harmful to getting things finished.
>
> I have been unable to deduce a consistent IETF style from the
> recent standards-track specifications published as sets of
> document that I've examined.    Some split things up, others
> combine them.
>
> Rather than run the (quite precedented) risk of the WG spending
> a lot of time debating this, reaching a conclusion that falls
> well short of clear consensus, sending the documents to the
> IESG, and having them decide they want something completely
> different, I have written to the Security ADs querying them
> about their preferences, advice, or instructions.  If we get
> that advice, I expect to follow it unless Vint concludes that
> there is WG consensus for going to battle on this subject (I
> would personally infer that anyone advocating such a battle is
> simply trying to delay the WG's work, but that would be just my
> opinion).
>
> * As editor, I am strongly opposed to changing the names of
> specs (specifically the "IDNA2008" references) at this time.
> There are two reasons for this.  One is that, regardless of what
> goes on in the WG, the work is widely known outside as
> "IDNA2008".  Changing the name will create confusion as to
> whether we have taken a different substantive direction and will
> require work on explanations that we have not.  The other,
> probably more important, reason is that it is a waste of time.
> These are the type of changes normally made by the RFC Editor,
> and will become much simpler at the point of editing for RFC
> publication because all of the internal inter-document
> references will disappear and be replaced by RFC numbers.  When
> we get closer to that point, we can also have a discussion, not
> about "IDNA2008"->"IDNA2009" but about whether the new version
> should be "IDNA2", "IDNAng", or some such thing (or just
> "IDNA"): the long-term perceptual disadvantage of using
> something that looks like a date is that it immediately raises
> the questions of when the next version is going to come along,
> whether "IDNA2008" is obsolete in 2010, and so on.
>
> If we continue to waste time at the current rate, we may need a
> discussion about IDNA2010.   I really wish we could concentrate
> on substance and get finished instead.
>
> just my opinion.
>
>    john
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20081207/4bff4712/attachment-0001.htm