NTS client configuration support has landed

[Eric S. Raymond]

Hal Murray <hmurray at 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.