IETF
6lo
6lo@jabber.ietf.org
Tuesday, November 11, 2014< ^ >
Room Configuration
Room Occupants

GMT+0
[18:35:00] Alex Petrescu joins the room
[18:51:13] Dan York joins the room
[18:53:50] Ruri Hiromi joins the room
[18:58:32] Ines  Robles joins the room
[18:59:32] <Ines  Robles> Hi, here you are going to find the materials
[18:59:34] <Ines  Robles> https://datatracker.ietf.org/meeting/91/materials.html
[19:00:54] Alex Petrescu leaves the room
[19:01:19] Nathalie Trenaman joins the room
[19:02:11] Meetecho joins the room
[19:02:24] Alissa Cooper joins the room
[19:02:41] Alex Petrescu joins the room
[19:03:41] <Alex Petrescu> Ralph is 'temporary' co-chair
[19:03:48] <Alex Petrescu> Ralph is looking for volunteers
[19:03:51] <Alex Petrescu> to co-Chair
[19:04:08] <Alex Petrescu> Ralph: are you interested to co-chair please step forward
[19:04:16] <Ines  Robles> current slides
[19:04:16] <Ines  Robles> http://www.ietf.org/proceedings/91/slides/slides-91-6lo-0.pdf
[19:04:31] <Ines  Robles> slide 2
[19:04:33] <Ines  Robles> slide 2
[19:04:38] <Ines  Robles> slide 3
[19:05:01] Nathalie Trenaman leaves the room
[19:05:11] jiye park joins the room
[19:05:17] <Ines  Robles> slide 5
[19:05:25] Alissa Cooper leaves the room
[19:05:26] Alissa Cooper joins the room
[19:05:27] Nathalie  Trenaman joins the room
[19:05:31] Kerry Lynn joins the room
[19:06:04] jiye park leaves the room
[19:06:49] <Nathalie  Trenaman> Am I the only one who can't see the slides (remote)
[19:07:10] <Nathalie  Trenaman> ah, fixed!
[19:07:21] <Ines  Robles> ok
[19:07:59] <Ines  Robles> slide 6
[19:09:11] Dave Thaler joins the room
[19:09:12] <Alex Petrescu> Dominique Barthel is DB : update a draft
[19:09:26] <Alex Petrescu> Brian Haberman is BH: do I need to ask someone about '...sec'
[19:09:36] <Alex Petrescu> Carsten Bormann is CB
[19:09:52] <Alex Petrescu> CB: channel ID, number of decisions reverting everything decided in 6lowpan
[19:09:57] <Alex Petrescu> CB: this is not ready for IESG
[19:10:10] <Alex Petrescu> CB: how can we work with channel assignment that works
[19:10:26] <Alex Petrescu> Ralph:...
[19:10:33] <Alex Petrescu> Markus Isomaki is MI
[19:10:47] <Alex Petrescu> MI: procedure to discover IP gatew a,d discover channel
[19:11:04] <Alex Petrescu> MI: bluetooth sig? nothing special happening, just taking time, need to check with Teemu Savolainen
[19:11:20] <Alex Petrescu> RD: clarifying q: not clear of state of dosc out of bluetooth sig? are they done or not?
[19:11:27] <Alex Petrescu> MI: done, but not publicly available
[19:11:52] <Alex Petrescu> RD: can you prepare revision for the I-Ds, such that as soon as the docs of bt sig are published we can then do quickly, paralleilze
[19:12:14] <Dave Thaler> what's the link to the notes-in-progress (etherpad?)
[19:12:34] <Ines  Robles> http://etherpad.tools.ietf.org:9000/p/notes-ietf-91-6lo?showControls=true&showChat=true&showLineNumbers=true&useMonospaceFont=true
[19:12:41] <Ines  Robles> etherpad
[19:12:45] <Dave Thaler> thx
[19:12:49] <Ines  Robles> np
[19:13:05] <Ines  Robles> slide 7
[19:14:07] <Alex Petrescu> Pascal Thubert is PT: folding fragments, I had some responses
[19:14:28] <Alex Petrescu> PT: I have put up some slides, i finterested to why need to fragments, we can do a meeting
[19:14:38] <Alex Petrescu> RD: plan to update the docs? such as to I-D?
[19:14:47] <Alex Petrescu> PT: probably a separate document.
[19:16:34] <Ines  Robles> slide 8
[19:17:17] <Ines  Robles> http://www.ietf.org/proceedings/91/slides/slides-91-6lo-1.pdf
[19:17:30] <Ines  Robles> sldie 2
[19:19:45] <Ines  Robles> slide 3
[19:20:19] <Kerry Lynn> Format of these slides is w i d e s c r e e n
[19:20:44] <Kerry Lynn> Clipping the L & R sides
[19:22:48] <Ines  Robles> slide 4
[19:23:29] <Ines  Robles> slide 5
[19:25:03] <Ines  Robles> next slide
[19:25:09] <Ines  Robles> compressing the sender rank
[19:26:21] <Ines  Robles> next slide
[19:26:46] <Ines  Robles> compressing the rplinstanceid
[19:27:44] <Alex Petrescu> CB approach
[19:28:03] <Alex Petrescu> CB: q is how much of the codepoints space of rfc6828 provides can be reused for this
[19:28:20] <Alex Petrescu> CB: current draft provides 2 extremes for that and smth in the middle , which has a problem, more complicated
[19:28:38] <Alex Petrescu> CB: one approach i(greedy) we could use 64 of those codepoints so why not grab them
[19:28:59] <Alex Petrescu> CB: NHC is 256 codepoints, how many useD?, taking away some is not going to bean emergency
[19:29:13] <Alex Petrescu> CB: other things there are, that marches out above the the IP layer, in the extension headers
[19:29:24] <Alex Petrescu> CB: other extreme is this is one client of NHC, and give it a codepoint
[19:29:35] <Alex Petrescu> CB: all th edata still needs to be encodes somewhere...
[19:29:42] <Alex Petrescu> CB: every packet transported using RPL
[19:29:48] <Alex Petrescu> CB: in general we just adda  abyte to RPL
[19:30:19] <Alex Petrescu> 3rd approach is say we are not, there are some bits in the greedy header that are les slikely, occur less often, put thos bits in the additional byte, define an escape mech, only use 16  codepoints
[19:30:31] <Alex Petrescu> CB: the advantage is leaving us some future leeway
[19:30:57] <Alex Petrescu> CB: disadvantage is that comes on the way, problem, F flag set in the packet, has to include new escape byte, there is some packet expansion
[19:31:08] <Alex Petrescu> CB: potential for new fragmentation, creates complexity, nico to avoid
[19:31:12] <Alex Petrescu> CB: other places there are
[19:31:18] <Alex Petrescu> CB: hop limit and address compression
[19:31:30] <Alex Petrescu> CB: my view is that people will have to deal with this expalnsion anyways
[19:31:42] <Alex Petrescu> CB: I wrote a few paragraphs about how to minimize th eimpact
[19:31:53] <Alex Petrescu> CB: it is more work, rrequires router to break packet into 2
[19:31:59] <Alex Petrescu> CB: thats the choice we have here
[19:32:23] <Alex Petrescu> CB: in general, spend the 64 and have a nice soution, conservative, nice, always spend a byte, but rewuire addiiotnla complexity in documentation
[19:32:35] <Alex Petrescu> SC: needs to change RFC6282?
[19:32:39] <Alex Petrescu> PT: oits an IANa action
[19:32:54] <Alex Petrescu> PT: here we consume valu e5
[19:33:00] <Alex Petrescu> PT: every space is constrained anyewyas
[19:33:16] <Alex Petrescu> PT: specific next header i s RPL, gives us extra advantage
[19:33:27] <Alex Petrescu> PT: have more space for future is not a ba didea
[19:33:35] <Alex Petrescu> PT: this is the only one which has...
[19:33:45] <Alex Petrescu> PT: if the RPL changes in v2, then vé is screwed
[19:33:54] <Alex Petrescu> PT: need to make this case bigger
[19:34:07] <Alex Petrescu> CB: the escape mech is designed such as be use by any other encoding
[19:34:12] <Alex Petrescu> PT: but we need to define in advance
[19:34:22] <Alex Petrescu> CB: we need to reserve bits but not...
[19:34:30] <Alex Petrescu> RD: how many people read draft?
[19:34:35] <Alex Petrescu> room: half a dozen
[19:34:50] <Alex Petrescu> RD: how many people read it and understand such that we can discuss in meeting
[19:34:53] <Alex Petrescu> room: a few
[19:35:03] <Alex Petrescu> RD: so better go to email list
[19:35:11] <Alex Petrescu> Michael Richardson i sMR
[19:35:22] James Gould joins the room
[19:35:31] James Gould leaves the room
[19:35:44] <Alex Petrescu> MR: problem of deciding... people who have read it is having more difficulty than those who havent
[19:35:46] <Alex Petrescu> room: true
[19:35:55] James Gould joins the room
[19:36:02] <Alex Petrescu> MR: good for us is good, CB is having far thinking view
[19:36:20] Samuel Erik joins the room
[19:36:28] <Alex Petrescu> MR: people who have not read the draft, how many bits...
[19:36:33] <Alex Petrescu> PT:...
[19:36:36] <Alex Petrescu> RD: chai hat off
[19:36:42] <Alex Petrescu> RD: minor tech a
[19:36:51] <Alex Petrescu> RD: header expansion problemm?
[19:37:13] <Alex Petrescu> RD: in practice, there are other header componentns who could do same.  But in practice, has it been a problem?
[19:37:33] <Alex Petrescu> RD: how many apps are able of (a) be aware of 256 byte frame, and (b)
[19:37:55] <Alex Petrescu> CB: read 4144 tells to reassemble every packet
[19:38:24] <Alex Petrescu> CB: if the originating host doesnt know one werid little trick, it makes it hard for the router in the way
[19:38:34] <Alex Petrescu> CB: ...
[19:38:59] <Alex Petrescu> CB: if the originating host knows that ithen it makes it easy... if the originating host doesnt then its harder
[19:39:09] <Alex Petrescu> RD: implementation detail, ok.
[19:39:21] <Alex Petrescu> RD: ...
[19:39:26] <Alex Petrescu> BC:...
[19:39:39] <Alex Petrescu> PT: stress, thi sis almost a philo discussion
[19:39:54] <Alex Petrescu> PT: we can do improvements, or ... it's a long discussion
[19:40:25] <Alex Petrescu> PT: dont know what to expect.  Do you care for saving a lot of spac ein the HC or not?  if not then I am happy with the greedy
[19:40:37] <Alex Petrescu> PT: thi sis compatible with the spirit with RFCXXXX
[19:41:06] <Alex Petrescu> RFC6282
[19:41:24] <Alex Petrescu> PT: can we afford greedy?
[19:41:30] <Alex Petrescu> PT: if so why not go for it
[19:41:38] <Alex Petrescu> RD: have not got the exact number
[19:41:51] <Alex Petrescu> RD: how many codepoints would be left after assigning...
[19:42:20] <Alex Petrescu> PT: its above 127 still free, maybe 140.
[19:42:33] <Alex Petrescu> RD: an exact number would be ok.
[19:42:45] <Alex Petrescu> RD: that woul dbe an important number to make a decision.
[19:42:50] <Alex Petrescu> SC approaches
[19:43:05] <Kerry Lynn> Would also be nice to have some justification that RPL needs 64 code points
[19:43:15] <Alex Petrescu> SC: what are the other apps we foresee?  other rt protocol? or another app over TCP or UDP?
[19:43:36] <Alex Petrescu> Kerry - are you in the physical room or you want the message relayed?
[19:43:54] <Alex Petrescu> PT: no req today
[19:44:13] <Alex Petrescu> SC: my concern we hand out to 64bit space, if another app tomorrow asks for 16 bits?
[19:44:22] <Kerry Lynn> I am remote - pls relay
[19:44:26] <Alex Petrescu> SC: I like th econservative approach.
[19:44:37] Samuel Erik leaves the room
[19:44:41] <Alex Petrescu> PT:...
[19:44:56] <Alex Petrescu> SC: both conservative and efficient options, comparison of implementation?
[19:44:59] <Alex Petrescu> PT: its the same
[19:45:09] <Alex Petrescu> Carsten approach
[19:45:24] <Alex Petrescu> CB: the answer is 4
[19:45:26] <Alex Petrescu> 242
[19:45:28] <Alex Petrescu> 42
[19:45:40] <Alex Petrescu> CB: free number is 214
[19:46:23] Samuel Erik joins the room
[19:47:04] cabo joins the room
[19:47:21] Ines  Robles leaves the room
[19:47:28] Samuel Erik leaves the room
[19:47:37] <Alex Petrescu> PT: ...
[19:47:59] Ines  Robles joins the room
[19:48:04] <Alex Petrescu> Thomas Watteyne is TW
[19:48:06] Samuel Erik joins the room
[19:48:14] <Alex Petrescu> TW: this talks about 6553
[19:48:21] <Alex Petrescu> TW: but header compression and source route?
[19:48:37] <Alex Petrescu> CB: this is half of the thing we want to do for RPL
[19:48:42] <Alex Petrescu> CB: we discussed before
[19:48:53] <Alex Petrescu> CB: we should re-visit the mesh header, this is a fwding thing
[19:49:05] <Alex Petrescu> CB: need changes to 41445?)
[19:49:44] <Alex Petrescu> TW: my q was not about ho, but.
[19:49:52] <Alex Petrescu> RD: sounds we discussed in the wrong order
[19:49:57] Samuel Erik leaves the room
[19:50:00] <Alex Petrescu> RD: the src route compression
[19:50:08] <Alex Petrescu> RD: the unwrap mesh header.
[19:50:24] <Alex Petrescu> RD: we cant make a decision about this until we consider what you raised.
[19:50:52] <Alex Petrescu> RD:...
[19:51:09] <Alex Petrescu> RD: unknown compression which might ocme along in the near future.
[19:51:26] <Alex Petrescu> RD: I feel less secure to make decision now.
[19:51:32] <Alex Petrescu> PT: q to the group
[19:51:45] <Alex Petrescu> PT: open the discussion at the 6tisch interim call
[19:51:52] <Alex Petrescu> PT: the reaction was major
[19:52:16] <Alex Petrescu> PT: we had discussion in the room for routing header, for mesh header
[19:52:48] <Alex Petrescu> PT: is there any known usage of this mesh header?
[19:53:02] <Alex Petrescu> RD: IEEE using it?
[19:53:09] <Alex Petrescu> RD: effort 802.15.4 mesh under
[19:53:13] <Alex Petrescu> RD: 15.5
[19:53:25] <Alex Petrescu> PT: IEEE looks at different solutions about routing
[19:53:32] <Alex Petrescu> PT: 15.10 is at the beginning
[19:53:44] <Alex Petrescu> RD: interested in sticking stuff in mesh header or smoewhere else?
[19:53:58] <Alex Petrescu> CB: hop count, src, final dst address are the uses of mesh header.
[19:54:08] <Alex Petrescu> CB: might be a good idea to look at this again.
[19:54:21] <Alex Petrescu> CB: anyone doing mesh protocol will have to care abou tthis
[19:54:26] <Alex Petrescu> Pat Kinney is PK
[19:54:48] <Alex Petrescu> PK: I am not a chair of .10 (mesh for layer2), they have just everybody to agree on a harmonized baseline
[19:54:56] <Alex Petrescu> PK: they didnt get into this extent yet
[19:55:01] <Alex Petrescu> PT: that said, I dont remember this
[19:55:14] <Alex Petrescu> PK: not remember this bit issue brought up in that group
[19:55:21] <Alex Petrescu> PK:  its a layer 2 mesh-under
[19:55:34] <Alex Petrescu> PT: tried to attend, but never seen IP there.
[19:55:39] <Alex Petrescu> PK: just started, really.
[19:55:44] <Alex Petrescu> RD: not IP was my concern.
[19:56:05] <Alex Petrescu> RD: if 802.10 is doing a mesh under applies to .15 MAC/PHY, then routing info must go some place, where?
[19:56:16] <Alex Petrescu> PK: technicall not specific to 15.4
[19:56:22] <Alex Petrescu> PK: focus on 15.4
[19:56:39] <Alex Petrescu> PK: where the info is going, they can put it into an I.E. and make it a stete-full implementation
[19:56:56] <Alex Petrescu> PK: put it in the headers? not beat on that.  I am in charge of review, got too many.
[19:57:03] <Alex Petrescu> PK: thats why PAscal is on the right approach.
[19:57:15] <Alex Petrescu> Bob Moskowitz
[19:57:21] <Alex Petrescu> BM: I am chair of 15.9
[19:57:42] <Alex Petrescu> BM: a feature in .9 is a mechanism of transporting data in Information Elements
[19:58:03] <Alex Petrescu> BM: in 15.10 people looked at mechanisms we created a, and created a similar approach
[19:58:16] <Alex Petrescu> BM: we have to do transport routing information w/o IP
[19:58:26] <Alex Petrescu> BM: complimentary efforts, not competing efforts.
[19:58:27] James Gould leaves the room
[19:58:49] <Alex Petrescu> TW: cautions I am about obsoleting something o fmesh under if people use it.
[19:58:56] <Alex Petrescu> TW: not obsolet stuff.
[19:59:16] <Alex Petrescu> PT: we will be carefull, IESG doestn let do.  But evidenc eof use?  Actual networks?
[19:59:23] <Alex Petrescu> TW: Actual evidence we have.
[19:59:32] <Alex Petrescu> RD: bring this to email list.
[20:00:08] <Alex Petrescu> RD: Pascal and Carsten please lay out addiitional possiblities we discussed here: this document, but possibility of additional bit spac ein the NHC that might be used for other uses fairly quickly by RPL.
[20:00:23] <Alex Petrescu> PT: either we dispatch
[20:00:31] <Alex Petrescu> PT: or an NHC space
[20:00:36] <Alex Petrescu> PT: these are the 3 choices.
[20:00:53] <Alex Petrescu> RD: include RoLL may come up with a compression mechanism for source route.
[20:01:00] <Alex Petrescu> RD: that will help conversation.
[20:01:12] <Alex Petrescu> PT: also it may bring IP-in-IP
[20:01:22] <Alex Petrescu> PT: the Laurent Toutain's draft.
[20:01:39] <Alex Petrescu> RD: all these considerations need to be put down, so we as a group can make decisions.
[20:02:08] <Alex Petrescu> RD: all presenters please be prepared to ramp it up a little bit (we run out of time)
[20:04:36] <Alex Petrescu> CB approach
[20:04:51] <Alex Petrescu> CB: careful with word req
[20:05:03] <Alex Petrescu> CB: some organizations build list of requirements and engineer
[20:05:08] <Alex Petrescu> CB: thi sis a list of objectives
[20:05:21] <Alex Petrescu> CB: for each of them we may figure whether we wa,t to do it
[20:05:24] <Alex Petrescu> BM approach
[20:05:48] <Alex Petrescu> BM: miss an address protection - v6? or MAC?
[20:05:53] <Alex Petrescu> PT: yes, v6
[20:06:01] <Alex Petrescu> SC: no time
[20:06:07] <Alex Petrescu> SC: just give basic ideas
[20:06:12] <Alex Petrescu> SC: please read thes doucments
[20:06:20] <Alex Petrescu> SC: need another co-author on this document
[20:06:30] <Alex Petrescu> SC: talk to Ralph an dme if you want to join.
[20:06:47] <Alex Petrescu> SC: need more co-authors.
[20:13:21] <Alex Petrescu> RD: how many people read this dtraft?
[20:13:24] <Alex Petrescu> room: not very many
[20:13:50] <Alex Petrescu> Yong-Geun Hong will present
[20:14:00] <Alex Petrescu> RD: not enough for get sense of room for adoption
[20:14:12] <Alex Petrescu> BH: shephering AD very interesting IESG member
[20:14:23] <Alex Petrescu> BH: please, just not ask for publication a req document
[20:14:51] <Alex Petrescu> BH: if update some RFC, then include the reqs in the RFC updat eitself, IESG thinks reqs does not need to be a separate doc
[20:15:11] <Alex Petrescu> SC: wondering - should we then consider it a WG document? or keep it a living doc?
[20:15:17] <Alex Petrescu> CB: this is bof material
[20:15:28] <Alex Petrescu> CB: use it as a place to steer content form other docs
[20:15:33] <Alex Petrescu> BH: could be an I-D
[20:15:42] <Alex Petrescu> BH: could do reqs on a wiki page
[20:15:56] <Alex Petrescu> BH: just publish it as rfc doesnt help anything...
[20:16:16] <Alex Petrescu> YGH is Yong-Geun Hong
[20:16:20] <Alex Petrescu> YGH presents
[20:17:12] levin  cole joins the room
[20:18:12] levin  cole leaves the room
[20:25:08] <Ines  Robles> few peoople read the document
[20:25:09] <Alex Petrescu> SC: any objection to it become WG doc?
[20:25:10] <Ines  Robles> no objection
[20:25:22] <Alex Petrescu> SC: please post comments on the email list
[20:25:31] jiye park joins the room
[20:25:42] <Alex Petrescu> SC: after comments we can ask for adoption
[20:25:44] <Nathalie  Trenaman> I'm happy it becomes a WG document
[20:25:49] <Alex Petrescu> CB: how stable are these LLCP addresses?
[20:25:50] <Ines  Robles> ok
[20:26:06] <Ines  Robles> please nathalie trenaman send this to the ML
[20:26:19] <Alex Petrescu> Or otherwise you want it relayed at the mike?
[20:26:20] <Nathalie  Trenaman> will do
[20:26:28] <Nathalie  Trenaman> no need for  the mic
[20:26:41] <Alex Petrescu> CB: multicast mapping - 3f?
[20:26:51] <Alex Petrescu> CB: not a normal LLCP address  you can get...
[20:26:56] <Alex Petrescu> CB: why choose 3f?
[20:27:31] <Ines  Robles> alex pretescu, question about interfae id designer
[20:27:42] <Ines  Robles> about ssap lot of zeros
[20:27:57] <Ines  Robles> why do u call 64 bit IID
[20:28:07] <Ines  Robles> There are questions in jabber?
[20:28:29] <Kerry Lynn> Who's at the mic?
[20:28:36] <Ines  Robles> Alex pretescu aat mic
[20:28:53] <Kerry Lynn> 64-bit IID is useful for SLAAC
[20:28:57] <Dave Thaler> right kerry
[20:29:05] <Ines  Robles> ok say at mic
[20:29:06] <Dave Thaler> SLAAC requires 64 bit
[20:29:32] <Dave Thaler> Fernando did (so I sat back down)
[20:29:43] <Ines  Robles> ok
[20:29:43] <Kerry Lynn> I moved ;-)
[20:29:46] <Ines  Robles> sorry
[20:30:14] <Alex Petrescu> Gianluca approach
[20:30:36] <Alex Petrescu> Gianluca Rizzo is GR
[20:31:05] Nathalie  Trenaman leaves the room
[20:32:47] <Alex Petrescu> Dave, Kerry - 64bit IID for SLAAC over Ethernet - ok; but here is not Ethernet.
[20:33:03] Ines  Robles leaves the room
[20:33:23] Ines  Robles joins the room
[20:36:39] <Dave Thaler> @Alex: RFC4291 "For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format."
[20:37:06] <Alex Petrescu> Dave: so 64bit IID is not about SLAAC, but about rfc4291?
[20:37:21] <Alex Petrescu> PT: why need to expose all this info to the rest of Internet?  Is GW a stateless?
[20:37:39] <Alex Petrescu> PT: why do we need to expose? this can be used by attackers?
[20:37:54] <Alex Petrescu> GR: idea is to have stateless, then you can have some mech to protect
[20:38:05] <Alex Petrescu> PT: conflict sbetween whom?  devices on same gw?
[20:38:20] <Alex Petrescu> GR: devices happen to have same Id because legacy protocol
[20:38:38] <Alex Petrescu> PT: if GW has a state per device that it maps then it can basically have a form of index, use that as IID,...
[20:38:47] <Alex Petrescu> GR: has it at state, didnt think such solution.
[20:38:54] <Alex Petrescu> PT: usecase in mind be statelesS?
[20:39:02] <Alex Petrescu> SC: this is informational not going to std.
[20:39:12] <Dave Thaler> @Alex: the SLAAC RFC says "Note that the address architecture [RFC4291] also defines the length of the interface identifiers for some set of addresses, but the two sets of definitions must be consistent."
[20:39:18] <Alex Petrescu> SC: this is implementation option you say, this is a q not the righ titme to discuss.
[20:39:40] <Alex Petrescu> MR: ask PT q differently: given any gw has a security relationship with the client on legacy turn off on...
[20:39:45] <Alex Petrescu> room: wishful thinking
[20:39:52] <Alex Petrescu> MR: security is wishful thinking?
[20:39:54] <Dave Thaler> room = Bob Moskovitz
[20:39:55] <Alex Petrescu> room: yes
[20:40:08] <Alex Petrescu> MR: ...
[20:40:38] <Alex Petrescu> MR: apply to security-less things? then wow, I think this ie ven e a recommendation to not do thi sever, it is wrong.
[20:40:58] <Alex Petrescu> MR: buy this GW because legacy, theyre cheap because not secure, thats why I put a gw there.
[20:41:02] <Alex Petrescu> Fernando Gont is FG
[20:41:08] <Alex Petrescu> FG: few lines on ULB...
[20:41:19] <Alex Petrescu> FG: should not assume any structure in the
[20:41:27] <Alex Petrescu> FG: not care abou tU/L bit anymore
[20:41:34] <Alex Petrescu> Ole Troan (6man Chair co)
[20:41:42] <Alex Petrescu> OT: why want to publish this as a document?
[20:41:44] <Dave Thaler> are these slides online?
[20:41:48] <Ines  Robles> yes
[20:41:53] <Alex Petrescu> OT: someone make some assumption.
[20:41:59] <Alex Petrescu> OT: we want to be opaque
[20:42:03] <Alex Petrescu> PT: why publisheD?
[20:42:19] <Dave Thaler> I don't see them on the meeting materials site, am I blind?
[20:42:21] <Alex Petrescu> GR: a way to try solve some problems, try to ingtagerate legacy devices
[20:42:21] <Ines  Robles> lit shoulc be tin the agenda
[20:42:29] <Ines  Robles> im wrong
[20:42:31] <Alex Petrescu> (url at beginning of log?)
[20:42:46] <Alex Petrescu> OT: stateless mapping funcntion...
[20:42:51] <Alex Petrescu> OT: different implementations?
[20:42:58] <Ines  Robles> sorry
[20:42:59] <Alex Petrescu> OT: if not, then why publis
[20:43:01] <Ines  Robles> the slides are not htere
[20:43:11] <Ines  Robles> the speaker gave to samita
[20:43:12] <Ines  Robles> today
[20:43:14] <Alex Petrescu> RD: 6man chairs and we co-chairs need to discuss
[20:43:33] <Dave Thaler> would be good for chairs to have them online before the speaker presents...
[20:43:34] <Alex Petrescu> RD: maybe appropriate to 6man, they have that generic address mapping expertise, we dont necessqrily have here.
[20:43:48] <Alex Petrescu> Dave - tell it to mike
[20:44:05] <Alex Petrescu> OT: 6man have lots of legacy, would be happy a conversation here.
[20:44:14] <Alex Petrescu> Fernando Gont approach
[20:44:49] <Alex Petrescu> RD: this is ... in here people aware of this docuement?
[20:45:08] <Alex Petrescu> RD: 1-2 clarifying questions may be entertained here, but discussion is in 6man.
[20:45:35] <Alex Petrescu> Dave - about this:  RFC4291 "For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format."
[20:45:53] <Alex Petrescu> Maybe the NFC IPv6 address will not start with 000?
[20:46:26] <Dave Thaler> @Alex: that would typically prevent routability as shown in use case diagram 1.
[20:46:26] Meetecho leaves the room
[20:47:02] <Alex Petrescu> Dave - so we need routability to not be prevented.
[20:47:18] <Dave Thaler> (i.e. the top diagram on the "Key Issues 1: Connectivity" slide)
[20:47:45] Meetecho joins the room
[20:48:39] <Alex Petrescu> Pascal Thubert approach
[20:49:02] <Alex Petrescu> Rene Struik approach
[20:49:08] <Alex Petrescu> Bob Mosckowitz approach
[20:49:14] <Alex Petrescu> PT: I support Ralph comment
[20:49:21] <Alex Petrescu> PT: nodes can still comress, not at the MAC
[20:49:41] <Alex Petrescu> PT: the operation from the MAch should be ocmputable, so intermeidat devices can still compress.
[20:49:56] <Alex Petrescu> PT: 6lo interested to sell outwhat is relevant for low policy devices?
[20:50:06] <Alex Petrescu> PT: something on the wall, subnets quite stable
[20:50:11] <Alex Petrescu> PT: not the classical use cases.
[20:50:18] <Alex Petrescu> PT: which reasons interested in 6lo?
[20:50:31] <Alex Petrescu> FG: computation is a SHOULD, not SHOULD NOT; if you have a ... not a MUST.
[20:50:40] <Alex Petrescu> FG: no tracking, there is case of AREA SCANNING
[20:51:03] <Alex Petrescu> PT: figurehwow bad it is, be honest, RPL network? then the nodes exactly, that will not cause DoS attacks
[20:51:31] <Alex Petrescu> PT: you wont dos the network
PT: work on compressible version of you rRFC, tilde, Ralph compression
[20:51:53] <Alex Petrescu> FG: change something in the I-D? or 6lo looks at the document, and maybe 6lo works on an alternative way to generate IIDs?
[20:52:08] <Alex Petrescu> FG: for each tech it is up to each tech to analyze, applky if you want
[20:52:15] <Alex Petrescu> RS: my presentation does analyze this scheme
[20:52:24] <Alex Petrescu> RS: provides reocmmendation, later in the queue.
[20:52:29] <Alex Petrescu> BM: this is small point
[20:52:55] <Alex Petrescu> BM: number of devices where MAC address i snot only local scope, manufacturer did not bother reauest qllocqtion form IEEE
[20:53:09] <Alex Petrescu> BM: every time come up with a different address, funny when you want to run a server
[20:53:30] <Alex Petrescu> BM: you encourage that the v6 address not tied in, there are some devices that perhaps help us.
[20:53:33] <Alex Petrescu> Dave Thaler is DT
[20:53:50] <Alex Petrescu> DT: preview to 6man, not comments, go to 6man.
[20:53:59] <Alex Petrescu> DT: how to address RD?
[20:54:03] <Alex Petrescu> DT: 3 points
[20:54:14] <Alex Petrescu> DT: link layers must define a mech to offer privacy
[20:54:24] <Alex Petrescu> DT: may also provide a mech different
[20:54:36] <Alex Petrescu> DT: choice should be configurable
[20:54:45] <Alex Petrescu> DT: I talk there, come there.
[20:55:00] <Alex Petrescu>     Robert Cragie is Rg
[20:55:19] <Alex Petrescu> RG: kind of link local management protocol, we have to use hw addresses, also used in conjunction with ULA addresses.
[20:55:29] <Alex Petrescu> RG: beyond a panel, the consideration is important.
[20:55:36] <Alex Petrescu> RG: both 16bit and 64bit
[20:55:46] <Alex Petrescu> RG: we use them now, look for justification.
[20:56:09] <Alex Petrescu> CB: this doucment now is confiused, uses a charmed hardware address which does not have defined meaning.
[20:56:18] <Alex Petrescu> CB: NFC what is the hw address?
[20:56:19] <Kerry Lynn> Right, let's not confuse L2 address and hardware address.
[20:56:37] <Alex Petrescu> CB: MAC layer addresses may or not be derived from these
[20:56:53] <Alex Petrescu> CB: have we mapping from IP to MAC, should be untangled.
[20:56:58] <Kerry Lynn> E.g. 802.15.4 defines a dynamic short-form address that is assigned by a local coordinator
[20:57:05] <Alex Petrescu> CB: in this WG there are very diverse set of addresses.
[20:57:17] <Alex Petrescu> FG: a list of documents this document updateS.
[20:57:26] <Ines  Robles> kerry should we put your comment at the mic?
[20:57:33] <Alex Petrescu> CB: not useful if I go to tech X if I need to find out what should do.
[20:57:37] <Kerry Lynn> nah, discussion is in 6man
[20:57:40] <Ines  Robles> ok
[20:57:43] <Alex Petrescu> RD: more convesation to 6man email list.
[20:58:25] <Alex Petrescu> In the mean time, the number 42 which provokes laughs is from th eHitchiker's Guide to the Galaxy, the big Computer found the big answer, and the answer aws '42'.
[20:58:32] <Alex Petrescu> RD: we are on time.
[20:58:55] Alissa Cooper leaves the room
[20:58:59] <Alex Petrescu> Behcet Sarikaya presents
[21:01:17] Ruri Hiromi leaves the room
[21:02:39] <Alex Petrescu> SC: CGA on 6lo?
[21:02:42] <Alex Petrescu> Rene Struik
[21:02:58] <Alex Petrescu> RS: more applicable in mor eplaces, wider applicability than just constrained devices
[21:03:07] <Alex Petrescu> RS: millions of groups at IETF?
[21:03:14] <Alex Petrescu> BH: only 27
[21:03:24] <Alex Petrescu> BS: should allowed be by RFC
[21:03:27] Catherine Dibble joins the room
[21:03:39] <Alex Petrescu> BH: slide 3
[21:03:45] <Alex Petrescu> BH: what is multihop ND?
[21:03:56] <Alex Petrescu> BS: discussed in 6775
[21:03:59] mcr joins the room
[21:04:02] <Alex Petrescu> BS: in some industrial networks
[21:04:14] <Alex Petrescu> BS: you might have border router, smaller routers in between
[21:04:22] <Alex Petrescu> BS: closer to the nodes, in charg eof many br
[21:04:34] <Alex Petrescu> BH: not applicable to std ND, decrement Hop Limit
[21:04:52] <mcr> multi-hop Neighbour discovery educational video/singalong: https://www.youtube.com/watch?v=jwDq32MtOQU
[21:04:55] <Alex Petrescu> BH: maybe applicatble to more things?  but has this req of playing games with traditional ND
[21:05:01] <Alex Petrescu> PT: talked to Suresh
[21:05:15] <Alex Petrescu> PT: he suggested, you may use the CGA s the uniq id in ARO
[21:05:36] <Alex Petrescu> PT: not need all signature info in every reg, no need to put them at all unless there is conflict
[21:05:44] <Alex Petrescu> PT: we need to protect address initiate
[21:05:51] <Alex Petrescu> PT: here we get state in the 6lo and 6lbr
[21:06:03] <Alex Petrescu> PT: 6lr and 6lbr can do first enforced
[21:06:11] <Alex Petrescu> PT: there is a way to check
[21:06:19] <Alex Petrescu> PT: first registration had that.
[21:06:36] <Alex Petrescu> PT: Suresh said why dont we challenge later.  If no conflict then why not put anything in the packets?
[21:06:45] <Alex Petrescu> BS: good  point, add some text?
[21:06:48] <Alex Petrescu> PT: I think so.
[21:07:02] <Alex Petrescu> SC: do people think thi sis an interesting work fo rthe group?
[21:07:16] <Alex Petrescu> SC: thos who think this work this work on 6lowpan ND hum,
[21:07:20] <Alex Petrescu> room: little hum
[21:07:30] <Alex Petrescu> SC: how many people read drafts
[21:07:34] <Alex Petrescu> SC: we need more hands
[21:07:39] <Alex Petrescu> SC: please read and make comments
[21:07:49] <Alex Petrescu> SC: work with Pascal and anybod interested
[21:07:52] <Alex Petrescu> Dave Thaler approach
[21:08:02] <Alex Petrescu> DT: two hands there were
[21:08:06] <Alex Petrescu> DT: not ready for adoption
[21:08:12] <Alex Petrescu> DT: not enough info to make a decision
[21:08:17] <Alex Petrescu> DT: I need info, because
[21:08:29] <Alex Petrescu> DT: CGA type of co,mputation protects suffic and not prefix
[21:08:41] <Alex Petrescu> DT: mitigate?  some attachs - me grabbing and replaying
[21:08:55] <Alex Petrescu> BS: optimal part does that, not preotect prefix
[21:09:02] <Alex Petrescu> DT: if not then other attacks
[21:09:06] <Alex Petrescu> PT: beginning of work.
[21:09:17] <Alex Petrescu> PT: you do not sign the address itself.
[21:09:27] <Alex Petrescu> PT: you may form more than one address
[21:09:38] <Alex Petrescu> PT: leverage that we are in a state in 6lo and 6lbr
[21:09:54] <Alex Petrescu> PT: this unique id came with the address, but not embedde din the address.
[21:10:10] <Alex Petrescu> PT: 6lr will remember who was the first use of this address.
[21:10:23] <Alex Petrescu> René Struik approach
[21:11:08] <Dave Thaler> font size is very small, unreadable from back of room
[21:12:10] <Dave Thaler> thanks alex, that's a bit better
[21:12:50] <Alex Petrescu> Once again I forgot my binoculars at home :-)
[21:14:37] jiye park leaves the room
[21:16:01] <Dave Thaler> like Fernando's presentation, there's nothing specific to 6lo in this one either, right?
[21:16:11] <Dave Thaler> i.e. all discussion should be in 6man instead?
[21:16:34] <Ines  Robles> yes
[21:16:44] <Ines  Robles> Fernando just said to me yes to that question
[21:16:49] <Alex Petrescu> Well yes, but arent there too many such things for a group like 6man?
[21:17:24] <Alex Petrescu> Fenando Gont approach
[21:17:36] <Dave Thaler> I was hoping this presentation would be about 6lo-specific stuff.  The only 6lo mention I see in the slides is in the WG name in the top right corner.
[21:17:49] <Alex Petrescu> FG: this is a goal (first bullet)
[21:17:56] <Kerry Lynn> @Dave:6man is not going to care a whit about IPv6 header compression.  Preserving the benefits of 6282 is 6lo's concern.
[21:18:00] <Alex Petrescu> FG: rfc6xxxx
[21:18:08] <Alex Petrescu> RS: this is a privacy issue
[21:18:10] <Dave Thaler> @Kerry: strongly disagree.
[21:18:16] <Alex Petrescu> FG: two types aof address: stable and temporary
[21:18:23] <Kerry Lynn> I agree this preso just addresses Fernando's
[21:18:34] <Alex Petrescu> FG: if you want addresses that do vary over time, this is a goal, actually.
[21:18:40] <Alex Petrescu> FG: 7017
[21:18:49] <Alex Petrescu> Alissa Cooper
[21:19:05] <Alex Petrescu> AC: in 6man we look at all different address generation mechanisms, side by side.
[21:19:11] <Alex Petrescu> AC: this one has a specific goal set.
[21:19:17] <Kerry Lynn> @Dave: about 6man not caring about IPHC or 6lo wishing to preserve it?
[21:19:17] <Alex Petrescu> AC: this feeback would be useful for that.
[21:19:19] <Dave Thaler> and I challenge you to find any mention of header compression in this presentation, other than the "further reading" list on the slide at the end that we havent' seen yet
[21:19:26] <Alex Petrescu> RS: only noticed being already an RFC
[21:19:29] <Dave Thaler> @Kerry: about 6man not caring.
[21:19:36] <Alex Petrescu> RS: some comments my hope is about revision some assumptions
[21:19:46] <Alex Petrescu> AC: might be useful to evaluate properties of separate mechanisms
[21:19:57] <Alex Petrescu> AC: this mechanism was aimed at a specific goals,
[21:20:20] <Alex Petrescu> RS: practically for 6lo, it is important something similar eui-64 contianing maintaiining compression benefits , but using other mechanisms
[21:20:49] <Alex Petrescu> FG: we have an I-D, nit published RFC, security and privacy properties, it contians among other things an analysis of this schele.
[21:20:54] <Alex Petrescu> RS: so I have to look at it.
[21:25:22] <Alex Petrescu> this looks like the random generation of ULAs...
[21:25:28] <Dave Thaler> this is a really good point... if you make the mac address be a stable random id, then you could get privacy using the standard EUI-64 based address generation mechanisms.
[21:25:49] <Dave Thaler> (stable random per-network)
[21:26:49] <Alex Petrescu> "larger-size IIds (i.e. more than 64 bits (7])"
[21:27:19] <Alex Petrescu> I wonder wha tis [7]
[21:28:21] <Dave Thaler> the final slide says [7] is draft-ietf-6man-why64-08
[21:28:41] <Alex Petrescu> Ole Troan
[21:28:49] <Alex Petrescu> OT: working on this long, bring this to 6man list
[21:29:02] <Alex Petrescu> OT: not presenting at this meeting drafts about privacy, but bring to 6man list
[21:29:05] <Alex Petrescu> Dave Thaler
[21:29:13] <Alex Petrescu> DT: very relevant to 6man, more than 6lo
[21:29:20] <Alex Petrescu> DT: key observation for 6man
[21:29:42] <Alex Petrescu> DT: if you make MAC address or equivalent is stable per network, then existing EUI-based gives you privacy.
[21:29:51] <Alex Petrescu> DT: that is great, bring this Friday on 6man meeting.
[21:30:04] <Alex Petrescu> SC: any intention of defining something for 6lo?
[21:30:15] <Alex Petrescu> SC: some parts could apply to 6lo generation
[21:30:17] <Kerry Lynn> What is 6lo relevant is that some links have a small L2 address space.
[21:30:20] <Alex Petrescu> RS: the compression part
[21:30:36] <Alex Petrescu> RS: anything related to crypto generabted addresses...
[21:30:42] <Alex Petrescu> RS: how to navigate at IETF...
[21:30:45] <Kerry Lynn> Will 7217 require e.g. 64 random bits of IID?
[21:30:57] <Alex Petrescu> RD: 6man Chairs are genial
[21:31:06] <Alex Petrescu> RD: bluesheets
[21:32:47] mcr leaves the room
[21:33:47] Kerry Lynn leaves the room
[21:34:16] Catherine Dibble leaves the room
[21:35:09] Meetecho leaves the room
[21:38:26] cabo leaves the room
[21:39:28] Ines  Robles leaves the room
[21:41:56] Alex Petrescu leaves the room
[21:47:56] Dave Thaler leaves the room
[22:14:00] 410fd10042cc10d3 joins the room
[22:14:02] kepeng_li joins the room
[22:14:48] 410fd10042cc10d3 leaves the room
[22:21:31] lishan.li joins the room
[22:22:21] lishan.li leaves the room
[22:24:52] kepeng_li leaves the room
[22:31:37] mcharlesr joins the room
[22:52:55] Dan York leaves the room
[22:55:25] Ruri Hiromi joins the room
[22:57:56] Ruri Hiromi leaves the room
[23:02:32] Ruri Hiromi joins the room
[23:03:04] Dan York joins the room
[23:03:26] Dan York leaves the room
[23:05:18] Alissa Cooper joins the room
[23:12:09] cabo joins the room
[23:47:38] cabo leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!