[12:24:43] --- ian.chakeres@gmail.com has joined
[12:25:06] <ian.chakeres@gmail.com> \topic agenda
[12:51:47] --- kazuya has joined
[12:57:05] --- badamson has joined
[12:58:16] --- jishac has joined
[13:01:21] --- badamson has left
[13:01:49] --- manetservent has joined
[13:02:16] --- jeffa has joined
[13:03:43] --- manetservent has left
[13:04:08] --- badamson has joined
[13:07:00] --- ian.chakeres@gmail.com has left
[13:07:18] --- ian.chakeres@gmail.com has joined
[13:09:55] --- yowada has joined
[13:09:59] --- bkhabs@jabber.org has joined
[13:10:02] --- thomas.heide.clausen@gmail.com has joined
[13:10:16] --- doug_trend@jabber.org has joined
[13:10:54] <thomas.heide.clausen@gmail.com> (I'll do some ad-hoc scribing while Ian is presenting)
[13:11:24] --- washad has joined
[13:11:28] <thomas.heide.clausen@gmail.com> Agenda - new things: nhdp (new WG I-D). SMF has not been updated as I-D, but Joe will say a few words to this end.
[13:11:42] <thomas.heide.clausen@gmail.com> Justin Dean: status of DSR is...?
[13:11:49] <thomas.heide.clausen@gmail.com> Ian: Will touch that during WG progress.
[13:12:00] <thomas.heide.clausen@gmail.com> Ian: WG status and update presentation.
[13:12:45] --- monden has joined
[13:12:47] <thomas.heide.clausen@gmail.com> Lots of progress within the different items (components), but also lots of interaction since we are going for a more modularized approach.
[13:12:52] <thomas.heide.clausen@gmail.com> Go read the drafts ;)
[13:13:07] <thomas.heide.clausen@gmail.com> Slide "Various remaining topics"
[13:13:28] <thomas.heide.clausen@gmail.com> DSR now in RFC editor queue. No major updates, however minor things. This is historical stuff.
[13:13:42] <thomas.heide.clausen@gmail.com> Joe: Want to thank Bill Fenner (AD) for helping get DSR out.
[13:14:43] <thomas.heide.clausen@gmail.com> Ian: draft-fenner-zinin-rtg-standard-reqts provides guidance for "where the bar is" for the document requirements. Ian will discuss that. Also, RFC2026, draft-fenner-obsolete-1264 and RFC1264
[13:15:05] --- cabo has joined
[13:15:17] <thomas.heide.clausen@gmail.com> Also, wants Slide: "Routing Requirements for Proposed Standard"
[13:15:39] <thomas.heide.clausen@gmail.com> (walking through the items of the slide).
[13:16:06] <thomas.heide.clausen@gmail.com> MIBs need to be WG I-D for all documents. MIBs do not need to go to the IESG as such, but must be WG items.
[13:16:43] <thomas.heide.clausen@gmail.com> Discussion on operational evidence: all features must be tested, but no requirements of major operational experience.
[13:16:54] <thomas.heide.clausen@gmail.com> Slide: "Documents"
[13:17:50] <thomas.heide.clausen@gmail.com> Slide: "Security"
[13:18:13] <thomas.heide.clausen@gmail.com> Recent RFCs which might be applicable: RFC4552, for example, simplified IPsec.....
[13:18:20] <thomas.heide.clausen@gmail.com> Might be a starting-point?
[13:18:50] <thomas.heide.clausen@gmail.com> Still unclear how this would be applied to the MANET wg protocols, would it be IP header or in the messages, but we need to look at this in the context of our protocols
[13:18:55] <thomas.heide.clausen@gmail.com> Slide: MIBs
[13:19:06] <thomas.heide.clausen@gmail.com> Each routing protocol *needs* a MIB
[13:19:26] <thomas.heide.clausen@gmail.com> Solicitation: if you're good with MIBs or if you are interested in helping generate these documents, please contact WG chairs.
[13:19:32] <thomas.heide.clausen@gmail.com> Slide: "MANET IANA Considerations"
[13:19:45] <thomas.heide.clausen@gmail.com> Has been floating ideas within DTs, but need to look at this more.
[13:19:46] --- peetu has joined
[13:20:13] <thomas.heide.clausen@gmail.com> Discussions on scoped multicast addresses: administratively scoped all-manet-routers multicast address/
[13:20:22] <thomas.heide.clausen@gmail.com> (I need to go to the mike)
[13:20:59] <jeffa> THC: Differently scoped multicast addresses, which kind of different semantics do you envision there?
[13:21:27] <jeffa> THC: all-MANET-routers vs all-MANET-neighbors consideration ...
[13:21:54] <jeffa> THC: DYMO and OLSR won't use those addresses ... I assume you're talking about something else
[13:22:04] <jeffa> Joe Macker: There is no screaming requirement for it
[13:22:37] <jeffa> JM: idea was that many people were into autoconfiguring routers; that scope, if useful, could serve that purpose
[13:22:54] --- herokey has joined
[13:23:05] <jeffa> THC: if we specify these particular addresses, what are the semantics/functionalities of these address scopes
[13:23:15] <jeffa> IDC: these scopes are defined
[13:23:29] <jeffa> THC: we need to discuss these protocols/scopes here
[13:24:04] <jeffa> THC: we need to know why we are doing that before we require? it
[13:24:18] <jeffa> JM: the scope stuff is less defined ...
[13:24:40] <jeffa> JM: the group needs to decide whether this is too sticky of an issue to tackle immediately
[13:24:51] <jeffa> JM: there are people who want to use it now (more from AUTOCONF)
[13:25:02] <jeffa> JM/IDC: ** we need more discussion on the list **
[13:25:05] <thomas.heide.clausen@gmail.com> (Thanks Jeff)
[13:26:08] <jeffa> THC: I think we should try to decouple the namespace that we control (TLVs, etc) from the stuff we don't control (scoped addresses, etc)
[13:26:20] <jeffa> IDC: the port also?
[13:26:33] <jeffa> THC: yes, make them separate issues so we don't fall behind in other areas
[13:27:01] <thomas.heide.clausen@gmail.com> IDC: Take remaining discussions to the list?
[13:27:42] <jeffa> JM: have people decided on link local multicast?
[13:27:56] <thomas.heide.clausen@gmail.com> THC: that's our ongoing hypothesis ;)
[13:28:12] <jeffa> Fred Templin: we should cross-post this to AUTOCONF also
[13:28:32] <thomas.heide.clausen@gmail.com> Ian: Milestones update
[13:28:53] <thomas.heide.clausen@gmail.com> Need more experience documented, look at the documents previously mentioned.
[13:29:00] <thomas.heide.clausen@gmail.com> Want to submit I-Ds in April 2007
[13:29:19] --- fparent@jabber.org has joined
[13:29:21] <thomas.heide.clausen@gmail.com> Joe: since SMF is experimental, we will like to try for the MIB, but...
[13:29:42] <thomas.heide.clausen@gmail.com> Joe/Ian: they're different protocol classes, and there are different requirements
[13:29:51] <thomas.heide.clausen@gmail.com> Slide: "Questions for the WG"
[13:30:13] <thomas.heide.clausen@gmail.com> Who's running MANET protocols (show of hands)
[13:30:24] <thomas.heide.clausen@gmail.com> Idem for implementing....
[13:30:35] <thomas.heide.clausen@gmail.com> MIB documents: TWO people.....
[13:31:17] <thomas.heide.clausen@gmail.com> Slide: Short-term goals
[13:31:26] --- abhayroy has joined
[13:31:26] <thomas.heide.clausen@gmail.com> Review & comment on drafts.
[13:31:39] <thomas.heide.clausen@gmail.com> Bill Fenner: MIBs is creating data models which we will reflecting in the MIB
[13:31:59] <thomas.heide.clausen@gmail.com> BF: HArd part is the data model - the MIB simply reflects the data model.
[13:33:14] <jeffa> ---------- THC is presenting now: Generalized Packet and Message Format Discussion -------
[13:33:39] <jeffa> Thomas Heide Clausen
[13:33:41] <jeffa> = THC
[13:34:01] <jeffa> some working groups like to keep obscurity...
[13:34:09] <jeffa> (displays a list of issue numbers)
[13:34:24] <jeffa> http://olsrv2.online.fr/bugtrack/
[13:34:28] <jeffa> go see the bugtracker
[13:35:00] <jeffa> packetBB was an individual submission, then published -00, then -01 before this IETF
[13:35:12] <jeffa> we hammered out some issues this week
[13:35:36] <jeffa> we are going through it with a microscope and taking out every word we don't like
[13:35:47] <jeffa> we will submit version -02 of the draft ... the 17th? ...
[13:35:56] <jeffa> slide: Changes 00 to 01
[13:36:35] <jeffa> we had the idea of TLVs affixed to messages, hop-by-hop signalling for example
[13:36:56] <jeffa> we found that it didn't work .. didn't come up with a good use case...
[13:37:08] <jeffa> (the forward-if-don't-understand flag)
[13:37:42] <jeffa> roll-around issues with seq nos., thus type dependent/independent
[13:37:54] <jeffa> tried to add something for the security cons.
[13:38:07] <jeffa> but we haven't really started thinking about that area...
[13:38:55] <jeffa> slide: Address Block Changes
[13:39:20] <jeffa> (discussing different interface IDs, etc)
[13:40:01] <jeffa> wanted a more compact way of doing things --> zero-tails
[13:40:13] <jeffa> slide: Changes 01 to 02
[13:40:38] <jeffa> removing redundancy -- there were a number of areas. getting the text nice and concise
[13:41:01] <jeffa> no more hidden interpretations anymore
[13:41:38] <jeffa> process is about 1 page per hour ...
[13:41:52] <jeffa> slide: The Future
[13:42:04] <jeffa> this is the time to read the document and give us input
[13:42:25] <jeffa> Charles Perkins: I'm catching up on the doc, but ... first, a lot of text about fragmentation
[13:42:38] <jeffa> why network layer fragmentation wasn't sufficient for this purpose
[13:43:01] <jeffa> THC: consider OLSR, someone might send an incremental update
[13:43:18] <jeffa> THC: you want a mechanism for incremental -style updates
[13:43:29] <jeffa> CP: but those updates are less likely to be fragmented
[13:43:41] <jeffa> CP: fragmentation == allowing for contiuation messages?
[13:43:47] <jeffa> THC: no, that's one use of it
[13:43:53] <jeffa> THC: another is a small MTU ...
[13:44:21] <jeffa> THC: (discusses receiving TC messages in OLSR)
[13:44:53] <jeffa> THC: ... using the self-contained flag ... updating data...
[13:45:03] <jeffa> CP: I don't find it a very convincing argument
[13:45:13] <jeffa> CP: network fragmentation can do the job
[13:45:18] <jeffa> THC: it cannot do the job
[13:45:28] <jeffa> CP: the best way to do this segmentation is really at the application layer
[13:45:43] <jeffa> THC: the message format permits you to say the message can/cannot be interpreted
[13:45:58] <jeffa> Chris: it is true that frag. is not essential, question is whether it is useful
[13:46:18] <jeffa> Chris: whether or not you have to get ALL bits through, i.e. TC message
[13:46:42] <jeffa> Chris: there are ways of using fragmentation beyond the original design to do some interesting things
[13:46:56] <jeffa> Chris: frag. is not quite as critical as the other things
[13:47:20] <jeffa> Chris: and .... we might be interested in running this over some sort of physical layer
[13:47:25] <jeffa> ...?
[13:47:38] <jeffa> CP: that brings up an interesting point...
[13:47:53] <jeffa> CP/THC: (discussing packetBB and what it provides)
[13:48:19] <jeffa> CP: I've raised an issue that I think this frag. is "different" than the other packet BB stuff
[13:48:25] <jeffa> CP: not needed by all routing protocols
[13:48:40] <jeffa> THC: it's a TLV, you don't need to use it, be encumbered by it
[13:48:50] <jeffa> CP: you don't have to implement all parts of packetBB ?
[13:48:54] <jeffa> THC: yes
[13:49:09] <jeffa> THC: OLSRv2 for example doesn't allow you to remove parts of the message header
[13:49:21] <jeffa> THC: purely syntax document, allowing a protocol to express itself
[13:49:27] <jeffa> CP: tricky issue ...
[13:49:35] <jeffa> IDC : ** take that item to the list **
[13:50:02] <jeffa> Fred Templin: in general, host-based frag in preferrable than network frag
[13:50:21] <jeffa> FT: ... smaller transmission size from the host, not the underlying media that's important but the path
[13:50:27] <jeffa> THC: yes, absolutely
[13:50:42] <jeffa> CP: the router ID is used in routing protocols but AODV and DYMO didn't have to use it before
[13:51:01] <jeffa> CP: the restriction of a single identifier per node... seemd to work ok
[13:51:25] <jeffa> CP: I would need to see if you mandate the router ID, how many addresses you could have per node
[13:51:35] <jeffa> Chris: purpose of interface address is for duplicate detection
[13:52:00] <jeffa> Chris: all that matters is the combination of interface address, router id, and type is what identifies you correctly
[13:52:27] <jeffa> Chris: OLSRv2 can have multiple interfaces, with multiple addresses per interfaces
[13:52:40] <jeffa> Chris: there is a flag in the header if you don't need the orig address
[13:52:53] <jeffa> CP: I'll go back and look again, I thought it was called the "Router ID"
[13:53:04] <jeffa> THC: explicitly called "Originator Address"
[13:53:19] <jeffa> CP: requiring different seq. no. for every interface
[13:53:24] <jeffa> CP: may want the same one...
[13:53:30] <jeffa> THC: which sequence number?
[13:53:34] <jeffa> CP: the message seq no
[13:53:52] <jeffa> THC: we don't say that the msn doesn't need to be different per i/f
[13:54:05] <jeffa> Chris: maybe that was in -01, we stripped it out in -02
[13:54:21] <jeffa> THC: ...
[13:54:28] <jeffa> Chris: I think we've taken it out.
[13:54:39] <jeffa> THC: sit down with us and run over the draft with us!
[13:55:04] <jeffa> THC: anyone who has an interest -- what do you think is good or bad?
[13:55:15] <jeffa> THC: preferrably send a message to the mailing list
[13:55:19] <jeffa> CP: What does BB mean?
[13:55:26] <jeffa> THC: It means Building Block !
[13:55:36] <jeffa> THC: (I guess you're not from California)
[13:55:54] <jeffa> ?: procedural comment, I-D can be posted since Monday this week
[13:56:32] <jeffa> ?: one real comment - this document is pretty interesting. in 6lowpan we have a feeling that we are not going to use it
[13:56:43] <jeffa> ?: we may want to use a more compact way of encoding things
[13:56:52] <jeffa> ?: wanted to float this fact and collect comments on it
[13:57:13] <jeffa> THC: this format is appropriate for the kind of networks we are considering here in MANET
[13:57:23] <jeffa> THC: it helps to decouple the formats ...
[13:57:33] <jeffa> THC: then you are able to do something better
[13:57:54] <jeffa> can you abstract the ...
[13:58:14] <jeffa> ?: people who use packetBB have to be careful to use the _interface_ and not the ...
[13:58:22] <jeffa> THC: let's encourage good code
[13:58:37] <jeffa> THC: do we need to specify something additional to more encourage that style/behavior ?
[13:58:46] <jeffa> THC: leave that up to the protocols
[13:58:53] <jeffa> ?: I'll ask that offline
[13:59:12] <jeffa> Chris D: if packet BB doesn't service your protocol, let us know what ideas you are using
[13:59:37] <cabo> ? ::= Carsten Bormann, 6lowpan co-chair
[14:00:10] <jeffa> CP: ... not a real constructive comment. it would be nice to put in a paragraph on why you need this feature
[14:00:27] <jeffa> THC: the comment on readability has taken on board... we are trying to get it more readable
[14:00:39] <jeffa> hopefully we've improved on that point
[14:00:46] <jeffa> CP: explain why some features are there
[14:01:29] <jeffa> THC: ...
[14:01:38] <jeffa> IDC: you are going to send your comments Charlie?
[14:01:57] <jeffa> CP: would you consider some text?
[14:02:05] <jeffa> THC: sure we'll put it in if it makes sense
[14:02:18] <jeffa> THC: I always reserve the right to violently disagree with you Charlie!
[14:02:22] <jeffa> CP: that's even better!
[14:02:39] <jeffa> slide: the Future
[14:03:06] <jeffa> Chris D: we have the amibition to produce some sort of rationale document for an OLSR document
[14:03:17] <jeffa> THC: it's been an ambition since Paris
[14:03:35] <jeffa> -------- switching presentations ----------
[14:03:53] <jeffa> MANET Neighborhood Discovery Protocol Discussion
[14:04:23] <jeffa> preseneter: Christopher Dearlove
[14:04:33] <jeffa> slide: Status
[14:04:44] <jeffa> draft-ietf-manet-nhdp-02.txt
[14:05:09] <jeffa> NHDP not to be confused with ND
[14:05:19] <jeffa> slide : Relationship with ...
[14:05:42] <jeffa> I'm not sure whether DYMO has interest in using it
[14:06:20] <jeffa> number of possible solutions, we need to talk to the users
[14:06:27] <jeffa> slide: Goals
[14:07:10] <jeffa> (describing the bullets)
[14:07:56] <jeffa> it's worth noting that the multiple interface support has got some complications with it
[14:08:07] <jeffa> if you don't use it, you don't pay for it (in terms of bits on the wire)
[14:08:11] --- rjaksa has joined
[14:08:21] <jeffa> THC: it's easy to do in a way where you think you'll get it right, but you don't
[14:08:43] <jeffa> THC: don't try something simple ... please look at that part carefully and provide feedback
[14:09:20] <jeffa> slide: Info Base
[14:10:19] <jeffa> Joe Macker: to clarify, it can support different times from different neighbors, and can support the adaptation of those timers?
[14:10:39] <jeffa> Chris: explicit rather than implicit (?)
[14:11:15] <jeffa> slide: Info ... Usage
[14:12:26] <jeffa> Justin Dean: it's made in such a way that other ......
[14:12:40] <jeffa> Chris: yes in the case of MPRs you just need to signal the case that you need to calculate it
[14:13:08] <ian.chakeres@gmail.com> Justin ... that other algorithms to reduce the relay set can be used
[14:13:19] <jeffa> slide: The Future
[14:14:19] <jeffa> http://olsrv2.online.fr/blog http://olsrv2.online.fr/bugtrack
[14:15:04] <jeffa> IDC: any other comments about the neigh. disc. doc?
[14:15:15] <jeffa> -------- switching presentation --------
[14:15:18] <jeffa> speaker: Joe Macker
[14:15:32] --- doug_trend@jabber.org has left
[14:15:39] <jeffa> SMF Discussion - draft-ietf-manet-smf-02.txt
[14:16:01] <jeffa> slides: http://www3.ietf.org/proceedings/06jul/slides/manet-6.pdf
[14:16:37] <jeffa> I'll be brief, SMF hasn't been rewritten yet, has some old stuff, and some newer ideas we've been working on
[14:16:42] <jeffa> that should be published soon
[14:16:54] <jeffa> slide: SMF Doc. Progress/Intent
[14:17:37] <jeffa> (discussing duplicative efforts w/others)
[14:18:05] <jeffa> so -02 section 7 will be removed for -03
[14:18:22] --- herokey has left
[14:19:02] <jeffa> you'll have a pretty complete description to go and build a prototype
[14:19:10] <jeffa> (when the next version is done)
[14:19:42] <jeffa> slide: Running Code Options
[14:20:01] <jeffa> emphasizing that SMF can run by itself, w/o other MANET protocol running
[14:20:09] <jeffa> we know people that want to do that
[14:20:43] <jeffa> the plan for the running code is to have nhd optionally
[14:21:03] <jeffa> if you have a unicast protocol running, then you can borrow that data
[14:21:26] <jeffa> last IETF has a pointer to download this code
[14:21:55] <jeffa> slide: Further Planned Work
[14:22:22] <jeffa> http://pf.itd.nrl.navy.mil/smf/
[14:23:25] --- thomas.heide.clausen@gmail.com has left
[14:24:37] <jeffa> Charlie Perkins: do you expect this to have any interaction/impact on the OSPF work?
[14:25:01] <jeffa> JM: only from the sense that there is a project where we're taking the CDS info from OSPF-MANET and using those values in SMF
[14:25:15] <jeffa> JM: it doesn't impact the MANET-OSPF spec at all
[14:25:27] <jeffa> CP: do you take the information right from CDS?
[14:25:52] <jeffa> JM: (see above) ... SMF is designed to take any CDS information
[14:25:59] <jeffa> JM: one source specific one not
[14:26:19] <jeffa> Brian Adamson: potential work with folks from multicast ...
[14:26:44] <jeffa> BA: in SMF maybe we want to think about guidlines for a RIB/fwd engine
[14:26:52] <ian.chakeres@gmail.com> ... work with multicast group to identify borders between smf and other multicast regions
[14:26:57] <jeffa> JM: good comment. people are doing different things
[14:27:03] <jeffa> (thanks Ian)
[14:27:30] <jeffa> S. Ruffino: you commented on SMF incrementing hop count of __ during yesterdays presentation
[14:27:43] <jeffa> JM: Chris made the comment, it's not hop TTL but a counter
[14:27:50] <jeffa> SR: SMF should deal only with the IP header
[14:28:01] --- sp has joined
[14:28:07] <jeffa> SR: if it's possible to change something within the message after the IP header?
[14:28:24] <jeffa> JM: not encapsulated protocol, we wanted to try and build an IP-native approach
[14:28:26] --- nkawa has joined
[14:28:36] <jeffa> SR: is it possible to increment or not?
[14:28:49] <jeffa> JM: let the packet BB people answer the question
[14:29:03] <jeffa> Justin: the packet is not going to be modified
[14:29:11] <jeffa> JM: we're not parsing anything down there
[14:29:19] <jeffa> Justin: (more about NHDP)
[14:29:38] <jeffa> Chris D: if you are building a message using packet BB then you would get that information
[14:29:49] <jeffa> JM: SMF does not use packetBB ...
[14:30:00] <jeffa> JM: there was some confusion yesterday
[14:30:25] <jeffa> slide:SMF MIB
[14:30:47] <ian.chakeres@gmail.com> summary: smf does not modify the IP packet payload
[14:31:05] <jeffa> questions?
[14:31:36] <jeffa> -------- switching presentations ----------
[14:31:56] <jeffa> DYMO Discussion
[14:32:01] <jeffa> presenter: Ian Chakeres
[14:32:08] <jeffa> draft-ietf-manet-dymo-05.txt
[14:32:16] <jeffa> slide: Changes 04 05 06pre
[14:32:25] <jeffa> http://www3.ietf.org/proceedings/06jul/slides/manet-2.pdf
[14:33:32] <jeffa> bullet 2: specifically for protocols that want to run with very small code size can run without modification
[14:33:47] <jeffa> there was a lot of miscomm. about sequence numbers and loop free routing
[14:34:10] <jeffa> will walk through the different states/categories of routing info for DYMO
[14:34:14] <jeffa> slide: DYMO-06pre
[14:34:42] --- thomas.heide.clausen@gmail.com has joined
[14:35:11] --- Tsubasa has joined
[14:35:26] <jeffa> discussing sequence number / info. categories
[14:36:05] <jeffa> these other categories are more challenging
[14:36:17] <jeffa> I'm looking for better names here
[14:36:24] <jeffa> (stale/loop-prone)
[14:36:38] <jeffa> disqualified /loop-prone "loop-possible"
[14:37:57] <jeffa> I'll put this out in the next few weeks
[14:38:05] <jeffa> ** comments on this appreciated **
[14:38:06] <jeffa> slide: DYMO-06pre (2)
[14:38:48] <jeffa> slide: DYMO-06pre - Open Questions
[14:38:58] <jeffa> these are not clearly answerable
[14:39:07] <jeffa> plan to continue to discuss these on the list
[14:39:36] <jeffa> anyone want to say a word about this?
[14:40:03] <jeffa> Justin Dean: for DYMO I don't know that you want lots of guidance as much as you want requirements about what you NEED to have happen for proper operation
[14:40:17] <jeffa> JD: use MAYs were they have a little flexibility
[14:40:30] <jeffa> JD: what is mandatory and recommended is more important
[14:40:41] <jeffa> IDC: yes
[14:41:18] <jeffa> these last two items are definitley open issues -- would like feedback
[14:41:28] <jeffa> what are the use cases?
[14:42:24] <jeffa> (discussing behavior w/semantic bits)
[14:43:21] <jeffa> please come to the mic or the mailing list to present some use cases
[14:43:31] <jeffa> or why is this bad behavior?
[14:43:51] --- peetu has left
[14:44:02] <jeffa> THC: I think it's important when we design general-purpose protocols that we try to structure things in
[14:44:08] <jeffa> the normal way ....
[14:44:33] <jeffa> ... ... for control traffic we should be careful to separate the header processing
[14:44:52] <jeffa> THC: and the payload processing, is specific to the routing protocol
[14:45:07] <jeffa> THC: it's important to keep in mind that they should live in the payload part
[14:45:27] <jeffa> CP: in the type field of the message, you should not include any such info?
[14:45:36] <jeffa> THC: packet BB ?
[14:45:43] <jeffa> CP: yes, in the context of packet BB
[14:45:53] <jeffa> THC: routing protocol should be able to recognize a set of messages.
[14:46:11] <jeffa> THC: processing of that type may well include such relevant information
[14:46:32] <jeffa> IDC: before we get into how we implement this, let's come to a consensus that this behavior is needed
[14:46:35] <jeffa> IDC: is that OK?
[14:46:52] <jeffa> CP: yes it's ok if we come to a consensus that matches my preconception.
[14:47:13] <jeffa> THC: this may or not be the solution, but if you could define a message TLV, fine
[14:47:27] <jeffa> THC: can we support this whether or not we need to do this?
[14:47:36] <jeffa> IDC: yes, where in the chain would you accomplish this type of feature
[14:48:21] <jeffa> CP: it's a tradeoff, bits from a reserved field, then I'm not sure it's such a good idea; esp if you have to make a linked list of every type you do in a certain way. I'm not convinced about there must be such a type
[14:48:40] <jeffa> Chris D: it's specifying behavior that everybody must impl in their code .... whether or not they actually need it
[14:48:53] <jeffa> CP: Mobile IP has extensions that are needed/not needed
[14:49:29] <jeffa> THC: you may just need two message types - route req, route req that you don't need to understand
[14:49:56] <jeffa> CP: more than the message type, this discussion is appropriate for the TLV types
[14:50:20] <jeffa> jeffa notes: HIP has a critical bit for message TLVs
[14:50:27] <jeffa> CP: ...
[14:50:43] <jeffa> THC: processing chain is much less iffy than the message header
[14:50:59] <jeffa> IDC:
[14:51:10] <jeffa> 6lowpan would like to do MANET routing at layer 2
[14:51:17] <jeffa> slide: 6lowpan WG
[14:52:36] <jeffa> http://moment.cs.ucsb.edu/dymo https://lists.sourceforge.net/lists/listinfo/aodvimpl-public
[14:52:40] <jeffa> comments to the list please
[14:52:54] <jeffa> -------- switching presentations ---------- http://www3.ietf.org/proceedings/06jul/slides/manet-3.pdf
[14:53:05] <jeffa> speaker: Thomas Heide Clausen
[14:53:15] --- bkhabs@jabber.org has left
[14:53:17] <jeffa> slide: Status
[14:53:21] <jeffa> topic: OLSRv2
[14:53:51] <jeffa> slide: changes 01 02
[14:55:06] <jeffa> slide: Implementations
[14:55:33] <jeffa> one in Java, a couple in progress in various states of compliance
[14:56:00] <jeffa> if you have an implementation or experience, let us know on the list and privately
[14:56:05] <jeffa> slide: Future
[14:56:30] <jeffa> security cons - had chat with Bill Fenner
[14:56:54] <jeffa> slide: 3rd OLSR Interop ...
[14:57:05] <jeffa> we have had this yearly event
[14:57:58] <jeffa> see http://olsrv2.online.fr/blog for announcements, info, etc
[14:58:46] <jeffa> would like to produce interop reports
[14:58:50] <jeffa> questions/comments?
[14:59:04] <jeffa> any impl experience/ any MANET discussion ?
[14:59:06] --- thomas.heide.clausen@gmail.com has left: Logged out
[14:59:13] --- badamson has left
[14:59:18] <jeffa> < no comments >
[14:59:22] --- washad has left: Computer went to sleep
[14:59:28] --- ian.chakeres@gmail.com has left: Logged out
[14:59:57] --- yowada has left
[15:00:13] --- jeffa has left
[15:00:20] --- monden has left
[15:00:23] --- nkawa has left
[15:00:30] --- kazuya has left
[15:01:15] --- yowada has joined
[15:03:32] --- fparent@jabber.org has left
[15:04:20] --- yowada has left
[15:05:10] --- cabo has left: Logged out
[15:05:46] --- Tsubasa has left
[15:06:45] --- jishac has left
[15:10:46] --- sp has left
[15:23:42] --- rjaksa has left: Replaced by new connection
[16:05:06] --- abhayroy has left