[08:38:55] sebasdoman joins the room [11:17:22] jpronans@gmail.com joins the room [12:25:54] gclark-ohiou joins the room [12:28:15] dyoung-ohiou joins the room [12:32:00] dyoung joins the room [12:32:41] testing. [12:33:26] dyoung-ohiou leaves the room [14:53:24] I hear "check one two" on the mic [14:54:11] what time is it over there btw? [14:56:02] California should be 8:00AM. I'm in New Jersey, and it is 11:00AM for me. [15:16:02] 4:15 pm in Stockholm :) [15:18:26] Elwyn joins the room [15:36:25] avri joins the room [15:45:22] Armando Caro joins the room [15:58:21] weddy-mti joins the room [15:58:40] I will jabber scribe [15:59:23] Thank you and good morning [15:59:53] dellard joins the room [16:00:30] hkruse joins the room [16:00:39] dugdale joins the room [16:01:05] Kevin Fall joins the room [16:03:06] Melinda joins the room [16:03:22] gorryf joins the room [16:05:30] new DTN2 code is on sourceforge w/ LTP [16:06:08] Week after sigcomm [16:06:10] ExtremeCom will be nearby to SIGCOMM and the week after [16:06:36] stephen shows loooong list of draft-*dtnrg* [16:07:46] Kevin Fall speaking [16:08:16] on Endpoint Discovery Protocol [16:08:35] gorryf leaves the room [16:10:19] naming CLAs is in a separate specification [16:10:36] slide labelled "EDPv1 Basics" [16:11:25] upper right block [16:11:35] Melinda leaves the room [16:12:53] down to second row for reference count [16:13:04] now into 3rd row for active registrations [16:13:17] now into expiration counters [16:13:44] available CLA references [16:14:33] now into the preferred CLAs list [16:15:22] Why would an app only be accessible via a specific CLA? [16:15:49] do you need us to ask at the mic? [16:16:09] yes, I guess. There's no audio in. [16:16:22] Melinda joins the room [16:16:27] ok; he moved on so I will wait until the end of his presentation [16:16:47] on Example (3) slide [16:17:33] because of wanting reliability perhaps [16:17:55] or bidirectionality [16:18:35] Yes, we need to update that naming draft. [16:19:14] Example (4) slide [16:19:58] Joseph joins the room [16:20:09] on the Preferences slide pointing at the CLA index [16:21:06] onto Recap slide [16:22:12] gorryf joins the room [16:22:17] Joerg at MIc [16:22:20] joerg ott [16:22:32] wouldn'twe also need to move the draft on naming over to draft-dtnrg ? [16:22:41] Can someone in the room ask my earlier question? Thanks! [16:22:48] yes, I'm at the mic for you :) [16:22:57] joerg was closer than me [16:23:03] no rush [16:23:39] it sounds like he's partially answering it [16:24:12] that's why to prefer a cla in general, but not app to cla, I think. [16:24:21] right [16:26:21] never mind my question - it is already dtnrg draft. sorry [16:27:28] bob coles at mic [16:28:27] scott burleigh asking question [16:29:34] any thought of extending beyond one hop? - sort of a form of service discovery? [16:29:47] kevin mills asking question [16:31:28] does anybody object, no hands [16:31:38] now 2 at mic [16:31:51] there's another discovery protocol in the queue [16:32:18] maybe we should see how they mesh, if they can, before we move one forward [16:32:20] so maybe we should hear both first? [16:32:25] in chicago, we presented on bundle agent discovery, but I see this is more for EIDs that don't aggregate [16:32:40] Will Ivancic now presenting on reactive fragmentation [16:32:56] on "DTN Multi-Ground Terminal Tests" [16:34:05] Will's mike is pretty muffled [16:35:08] much better [16:35:09] on "Observations" slide [16:35:10] better [16:35:44] stephen talking [16:36:48] kevin fall at floor mic [16:37:41] on "thoughts" slide [16:38:07] joerg is asking at mic [16:39:23] stephen clarifying context [16:40:23] joerg at mic again [16:41:57] now into "DTN Network Management" slides [16:42:06] kevin fall asking a question about auth of frags [16:45:02] on Terminology slide [16:45:38] on Strategy [16:47:53] on DTN2 Basic Nework Configuration slide [16:48:52] on ION Baic Network Configuration [16:49:16] onto DTN Network Management - Monitoring [16:50:23] onto the DTNbone slide [16:52:50] kevin fall asks about other testbed infrastructures [16:53:21] onto chart with network map [16:55:25] onto slide GRC Network Management Software [16:56:00] question about how to distribute this on sourceforge [16:56:23] stephen suggests dtn-users mailing list [16:56:37] "Other Items" slide [16:56:44] IPN Naming in DTN2 [16:57:56] stephen asks about CBHE's relation to convergence layers in DTN2 [16:58:09] it's not a convergence layer [16:58:46] his comment was that to implement you would have to replicate a CBHE and non-CBHE version of each CLA, I believe [16:59:18] onto DTN Implementation Capabilities Database slide [16:59:28] weddy-mti: ah ok... I'm still struggling to get audio working [16:59:32] Bernie joins the room [17:00:25] stephen asked if the information is gathered already [17:00:34] will has some data on ION, DTN2, and spindle [17:00:40] stephen suggests using the wiki [17:01:18] will asks other implementations to send him their data to put up [17:01:27] Bob Coles scrolling back to research issues slide [17:01:56] in MANET, the report MIB accomplishes a similar thing to what Will is going for [17:02:35] Bernie leaves the room [17:03:14] schemas. think "templates" in IPFIX. [17:03:28] kevin fall is at the floor mic [17:03:47] kfall: is IP required for local management [17:04:30] answer is that you're either on the console port or real-time connected [17:04:50] kevin asks if using DTN protocols to access the data would be a problem [17:05:03] scrolled back to DTN2 Basic Network Configuration slide [17:05:21] avri leaves the room [17:05:48] to answer Kevin's "using DTN protocols" question: in DING's case, no. [17:06:46] You would use the "remote" approach [17:06:55] kevin is concerned that optimization/assumption about IP availability exists [17:07:02] There is no assumption that IP be available [17:07:22] mic: DING is designed to work over the bundle protocol. it does not depend on IP. [17:07:38] this is what will is saying is "remote management" [17:07:56] mic: The SNMP gateway is one way to provide access to the data gathered by management protocol X [17:07:58] You can [17:08:03] kevin wants to use bundle protocol in both cases, it sounds like [17:08:50] will clarifies that you can treat anything as a remote management [17:09:37] Yes...... [17:09:45] kevin re-asks if you have a DTN-only agent that can respond to MIB-like queries [17:09:48] Will answers yes [17:10:08] kevin asks if you can use only DTN without IP, without a proxy [17:10:17] but we know how to do an ip underlay over dtn. So if you have dtn, you can have ip too. [17:10:40] decision to take offline [17:10:59] Bob Cole brings up SNMP is transaction oriented and can run over BP [17:11:07] 2 issues [17:11:20] 1 - traditionally polling intensive SNMP apps (hence report MIB) [17:11:27] 2 - configuration mangement is tricky [17:11:49] will continue discussion later [17:12:23] henry haas(sp?) asks if will would like help [17:12:44] Blanchet slides about IANA registries up [17:13:01] on "Goals" [17:13:47] Registration Policies [17:15:32] gclark-ohiou leaves the room [17:15:34] neither IETF Review now Standards-Action apply [17:15:53] Bundle Block Type Code [17:17:04] handwaving at table [17:17:28] reserve a codepoint to signal extensions [17:17:52] suggested to use 0 reserved [17:18:38] decision to focus on "interesting" registries in this meeting, not all 35 slides [17:18:52] IRSG-review documents will be blocked until this is finished [17:19:02] should be done quickly [17:19:09] yes - don't put allocations from drafts into IANA registry draft [17:19:32] (unknown) at mic mentions expert review required [17:19:46] 5226 is the reference to check [17:20:09] stephen mentions 5326 is what LTP is and it doens't have a designated expert [17:21:00] expert-review requires the I_E_SG to designate the expert, and stephen explains that we don't talk to them [17:21:29] Specification Required seems correct to Stephen for block type code [17:21:32] oh god.. it changed.. spec reqd does now require expert review [17:21:34] room silent [17:21:48] 3 people at mics [17:22:27] suggestion that RFC-required is better [17:22:35] i would be happy with the old style spec reqd but with the new form with expert review i think rfc required is better [17:22:42] scott burleigh thinks specifcation required is right [17:22:53] wes can you channel please [17:22:57] yes [17:24:04] Will Ivancic joins the room [17:25:04] jpronans@gmail.com leaves the room [17:25:25] Bernie joins the room [17:25:31] 2 for RFC, 2 for spec, take it to the list, but we need to resolve quickly (Stephen) [17:25:44] marc on primary bundle protocol version [17:25:52] I think I'm on the 'spec reqd' side... but haven't thought deeply [17:26:13] Specification Required - Values and their meanings must be documented in a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible. When used, Specification Required also implies use of a Designated Expert, who will review the public specification and evaluate whether it is sufficiently clear to allow interoperable implementations. The intention behind "permanent and readily available" is that a document can reasonably be expected to be findable and retrievable long after IANA assignment of the requested value. Publication of an RFC is an ideal means of achieving this requirement, but Specification Required is intended to also cover the case of a document published outside of the RFC path. For RFC publication, the normal RFC review process is expected to provide the necessary review for interoperability, though the Designated Expert may be a particularly well-qualified person to perform such a review. [17:26:25] (from RFC 5226) [17:26:59] skipping to last slide [17:27:05] "next steps" [17:27:21] next rev should be draft-irtf-dtnrg for 5050 registries [17:27:32] I don't know if we can codify the exact rules to cover all the cases better than "an expert looked at it and thought it was adequately spec'd". [17:27:38] "yell on the list" [17:27:56] next presentation [17:28:01] "fun with time" [17:28:48] Are there slides for "fun with time"? [17:28:56] they're on display [17:29:03] stephen says they did them this morning [17:29:08] are they online? [17:29:25] slide on-display is SCHL - DTN Scope Control using Hop Limits [17:29:30] bernie joins the room [17:29:31] Not from what I can tell. Link points nowhere. Maybe a typo on the page? [17:29:41] Bernie leaves the room [17:30:03] https://datatracker.ietf.org/meeting/77/materials.html#wg-DTNRG [17:30:06] working from here [17:30:25] on SCHL slide [17:31:05] i agree: scope limitation is orthogonal to time based expiry [17:31:17] maybe my proxy is showing me a stale version. anyway, got them thanks to Anders Lindgren. [17:31:19] it appears that spec reqd changed between RFC 2434 and 5226 [17:31:26] sebasdoman leaves the room [17:31:37] on SCHL Basics [17:31:38] sebasdoman joins the room [17:31:59] on Issues/Actions [17:32:40] Marc Blanchet joins the room [17:33:16] IANA: Specification Required [17:33:21] RFC5226 says: [17:33:23] Count down is nice with SDNV because it doesn't require changing the length when decrementing... but that's a impl trick. [17:33:23] Specification Required also implies use of a Designated Expert, who will review the public specification and evaluate whether it is sufficiently clear to allow interoperable implementations. The intention behind [17:33:46] nobody at mics yet [17:33:59] now "fun with time" back up [17:34:22] stephen presenting [17:34:33] on Drafts slide [17:35:18] stephen declares there is consensus to separate hop count out and go forward with that [17:35:25] "consensus outline" [17:35:43] new draft will base time on extension blocks [17:36:18] scott created slides to sketch scheme [17:36:22] on "Problem" slide [17:36:23] velt joins the room [17:36:53] solution sketch (1 of 5) slide [17:37:03] stephen doesn't like relative time name [17:37:24] "AGE" carried in extension block in addition to creation time in primary block [17:37:32] haven't heard SF's objection to age exactly... yet anyhow [17:38:04] skipped through rest of solution sketch (too much detail) [17:38:07] bernie leaves the room [17:38:27] "after that ..." slide [17:38:43] producing new draft as soon as we can [17:38:58] bernie joins the room [17:39:59] where should effort be focused in next year? [17:40:01] slide mentions: [17:40:08] 5050bis (modification from experience) [17:40:14] naming [17:40:14] routing protocols [17:40:17] 5050bis based on experience [17:40:19] experiemnts [17:40:40] I will collect your thoughts and take them to the mic [17:41:04] naming and management [17:41:37] latency for management.. agreed that is research [17:43:03] getting some serious experience with dynamic routing.. PRoPHET needs real world testing [17:44:04] does this solution sketch provide the ability for interoperability between nodes that are AT-only and RT-only. AT-only being those that have accurate clocks and would like to operate on absolute time info. RT-only being those that do not have accurate clocks and those that can only do relative time. [17:44:19] joerg speaking at mic [17:44:40] the solution sketch doesn't do as you are saying, AC [17:44:42] agree with joerg [17:44:43] imagine a world where the deep space DTN network wants to communicate with a terresterial DTN network [17:45:02] Answer to Amando: Time solution should allow RT only, AT only or mix, [17:45:02] nobody else at mics [17:45:39] I agree that there are issues to work out in a research domain... but it doesn't mean that we can't progress on things we have already learned [17:45:48] decision to show neighbor disovery slides [17:46:04] will those slides go up online somewhere? [17:46:14] dan brown from BBN [17:47:42] Marc Blanchet leaves the room [17:49:14] hmm... conflicting response from Kevin and Will on RT-AT interoperability [17:49:18] sftcd joins the room [17:49:45] dugdale leaves the room [17:50:06] Dan's just shufflling computer [17:50:29] slides are on screen [17:51:47] slides on ietf site? [17:52:53] BBN ND architecture is 3 boxes [17:53:05] gorryf leaves the room [17:53:17] "neighbor discovery (PDU)" with double-arrow lines between "ND adapter" box and "CLA" box [17:53:27] component interaction slide [17:53:36] CLA registers associations with an adapter [17:53:50] neighbors discovered are convetyed to other CLAs [17:54:11] allows single IPND implementat to be used across multiple IP-related CLAs (UDP, TCP, NORM) [17:54:39] inside/outside BP slide [17:54:47] bbn implementation avoids BP in ND [17:54:51] broadcast media [17:55:07] nice to have a protocol that is not n^2 in a wireless medium, multicast-aware [17:55:14] need to support distince channels [17:55:19] multiple multicast groups [17:55:24] overhead/frequency slide [17:55:33] in some cases, high frequency beaconing is desired [17:55:39] max contact opportunity [17:55:48] decrease latency for discvery of down links [17:55:56] allow high overhead fields to be optional [17:56:12] hold-down should help substatially (unimplemented) [17:57:11] joerg ott asks about sending parallel beacons [17:57:28] last thing you want to do when receiving is to then send [17:57:33] what does high frequency mean? [17:57:49] what is the scenario / threashold (ms, min, hour)? [17:58:05] dan: varies by application and network [17:58:19] once a second in some cases [17:58:21] sebasdoman leaves the room [17:58:41] bidirectionality slide [17:58:49] many routing protocols presume bidirectional links [17:59:03] manets in practice may have links with only unidirectional capability for many reasons [17:59:28] epidemic protocol - multicast optimization, offers may get "stuck" to neighbor to which I can't transmit [17:59:52] Bernie joins the room [18:00:01] I just posted Dan's slides to the materials site [18:00:11] excellent :) [18:00:17] bernie leaves the room [18:00:18] bernie joins the room [18:00:20] Bernie leaves the room [18:00:38] bernie leaves the room [18:00:42] http://www.ietf.org/proceedings/10mar/slides/DTNRG-6.pdf [18:00:44] bernie joins the room [18:00:59] on "Bidirectionality" slide [18:01:57] avri joins the room [18:02:27] what was posted (or what I see as DTNRG-6.pdf) is "Fun with Time" again. [18:02:36] right [18:02:39] same here [18:06:10] presentation and meeting are over, so will have to clean that up later [18:06:19] WRT expert review: Maybe IRTF RFCs don't have the same process as IETF RFCs [18:06:21] adjourned [18:06:25] weddy-mti leaves the room [18:06:31] dellard leaves the room [18:06:35] hkruse leaves the room [18:06:47] Armando Caro leaves the room [18:07:38] 'bye.. have a good trip home everyone (avoiding Britsish Airways!) [18:07:44] bye bye [18:08:47] bernie leaves the room [18:10:31] velt leaves the room [18:12:36] Elwyn leaves the room: offline [18:12:46] Joseph leaves the room [18:14:38] dyoung leaves the room [18:25:38] sftcd leaves the room [18:34:28] Kevin Fall leaves the room [18:36:57] gorryf joins the room [18:37:01] gorryf leaves the room [18:45:39] Melinda leaves the room [18:47:18] avri leaves the room [18:51:47] Joseph joins the room [18:51:51] Joseph leaves the room [18:52:08] Joseph joins the room [18:52:27] Joseph leaves the room [18:52:58] Will Ivancic leaves the room: Computer went to sleep [18:53:32] gorryf joins the room [18:53:39] gorryf leaves the room [18:53:43] gorryf joins the room [19:08:44] Kevin Fall joins the room [19:39:12] gorryf leaves the room [20:06:20] Melinda joins the room [20:06:35] gorryf joins the room [20:06:39] gorryf leaves the room [20:06:49] gorryf joins the room [20:19:56] Melinda leaves the room [21:02:05] gorryf leaves the room [21:06:59] gorryf joins the room [21:07:14] gorryf leaves the room [22:14:07] gorryf joins the room [22:14:15] gorryf leaves the room [22:14:17] gorryf joins the room [22:16:25] gorryf leaves the room [22:16:33] gorryf joins the room [22:16:37] gorryf leaves the room [22:30:45] Kevin Fall leaves the room