[10:14:00] --- LOGGING STARTED
[10:14:21] --- peetu has joined
[10:14:38] --- jpope has joined
[10:14:52] --- mrichardson has joined
[10:15:01] <jpope> hi ... just set the room up ... testing ... look ok?
[10:15:13] <peetu> Seems to work
[10:15:14] <mrichardson> hi.
[10:15:17] <mrichardson> thanks.
[10:15:28] <jpope> no problem. see you later.
[10:15:39] <mrichardson> can't get back into hallway.
[10:16:09] --- nm has joined
[10:16:44] <jpope> i just joined the hallway ... looks ok
[10:16:51] <mrichardson> must be my cient.
[10:17:35] --- rjaksa has joined
[10:17:44] <jpope> ok, i'll see you later.
[10:18:10] --- jpope has left
[10:19:28] --- mrichardson has left: Logged out
[10:19:36] --- mrichardson has joined
[10:19:38] --- loughney has joined
[10:20:02] <mrichardson> greg says that IESG feedback was that we shouldn't push both documents.
[10:20:17] <mrichardson> the should probably be merged, but haven't been merged yet.
[10:21:15] <mrichardson> having straw-poll on whether or not to merge documenets.
[10:21:19] <loughney> actually, Thomas Narten asked for a merge. Thomas is not on the IESG.
[10:21:21] <mrichardson> merging is hard.
[10:21:27] <mrichardson> (good point)
[10:21:39] --- sarolaht has joined
[10:22:06] <mrichardson> comment: cpl is mosty about how to do dna with unmodified routers.
[10:22:13] <mrichardson> not sure what other document is about.
[10:22:22] --- sureshk has joined
[10:23:02] --- JackBurbank has joined
[10:23:22] --- JackBurbank has left: Lost connection
[10:24:34] --- thor101 has joined
[10:26:14] <mrichardson> eric suggests that an implementer would not implement just one method.
[10:26:30] --- thor101 has left
[10:26:34] --- jinmei has joined
[10:26:48] --- jinmei has left
[10:26:53] <mrichardson> if the target audience is the implementers, then write the documents for them. if this is just about making a nice scientific paper, then splitting makes sense.
[10:27:23] --- jinmei has joined
[10:27:41] --- pascal_Hennequin has joined
[10:27:49] --- momose has joined
[10:28:03] <mrichardson> eric: there doesn't have to be a single document, but the documents have to make sense together. either cross-reference, or overview document.
[10:28:35] <mrichardson> loughney: doesn't have to be merged, but they don't fit together well.
[10:28:47] <mrichardson> greg: if they had roughly merged documents, would that help?
[10:29:02] <mrichardson> two merged versions will go online?
[10:29:15] <mrichardson> need to figure out role of each documents.
[10:30:43] --- Tsubasa has joined
[10:31:14] <mrichardson> now to protocol-00
[10:31:29] <mrichardson> (slides and speaker too fast for me...)
[10:31:39] --- geir_egeland has joined
[10:31:56] <mrichardson> open issues: should the explicit linkid always be in the LPO? or a flag in PIO?
[10:32:08] <mrichardson> 2) what order do the hosts treat the indications?
[10:32:20] <mrichardson> 3) should we get rid of all of he flags in he landmark option?
[10:33:18] --- pascal_Hennequin has left: Logged out
[10:33:35] --- momose has left
[10:33:41] <mrichardson> greg: we have landmark and complete prefix list and designated prefix.
[10:33:44] --- pascal_Hennequin has joined
[10:33:58] --- momose has joined
[10:33:58] <mrichardson> can these pieces give you conflicting information state? and what happens then?
[10:35:03] --- nm has left: Replaced by new connection
[10:35:03] --- nm has joined
[10:35:03] --- nm has left
[10:35:15] * mrichardson has been called away and can't scribe anymore.
[10:35:24] --- nm has joined
[10:36:29] --- pascal_Hennequin has left: Logged out
[10:36:31] <sureshk> should we remove the flags from the landmark option
[10:37:34] --- jinmei has left
[10:37:41] <sureshk> these are artifacts from the design team
[10:37:42] --- jinmei has joined
[10:38:13] <sureshk> since they are no longer useful they can be removed
[10:38:22] <sureshk> discussing thomas narten's comments
[10:39:19] --- pascal_Hennequin has joined
[10:39:50] <sureshk> should the host just send an RS on startup or should it do probing with ND
[10:40:46] <sureshk> greg thinks using ND can be tricky
[10:41:07] <sureshk> james thinks that this would increase the latency
[10:41:16] <sureshk> and it is a bad idea
[10:41:39] <sureshk> since the originator is not in the room
[10:41:52] <sureshk> this question will be resolved on the mailing list
[10:42:31] <sureshk> Do we need to spend any effort to address unplanned renumbering
[10:42:34] --- loughney has left
[10:42:44] --- loughney has joined
[10:43:10] <sureshk> james believes that since it is already there
[10:43:23] <sureshk> .unless somebody wants to redo it,
[10:43:29] <sureshk> it does not make sense to remove it
[10:43:40] <sureshk> When should we rerun DAD?
[10:45:26] <sureshk> oDAD is very cheap and it enables traffic quickly
[10:45:35] <sureshk> so this is not really a problem
[10:46:19] <sureshk> james had a comment about IEEE. Did not catch that
[10:46:19] --- loughney has left
[10:46:28] --- momose has left: Replaced by new connection
[10:46:30] --- loughney has joined
[10:46:49] <sureshk> greg thinks we need to do a cost/benefit analysis
[10:47:05] --- pascal_Hennequin has left: Logged out
[10:47:11] --- momose has joined
[10:47:53] <sureshk> so it makes sense to use SHOULD instead of MUST
[10:48:29] <sureshk> as leaving the interface in optim mode is not too expensive
[10:48:58] --- pascal_hennequin has joined
[10:49:28] <sureshk> jinmei thinks DAD is necessary and
[10:49:47] <sureshk> if latency is an issue run oDAD
[10:52:00] <sureshk> christian talks about the signaling overhead due to MLD
[10:52:22] <sureshk> Vidya and Erik think that making this a SHOULD would solve the problem
[10:53:55] <sureshk> Erik thinks the probability of collision increases with the amount of time the node was away from the network
[10:54:09] --- pascal_hennequin has left
[10:55:09] <sureshk> Mohan wants to know if the document will contain solid time limits for this
[10:55:56] <sureshk> erik and think we should not have numbers but guide implementers to pick the right time limits
[10:56:33] <sureshk> Should current IP configuration be retained while performing DNA
[10:58:00] <sureshk> Erik thinks this depends on the scope of the addresses
[10:58:16] <mrichardson> my opinion is that eric has just identified a common threat....
[10:58:32] <sureshk> yep.
[10:58:53] <sureshk> a node sending packets using a Link local source and destination address
[10:59:01] <sureshk> can create false TCP state on the peer
[10:59:38] <sureshk> possibly leading to adverse consequences for any other node which happens to own the address on the new link
[10:59:38] --- pascal_hennequin has joined
[11:00:28] <sureshk> greg believes there is no ND problem
[11:00:39] <sureshk> but there might be a problem at the application level
[11:01:28] <sureshk> an API may be required to pass notifications from L3->L4...
[11:02:18] <sureshk> james thinks that the upper layers do not need to know this
[11:02:41] <sureshk> information
[11:03:07] <sureshk> mohan is concerned about using global addresses as well since they might lead to return packets going to the old link
[11:05:10] <sureshk> greg thinks this really does not break much
[11:05:46] <sureshk> jin and greg think that we need to distinguish ND packets from other types of packets
[11:06:04] <sureshk> since the ND packets have the potential to break stuff
[11:06:52] <sureshk> Should the host do Lazy or Eager switching for the Default Router
[11:07:43] <sureshk> james talking about the netlmm case
[11:08:28] <sureshk> many routers on different multicast domains
[11:08:34] <sureshk> all advertising the same prefix
[11:08:55] <sureshk> james will write some text and mail it to the list for addressing this
[11:09:09] <sureshk> sathya wants to know if this issue is netlmm specific
[11:10:59] <sureshk> one hack might be to use the same link local address on all the routers in the netlmm domain
[11:11:08] <sureshk> but this will break SEND unless they share keys
[11:11:27] --- quinn has joined
[11:11:56] <sureshk> non-prefix link identifiers might help
[11:12:17] <sureshk> if the linkid changes and the prefixes remain same
[11:12:33] <sureshk> the host can perhaps keep the configuration
[11:13:00] <sureshk> I guess the netlmm and dna goals are not the same
[11:13:19] <sureshk> non-prefix link ids are for the future
[11:13:52] <sureshk> vidya thinks dna for netlmm is not a good idea
[11:14:07] <sureshk> since netlmm is basically about unmodified hosts
[11:14:55] <sureshk> hesham does not understand the issue with non prefix link identifiers
[11:15:10] <sureshk> dave thinks this problem is not netlmm specific
[11:15:39] <sureshk> james to send more text to list
[11:16:04] <sureshk> further discussion on the intarea mailing list
[11:16:23] --- inet6num@jabber.org has joined
[11:16:45] <sureshk> recapping the issues raised by Thomas
[11:16:50] <sureshk> since he just got into the room
[11:17:48] <sureshk> end of presentation
[11:18:24] <sureshk> TSLLAO presentation by Greg
[11:18:37] <sureshk> now called Tentative Option
[11:19:24] <sureshk> is works just like a SLLAO
[11:19:46] <sureshk> but if a node receives a packet with Tentative Option
[11:20:03] <sureshk> and it contains a NC entry with a different LL address
[11:20:09] <sureshk> it does not replace it
[11:20:26] <sureshk> it is transparent to RFC2461 compliant nodes
[11:22:06] --- loughney has left: Replaced by new connection
[11:23:06] <sureshk> thomas thinks that this might create false state on a node if it had no NC entry for this address
[11:23:17] <sureshk> and there is a silent node on the link which owns the address
[11:23:30] <sureshk> greg thinks this false state will be flushed out quick
[11:23:39] <sureshk> thomas wants some text to warn about this
[11:24:57] <sureshk> greg thinks Tentative Option is a MAY
[11:25:05] --- pascal_hennequin has left
[11:25:09] <sureshk> thomas wants to pick either do it always
[11:25:12] <sureshk> or never do it
[11:25:26] <sureshk> as it complicates things if it is optional to implement
[11:27:17] <sureshk> greg thinks this option is more useful with the RS than with the NS
[11:27:52] <sureshk> it is still not clear what a router would do
[11:27:59] <sureshk> if it does not support Tent. Opt.
[11:28:06] <sureshk> and it receives an RS with one
[11:28:09] <sureshk> will it multicast RA
[11:28:23] <sureshk> or will it try to resolve the LL addr
[11:28:30] <sureshk> further discussion on list
[11:29:15] <sureshk> mohan thinks the NC entry can be removed after sending the RA
[11:29:39] <sureshk> greg thinks it makes sense to keep the NC entry for rate limiting
[11:31:08] <sureshk> jinmei wants to know if this works with NAs
[11:31:57] <sureshk> greg talks about unsolicited NAs not updating all nodes NC entries
[11:32:03] <sureshk> issues on list
[11:33:14] --- pfc has joined
[11:34:15] <sureshk> hesham thinks that the fmip-dna should be folded into fmip PS
[11:34:23] <sureshk> since it belongs there and is small
[11:35:02] <sureshk> rajeev wants a separate document since it talks about interaction between two protocols
[11:36:19] <sureshk> hesham wants to know what will be in this document that should not be described in FMIPv6
[11:36:44] <sureshk> hesham describes the security considerations
[11:36:50] <sureshk> for exampls
[11:37:25] --- momose has left: Replaced by new connection
[11:37:31] <sureshk> james talks about antiquated RFC mechanisms (txt)
[11:37:50] <sureshk> he thinks it should be in 1 document
[11:38:01] --- loughney has joined
[11:38:19] <sureshk> describing fmip and its interactions with other protocols
[11:39:11] <sureshk> jari (incoming AD)
[11:39:19] <sureshk> wants to know if this is in the charter
[11:39:39] <sureshk> greg thinks that this might be in the charter
[11:39:44] <sureshk> but it is upto the AD
[11:40:28] <sureshk> jari wants to take a closer look
[11:40:58] <sureshk> he is also thinks there are a lot of open WG documents to take on new work
[11:41:56] <sureshk> thomas thinks that DNA should be upper layer agnostic
[11:42:08] <sureshk> and should not address fmip
[11:42:55] <sureshk> hesham and thomas think that fmip ps must be contains this
[11:43:24] --- nm has left: Replaced by new connection
[11:43:25] --- nm has joined
[11:43:25] --- nm has left
[11:43:29] <sureshk> rajeev is concerned about the explosion of interactions
[11:43:48] --- nm has joined
[11:44:09] <sureshk> and he is worried about the workload of the mipshop wg
[11:44:18] --- pascal_hennequin has joined
[11:44:32] --- pascal_hennequin has left
[11:44:44] --- pascal_hennequin has joined
[11:45:11] <sureshk> vidya is worried about this trend as this kind of kills the motivation for dna
[11:45:28] --- pascal_hennequin has left
[11:45:33] <sureshk> greg thinks fmip is different because fmip can start before dna
[11:47:02] <sureshk> Q1. Do we have an urgent need to publish this as RFC?
[11:47:16] <sureshk> Thomas wants to know what is "urgent need"
[11:47:36] <sureshk> Is anyone using fmipv6 with dna in the next 6 months
[11:48:16] <sureshk> thomas thinks since this is 2 pages long and it should be folded into the fmipv6 spec
[11:49:25] <sureshk> greg wants to hold onto the document until mipshop can work with this
[11:49:40] <sureshk> jari says either take it or leave it
[11:49:51] --- loughney has left
[11:50:00] --- loughney has joined
[11:51:05] <sureshk> gerardo wants to know what is the targeted status
[11:51:09] <sureshk> it is INFORMATIONAL
[11:51:30] <sureshk> Vidya thinks it is good to avoid optional things in drafts
[11:51:42] <sureshk> Greg thinks dna is really not optional
[11:51:49] <sureshk> for fmipv6
[11:52:11] <sureshk> hesham thinks that fmipv6 is an optimization in itself and it works better with dna
[11:52:45] <sureshk> rajeev thinks mandating dna is not possible if the network does not support it
[11:52:58] <sureshk> greg things you can still to dna with unmodified routers
[11:58:08] --- Tsubasa has left
[11:58:19] --- Tsubasa has joined
[11:58:50] --- Tsubasa has left
[11:59:22] <sureshk> Q: Should this document be published from here or mipshop
[11:59:27] <sureshk> DNA: 4 hands
[11:59:34] <sureshk> MIPSHOP: 20 hands
[11:59:42] <sureshk> This is just the feel of the room
[12:00:35] <sureshk> Rajeev wants to know if it should be rolled into the fmipv6 spec
[12:00:40] <sureshk> for sure
[12:01:05] <sureshk> Greg thinks it is the responsibility of the mipshop wg
[12:01:34] <sureshk> thomas is concerned that if it is required for fmipv6 it must be handled there
[12:01:48] <sureshk> hesham thinks that the users of fmipv6 are the users of dna
[12:01:56] <sureshk> and not vice versa
[12:05:08] --- sarolaht has left
[12:05:12] <sureshk> milestones
[12:05:37] <sureshk> sathya thinks that june 2006 for dna hosts is unrealistic
[12:05:59] <sureshk> john loughney thinks that many WGLCs running in parallel is a bad idea
[12:06:58] <sureshk> Thomas thinks that DNA will be universally adopted as an improvement to ND
[12:07:16] <sureshk> so he thinks all recommendations to hosts should be in 1 document
[12:07:55] <sureshk> he thinks there is 2 audiences
[12:08:00] <sureshk> 1 -> host implementers
[12:08:07] <sureshk> 2 -> router implementers
[12:08:12] <sureshk> greg agrees
[12:08:46] <sureshk> thomas thinks that it is bad to have multiple documents with redundant text
[12:09:26] <sureshk> he thinks dna will be an integral part of ND (only developed later)
[12:10:02] <sureshk> he just wants two documents from the group
[12:10:15] <sureshk> dave thaler agrees with thomas
[12:10:25] <sureshk> he also prefers 2 documents
[12:10:56] <sureshk> he points to the difficulty with reading ipv6 node requirements
[12:11:51] <sureshk> he thinks it is better to do 2 documents e.g. for compliance statements
[12:12:34] <sureshk> erik thinks 1 document is better since the packet formats need to be documented somewhere
[12:12:58] <sureshk> he is worried about inconsistencies between the two documents
[12:12:59] <mrichardson> sounds like three documents to me. 1 document for packet formats, 1 document each for router/host semantics/state machine.
[12:13:55] <mrichardson> that way people like me, that write the tcpdump module, will just read the first document :-)
[12:13:58] <sureshk> longer documents are harder to read and review
[12:14:01] <sureshk> :-)
[12:14:49] <sureshk> erik wants to have an overall flow
[12:14:59] <sureshk> and carve out things from it which can stand alone
[12:15:34] <sureshk> greg thinks we need to agree on the list
[12:15:42] <sureshk> the form
[12:15:46] <sureshk> of the document
[12:16:06] <sureshk> we need the discussions done soon and on the list
[12:17:12] <sureshk> sathya thinks router bcp is basicallu an administrative guidance document
[12:17:18] <sureshk> and it should standalone
[12:17:38] <sureshk> soln document contains both router and host behavior
[12:17:58] <sureshk> hosts and cpl are for hosts work with unmodified routers
[12:18:46] <sureshk> sathya does not want to touch the solution document
[12:19:01] <sureshk> greg wants to have a review of the structure
[12:19:12] <sureshk> and pick up the text from the existing documents
[12:19:42] <sureshk> thomas is volunteering to write up text for an overview
[12:19:53] --- geir_egeland has left
[12:20:58] <sureshk> erik thinks DNA routers must be renamed to "operational foo..."
[12:21:28] <sureshk> mohan and Sathya think that it is very hard to separate the soln document into 2
[12:21:43] <sureshk> Sathya thinks it makes sense to merge CPL and hosts
[12:22:20] --- loughney has left
[12:22:24] <sureshk> greg believes that we have all the information we need and we just need to put them together right
[12:22:27] <sureshk> END OF MEETING
[12:22:34] --- nm has left: Replaced by new connection
[12:22:34] --- nm has joined
[12:22:34] --- nm has left
[12:22:46] --- nm has joined
[12:23:21] --- pfc has left
[12:25:30] --- nm has left
[12:35:08] --- inet6num@jabber.org has left
[12:41:00] --- peetu has left
[12:41:25] --- rjaksa has left
[12:41:46] --- sureshk has left
[12:59:30] --- LOGGING STARTED
[13:03:30] --- LOGGING STARTED
[13:42:33] --- quinn has joined
[15:36:42] --- mrichardson has joined
[16:35:50] --- quinn has left
[19:23:54] --- mrichardson has left
[21:04:51] --- mrichardson has joined
[21:40:46] --- mrichardson has left: Logged out