[ntpwg] [dhcwg] NTP option: IP address and/or FQDN

[Rob Seaman]

On Dec 10, 2007, at 8:55 AM, TS Glassey wrote:

> the key to this problem isn't technology - its the License.

and...

On Dec 10, 2007, at 6:46 AM, Danny Mayer wrote:

> What I think I'd like to do is go back to basics [...] I'm finding  
> it rather difficult going from the the DHCP server/options forward  
> without knowing or understanding the targets.

and...

On Dec 10, 2007, at 5:49 AM, Brian Utterback wrote:

> I suspect that if we see many more such situations, there will have  
> to be a mechanism
> installed in the Internet routers like the certificate revocation  
> protocol in PKI. A way to tell all routers everywhere that certain  
> IP addresses are never to be forwarded.

and...

On Dec 10, 2007, at 2:23 AM, <anthony.flavin at bt.com> <anthony.flavin at bt.com 
 > wrote:

> The main problem with the DHCP doing the DNS lookup on behalf of  
> it's NTP clients, is that architecturally, that's a complete mess.  
> [...]
>
> So are we going to move some of the NTP features into DHCP, or  
> accept where the boundaries are and let each system do what it's  
> good at?

and...

On Dec 9, 2007, at 6:52 AM, MORAND Lionel RD-CORE-ISS wrote:

> But as a "client" of the dhc wg, I'm interested by a clear statement.

and on and on.

All this tussling over details has been very engaging.  The exchange  
about motorcycles was particularly entertaining.  However, positional  
negotiations are a poor way to arrive at a functioning consensus.   
There seems to be some notion that we're involved in some zero sum  
game and that there have to be losers as well as winners.  Rather,  
this is a pure architectural design issue and the NTP edifice of all  
will either stand or fall together.

The diversity of points of view is a strength of the working groups,  
not a weakness.  Surely the need that is most evident here is to carry  
out a coherent analysis of the trade-offs.  This is a rich literature  
in system engineering, see for example:

	http://www.sie.arizona.edu/sysengr/publishedPapers/quantitativeMethods.pdf

The first step to studying the trade-offs between several options is  
to coherently describe those options.  Do we have a half-page  
description for each of the major variations that have been  
discussed?  You can't tell the players without a scorecard.  The  
proposed solutions can be purely technical - or purely legal.

A lot of us are skeptical of licensing.  The way to make the case is  
to provide explicit data, scoring functions, figures of merit,  
sensitivity and risk analyses - not to simply state that licensing  
will save the day.  A discussion and detailed dissection of a business  
model(s) would be entirely appropriate, too.  How will corporate  
entities react to licensing?  How will they react to changes to  
technical standards?

By all means include both the status quo - and blue-sky solutions - in  
the matrix of options to be scored.  We may be convinced already that  
neither extreme will satisfice - but 1) we may be wrong, and 2)  
including such extremes sharpens the challenge to the other proposed  
solutions.

Simply elucidating the criteria key to such a trade-off is worth the  
price of admissions to get us past comparing apples and oranges.  Yes,  
yes - we want to keep inane vendors from fielding devices tailor made  
for D.O.S., but is this really a complete list of the important NTP/ 
DHCP issues?

NTP is as much a risk factor to DHCP as DLink has been to NTP.  Should  
there be an attempt to characterize the full range of risks before  
deciding which will result in actionable changes to technology (or to  
its licensing)?

Rob Seaman
National Optical Astronomy Observatory