In message <00e13499-7cea-a79a-7de1-dd9bad4bc530@xxxxxxxxxxxx>, Dave Crocker wr ites: > On 2/13/2017 8:50 PM, Pete Resnick wrote: > > The WG participant who felt that the functionality should be in-scope > > and is perfectly within bounds to make the case that the functionality > > is somehow necessary during Last Call. The chair and/or AD should > > summarize why they judged the functionality to be out of scope. Others > > in the community might want to take up the argument and explain why it > > should be added. > > > This sounds like reasonable theory, but is actually rather destructive > practice. > > It takes the position that Last Call is acceptable to use as a form of > appeals process, where folk who have been working on the topic for an > extended time have to defend their choices to a collection of other folk > who are new to the topic and are, therefore, making snap judgements. > > While, yes, there will be times that the new folk see something new or > better, that's not the usual occurrence. The usual occurrence is that > folk who are experienced with the topic and are tired from the extended > effort have to rehash their work and defend it to folk who have not done > their homework. And workgroups get it wrong. I gave up trying to convince behave that the DNS64 DNSSEC processing was insane. Validating clients send both <DO=1,CD=1> and <DO=1,CD=0> queries. You can't expect synthesised AAAA response to be accepted with either set of flags. They wanted a flag that said that the client is validating and that DOES NOT EXIST in DNSSEC. DO=1 say a client MAY be validating. DO=0 indicates that it is NOT validating. CD is independent of whether the client is validating or not. Lots of wishful thinking when that section was written. I also gave up trying to get 5.9. "Always Set the CD Bit on Queries" removed from the draft for RFC 6840. Named totally ignores that section because it just plain bad advice. Recursive servers need to honour CD as originally specified or there are failure modes that are not recoverable when some of the authorative servers are broken or the recursive server is under attack unless CD is controllable. You need to be able to control validation in the entire chain of recursive servers for DNSSEC to work. There are a number of different failure senarios in DNSSEC. Some require CD=1 to recover from (if you initially set CD=0), some require CD=0 to recover from (if you initially sent CD=1). In both cases CD needs to passed down the entire chain for the recovery to work. Should I have raise these again at IETF last call? Mark > Either working groups are where the work really does get done or they > aren't. The burden of having to worry about and deal with a larger, > less-involved community being frankly encouraged to second-guess the > folk who have actual skin in the game, is an example of what makes the > formality of IETF process onerous. > > Last Call should not require a working group to be subject to random > demands to defend itself. It should be for independent reviews that see > something the working group missed. Missed is different from "we had a > choice and we made it". > > If a fresh reviewer really does do their homework and really does > present a good case for making a different decision, that's fine. But > it also is quite different than supporting the re-hashing exercise that > occurrs when an existing wg participant expresses dissatisfaction with a > decision made during normal wg processes. > > d/ > > ps. Pete's other point was about a claim that an issue didn't really get > settled and needs further review. That's quite a different case. Maybe > it's worthy for LC discussion. Maybe it isn't. Dunno. > > pps. There's at least one case where I chose to attempt to use LC as a > kind of appeals process, since I deemed the wg process to have been > significantly flawed, including the cognizant AD. Like all good rules, > there need to be some exceptions thoughtfully permitted, though of > course my effort in this example of an exception bore no fruit... > > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx