Re: WGLC for DNSSECbis docs

[geoff@nominet.org.uk (Geoffrey Sisson)]

Paul Vixie <paul@vix.com> writes:

> they are already friendly, in terms of a new edns0 flag bit having end-to-end
> caching/forwarding treatment, and new type codes.  MBZ on the other hand would
> open a can that contains a large number of worms.  would the whole RDATA be
> able to change based on this MBZ not being zero?

With something resembling NSEC2 it would be likely.

>                                                   if so, then an implementor
> who ignored the MBZness would not be penalized until several years had gone
> by, which has usually been a recipe for disaster.

There aren't many implementations that would have a significant impact
if MBZness is ignored, which hopefully makes vigilence a viable
solution.  But I'm curious: is it reasonable to design protocols to
compensate for the rich diversity of ways in which they might be
mis-implemented?  Or does MBZ/version/reserved for future use/etc.
represent a special case?

> > This shouldn't require a one-year delay, as some of the more
> > pessimistic projections have put it.
>
> adding an MBZ would absolutely have that effect on the schedule.

Yesterday you said:

>                            unless the change to dnssec-bis were as
> simple as "add an MBZ octet to DS, DNSKEY, RRSIG, and require current
> implementations to ignore RRs where this octet has a nonzero value"
> then we're not going to see "production software ready to go" again in
> 2004.

. . . which I interpreted to mean you believed MBZ might not be so
costly.

I wouldn't wish to challenge your estimate of a one-year delay, but
I would be interested to learn of previous instances where this has
happened.

Regards

Geoff

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>