Re: [dnsext] Forgery resilience and meeting in Stockholm

["Federico Lucifredi" <[e-mail]>]

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

I would support #3 for further study.

Best-F

------Original Message------
From: Ólafur  Guðmundsson /DNSEXT chair
Sender: [e-mail]
To: [e-mail]
Sent: May 20, 2009 11:17
Subject: Re: [dnsext] Forgery resilience and meeting in Stockholm



With less than one day left before the chairs need to make a determination.
The purpose of this message is to point out that the discussion has
possibly been derailed by heated arguments about the merits of a subset of the
options, at the detriment of other options.

At this point we have enough support to say EDNS0 Ping is acceptable for
further study, even though there is a large number detractors.
(option #4)

It is close call for option #3 x20

There is no public support for option #2, and no one has argued for option #1.

If you are in favor of options #1, #2 or #5 now is the time to speak up.

As an experiment I have set up a poll for the different options,
http://www.doodle.com/7yvife73qvwtnr5m

Feel free to post to namedroppers or participate in the pool.
When you participate in the poll use a name that I can correlate to
a namedroppers subscription i.e. no AB or BA names.

thanks
         Olafur

    Olafur

At 14:14 08/05/2009, Andrew Sullivan wrote:
>Dear colleagues,
>
>Your Chairs have been observing the discussion around adoption of
>various drafts for techniques to mitigate forgeries and cache
>poisoning.  It appears to us that the WG is not converging on
>consensus.
>
>We currently have a request open to adopt EDNS0 ping.  The discussion
>of adopting the document appeared to expose a fault in the community,
>where some expressed strong opposition to undertaking any further forgery
>resilience work when DNSSEC is already available, while others argued
>that DNSSEC is not getting deployed and therefore we need other urgent
>action.
>
>Meanwhile, some other mechanisms, including "0x20" and those outlined
>in draft-wijngaards-dnsext-resolver-side-mitigation-01.txt seem to be
>showing up in various implementations.
>
>We think it would be better if we came to some more or less shared
>agreement on what to do in this space (including nothing).  The
>portion of the meeting we had in Dublin that was dedicated to this
>topic seems not to have inspired consensus.  Therefore, we would like
>to present five options for consideration:
>
>1.  Do nothing, and take all energy that might be devoted to this
>effort and direct it towards DNSSEC deployment.
>
>2.  Adopt draft-wijngaards-dnsext-resolver-side-mitigation-01.txt, and
>include in it recommendations to do nothing else except what that
>document contains.  Remove from section 3 any strategies we do not
>want to adopt.  (Note that this latter condition entails decisions
>about the next two options.)
>
>3.  Adopt draft-vixie-dnsext-dns0x20-00.  If we do (2), then perhaps
>this gets included in that document, or perhaps it proceeds as part of
>a set of documents.  Let's leave the editorial process issues out of
>the discussion, and just focus on whether we want to include this
>strategy in the tool box.
>
>4.  Adopt draft-hubert-ulevitch-edns-ping-01.txt.  As in (3), this
>might be included as part of (2) or processed individually, but that
>doesn't matter.
>
>5.  Officially adopt nothing, but support (2) and (3) going ahead as
>individual submissions on the Informational track.  (2) would
>obviously need to be modified slightly to keep out any protocol items
>that might be entailed.  The reason (4) can't just go ahead on the
>individual track is that the assignment of an EDNS0 code point
>requires standards action, so the work would come back here anyway.
>
>We will plan to request a meeting session in Stockholm to discuss this
>issue (and possibly some other topics before us).  If the WG can come
>to a clear consensus on-list before then (and we have no other
>business), then obviously we will be in a position to cancel the
>Stockholm session.  If we have not come to a conclusion by 20 May, we
>will keep the session scheduled.
>
>In the absence of strong arguments in favour of action and at least an
>apparently broad constituency to do the work within the WG, the Chairs
>are inclined to take option (1), because the WG is supposed to be
>sleeping.  This is by no means to say that we are prejudiced in favour
>of that option.  It is rather to say that we are procedurally bound,
>by our charter, to a default of "No" for at least some of these
>documents.  Adding a new standards-track item to the WG work requires
>rechartering, please note, and given one other request we have open we
>may therefore need to recharter anyway.
>
>Best regards,
>
>Olafur and Andrew
>
>--
>Andrew Sullivan
>[e-mail]
>Shinkuro, Inc.
>
>--
>to unsubscribe send a message to [e-mail] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://ops.ietf.org/lists/namedroppers/>


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

 

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