Eszett and Final Sigma (was: Re: Consensus Call Tranche 8 Results)
JFC Morfin
jefsey at jefsey.com
Wed Nov 5 23:08:48 CET 2008
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
More information about the Idna-update
mailing list