Eszett and Final Sigma (was: Re: Consensus Call Tranche 8 Results)

[JFC Morfin]

answers in the text.

At 22:05 05/11/2008, John C Klensin wrote:
>--On Wednesday, 05 November, 2008 17:26 +0100 JFC Morfin
><jefsey at jefsey.com> wrote:
>
> > At 14:55 05/11/2008, John C Klensin wrote:
> >> Unless one argues that doubling the number of DNS queries
> >> would have  an insignificant operational effect, I'd assume
> >> the latter would be  operationally significant.
> >
> > Not necessarily if doubling the number of DNS queries was a
> > general security light load alternative to DNSSEC. Another
> > possibility would be to increment the port or the class number
> > when certain sequences are observed, in order to properly
> > address the label, or to get it rejected. Another possibility
> > would be to change the IDNA implementation architecture
> > without affecting the protocol.
>
>I am not sure I understand what you are proposing or whether we
>both understand the words in the same way.  For example,
>"increment the class [number]" implies a lookup in an entirely
>different DNS tree, something that would raise interesting
>issues in cache validity as well as ones about maintaining
>parallel trees, presumed hits on both roots, etc.   My long-ago
>"different Class" proposal was carefully designed to avoid some
>of these problems and was probably still not sufficient.
>Thinking about the implementation and operational details of
>what you are suggesting (assuming we understand the words the
>same way) gives me a headache.

John,
I use to play with classes/group/ports notions for thirty years. It 
is true it is not in the way of the "Internet" monolythic 
architecture, but sometimes the Internet architecture is to evolve. 
For example, it should sometimes work on virtual DNS and externets 
(external network look alikes).

ICANN a few years ago (ICP-3) suggested to experiment in that area. 
At that time you proposed to test classes, but you proposed it in an 
Internet way, using Internet classes, not classes (and groups) as 
such.  What I mean is that if you want to consider innovative ways, 
you have to play with ideas, not only to keep condisidering options 
along the same old rules. You might be surprised as the "bare 
Internet system" could support in terms of innovation. We touched it 
in running a two years community ICP-3 test-bed, even if we only were 
lead users.

>I also don't have a clue about what it would mean to change "the
>implementation architecture without affecting the protocol"
>because, to me, the purpose of a standardized protocol is
>precisely to specify the implementation architecture (although
>typically not all of the implementation details).

I do not think this WG within the current IETF approach is to address 
the problem. Precisely because of what you say. The purpose of a 
protocol is that end to end processes work well together. The 
architecture is about saying where/what the ends are. This is not a 
WG issue in the IETF, it is an IAB issue. And for years, IAB tends to 
think it is an IRTF issue. As long as the Internet architecture is 
intangible, has no presentation layer, etc. and its standarizer's 
vision of it stays the same, i.e. nothing changes, how do you want 
something new to be implemented that partly contradicts or changes 
the way it works ? Except if it is to patch a bug. But the bare 
Internet system as no bugs.

IMHO this WG should follow its charter, describe IDNA2008 as it can 
be from the previous RFCs and BCPs, trying to protect as much 
flexibility as possible, carving all this in stone. Then it will be 
to RFC users to adapt its use to their needs. But this will only be 
possible if IDNA is very very clear and stable because users will 
need to build around it, in different ways, a mutual interoperability.

I hope this helps understanding what I mean to say.
jfc