Subject: Re: [dnsext] Meeting in Beijing

From: "Jeffrey A. Williams" <[email-masked]>
Date: Wed, 13 Oct 2010 16:32:09 -0500 (GMT-05:00)

Andrew and all,

  I noticed that Phillips proposal is not on the list.
Was there some reason as to why not?

-----Original Message-----
>From: Andrew Sullivan <[email-masked]>
>Sent: Oct 13, 2010 4:15 PM
>To: [email-masked]
>Subject: [dnsext] Meeting in Beijing
>
>Dear colleagues,
>
>At the moment, we have a very light agenda for the Beijing meeting.
>These are the items for which we've received requests:
>
>1.  A brief presentation on a DNSSEC history wiki (with a solitication
>for participation).
>
>2.  A discussion of draft-vixie-dnsext-resimprove-00.
>
>3.  A discussion of draft-yao-dnsext-identical-resolution-0[1|2].
>
>We'd like people to treat (3) as though it's a WG draft.  Assuming the
>charter we sent to the IESG gets approved, that document will
>automatically become a WG document by virtue of the charter adoption.
>We're being careful not to step out of process, however, and as of
>right now, the document isn't strictly speaking on charter.
>
>Our feeling is that a meeting of this sort can be completed within an
>hour or so.  However, we find ourselves at the moment with a much
>longer slot (currently, Wed. morning, for 2 1/2 hours.  We didn't ask
>for that much; it is apparently mostly to deal with scheduling
>difficulties).
>
>I note, however, that we have a number of drafts that have been
>lingering for some time.  This is mostly due to inertia.  Olafur and I
>therefore propose to use the extra time as a breakout session to nail
>down whatever changes are still needed in those lingering drafts.  If
>we can get five committed reviewers for each document in the room, and
>get the necessary text compromises settled, we can then immediately
>send them through WGLC, and we would clear our docket.  We think this
>would be a productive use of the time.
>
>If you have objections to this plan, please let us know.  If you do
>not so object, we'll take that as an indication that the plan sounds
>sensible.
>
>Best regards,
>
>Andrew and Olafur.
>
>-- 
>Andrew Sullivan
>[email-masked]
>Shinkuro, Inc.
>

Regards,
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 13 Oct 2010 19:53:06 -0400

Unless I completely overlooked it, he didn't request a slot in the meeting. 

-- 
Andrew Sullivan
<[email-masked]>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 14 Oct 2010 00:48:40 -0400

Unfortunately I will not be in Beijing. But I am planning to attend Prague
and I think my proposal will be rather better to understand once I have the
whole scheme developed.

My overarching concept is that Security Policy is the way to create a
compelling value proposition for DNSSEC.

One approach would be to specify each chunk piecemeal so that the larger
scheme only becomes gradually apparent. I don't think that is an honest
approach, but it is an approach that is often encouraged in the interests of
'focus'.

I would prefer to present a sketch of the overarching scheme and the initial
starting points at the same time so that people can see that the initial
work items are practical but do not lead to a dead end.

For example, any scheme that requires additional DNS lookups on every http
transaction is going to look unattractive in the short term when deployment
is limited. In the larger scheme that overhead is factored out of the
critical response loop entirely.

-- 
Website: http://hallambaker.com/