ietf
[Top] [All Lists]

Re: To "lose the argument in the WG"

2017-02-14 00:02:20

In message <00e13499-7cea-a79a-7de1-dd9bad4bc530(_at_)dcrocker(_dot_)net>, 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(_at_)isc(_dot_)org