[00:43:43] --- marka-isc has left
[15:09:27] --- kivinen has joined
[15:09:30] --- kivinen has left: Logged out
[17:46:08] --- sleinen has joined
[18:23:32] --- raeburn has joined
[18:28:57] --- sleinen has left: Disconnected
[18:37:03] --- bensons has joined
[18:44:45] --- warlord has joined
[18:50:30] --- bensons has left: Replaced by new connection
[18:50:31] --- bensons has joined
[18:57:10] --- tlyu has joined
[19:01:16] --- ogud has joined
[19:02:03] --- ggm has joined
[19:02:45] --- Tom Phelan has joined
[19:03:11] <ggm> hmm. I suppose its time to get into the plenary room. or, alternatively, I can whip myself with stinging nettles, and rub a cheesegrater over my chest. which is worse?
[19:04:09] --- jc_lee has joined
[19:04:13] --- ogud has left
[19:04:33] <bensons> stinging nettles do hurt...
[19:07:55] --- frodek has joined
[19:10:32] --- marka-isc has joined
[19:10:58] --- rlbob has joined
[19:20:11] <ggm> IRTF section: crypto group
[19:20:37] <ggm> hashes somewhat misused. often misunderstood. now, concern about lifetimes, proving shorter than expected.
[19:20:40] --- deng has joined
[19:20:41] --- Tom Phelan has left: Lost connection
[19:20:59] --- ggm has left
[19:21:27] --- ggm has joined
[19:21:33] <ggm> main goal is collision resistance.
[19:22:40] <ggm> table on slide showing goals, status for various functions. goal to protect 2**64 operations cost. now 2**20
[19:22:43] <ggm> sha1 was 2**80, but now broken for 2**63.
[19:22:49] --- rlbob has left
[19:23:01] <ggm> sha-224/256 not known. whirlpool likewise (newer function)
[19:23:17] <ggm> dates expected to be useful. NIST crypto program
[19:24:06] <ggm> [is this worth doing, or can I go back to flailing myself with nettles? -ggm]
[19:24:41] <ggm> computational resources growing. have to keep upping the ante. SHA1 phase-out 2011. internet community interested in NIST guidelines, want certification
[19:24:58] <ggm> obviously need to replace, what with?
[19:26:06] <ggm> russ housely suggested SHA256 for digisigs. *security directorate*
[19:26:29] <ggm> SHA1 is still ok for some uses. slide with table of uses, some of which are fine for now.
[19:26:45] <ggm> digisigs, broken for third party, but ok for entity auth (for now)
[19:27:03] <ggm> mesg/auth raw sha1 is bust, HMAC/SHA1 is ok for now
[19:27:10] --- raeburn has left: Lost connection
[19:27:15] <ggm> key auth: raw sha1 and hmac sha1 both ok for now.
[19:30:04] --- Roy Brabson has joined
[19:31:47] <ggm> looked for hash citations in RFCs. grep/awk job.
[19:32:10] <ggm> totals are scary! sha1 cited by 151. not many obsoleted. big impact.
[19:32:23] <ggm> HMAC popular, 120. sha2 has 2, but MD5 has ...
[19:32:25] <ggm> 360
[19:32:29] <ggm> thats the scary part
[19:32:41] --- Roy Brabson has left: Disconnected
[19:33:03] --- Roy Brabson has joined
[19:33:55] --- mrichardson has joined
[19:34:02] --- javier has joined
[19:34:21] <ggm> CRFG and hashing.
[19:34:26] <ggm> looking at alternative functions.
[19:34:42] <ggm> looking for the places where hashes can be replaced.
[19:35:23] <ggm> consideration of SHA-224, SHA1-IME, SHA-256, Whirlpool. -IME is a SHA1 redesign, to get better diffusion in the hashspace, quantifyable. worth persuing.
[19:35:31] <ggm> even though SHA1 has only 5 years to go.
[19:35:47] <mrichardson> ggm, thanks.
[19:35:52] <ggm> [I guess because the field/code could stay the same, its just different bit generation in the same space so zero protocol impact]
[19:36:06] <ggm> polls for whirlpool impl.
[19:36:07] <ggm> none.
[19:36:18] <ggm> one.
[19:36:20] <mrichardson> had to go up to room to help feed munchkin.
[19:36:21] --- raeburn has joined
[19:37:48] <ggm> hash replacement
[19:37:53] <ggm> think HMAC secure
[19:39:17] --- nico has joined
[19:39:42] <ggm> AES based methods. msg auth codes.
[19:40:26] <ggm> gets confidentiality AND auth at the same time. nice outcome
[19:40:40] --- javier has left: Logged out
[19:40:43] --- javier has joined
[19:41:05] <ggm> want random input hashing. can prove some things about the security goal.
[19:41:50] <ggm> so. what to do.
[19:41:54] <ggm> replace SHA1. replace MD5.
[19:42:12] <ggm> MAC use, use AES-based MAC. or auth-enc mode.
[19:42:22] <ggm> for other apps, SHA-256, or analyse security needs
[19:43:05] <ggm> build in alg. agility. code able to cope with changes
[19:43:15] --- kanda has joined
[19:43:25] --- paulwouters@jabber.org has joined
[19:44:33] --- Roy Brabson has left
[19:44:45] --- Roy Brabson has joined
[19:45:11] --- Ed J. has joined
[19:46:10] <ggm> Q about ECC use
[19:46:20] <ggm> A: never done analysis. depends who you ask
[19:47:35] <ggm> using SHA256 is reasonable if wanting DigSig takes so long to get cert auth, to support all the algs for certs, multi0year process. choose more secure to start with
[19:48:12] <ggm> Q: chop down SHA-256 and use its bits, or just use SHA1?
[19:48:16] <ggm> A: excellent Q.
[19:49:08] --- geoff has joined
[19:50:29] <ggm> zinin. Q. consistenly hearing msg don't use keyed md5 for msgauth. applies here?
[19:50:48] <ggm> A yes. HMAC MD5 no published crypto. break but move away from it. bet thats the next MAC to go
[19:51:11] <ggm> Zinin. don't look at HMAC, or actively move away..
[19:51:17] <ggm> A move away from HMAC-MD5
[19:52:03] <ggm> maybe will be ok, when analysis completes but dont bet on it
[19:52:19] <ggm> zinin draft/RFC to document issues at this point. have one on HMAC-MD5, then replace
[19:52:31] <mrichardson> who uses it, or is it vulnerable due to SHA dependancy?
[19:52:42] <ggm> Q: status, more sanguine on HMAC-MD5
[19:53:08] <ggm> [dunno]
[19:53:22] <ggm> talk about current results on applying collisions to certs.
[19:53:53] <ggm> A state of art forging certs. don't think alg. presented, sha1 hash presented in practice which did it. community expects to come.
[19:54:06] <ggm> wrong to rely on fact no alg presented to forge, at this point. forged MD5 docs are great example
[19:54:31] <ggm> people think certs wont be a problem.
[19:54:43] <ggm> Qnr, best I know, two certs same name, diff keys.
[19:54:55] <ggm> even if MD5 broke tomorrow, pair certs in collission, wouldnt affect issued certs.
[19:54:59] <ggm> gone to SHA
[19:55:07] <ggm> as long as CA role algs before break, no problem
[19:55:11] <ggm> unless attacks much better than before
[19:55:20] <ggm> Nico Williams. what said at SAAG
[19:55:39] <ggm> need to consider PRGs, PRFs. now two drafts in IESG make PRF avail as proto-elem.
[19:55:41] <ggm> A agree
[19:55:57] <ggm> (pseudo random funcs, generators)
[19:56:03] <ggm> A great discussion.
[19:56:11] <ggm> Dave Crocker. Q about agility thing
[19:56:29] <ggm> msging in deep space introduced latencies which are a bit of a problem. negotiating which to use.. doesn't work to well on high latency
[19:56:38] <ggm> A slow. open problem
[19:56:55] <ggm> <ends>
[19:56:59] <ggm> Leslie in the chair.
[19:57:19] --- nov has joined
[19:57:29] <ggm> [if anybody isn't doing it, the .mp3 feed from UO is *brilliant* -ggm]
[19:57:32] --- nico has left: Disconnected
[19:57:36] <ggm> IAB chair report
[19:57:42] <ggm> then rest of IAB to take Qs
[19:58:55] <ggm> http://videolab.uoregon.edu/events/ietf/
[19:59:06] <ggm> want to discuss IAB overview because its NomCom time.
[19:59:22] <ggm> see 2850 for documentation of role.
[19:59:35] <ggm> talking how to get on. process stuff.
[20:00:27] <ggm> IAB role in IESG appt. confirmation. rarely seen part of NomCom process, finishes list, gets delivered to IAB to review (for IESG)
[20:00:54] --- Ed J. has left
[20:01:21] <ggm> Other IAB roles
[20:01:30] --- geoff has left
[20:01:32] <ggm> stds process oversight. appeals chain.
[20:02:03] <ggm> Liaison role. ISOC, Externals
[20:03:11] <ggm> and Architecture
[20:03:18] --- nov has left: Disconnected
[20:03:38] --- nov has joined
[20:05:56] <ggm> Ad-Hocs now listed at http://www.iab.org/about/adhocs/index.html
[20:05:56] <ggm> IPv6 AdHoc continues, IDN concluding
[20:06:16] <ggm> Documents
[20:06:42] <ggm> tech focus
[20:07:01] <ggm> V6. uptake issues.
[20:07:16] <ggm> Internet Architecture. what bits to collect, disseminate about it
[20:07:33] <ggm> Bad Net Traffic. info/insight on bad traffic, what to do
[20:07:36] <ggm> since ietf63.
[20:07:58] <ggm> on v6, did the MH BoF at NANOG. effort to take MH to operator fora. bring experiences back into IETF
[20:08:05] --- Roy Brabson has left: Replaced by new connection
[20:08:23] <ggm> overall, useful discussion. more sessions will follow perhaps
[20:09:14] <ggm> TLD doc 'whats in a name' approved
[20:09:18] <ggm> Bad traffic
[20:09:26] <ggm> DoS attack doc updated.
[20:09:28] <ggm> workshop proposal
[20:10:12] <ggm> Town Hall time. IAB on stage, pole-dancing
[20:10:31] <ggm> <dead men walking>
[20:10:51] <ggm> Leslie shows 'the plan' as a spreadsheet
[20:11:18] <ggm> IAB introduces itself
[20:12:16] --- mrichardson has left: Replaced by new connection
[20:12:23] <ggm> Ted at mike. bringing up issue, IAB, reviewing BoFs, to be more involved with BoF formation
[20:12:34] --- mrichardson has joined
[20:12:49] --- Tom Phelan has joined
[20:13:52] <ggm> Patrik. good liaison. we discuss
[20:13:59] <ggm> Leslie how can the IAB be more involved
[20:14:05] --- nov has left: Replaced by new connection
[20:14:14] --- kivinen has joined
[20:14:19] <ggm> Dave my experience, BoF formation, relationship between AD and proposer.
[20:14:20] --- nov has joined
[20:14:56] <ggm> hadn't been a place for IAB to inject themselves in process. might personally do this, not sure, when bof proposals come up, IESG member, let us know, we can see how to discuss with you
[20:15:08] <ggm> John Loughney. related comment
[20:15:40] --- kivinen has left: Disconnected
[20:15:45] <ggm> noticing few IETFs people not re-using proto, extending in non-backwardscompat ways. hard to get people involved with arch grounding.
[20:16:09] <ggm> help. make key decisions early on. group of people, already made design, have arch, if doesn't fit whats done, hard to persuade them to change
[20:16:09] --- kanda has left: Disconnected
[20:16:28] --- tlyu has left: Lost connection
[20:16:29] <ggm> proactive is good
[20:16:58] <ggm> A from IAB: having issues visible, Q visible, more likely IAB will take them on
[20:17:09] <mrichardson> ggm, can you ask AV people to turn up gain on mikes?
[20:17:20] <mrichardson> remote is apparently very soft.
[20:17:27] <ggm> remote mike soft. ok.
[20:18:13] <ggm> [pinged joel. will see if responds, may be busy/elsewhere]
[20:18:21] <paulwouters@jabber.org> i think it is slight better. still very quiet though. thanks
[20:18:38] <ggm> Tomas Narten. good to get IAB involved. not just IAB, community
[20:18:41] <ggm> need to change culture
[20:18:43] <ggm> do more work
[20:19:13] <ggm> partnership.
[20:19:38] <ggm> Leslie -comment
[20:20:01] <ggm> background, agree with what Thomas just described, good thread, IAB doesn't find out BoF until cruise agenda, same as everyone else.
[20:20:09] <ggm> to be fair, lot of AD's caught in squeeze.
[20:20:23] <ggm> right idea as ideal, reality intervenes
[20:20:36] <ggm> Keith Moore
[20:20:42] <ggm> problem in community, work is piecemeal
[20:20:52] --- nov has left: Replaced by new connection
[20:20:59] --- nov has joined
[20:21:01] <ggm> often never reconcile things
[20:21:10] <ggm> need to get away from notion WG frames context by itself
[20:21:33] <ggm> should start not hosting BoF forming WG. neutral body. bring in discussion, review scope, other PoV.
[20:21:45] <ggm> IESG, might invite IAB members to chair bofs
[20:21:45] --- bensons has left: Disconnected
[20:21:57] <ggm> not requiorement, but may bring them in
[20:22:04] <ggm> Missed name
[20:22:04] --- nov has left: Disconnected
[20:22:20] <ggm> practical proposal. what john said. read eriks proto model document.
[20:22:30] <ggm> tells people to describe document in high level way, structured approach
[20:22:33] <Tom Phelan> Hannes Tschoefenig (spelling?)
[20:22:39] <ggm> sometimes BoF missing structure approach
[20:22:47] --- nov has joined
[20:23:06] <ggm> good maybe, there is a structure, some architecture, short description, key issues, arch impacts, some BoF proposals have impact onarch. security challenges
[20:23:21] --- javier has left
[20:23:22] <ggm> few interesting issues. come up with description beforehand, easier for eveyrone to figure out what going on.
[20:23:45] <ggm> Brian. want to say, recently had to give talk about IETF to audience of newbs. tried to show process in 1 chart.
[20:24:00] <ggm> idea -> RFC. first stage, apart from initial idea, is 'informed discussion'
[20:24:20] <ggm> we talk about how we deal with new ideas when we get to BoF. maybe we need IAB in initial discussion, which btw is anytime, anywhere
[20:24:27] <raeburn> informal, i think, not informed?
[20:24:33] <ggm> David. enough criticism from floor. want to give some praise
[20:24:43] <ggm> [probably. -=ggm]
[20:24:46] <raeburn> maybe i mis-heard...
[20:24:48] --- jc_lee has left
[20:25:07] <mrichardson> i suggest that BOFs have seperate time slots allocated for them.
[20:25:19] <ggm> Hinden. 15-16. seems like an awful lot. lot of new work to think about. like to see IAB get a little more earlier into BoF. maybe its discussion. review. plan of BoF.
[20:25:37] <mrichardson> i.e. thursday morning is reserved for BOFs, 3 1 hour slots, no simultaneous WGs scheduled.
[20:26:16] <ggm> Focus more on problems, helps see them evolve
[20:26:56] <ggm> Patrik. BoF examples was involved in today.
[20:27:22] <ggm> Voipeer. one ID member, chair of bof, large amount of discussions before BoF, meetings, and after BoF, went through what happened.
[20:27:23] --- raeburn has left: Replaced by new connection
[20:27:49] --- nov has left: Replaced by new connection
[20:28:01] <ggm> another one, not done so much homework was I18n email addresses. issues wre brought out in BoF, have to do homework afterwards, find things IAB can do. without consensus. two different BoF, ways IAB can help.
[20:28:07] --- nov has joined
[20:28:16] <ggm> Johnathan want to echo what David said.
[20:28:28] <ggm> recipe for success was BoF chair reaching out.
[20:28:44] <ggm> IAB speak, did big-picture stuff.
[20:29:00] <ggm> Problem, going in, taking notes, making recommendations., doesn't help. takes investment to make +ve change
[20:29:07] <ggm> Erik
[20:29:16] <ggm> hearing a lot, people thjink IAB should be involved.
[20:29:39] --- raeburn has joined
[20:29:45] --- tlyu has joined
[20:29:48] <ggm> happy to take role with qualifications
[20:30:50] <ggm> Aaron. involved in 3 bofs. in all 3 cases, became WG. reason successful in BoF and WG charter process, was because we had senior IETF folks guiding us, esp. when very new to process, got oriented. discussions, finding the key individs active in the area, finding objections/issues before the BoF. no suprises.
[20:30:53] <ggm> IAB can play role here
[20:31:39] <ggm> Keith Moore.
[20:31:47] --- nov has left: Replaced by new connection
[20:31:48] <ggm> happy the IAB is taking a greater role
[20:33:22] <ggm> (sorry, missed things a bit)
[20:33:42] <ggm> <person> get stories. tell story. collect the history. find the parallels/parables
[20:34:48] --- nov has joined
[20:34:58] <ggm> if want to do IPSEC on machine in the future, moving I/F MH issues, trying to think how to implement all the choices of <x>6 and mobike, how do you do it? 4 groups spanning the problem space. its too much. take a few WG, take the idea of implementing ALL of the wg overlaps. in same app/kernel. the 'story' is hard, then think about other stories
[20:35:02] --- kanda has joined
[20:35:18] <ggm> this is not something exclusively the IAB could do, we can do this. figure stuff out, get clue. write drafts
[20:35:28] <ggm> Ted yes
[20:35:51] <ggm> Pekka. have identified this particular case/issue, have discussed (the number of MH v6 related WG)
[20:36:09] <ggm> want to discuss/principles in a doc
[20:36:09] --- kanda has left: Disconnected
[20:36:25] <ggm> what are the relationships. doing this kind of work is not easy. will tkae time. talk to me, other IAB.
[20:36:40] <ggm> Tom.
[20:36:49] <ggm> IAB drafts, help focus things.
[20:37:00] <ggm> thinking mode. more you can push opinions around, argue them out, the better
[20:37:14] <ggm> Leslie thanks. has come up in IAB, feel writing into vacuum.
[20:37:38] <ggm> docs do reference IAB docs. so thats good
[20:38:05] <ggm> talk to IAB. via AD, or directly
[20:38:26] <ggm> HTA.
[20:38:35] <ggm> one comment haven't heard at plenary.
[20:38:49] <ggm> someone standing at the mike, IAB, your recommendations are bullshit.
[20:38:55] <ggm> two possibilities: [laughter]
[20:39:09] <ggm> either IAB is perfect
[20:39:10] <ggm> or
[20:39:29] --- kanda has joined
[20:39:36] <ggm> the IAB is sharper, more pointed in its documentation without causing problems in community. but absence of even ONE is odd..
[20:39:41] <ggm> Maybe all frightened
[20:39:45] <ggm> [nervous laughter]
[20:40:03] <mrichardson> maybe someone already in the mike lineup can channel me, if they agree.
[20:40:17] <ggm> Patrilk: argue back. need to see it
[20:41:24] <ggm> Ted
[20:41:30] <ggm> we have new protos. DCCP, etc
[20:41:50] --- kanda has left: ログアウトしました
[20:42:00] <ggm> also apps used to running just on TCP. just finished talking about krypto agility.
[20:42:06] <ggm> how to manage it over SCTP sometimes, TCP sometimes
[20:42:12] <ggm> or SIP over DTLS sometimes. how to manage it?
[20:42:20] <ggm> BC
[20:42:27] <ggm> solved many years ago.. [laughter]
[20:42:45] <ggm> applications/packages which do include agility layer [the joke was he meant OSI session layer]
[20:42:51] <paulwouters@jabber.org> [stream died complelty for me now]
[20:42:59] <ggm> problem is the delays/effects. if goinh in that direction
[20:43:07] <ggm> mp3 stream dead? I'll feed that back.
[20:43:38] <ggm> BC serious risk multiplicity of TX protos is complexity just above the waist in the hourglass. not good thing
[20:44:20] --- sleinen has joined
[20:44:25] <ggm> Joel says audo feed is live for him
[20:44:54] <ggm> Keith. dont want to require transport agility. nice to allow it
[20:45:03] <paulwouters@jabber.org> [back now]
[20:45:06] <ggm> Jonathen agree with keith.
[20:45:25] <ggm> NAPTR stuff interesting. complicated. complex
[20:45:41] <ggm> diversity is not feature at this time
[20:45:48] <ggm> agility not always good.
[20:45:56] <ggm> john laughney. follows tims comment.
[20:46:04] <ggm> avoid complexity at TX, complexity just below it.
[20:46:36] <ggm> multiple radios, multiple properties. add lots of things at IP layer. mobile4 mobile6 combined 4/6. dhcpmobility. all sorts of things. wreaks havoc with tx protos
[20:46:41] <ggm> do everything over UDP to avoid it
[20:46:50] <ggm> network buffer etc etc
[20:47:05] <ggm> arch issue
[20:47:16] <ggm> ePete resnick
[20:47:33] <ggm> view shim6 as interesting way now push tcp a little higher to session layer. apps don't think about tx issues underneath
[20:47:45] <ggm> big concern
[20:47:51] <ggm> pekka
[20:47:59] <ggm> john, asking Q tim asked, tried to ask before.
[20:48:31] <ggm> to me, dunno if IAB agrees, become clear need id/loc split.
[20:48:45] --- nov has left: Replaced by new connection
[20:48:52] --- nov has joined
[20:48:55] <ggm> dont know which kind, from CS PoV, when hve mob, and MH, multi-addressing, need new layer of indirection, to add to archm need new namespace
[20:49:54] <ggm> split ads into host-ids, locaters, bits and pieces in IETF working on same thing. KHI, keyed hash identifiers, allocate, part of V6 address space for identifiers, used as nonroutables, not locaters, look like them, but are just unique. can be bound to other ones by crypto means
[20:50:34] --- ogud has joined
[20:51:03] <ggm> Pekka had meeting with shim6, how to do
[20:51:08] <ggm> Leslie wrapping up here
[20:51:36] <ggm> Hinden
[20:51:41] <ggm> nobody said one box fits and works all cases
[20:52:00] <ggm> we dont do systems here, we do pieces, parts.
[20:52:15] <ggm> requires careful selection what you put together. maybe we need roadmap/framework
[20:52:25] <ggm> always going to have problem
[20:52:36] --- ogud has left: Replaced by new connection
[20:52:38] --- raeburn has left
[20:52:52] <ggm> <my brain hurts. I may be stopping in a while, reaching end-of-life time as a jabberscribe>
[20:53:14] <ggm> Rescorla
[20:54:41] <ggm> Kengo Nagahashi, presented to CRISP, routing registry draft, consensus in WG, routing is different, CRISP has validity over domain name, address, intention is to adopt RR into such kind of framework, to ensure hierarchical framework in RR. right now its very loose, intention to adopt very hierarchical arch.
[20:55:38] <ggm> consensus in CRISP is routing is different, to domain, address registry. have clear structure, TLD, have some addresses, same thjing, top down assignment process through RIR.NIR. routing is different. Ted suggested us to have BoF to adapt RR to loose hierarchical framework, have another, framework, that is good idea,
[20:55:54] <ggm> want to know, comments about, completely different, routing, domain and address, whan
[20:56:13] <ggm> Leslie. I was at CRISP WG. heard that exchange.
[20:56:16] <ggm> two separate points.
[20:56:33] <ggm> CRISP WG is focussed on domain registries, not neccessarily differnt, its a work item for someone else
[20:56:38] <ggm> Kurtis
[20:57:16] <ggm> ggm goes to mike, not scribing here
[20:59:41] <deng> hierarchical routing management could be considered in Japanese communicty, but not in world community
[21:00:14] <deng> not in gmm group, could form a new group
[21:00:45] <ggm> [thanks]
[21:01:01] <deng> [you are welcome]
[21:01:55] <ggm> Ted. how using RR to understand this thing, its not typically hierarchical, not just origin-AS announcing, what transit AS, its not hierarchy its mesh. where does this protocol stop? where can it add value? encourage audience, IAB to get involved in BoF planning
[21:01:56] <ggm> Pekka
[21:02:50] <ggm> taking long term view, 20-50 years, 100, I think its bad to add hierarchy to routing. adding hierarchy to routing adds political hotspot to architecture. in my opinion, work towards address/routing less hierarchical, less controlled, more decentralized. longterm view. in short term may want to go into hierarchy. but is dangerous, creates power structures
[21:02:52] <ggm> Kurtis
[21:03:39] <ggm> routing table as seen today, very fragmented, nonstructured, makes its own problems. when you try to mimic this tructure, hierarchy in DB, there are problems. very hard to anticipate who claims ownership. try to verify the path seen
[21:04:04] <ggm> suballocs. 5 RIRs, single AS throughout world, get resources from all 5, move them around a bit. don't show up in one registry. not easy
[21:04:29] <ggm> in AP have NIR, national registries., makes it easier in asia, allocated in hierarchy, only true for specific countries, can be close to impossible in europe for instance
[21:05:38] <ggm> Leslie with regard to wire tracking ptorocol, using IRIS, to use hierarchy as mechanism for finding auth servers. don't know details of proposal, don't know how works, concievable, we can decouple hierarchy used by auth srvs vs info served by them, importantr distinction.
[21:05:53] <ggm> Zinin two issues confused. hierarchy of routing, and hierarchy in address alloc
[21:06:22] <ggm> while agree routing dynamics should be no strict hierarchy, noting aggregation, allocation current status has to be managed. cant just grab and go. need authority
[21:06:37] <ggm> Pekka. that is the danger
[21:06:40] <ggm> Zinin which?
[21:06:42] <ggm> Pekka the second.
[21:06:52] <ggm> someone to control the addresses
[21:06:58] <ggm> research question
[21:07:20] <ggm> reasons why believe in it, if we get new ID space, then, addresses , just locaters, dont matter so much, can renumber easily
[21:07:32] <ggm> 20/50 years can design structure which doesn't need the hier.
[21:07:50] <ggm> Kurtis. agree with alex.
[21:08:09] <ggm> ownership/authenticicy, verify alloc has alloc, is easier problem to solve, RIRs helping.
[21:08:53] <ggm> other problem is aggregation, more and more a problem, bad traffic, serious problem
[21:10:07] <ggm> Lixia debate regarding issueof after split ID/Loc, whether still important to do address mgt.
[21:10:16] <ggm> need to talk on arch ML
[21:10:27] <ggm> Ted
[21:10:31] <ggm> calls for beer
[21:10:36] <ggm> <close>
[21:10:48] --- deng has left
[21:10:56] --- Tom Phelan has left
[21:11:11] --- ggm has left
[21:11:34] --- nov has left
[21:12:03] --- tlyu has left
[21:12:20] --- warlord has left
[21:25:13] --- paulwouters@jabber.org has left
[21:27:23] --- frodek has left: Disconnected
[21:27:42] --- sleinen has left: Disconnected
[21:40:13] --- marka-isc has left: Disconnected
[22:50:23] --- mrichardson has left