[03:36:06] --- oern has joined
[03:36:10] --- oern has left
[04:06:43] --- ogud has joined
[04:57:14] --- ogud has left
[05:47:19] --- ogud has joined
[05:47:43] --- ogud has left: Replaced by new connection
[06:29:30] --- Jelte has joined
[06:29:37] --- Jelte has left: Logged out
[06:29:50] --- wes has joined
[06:30:47] --- Jelte has joined
[06:30:53] <Jelte> hi
[06:31:01] <wes> hello
[06:31:22] <Jelte> could you help me out with peoples names?
[06:31:38] <wes> sure, who do you need names for?
[06:31:54] <Jelte> olaf just volunteered me to be scribe
[06:32:02] <Jelte> normal scribe, not jabber
[06:32:20] --- ogud has joined
[06:32:25] <wes> i'll try and put names in jabber
[06:32:27] <wes> as they get up
[06:32:36] <Jelte> ok thanks
[06:32:40] <wes> plus, just ask away someone will chime in as well
[06:32:52] <ogud> and I will issue corrections
[06:33:02] <wes> i think ogud should scribe
[06:33:20] --- matt@ecotroph.net has joined
[06:33:30] --- matt@ecotroph.net has left
[06:34:03] --- matt_larson has joined
[06:43:19] --- jakob has joined
[06:44:39] <jakob> "esto es el Grupo de Trabajo DNSSEC"
[06:46:26] <Jelte> las cucarachas entran, pero no pueden salir
[06:47:37] <jakob> les cucarachas entrent, mais ne peuvent pas sortir
[06:49:00] --- schoenw has joined
[06:54:58] --- dblacka has joined
[06:57:04] --- weiler has joined
[06:57:26] --- Peter Koch has joined
[06:59:32] --- matt_larson has left: Disconnected
[07:00:16] --- pawal has joined
[07:00:28] --- suz has joined
[07:00:32] --- CathyM has joined
[07:00:50] --- suz has left
[07:01:06] --- suz has joined
[07:01:08] <wes> order:
[07:01:15] <wes> documents past last call
[07:01:20] --- jinmei has joined
[07:01:20] --- jinmei has left: Lost connection
[07:01:22] <wes> docs in last call
[07:01:22] <wes> docs need last call
[07:01:23] --- amarine has joined
[07:01:38] --- marka-isc has joined
[07:01:38] --- marka-isc has left: Lost connection
[07:01:41] --- matt_larson has joined
[07:02:28] <wes> llmnr: past llgc long time ago
[07:02:29] --- marka-isc has joined
[07:02:29] --- marka-isc has left: Lost connection
[07:02:47] <wes> ad issues are closed
[07:02:55] <wes> doc is waiting on chairs
[07:03:03] --- raj has joined
[07:03:07] --- jlcjohn has joined
[07:03:24] <wes> tsig sha-1 passed last call
[07:03:41] <wes> chairs need to write summary for ad
[07:03:54] --- mo7sen has joined
[07:04:00] <wes> wildcard document
[07:04:04] <wes> passed wglc
[07:04:12] <wes> char will write summary and submit
[07:04:40] --- marka-isc has joined
[07:04:40] --- marka-isc has left: Lost connection
[07:04:46] <weiler> chair doesn't know where 2538bis is.
[07:04:48] <wes> rfc2538bis (cert rr) last call ended march 20
[07:05:05] <wes> docs in last call:
[07:05:17] <wes> dnsext-dns-name-p-s-00
[07:05:26] <wes> and dnsext-dnssec-online-signing
[07:05:29] <wes> -00
[07:05:44] <wes> "white lies" docs
[07:05:58] <wes> chair question: what kind of status do these docs need?
[07:06:05] <wes> experimental or informational?
[07:06:11] --- robertml has joined
[07:06:31] --- ryanczak has joined
[07:06:37] <wes> the initial interest in these docs have waned
[07:06:39] --- marka-isc has joined
[07:06:39] --- marka-isc has left: Lost connection
[07:06:48] <wes> peter koch at mike:
[07:06:54] <wes> de nic would like to see an implementation
[07:07:09] <robertml> if possible get one to do it
[07:07:10] <wes> don't have a firm commitment yet, but on their path to dnssec
[07:07:32] <wes> doesn't mean they will not consider nsec3, but this is critical path
[07:07:48] <wes> olaf: does PK have a preference for which track?
[07:08:23] <wes> PK: not sure if experimental is appropriate, since this modifies the protocol
[07:08:46] <wes> olaf: language modifying 4034/4035
[07:08:57] <wes> in these docs
[07:09:17] --- raj has left: Disconnected
[07:09:25] <weiler> from "white lies" to "weasel words"
[07:09:33] --- raj has joined
[07:09:40] --- raj has left: Disconnected
[07:09:46] <wes> if the document goes to standards track then the language issue becomes irrelevant
[07:09:55] <wes> look at the documents and comment on them
[07:09:56] --- matt_larson has left
[07:10:10] <wes> dnsext-dnssec-trans-02
[07:10:13] <wes> about to go to last call
[07:10:28] <wes> peter koch at mike:
[07:10:32] --- marka-isc has joined
[07:10:32] --- marka-isc has left: Lost connection
[07:10:45] <wes> if send to lc might get an objection from one author so expect another round
[07:11:02] <wes> docs that are finished or about to be
[07:11:07] <wes> dnsext-dnssec-experiments-01
[07:11:17] <wes> about to appear in wglc in september
[07:11:32] <wes> three drafts waiting on dnssecbis docs
[07:12:00] <wes> ongoing work:
[07:12:07] <wes> dnsext-dnssec-bis-updates-01
[07:12:29] <wes> corrects things seen that needs clarification or small editorial changes or small interpretation changes with 4033-4035
[07:12:55] <wes> if anything anyone thinks is relevant for sharing (implementors, readers who see odd language) please inform sam weiler (editor)
[07:13:09] --- Xag has joined
[07:13:12] <wes> additional relevant items: choices made during implementation
[07:13:19] <wes> other ongoing work:
[07:13:23] <wes> dnsext-nsec33-02
[07:13:30] <wes> (nsec3)
[07:13:48] <wes> other work item for group: key management
[07:14:00] <wes> other item (waiting for requirements): last mile
[07:14:11] <wes> what to do with validation result and is there a protocol needed there?
[07:14:18] <wes> nsec3 has recently been updated to new version
[07:14:37] <wes> want to proceed, but don't want to push forward without at least one workshop with running code
[07:14:51] <wes> plan is to organize workshop between now and ietf64
[07:15:19] <wes> if anybody is interested in implementations contact chairs for workshop participation
[07:15:28] <wes> roy arends at mic:
[07:15:33] <wes> small update on changes to nsec-03
[07:15:36] <wes> (nsec-02)
[07:15:50] --- raj has joined
[07:15:56] --- raj has left: Disconnected
[07:15:57] <wes> some tools ready
[07:16:06] <wes> most changes are word changes
[07:16:06] <wes> lesser salt requirements
[07:16:29] <wes> clarified wireformat to a binary form
[07:16:34] <wes> better algorithm description
[07:16:41] <wes> easier to read 6.2 with proper labels
[07:16:48] <wes> 6.4 crypto errors corrected
[07:17:30] <wes> hash truncation bits
[07:17:42] <wes> clarified dos issues with using high iterations value
[07:17:48] --- ripple has joined
[07:17:49] <wes> included an example zone
[07:17:50] --- raj has joined
[07:18:02] <wes> (same zone in dnssecbis drafts but done with nsec3 and optin)
[07:18:05] --- RussMundy has joined
[07:18:06] --- raj has left: Disconnected
[07:18:19] --- marka-isc has joined
[07:18:31] <wes> lack of specification of signaling mechanism for indicating nsec3 othrer than nsec will be addressed in -03
[07:18:39] --- engelhard has joined
[07:18:52] <wes> identified which hash algorithms are required/mandatory
[07:19:08] <wes> rolling to/from nsec3 will be addressed in -03
[07:19:13] <wes> tools:
[07:19:16] <wes> nsec3 capable signer
[07:19:22] <wes> based on net::dns and net::dns::sec
[07:19:32] <wes> includes a lib for nsec3
[07:19:36] <wes> have an nsec3 capable server
[07:19:43] <wes> auth server from scrath
[07:19:46] <wes> to test weird corner cases
[07:20:03] <wes> ben has nsec2 patches for bind with plan to turn them into nsec3 patches
[07:20:05] <wes> further work for -03:
[07:20:09] <wes> rollover text
[07:20:14] <wes> signalling mech for nsec/nsec3
[07:20:18] <wes> required hash algorithms
[07:20:39] <wes> (presentation done)
[07:20:45] <wes> mark kosters with question for chair:
[07:21:01] <wes> plan on having nsec3 auth server available and ready for workshop
[07:21:08] <wes> miek geiben:
[07:21:18] <wes> why is opt-in requirement written in draft?
[07:21:24] <wes> roy arends:
[07:21:32] <wes> sam weiler first:
[07:21:49] <wes> does mark's answer change if the wg decides to change if the wg decides to take the auth bit out of nsec3
[07:21:54] <wes> david blacka from crowd: yes
[07:22:00] <wes> roy arends:
[07:22:05] <wes> doesn't want to repeat discussion on opt-in
[07:22:13] <wes> he still thinks technically there is nothing wrong with it
[07:22:42] <wes> miek: opt-in isn't necessary for nsec3?
[07:22:50] <wes> roy: yes and nsec3 is not necessary for opt-in
[07:23:03] <wes> olafur: if the opt-in bit is taken out it becomes nsec4
[07:23:27] <wes> olaf: slippery slope
[07:23:35] <wes> doesn't want to rehash argument from several years ago
[07:23:46] <wes> hasn't heard technical arguments to take it ou
[07:23:48] <wes> out
[07:24:04] <wes> valid question: should nsec3 have opt-in bit or not?
[07:24:07] <wes> its now in
[07:24:14] <wes> haven't heard anyone complain with technical reasons
[07:24:20] <wes> matt larson at mic:
[07:24:32] <wes> at risk of opening up ancient can of worms
[07:24:40] <wes> agree with olaf that can't argue this point on aesthetics
[07:24:45] <wes> need technical reasons
[07:24:54] <wes> .com and .net have total of 44mil names and counting
[07:25:26] <wes> we can do it without opt-in
[07:25:30] <wes> but we need to give _all_ the tlds
[07:25:35] <wes> all the flexibility
[07:25:39] <wes> to deploy dnssec
[07:26:14] <wes> implore everyone: take the long view and need something we can get deployed
[07:26:16] <wes> sam weiler:
[07:26:21] <wes> question to folks at verisign:
[07:26:32] <wes> hesitant to adopt complexity of nsec3 just because they need opt-in
[07:26:46] <wes> do you need that or would you prefer just opt-in without complexity of nsec3?
[07:26:52] <wes> mark kosters:
[07:27:03] <wes> heard from other registries that need nsec3 for privacy perspective
[07:27:17] <wes> code for nsec2 is really small
[07:27:24] <wes> so saying complexity for nsec3 is a non-starter
[07:27:35] <wes> rob austein:
[07:27:56] <wes> sam was asking if you were offered just plain old opt-in would that be better suited to your needs
[07:27:59] <wes> mark kosters: yes
[07:28:16] <wes> robA: please review discussion from several years ago and stop repeating positions from several years ago
[07:28:28] <wes> olaf: we will not rat hole again
[07:28:32] <wes> main subject:
[07:28:45] <wes> essentially key management part of world
[07:28:52] <wes> olafur: intro slides
[07:29:14] <wes> anonymous at mic:
[07:29:50] <wes> olafur:
[07:30:11] <weiler> the peasants revolt!
[07:30:13] <wes> 2 drafts:
[07:30:22] <wes> threshold n out of m
[07:30:22] <wes> timers
[07:30:23] --- RussMundy has left: Logged out
[07:30:28] <wes> issue: managing trust anchors
[07:30:42] <wes> in ideal world: only 1 managed, in real world: multiple must be managed
[07:30:58] <wes> both have ipr claim filed against them
[07:31:01] <wes> the patent is valid in israel
[07:31:04] <wes> license is available
[07:31:16] <wes> some terms (nothing to do with revenue)
[07:31:25] --- raj has joined
[07:31:34] <wes> implementors in camp of not knowing what to do or ignoring it
[07:31:40] <wes> it being the ipr claim
[07:31:44] <wes> robA :
[07:31:51] <wes> (chair at of old IPR wg)
[07:32:02] <wes> valid isn't best terminology
[07:32:27] <wes> "patent is issued in israel"
[07:32:45] <wes> larger picture:
[07:33:05] <wes> lack of dnssec key mgmt may soon be excuse du jour for not deploying dnssec
[07:33:09] --- hsantos has joined
[07:33:18] <wes> large tlds will not deploy dnssec soon without a market
[07:33:24] <wes> some may never do it
[07:33:35] <wes> early adopters will have to bear particular cost with trust anchors
[07:33:42] <wes> in that TAs must be configured
[07:33:52] <wes> the need for configured TAs may never go away
[07:33:56] <wes> in the best case we only have to manage 1
[07:33:58] <wes> (the root)
[07:34:29] <wes> plea for wg to get more active
[07:34:35] <wes> editors of docs have been met with complete silence
[07:34:54] <wes> wg owes to these docs:
[07:35:02] <wes> DISCUSSION
[07:35:04] <wes> FEEDBACK
[07:35:09] <wes> selection criteria
[07:35:11] <wes> timeline
[07:35:19] <wes> bill manning at mic:
[07:35:28] --- ggm has joined
[07:35:44] <wes> as coauthor
[07:35:49] <wes> taken silence as consent from wg
[07:35:53] <wes> want doc to go to last call
[07:35:56] <wes> and head to iesg
[07:36:04] <wes> thinking the wg is happy with it
[07:36:07] <wes> so let it go please
[07:36:14] <wes> mike st. johns at mic:
[07:36:19] <wes> 2 docs with language in silence
[07:36:27] <wes> so this doc is "approved" as well
[07:36:32] <wes> olaf:
[07:36:39] <wes> we as a wg would like to have 1 solution
[07:36:47] <wes> that was said at a previous meeting
[07:36:56] <wes> but one solution doesn't exclude the other here
[07:37:00] <wes> one is a recommendation
[07:37:02] <wes> the other a protocol change
[07:37:13] <wes> mike st. johns: disagree
[07:37:18] <wes> both require changes to resolver behavior
[07:37:22] <wes> mark andrews:
[07:37:31] <wes> need to decide on one or the other
[07:37:37] <wes> does impact on how operators do their key mgmt
[07:37:47] <wes> don't want to try and manage keys for both of them simultaneously
[07:38:00] <wes> (robA: does mark have an opinon?)
[07:38:09] <wes> mark: (script didn't hear)
[07:38:15] <wes> sam weiler:
[07:38:21] <wes> not sure why we have to make a choice
[07:38:44] <wes> since they need resolver changes
[07:38:54] <wes> is there any harm in having a resolver not doing whats in these drafts?
[07:39:18] <wes> st johns: by ignoreing the timer bit the TAs won't be updated and things go stale
[07:39:33] <wes> SW: suggest this as a question to be added to a list of questions to be evaluated
[07:39:38] <wes> olafur: why not both?
[07:39:47] <wes> need signaling mech to indicate which they use
[07:39:54] <wes> markA:
[07:40:01] <wes> resolver doesn't have to change
[07:40:25] <wes> but something has to notice that the keys have changed
[07:40:25] <wes> could be external tool
[07:40:26] <wes> olafur: "key management component of validator"
[07:40:26] <wes> russ mundy at mic:
[07:40:33] <wes> have a process whereby keys could be updated in an automated way
[07:40:47] <wes> don't think intent was to prevent other types of mechanisms from being used if end-user chose to
[07:40:50] <wes> still valid?
[07:41:06] <wes> olafur: just described how key mgmt component could extract from protocol key changes
[07:41:12] <wes> could still use external processes
[07:41:41] <wes> russM: mike's comment about validators getting out of sync only apply if this auto update mech is only used
[07:41:56] <wes> olaf: comment on choice not strong anymore?
[07:42:20] <wes> st johns: if have mech to roll keys, then keys will roll which means ops will not pay as close attention and those not paying attention will fall behind
[07:42:36] <wes> russM: this not intended to be exclusive mechanism
[07:42:55] <wes> stJ: if ops are making different choices then signalling mech becomes interesting
[07:43:29] <wes> weiler:
[07:44:17] <wes> (scribe missed it and exchange with olafur)
[07:44:56] <wes> olaf: as soon as dnssec deployed, must know rules of key management and make it know to people who configure your keys
[07:45:13] <wes> rip loomis at mic:
[07:45:23] <wes> looked at both of drafts
[07:45:45] <wes> if editors could provide short statement about why they think their method is better would help
[07:45:55] <wes> if someone things we can both at the same time then please post that as well
[07:46:21] <wes> anything with auto-rekey, still need methodology to do a recover with manual rekey
[07:46:34] <wes> weiler:
[07:46:48] <wes> heard msj want to be able to use the schemes with already configured TA
[07:47:10] <wes> stJ: anything we can do to offload op load on end-user will improve deployment
[07:47:28] <wes> browser comes preconfigured with x509 roots
[07:47:56] <wes> olaf: all agree don't want people gonig back to configuration and changing stuff
[07:48:01] <wes> good suggestion from rip:
[07:48:06] <wes> 1 paragraph statement about draft on list
[07:48:12] <wes> with differences
[07:48:53] <wes> billM:
[07:49:55] <wes> wants someone unbiased and not involved with documents to write short doc with abstracts and differences
[07:50:03] <wes> (jim in back of room)
[07:50:12] <Jelte> which jim is that/
[07:50:15] <wes> agreed to try
[07:50:16] <wes> not sure
[07:50:17] <Jelte> ?
[07:50:19] <Jelte> hehe
[07:50:27] <wes> jam cassels
[07:51:10] <wes> wes hardaker at mic:
[07:51:19] --- fujiwara has joined
[07:51:22] <wes> if look at all protocols that have to deploy with keys without auto key rollover
[07:51:33] <wes> keys don't get rolled or key lifetimes are exceptionally wrong
[07:51:38] <wes> long not wrong
[07:52:10] <wes> olaf: short key lifetimes will cause ops to get bitten quickly
[07:52:18] <wes> wesH: unless written in protocol docs users will do whatever they want
[07:52:22] <wes> olafur summary:
[07:52:25] <Peter Koch> Yes, roll keys last Friday of July
[07:52:26] <wes> timers:
[07:52:46] <wes> configure TA
[07:52:52] <wes> keys get added as probationary
[07:52:56] <wes> at some time become TAs
[07:53:16] <wes> (state diagram in slides)
[07:54:10] <wes> if a key is valid and revoke bit set, it goes straight to revoked bucket
[07:54:18] <wes> if key is removed goes to temp state
[07:54:28] <wes> after timeout key is removed unless it reappears
[07:54:51] <wes> msJ: revoke bit to deal explicitly with compromise
[07:54:53] <wes> olafur:
[07:54:56] <wes> n out of m:
[07:55:10] <wes> relationship: certain number of keys in keyset must sign the set
[07:55:27] <wes> if 5 keys in set that a validator trusts, and 3 are required to trust the set
[07:55:34] <wes> if a key is added to the set and signed by others
[07:55:38] <wes> it is added to the set
[07:55:52] <wes> larger dnskey set required
[07:56:15] <wes> keys can become trusted instantly
[07:56:30] <wes> with timers: once a key enters, there is a delay before key can be trusted
[07:56:52] <wes> anybody have thoughts/questions to these two systems:
[07:56:54] <wes> robA:
[07:57:01] <wes> directed to olaf without chair hat:
[07:57:15] <wes> traffic levels with excessive fetching of dnskey sets.
[07:57:24] <wes> does olaf have any opinion on increasing dnskeyset size?
[07:57:26] <wes> olaf:
[07:57:43] <wes> context: there is an impl. that includes a dnskeyset in the additional section
[07:58:10] <wes> bandwidth growth is significantly larger compared to impl. that doesn't include set in additional section
[07:58:31] <wes> but this question is only relevant if keyset is in answer or auth sections
[07:58:39] <wes> because that's where truncation happens
[07:58:43] <wes> need to stay under 2048
[07:59:14] <wes> olafur:
[08:00:04] <wes> shows a spreadsheet that 3 2048 keys signing a set is under a good limit
[08:00:12] <wes> robA: with m of n probably need 3 ksks
[08:00:17] <wes> and you may want to do zsks
[08:00:25] <wes> olaf: fairly probably to have 2 zsks
[08:00:31] <wes> probable
[08:00:53] <wes> 2 zsks can be a little smaller
[08:00:59] <wes> this is rsa
[08:01:02] <wes> ecc relaxes this alot
[08:01:08] <wes> miek geiben:
[08:01:11] <wes> back to proposals
[08:01:42] <wes> m of n seems to be an implementation of mike's revoke bit
[08:01:52] <wes> msJ: concern with other proposal
[08:01:56] <wes> coherence of resolver's view of keyset
[08:01:58] <robertml> "miek"?
[08:02:02] <wes> revoke bit helps maintain
[08:02:10] <wes> yeah, not mike but miek
[08:02:16] <robertml> k
[08:02:31] <wes> RB helps maintain coherence of resolver's view of keyset
[08:02:45] <wes> helps do fast revoke during key compromise
[08:04:10] <wes> meik: can combine the two into 1 thing
[08:04:37] <wes> weiler:
[08:04:45] <wes> like revocation mech
[08:04:48] <wes> worried about this one
[08:04:58] <wes> what happens when resolver that doesn't understand revoke bit gets a key
[08:05:10] <wes> with one, can it still use it?
[08:05:21] <wes> msJ: language in doc: revoke bit is no worse than case without revoke bit
[08:05:33] --- maxwell has joined
[08:05:37] <wes> olaf: revoke bit changes key, key-id becomes different
[08:05:45] --- liman has joined
[08:05:50] <wes> so current resolvers won't recognize this key as the same key
[08:05:52] <wes> billM:
[08:06:05] --- liman has left
[08:06:16] --- mstjohns has joined
[08:06:20] <wes> hesitant about mike's proposal: dependency on shared accurate time
[08:06:25] <wes> olafur: dnssec needs accurate time
[08:06:33] <wes> bill: with revocation comes the impression of pki
[08:06:42] <wes> don't want dns to be pki
[08:06:46] <wes> johan ihren at mic:
[08:06:52] <wes> on threshold mech:
[08:07:05] --- liman has joined
[08:07:10] <wes> agree that packets get alrger
[08:07:12] <wes> larger
[08:07:16] <wes> with 4K packets we're oka
[08:07:30] <wes> with 2K as upper bound we'll run into limits
[08:07:39] <wes> 2K/4K assumption needs to be looked further into
[08:08:18] <wes> also
[08:08:33] <wes> dns is a lot of rope, if people want to shoot in foot with dns without dnssec then possible
[08:08:37] <wes> dnssec adds more rope
[08:08:48] <wes> no proposal will make it easier to do dnssec than to not do it
[08:09:13] <wes> the real task is to find a mechanism that make it viable to deploy this large-scale so that it works on full internet
[08:09:19] <wes> need sw dev to make this happen is clear
[08:09:29] --- jaap has joined
[08:09:33] <weiler> the cloesd-laptops thing seems to have not been completely successful.
[08:09:40] <wes> if people circumvent sw to do manual stuff then so be it
[08:10:07] <wes> if you remove keys and sign the removed set then you can have a problem
[08:10:12] <wes> olaf:
[08:10:16] <wes> slide with traffic data
[08:10:30] <wes> k.root and server with lots of /8 reverse zones
[08:10:31] --- avri has joined
[08:10:41] <wes> 1/10th have edns to k.root
[08:10:48] <wes> 1/3rd have edns to 2nd server
[08:10:52] <wes> looking at edns packets:
[08:11:04] <wes> essentially only 2048 and 4096 edns sizes seen
[08:11:17] <wes> 2048 is a significant fraction
[08:11:26] <wes> so 2K needs to be considered
[08:11:27] <wes> robA:
[08:11:50] <wes> very early discussion in dnssec on revocation mech
[08:12:01] <wes> dropped primarily as tough to figure out how to make it work
[08:12:40] <wes> but with thought that ttl will not be used past sig expire
[08:12:47] <wes> then revocation might work now
[08:12:55] <wes> leaning towards mike's proposal
[08:13:03] <wes> olaf: show of hands that have read the drafts
[08:13:09] <wes> (maybe 10 hands)
[08:13:28] <wes> olaf: who wouldn't mind going in direction of revocation mechanism
[08:13:33] <wes> does need resolver code updates
[08:13:54] <wes> couple of hands
[08:14:05] <wes> who wouldn't mind in other direction:
[08:14:05] <wes> couple of hands
[08:14:08] <wes> anyone with strong preference:
[08:14:09] <wes> not really
[08:14:33] <wes> olaf: this needs to be on list
[08:14:42] <wes> before ietf64 need consensus on which way forward
[08:14:45] <wes> olafur:
[08:14:51] <wes> both docs are currently expired
[08:15:23] <wes> msj: ask AD to revive
[08:15:40] <wes> johan: will resubmit new version
[08:15:45] <wes> next agenda topic:
[08:15:46] <mstjohns> re the state diagram Olaf showed from my presentation... that's the old one. The state machine in the ID currently does not remove the trust anchor unless explictly revoked
[08:16:09] <wes> rob austein:
[08:16:14] <wes> not yet work item
[08:16:16] <wes> nsid proposal
[08:16:23] <wes> about a year old
[08:16:26] --- jeroen has joined
[08:16:28] <wes> came out of work in dnsop
[08:16:34] <wes> on serverid mechanismm
[08:16:40] <wes> kicking around for a long time
[08:17:08] <wes> request from rssac to give way to identify which server in pool of anycast servers talking to
[08:17:17] <wes> existing ad-hoc mech
[08:17:29] --- RussMundy has joined
[08:17:46] <wes> tried to standardize and ran into issues
[08:18:17] <wes> nsid very simple mech
[08:18:24] <wes> edns extensions
[08:18:33] <wes> flag bit in query:
[08:18:38] <wes> "please identify yourself"
[08:18:45] <wes> edns option field for server to fill in and reply
[08:18:52] <wes> 2 open issues:
[08:18:58] <wes> what should nsid payload be?
[08:19:02] <wes> (contents of response)
[08:19:08] <wes> "realname" "realaddress"
[08:19:13] <wes> potential security issues
[08:19:19] <wes> one reason for anycast is to thwart attacks
[08:19:32] <wes> feedback: make it an arbritrary string
[08:19:42] <wes> cookie that is meaningful to server operators
[08:19:50] <wes> useful for debugging
[08:20:03] <wes> main point for protocol extension:
[08:20:31] <wes> in case of quick routing changes, this ident method needs to be in the packet that contains the query
[08:20:52] <wes> other open issue:
[08:21:01] <wes> should recursive server response to SI?
[08:21:15] <wes> original request applied to auth servers
[08:21:30] <wes> mechanism is explicity defined to be not transitive
[08:21:44] <wes> the si bit is for "the server i sent this packet to"
[08:21:52] <wes> yeah, probably okay
[08:22:11] <wes> up to wg to accept work item
[08:22:23] <wes> reqs doc over in dnsop needs to be finished
[08:22:27] <wes> daniel karrenberg:
[08:22:37] <wes> please separate this from dnsop and get this done
[08:22:47] <wes> likes this specific mechansim
[08:23:06] <wes> make as work item for dnsext now
[08:23:29] <wes> matt larson:
[08:23:35] <wes> what about the non-transitive case?
[08:24:07] <wes> you could find out what anycast pod a recursive server is using?
[08:24:14] <wes> ask room: anybody interested
[08:24:18] <wes> danielK:
[08:24:20] <wes> yes interesting
[08:24:24] <wes> get this easy one done first please
[08:24:26] <wes> billM:
[08:24:32] <wes> agree with DK
[08:24:47] <wes> arbitrary string writable by operator or computed by computer?
[08:25:07] <wes> robA: reco is that there is some default if turned on, but...
[08:25:09] <wes> 2 pages of text in draft
[08:25:26] <wes> billM: looks to be operator writable
[08:25:30] <wes> would prefer not to be writable
[08:25:33] <wes> robA:
[08:25:39] <wes> feedback indicated it must be writable
[08:26:05] <wes> mark andrews:
[08:26:13] <wes> leave transitive case for something else
[08:26:16] <wes> DK:
[08:26:24] <wes> don't agree with bill
[08:26:27] <wes> the whole point is that its operator writable
[08:27:05] <wes> robA:
[08:27:11] <wes> purley non-transitive
[08:27:17] <wes> feedback on this?
[08:27:20] <wes> peter koch:
[08:27:29] <wes> second daniel's statement
[08:27:41] <wes> leave transitive out for now
[08:28:06] <wes> something about cookie changing on fly
[08:28:11] <wes> needing to go into sec cons
[08:28:19] <wes> someone at mic:
[08:28:28] <Jelte> anyone got his name?
[08:28:46] <wes> robA: rephrasing transitive question:
[08:29:06] <wes> anybody who would scream about this doc just being non-transitive?
[08:29:08] <wes> none from room
[08:29:20] <wes> olaf: doc to be revised and headed for lc and standards track
[08:29:33] <wes> olafur: goal to be done before ietf64
[08:29:45] <wes> next agenda topic:
[08:29:48] <maxwell> Mohsen Soussi it was
[08:29:51] <wes> dns iana considerations
[08:29:55] <Jelte> ah thanks
[08:30:05] <wes> donald eastlak
[08:30:08] <wes> eastlake
[08:30:25] <wes> dnsext-2929bis-00
[08:31:14] <wes> first, briefly on ecc-key-07
[08:31:19] <wes> standard format needed for interop
[08:31:31] <wes> numerous patent claims and issues
[08:31:40] <wes> patents are on implementations and not basic scheme
[08:31:46] <wes> alg 4 always been reserved for ecc
[08:31:53] <wes> draft proposes specific format for packet
[08:32:02] <wes> please go read the doc and comment
[08:32:14] <wes> olafur: chairs want this draft to hit lc soon
[08:32:26] <wes> want implementors to provide feedback
[08:32:39] <wes> sig size and keys are significantly smaller than rsa
[08:32:58] <wes> DE:
[08:33:01] <wes> 2929bis
[08:33:19] <wes> 2929 was first iana considerations for rr types, classes, rcodes, opcodes, header bits, etc
[08:33:45] <wes> 2929 generally provides some private use, some pub required, some ietf consensus and few reserved for standards action
[08:33:54] <wes> most people concerned with getting new rr types
[08:34:07] <wes> problem: consensus and pub required seemed pretty easy
[08:34:16] <wes> never been rr type allocated on just pub
[08:34:28] <wes> leads to overloading txt cause its hard to get rr type
[08:34:32] <wes> discussion on list
[08:34:42] <wes> mechanism in rfc4020 called early allocation
[08:35:02] <wes> if something is going to be standards track, and wg will reach consensus, then allocation can happen early
[08:35:09] <wes> must be renewed each year
[08:35:17] <wes> feeling on list was that was still too strict
[08:35:44] <wes> 2929bis to fix this problem
[08:35:49] <wes> try to make things more liberal
[08:36:08] <wes> replaces "ietf consensus" with "dns special allocation policy"
[08:36:12] <wes> then section of doc
[08:36:26] <wes> that defines special allocation policy
[08:36:30] <wes> minor changes:
[08:36:35] <wes> covers afsdb subtypes
[08:36:47] <wes> provides some specification required rcode allocation
[08:36:49] <wes> update references
[08:37:02] <wes> not too controversial but what is special allocation policy?
[08:37:05] <wes> currently says:
[08:37:11] <wes> either standards action
[08:37:15] <wes> or approval as something experimental
[08:37:24] <wes> or temporary allocation along style of early allocation
[08:37:28] <wes> requirements for tempA:
[08:37:37] <wes> ID that accurately describes it
[08:37:48] <wes> approval by wg chair and AD or 2 ADs for indiv sub
[08:38:06] <wes> complete template published to namedroppers for at least 2 weeks
[08:38:38] <wes> DE:
[08:38:47] --- maxwell has left
[08:38:49] <wes> did assume namedroppers can exist permanently
[08:39:04] <wes> to where the templates can be published
[08:39:06] --- liman has left
[08:39:36] <wes> thomas narten at mic:
[08:40:00] <wes> 1 question: what problem are we trying to fix here? (by changing the rr type assignment)
[08:40:17] <wes> only one component is the difficulty to get rr type
[08:40:42] <wes> DE: agree, this doc only fixes that one problem (along with minor changes as correct revs to 2929)
[08:41:11] <wes> TN: just because ietf consensus is hard, doesn't mean to be changed across the board
[08:41:20] <wes> what kind of review is needed before things go forward
[08:42:17] <wes> 4020 not appropriate for this doc
[08:42:21] <wes> case for routing protocols
[08:42:38] <wes> where routing wg wants assignments for early code points
[08:42:41] <wes> in case of rrtypes
[08:42:50] <wes> proposals don't come to dnsext and have nothing to do
[08:42:56] <wes> with dnsext
[08:43:05] <wes> the role of this doc for reviewing proposed rr types
[08:43:12] <wes> the definition is specified enough
[08:43:20] <wes> doesn't cause dns to crash or cause operational problems
[08:43:29] <wes> olaf: that is the approach this wg has taken
[08:43:35] <wes> try to look at dns merits of proposals
[08:44:05] <wes> devs want the code point to start work
[08:44:10] --- mstjohns has left: Replaced by new connection
[08:44:13] <wes> TN: 4020 not way to achieve that
[08:44:40] <wes> DE; this only applies to 16bit spaces
[08:44:48] <wes> where we've only allocated a small number
[08:45:30] <wes> TN:
[08:45:43] <wes> with dns special allocation policy what he thinks we mean is:
[08:45:46] <wes> expert review
[08:45:52] <wes> with wg chair involvement
[08:46:18] <wes> the way ietf deals with wgs going away is by declaring an expert
[08:46:45] --- johani@jabber.org has joined
[08:46:46] <wes> why are we concerned with reclaiming unused allocations?
[08:46:50] <wes> olafur: we aren't
[08:46:57] <wes> TN: then why are they temporary?
[08:47:12] <wes> someone at mic:
[08:47:18] <wes> with allocations coming from ID
[08:47:36] <wes> then there might not be a reasonable pointer in code if ID goes away
[08:48:10] --- maxwell has joined
[08:48:19] --- joao has joined
[08:48:24] <wes> much better to try and fit this into existing structures
[08:48:28] <jeroen> wes: person speaking now is Margaret Wasserman
[08:48:40] --- joao has left
[08:48:46] <wes> thank you
[08:49:46] <weiler> she's our new AD.
[08:49:57] <wes> details
[08:50:47] <wes> (ed: the discussion is how this will affect iana and interactions with iana)
[08:50:59] <wes> robA: current process is not fundamentally broken
[08:51:09] <wes> people not getting rr types because they aren't asking
[08:51:20] <wes> specific suggestions:
[08:51:25] <wes> 2 weeks for notice is too short
[08:51:34] --- avri has left: Logged out
[08:52:00] <wes> 3rd: Not sure if rcodes should be loosened
[08:52:20] <wes> TN: changing rcodes is like changing the protocl
[08:52:35] <wes> replacing (something) with expert review will fit into iana structures
[08:52:53] <wes> (last line about wg + ad approval)
[08:53:09] <wes> not opposed to loosening rrtypes, but don't think its fundamentally broken
[08:53:32] <wes> MW: how is this easier or takes less time than specification required?
[08:53:44] <wes> olafur: wg with 2 proposals
[08:54:18] <wes> not sure how long it would take to get to iana queue
[08:54:27] <wes> MW: if assignment in complex documetn could take a while
[08:54:47] <wes> perhaps have a media-assignment-type doc where the assignment could be on a short doc
[08:54:51] <wes> and then processed quickly
[08:55:42] <wes> problem with getting an assignment without an archived publication
[08:56:14] <wes> billM:
[08:56:38] <wes> old rrtypes
[08:56:38] <wes> 101, 102, 103
[08:56:39] <wes> now iana reserved
[08:56:44] <wes> were temporary assignments
[08:57:07] <wes> difficulty with temp assignments: they will show up in some implementations and not others
[08:58:33] <wes> olaf: this discussion is not from thin air
[08:58:44] <wes> some people are unhappy with current process
[08:59:15] <wes> TN: is it red-tape or something else?
[09:00:40] <wes> olaf is talking about red-tape and process issues
[09:00:56] <wes> weiler:
[09:02:15] <wes> still part of space is standards action
[09:02:17] --- engelhard has left: Replaced by new connection
[09:02:18] --- engelhard has joined
[09:02:30] <wes> this only applies to ietf consensus part of space
[09:02:52] <wes> question: do we have a need to issue type codes temporarily or not without publication?
[09:03:00] <wes> TN: what's different between ietf consensus and this?
[09:03:07] <wes> diff between pub required and this?
[09:03:30] <wes> on pub required: iana not required to allocate code without doc through iesg
[09:03:46] <wes> with this mech: the draft can sit around in wg and get tweaked and still have a code
[09:03:58] <wes> olaf: people come to ietf with their work and want a code
[09:04:06] <wes> weiler: provide a faster method to publication
[09:04:11] <wes> TN: keep it simple please
[09:04:27] <wes> peter koch:
[09:04:52] <wes> heard about people adding things to dns and then can't change codebase because deployment is too large
[09:05:14] <wes> when temp allocation is done, how stable must (something) be for approval
[09:05:21] --- jeroen has left: Logged out
[09:05:38] <wes> DE: if people are going to get something allocated and then use for a different purpose, not sure what we can do about that
[09:07:28] --- CathyM has left
[09:08:19] <wes> (back to some slides at the end)
[09:08:43] <wes> possible template questions
[09:09:13] <wes> associated with class allocations
[09:09:34] <wes> and type allocations
[09:09:42] <wes> why won't an exisiting class/rr work?
[09:09:56] <wes> does the proposed rr/class require special handling?
[09:10:07] <wes> TN: how many class types have we assigned over the past 10 years?
[09:10:22] <wes> so why do we need a faster allocation for class?
[09:10:31] <wes> robA:
[09:11:04] <wes> there are enough layer9 issues with classes, not sure if we want to take the lid of the can of worms for easy class number assignment
[09:11:23] <wes> leave it alone
[09:11:31] --- joao has joined
[09:11:35] <wes> next agenda topic:
[09:11:59] <wes> (no, we're not done yet)
[09:12:11] <wes> interop testing report
[09:12:23] --- Xag has left
[09:12:49] <wes> (before test report, there are no current docs from other WGs needing review)
[09:13:11] <wes> olafur:
[09:13:15] <wes> interop testing report:
[09:13:30] <wes> mohsen soussi:
[09:13:43] --- bernt1998 has joined
[09:13:51] <wes> frnic testing for notify rfc
[09:14:50] <wes> expect mail to wg about possible implementations for testing
[09:14:59] <wes> jaap auekerhuis:
[09:15:06] <wes> (i can never spell his name right)
[09:15:12] <Jelte> akkerhuis :)
[09:15:19] <wes> uh huh :)
[09:15:29] <wes> testing about serial number arithmetic
[09:15:38] <weiler> rfc1982
[09:15:40] <wes> will write something up for mailing list
[09:16:05] <wes> nobumichi ozue:
[09:16:14] <wes> ozoe:
[09:16:24] <wes> tahi dns test tool
[09:16:29] <mo7sen> For the record (spelling): Actually, "Mohsen Souissi", just me ;-)
[09:16:59] <wes> thanks for the correction
[09:16:59] --- ggm has left: Disconnected
[09:17:27] --- fujiwara has left: Logged out
[09:17:41] <wes> tahi project starts to develop application layer protocol test
[09:17:49] <wes> test target: client/server
[09:17:52] <wes> tcp/udp/v4/v6
[09:17:57] <wes> this is a dns test tool
[09:18:01] <wes> support following rfcs:
[09:18:15] <wes> 1034,1035,1123,1995,1996,2131,2308,3425
[09:18:29] <wes> extension rfcs:
[09:18:47] <wes> 2671, 2782, 3596, 3401-3405,4034-4035
[09:18:50] <wes> schedule:
[09:19:01] <wes> october 2005 beta version available
[09:19:11] <wes> april 2006 version 1.0 released
[09:19:16] --- joao has left
[09:19:24] <wes> hope implementors will use this tool against their implementations
[09:19:37] <jakob> http://www.etsi.org/plugtests/IPv6.htm
[09:19:53] <wes> hope to discuss test specification
[09:20:02] <wes> at http://www.tahi.org/dns/
[09:20:22] <wes> mohsen souissi:
[09:20:30] <wes> understand to be test for compliance
[09:20:35] <wes> very useful for draft standard rfcs
[09:20:42] <wes> but for proposed standard rfcs
[09:20:51] <wes> is compliance testing appropriate?
[09:20:58] <wes> specifically notify and another draft
[09:21:07] --- marka-isc has left
[09:21:12] <wes> is there a risk of collision between compliance test and interop test?
[09:21:21] <wes> olafur: don't think any risk in having too many tests
[09:22:22] <wes> rip loomis atmic:
[09:23:13] <wes> wants another post to wgml when more content available
[09:23:43] <wes> MS: can we do compliance before interop?
[09:24:00] <wes> olaf: if there is compliance but non-interop, then that is a problem
[09:24:07] <wes> can see this testing as interop testing
[09:24:11] <wes> robA:
[09:24:17] --- amarine has left
[09:24:26] <wes> this seems quite useful
[09:24:35] <wes> especially for developers
[09:24:50] --- schoenw has left: Disconnected
[09:25:15] <wes> olaf: 2 final things
[09:25:40] <wes> changing job, so email address will change in september
[09:25:45] <wes> on namedroppers:
[09:25:54] <wes> see lots of discussion, good intentions, no actions
[09:25:57] <wes> /results
[09:25:59] --- dblacka has left: Logged out
[09:26:09] --- marka-isc has joined
[09:26:45] --- ryanczak has left
[09:26:47] --- ripple has left
[09:26:53] <wes> discussions don't get wg anywhere
[09:27:00] <wes> internet drafts are what wg can deal with
[09:27:06] <wes> put money where mouth is and write an id
[09:27:12] --- pawal has left
[09:27:26] <wes> robA:
[09:27:31] <wes> this problem not unique to this wg
[09:27:46] --- hsantos has left: Logged out
[09:29:11] <wes> both chairs on vacation
[09:29:17] <wes> ed lewis will be moderator of list while gone
[09:29:19] --- marka-isc has left: Disconnected
[09:29:19] --- jakob has left
[09:29:22] <wes> (who put ed in charge?)
[09:29:22] --- ogud has left
[09:29:27] --- bernt1998 has left
[09:30:01] --- johani@jabber.org has left: Logged out
[09:30:41] --- engelhard has left: Disconnected
[09:31:52] --- raj has left: Disconnected
[09:33:43] --- wes has left
[09:45:33] --- RussMundy has left: Logged out
[09:49:18] --- Jelte has left: Disconnected
[09:51:38] --- jaap has left: Disconnected
[09:52:03] --- robertml has left: Disconnected
[09:53:20] --- maxwell has left: Replaced by new connection
[09:54:41] --- suz has left
[10:04:07] --- mo7sen has left: Disconnected
[10:09:39] --- weiler has left
[10:14:12] --- marka-isc has joined
[10:14:20] --- marka-isc has left
[10:22:42] --- engelhard has joined
[10:24:15] --- engelhard has left
[10:24:31] --- Peter Koch has left: Disconnected
[14:04:53] --- jlcjohn has left