Gary E. Miller via devel <devel@ntpsec.org>: > Right, a bad thing.
I'm not going to argue with you about the way configuration is now
implemented. There are some problems with it, there are some advantages;
I'm certainly not married to the way it's done now.
What I *am* clear on is that we have a job to do to convince Cisco to
keep funding us. I want to impress them with quality and *speed* and that
means I am not going to go on any yak-shaving expeditions and you
shouldn't either.
I cannot, ultimately, tell you what to do. I will tell you what *I*
intend to do, which is: until we're out of this sprint, I will not
cooperate with any behavior that I think slows us down.
> > Yes, these declaration types are *semantically* different. All three
> > use different subsets of the universal option set in the config block.
> > But nothing in the code actually cares or knows which subsets those
> > are until the protocol machine starts picking parameters out of the
> > peer structures, well after config time.
>
> Which is now too late to do some of the new error checking required.
That is true. But there's no rule that said checking needs to live in
the grammar productions or the intermediate-configuration-block layer.
There are several places it could be inserted before the protocol machine
spins up and starts looking at the peer structure instances.
A way to make this line of discussion more productive would be for you
to give one or three examples of "new error checking required". Then we
can discuss how to fit them gracefully in the existing code structure.
What to do to *change* that structure is a topic for another time.
In part because it's tangled up with other issues like whether and
when we're moving to Go.
> > Adding an option is, in this context, generally something you do by
> > adding a token to an alternatives list. That *is* a one-keyword
> > change. Trivial. Turns into a new slot in the config block, or maybe
> > a new bit in a flag mask.
>
> Except that some keywords are now different.
> The alternative is now all these new keywords that are illegal, and
> pass the parser, for the old types.
Yes. None of this is anything new, happened between server and refclock too.
I'm also not going to argue with you about the overall grammar design.
We have different priorities, you've done your best to change my mind,
and I have nevertheless made some decisions you don't like.
That's going to happen occasionally until *you* are the tech lead at
whom the buck stops. Until then, try to bear in mind that you've
changed my mind before about other things, and I have every
expectation that you will succeed again in the future.
> > I believe you that nts needs 5 new semantically new options.
>
> We are past 13 now, plus some that changed from the old definitions.
> How do you explain that to a user? When the hostname in "server <hostname>"
> means something very different than in "server <hostname> xxx yyy zzz nts yyy"
This is *not a new problem*. The config language was already a maze
of twisty passages all different, and we will address that the only
way that has ever worked; by keeping feature count down as much as we can
and writing good documentation.
Furthermore, there has *never* been any serious error checking in this
grammar. You are a bit late to the party just noticing that now.
Would it be nice to have more? Sure. If you want to write a
top-node-of-config hook that does 90,000 consistency checks, be
my guest - but please do it *after* we've demonstrated NTS interop to
Cisco, because we need you on critical-path stuff before then.
> > There's zero evidence in all
> > the NTP issues I've looked at that any user has ever said "I
> > mistakenly put a refid option on a server declaration and ntpd didn't
> > complain and ZOMG THAT!S A BUG!!"
>
> We must be on different mailing lists...
[citation required]
Please save up a representative sample of those issues and drop them
on me after our first successful demo to Cisco. We'll do good practice
and turn them into invariant checks.
> Whoa! All those new options are REQUIRED.
This is something I want to understand better.
Are you seriously telling me that, for example, the TLS RFCs require me to
have a switch in configuration that says "Don't accept TLS 1.3 connections?"
If that is true, I want to see a chapter and verse cite.
I want to know why it's not fully conformant to always accept 1.2 *and*
1.3 connections and ditch the restrictive options.
> I was trying to be diplomatic before. Adding 'nts' to 'pool' is recklesss
> endangerment. Should be a felony.
Can you explain why you think so without circling back to arguments I am
not willing to be in right now?
> We either need to discuss before putting in nts.adoc, or put in nts.adoc
> before we discuss. It was discussed on the list, consensus reached,
> then put in nts.adoc, then gone. Going back to the list, to rediscuss,
> works better when the prior work product is not gone.
Yeah, we do need to smooth out the workflow. I'll try not removing
just-completed features for a while. I'll mark their status in the
document instead.
--
<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.
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
