(Times in brackets are times on the audio record: 
http://www.ietf.org/audio/ietf81/ietf81-206a-20110726-1256-pm.mp3)

1) Administrivia [4:56]

Minutes: Ondrej Sury
Jabber: Wes Hardaker, Paul Wouters

2) Status Update [10:45]

Four RFCs published
- Nameserver control protocol requirements (RFC 6168)
- Local zones document (RFC 6303)
- 2*AS112 documents (RFC 6304, 6305) ("Help Help" was
  going to be FYI, but FYI was discontinued.)

3) Active Drafts [13:10]
3.1) draft-ietf-dnsop-rfc4641bis-07
  - Edited by Olaf and Matthijs, it's past WGLC.
  - Little in-depth review during WGLC, not meeting 5-reviewer
    threshold.
  - However previous discussions mean that chairs still want to
    progress this.
  - Needs nits review.
  - Some issues popped up in WGLC (e.g. document promises not to make
    recommendations then does so, discussion on recommendation on
    KSK/ZSK split)
  - last chance to comment
  - Olaf: is there a timescale?  PK: Not finish before mid-September

3.2) draft-ietf-dnsop-dnsesec-dps-framework-04
  - 7 reviewers
  - couple issues raised
  - 05 will be submitted after meeting
  - some time in September to IETF LC

3.3) draft-ietf-dnsop-dnssec-key-timing-02
  - editors: Johan, Stephen & John Dickinson
  - 03 published after meeting
  - should be ready for IETF LC
  - after the first two

3.4) draft-ietf-dnsop-respsize-12
  - active at the moment
  - it had WG LC two years ago
  - do another review to WG LC
  - make sure the draft match the current operational needs
  - timeframe before the IETF82

4) non-WG Internet-Drafts [21:25]
4.1) draft-michaelson-as112-ipv6-00
  - AS112/IPv6
  - George Michaelson [GM]
  * draft-sotomayor-as112-ipv4-cull-00
  - [GM]: draft discusses more stuff, see the slides
  - [GM]: it's not the same draft, addresses different issues

* draft-sotomayor-as112-ipv4-cull-00
  - William Sotomayor
  - synchronize AS112 with local zones draft (6303?, 6304?)
  - not bis document
  - whether make this a simple instruction?
  - proposal to use DNAMEs to do delegation work
  - would DNAME help or create more traffic?

[Discussion]
  - [PK]: AS112 = Loosely connected cloud => lame delegations
Andrew Sullivan:
  - When AS112 set up, we already had experience.  IPv6 is early.  Andrew
    is nervous about adding IPv6 to the list because it's too early.
  - It's easy to take off the delegation (remove from in-addr.arpa).
    Be careful to not get lame delegations.
Warren Kumari:
  - Am I missing something something?  Why not have AS112 answer for
    everything and delegate/undelegate to it?
George Michaelson
  - Some observations.  RFC6303 - there's not
    0.0.0.0.0....0.ipv6.arpa, majority of stupid requests are IPv6
    requests.  Only way is to have ... 0.0.0.ipv6.arpa
  - Traffic is there - recommendations in local zones (RFC 6303) won't
    stop that traffic.
  - It's not early, it's just DNS and delegating some numbers.
Andrew Sullivan:
  - AS112 was elegant solution to a mess.  Can we do better in IPv6?
    IPv6 has still low penetration (as seen at IPv6 Day).  It doesn't
    cost to wait.
Wes Hardaker:
  - Question to Andrew S.: What's the downside of publishing it now?
Andrew Sullivan:
  - I don't think there's any harm.  I am nervous about reverse
    multicast tree.
George Michaelson:
  - I agree.  If we put too much there, we need to revise.
Andrew Sullivan:
  - Fewer objections if we just put current bogons there.
Peter Koch:
  - Not decisive.  Needs further instructions.
  - Fast-track?
  - How do we involve and invoke the AS112 operators.
Geoff Huston:
  - We don't need to conserve RFC numbers.  Publish two RFCs.
Peter Koch:
  - How we get this deployed once delegation is there?
  - How do we talk to operators?

4.1) draft-mekking-dnsop-dnssec-key-timing-bis-02 [46:30]
  - Key Timing - Future Work
  - Matthijs Mekking
  - How to do key-rollovers vs. how to implement rollovers key-timing
    (aka document for implementors)
  - Key timing document is incomplete (on purpose)
  - Two options: extend the current document (with missing scenarios)
    OR redefine key states so they're reusable
  - Future direction:
    - Is there a problem to solve?
    - Is there enough momentum?
    - Is this a reasonable approach?
    - Is this DNSOP/IETF work?
[Discussion]
Johan Ihren:
  - All in favor.
  - Similar to what we asked last autumn...
  - The WG said that last year.  Wrap-up and do the bis.
  - Original draft got complicated.  We should revise with open eye,
    not sure if this is the last document.
Matthijs M.:
  - Focus on missing rollover scenarios
  - It's good way to go, but maybe in a year something else will
    happen.
Johan Ihren:
  - Perhaps there is no way to describe with unique states.
  - Perhaps right way is to add properties to a keys instead of
    changing states.
Wes Hardaker:
  - If we have such complex state diagrams that we (experts) cannot
    describe, then we need the document for people out there.
Andrew Sullivan:
  - I said last year: ship it, it's good enough
  - It's weird to have bis for not published yet document
  - If we hold on, I am opposed - do the merge
Peter Koch:
  - It's strange, but not obvious which options to choose
Andrew Sullivan:
  - Timeline?
Peter Koch:
  - might be better to wait a bit for the -bis to gain experience in
    the advice just given.
Wes Hardaker:
  - Right way to forward - put a note in the document - this is
    rapidly changing stuff (leave out the more complex stuff, it will
    be covered in next document)
Matthijs Mekking:
  - Notes are there.
Johan Ihren:
  - I agree with Wes.  Incomplete != Wrong.  One key for everything is
    new. Algorithm rollover will be important.  Current document is
    not wrong.
Peter Koch:
  - What is the target audience?  Implementors or services?  What
    level of complexity we expose to them...
Wes Hardaker:
  - The questions is if they should read the document?  (The
    operators.)
  - People will always rollout their own solutions.
Mathijs Mekking:
  - All that applies to key-timing applies to key-timing-bis.
Peter Koch:
  - Is this urgent?  We need to come up with schedule.  We don't have
    to come up with -bis immediately after key-timing.

4.3) Automated KSK Rollover [1:06:49]
  - Problem Statement
  - Stephen Morris
  - Recent drafts:
    - draft-barwood-dnsop-ds-publish
    - draft-mekking-dnsop-auto-cpsync (Child-Parent)
  - Child-Parent Synchronization
    - Will it be used?
    - EPP (already) available for automated updates
Alexander Mayerhofer:
  - Our contract is between registry-registrar.  It won't work unless
    we change the contract.  In practice, registrars would want to be
    in full control.
Antoine Verschuren:
  - There is a parent->child relation without registrar.  (DNS
    delegation)
  - SIDN defines registrar only for administrative purposes
Alexander Mayerhofer:
  - We asked our registrars.
  - It will probably change in the time.
  - Registrars will have to get used.
Johan Ihren:
  - This is a protocol.  +1 to Antoine
  - We don't design the *ONE* solutions.
  - This will be just one more tool to make this work in automated
    fashion.
Wes Hardaker relaying Olafur Gudmunsson
  - Not all setup are RRR.  There are few registries, few registrars
    and hundred thousand of users.  The users should be priority.
  - We can support more things, users can pick one or more.
Wes Hardaker:
  - End user doesn't care by which channel the data travels.
Matthijs Mekking:
  - We heard "Don't side channel the registrar".
  - Want to clarify that this approach does not necessarily do this.
Alexander Mayerhofer:
  - It's not for us, but I would like to see it.

Stephen Morris:
  - NEXT question
  - Does DNSSEC obsolete updating NS and DS information via EPP/Web/
    Email
Antoine Verschuren:
  - No, it doesn't.  You need bootstrapping
Johan Ihren:
  - I wrote this type of registry 7 years ago.
  - It works like a charm
  - It's not a right solution to everyone.
Ondrej Sury:
  - Not for us, but would like to see it for others.

Stephen Morris:
  - If we are to have automatic sync, what should be passed?
  - DS or DNSKEY
  - Just DNSSEC or NS/GLUE too.
Andrew Sullivan:
  - Once you have a secure channel, if you can cross zonecuts.
    Agree fully.
Peter Koch [nohats]:
  - Is DNS to be viewed as provisioning protocol???
Paul Wouters:
  - Currently it's not easy to get DS to the right spot.  It would be
    nice to fix it if we can do this between parent-child.
Andrew Sullivan:
  - To respond to Peter Koch  It's the DNS it's mix of both data and
    control in same channel (zone transfer, etc...).     What is the
    least painful way. Adding this to the protocol is a good idea.
Eric Osterweil:
  - What if you have misconfigured your NS in child and it's sent to
    parent?
Wes Hardaker:
  - The network management world often gets it wrong.  Protocols easy
    to start.  Management not needed.  Doesn't scale.  Protocols have
    to be automated.  So yes, stick it into the protocol.
John Klensin:
  - Trying to use protocol for lots of things. Will it all work
    together?
Johan Ihren:
  - In response to John.  This is not about *the solution*, but one
    tool in the box.  It's good.
Eric Osterweil:
  - Synchronizing data between authoritative boundaries.  This means
    that things can be broken.  There should be more caution.
Johan Ihren:
  - There's agreement between child and parent (a checkbox: Yes, I
    want the synchronization)
Eric Osterweil:
  - People are often quicker to blame than to do something cautiously.
  - You have onus if you do something automatically not to break
    things.
Johan Ihren:
  - Some parents should not offer this, some will.
Lars-Johan Liman:
  - It's get more and more complicated.  Pushed towards people who
    want automated tools.
Stephen Morris:
  - What chairs are proposing?
  - Define the problem
    - Identify the audience
    - Feedback from likely users
    - Identify solution spaces
    - Choose solution to progress
  - People can go to me after the meeting

5) DNSOP - Future directions [1:32:45]
Peter Koch:
  - Number of open documents have decreased
  - List of what has been brought to attention (long list)
  - Number of options (from rechartering to dissolving)
  - Is there enough momentum to get work done?
Murray Kucherawy:
  - The operational reality check is useful, but never heard of WG
    providing oversight to other WGs. People can go and participate
    in other WGs.
Dave Crocker:
  - I have a draft on underscores in the domain names (now everybody
    creates it's own registry).  Have not got a single response,
    on list or not.  Would like to get at least a "not here" response.
Peter Koch:
  - The list presented was not created to say "yes or no"
  - You will get response
Ron Bonica:
  - Benchmarking and performance.  Might belong in pmol if talking
    about lab measurements.
Peter Koch:
  - We talked to El Martin
  - In close cooperation with some other WG
Ron Bonica:
  - Operational Reality Check
  - Could learn how DNS is being used and smack people on the head if
    they are doing it wrong (perhaps better done by DNS directorate).
  - Alternatively learning how people are using DNS and deciding how
    to operate it to accommodate them.
Peter Koch:
  - Smashing people's heads wasn't the intention
  - We invite people to speak here
Andrew Sullivan:
  - Similar problem in DNSEXT
  - Why is that?
Ondrej Sury:
  - I can get my people to review drafts.
Peter Koch:
  - Will raise question of momentum when new drafts are brought to
    the WG.
  
14:48 End of Meeting [1:52:15]