Hal Murray <hmur...@megapathdsl.net>:
> > The only way to avoid this would be for me to go out of my way to create
> > distinct grammar branches for *each declaration type*.
>
> If you ever do that, don't forget to merge in the fudge stuff.
Sorry, I didn't understand that.
> [Specifying nonsense options, like refid for a server.]
> > Considering that we're talking a quarter century of road miles...well, I'm
> > going to want to actually *see* a bug report like that before I incur the
> > complexity cost to prevent it.
>
> We could fix that by checking for silly options at your fancy copy-over stage.
Yes, that is certainly one of the possible intervention points.
Parse exit time would be another.
> >> My gut feel is that 'nts' can not be part of
> >> the 'pool' as then a casual attacker can break the system.
> > You might be right, but I'm not going to design on the assumption that you
> > are because the payoff matrix is too asymmetrical.
>
> Just because the current pool is untrustworthy doesn't mean that somebody
> couldn't run a trusted pool.
>
> Keep in mind that pool+nts isn't well specified yet. Do we want to get the
> info for several servers with one NTS-KE connection, or do we want to do the
> a
> DNS lookup to get several IP Addresses and then use separate NTS-KE
> connections with each of those addresses?
Right. Gary disagrees, but my designer instincts are telling me very
clearly that *somebody* is going to do something interesting near
there and we should be positioned to play nice with it. And I trust
those instincts.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
