IETF
core@jabber.ietf.org
Wednesday, 27 July 2011< ^ >
stpeter has set the subject to: CoRE WG | http://tools.ietf.org/wg/core/
Room Configuration

GMT+0
[07:44:22] nr2805 joins the room
[07:45:05] nr2805 leaves the room
[07:45:37] test joins the room
[07:46:36] test leaves the room
[12:35:35] nriou joins the room
[12:35:39] nriou leaves the room
[12:54:01] sal joins the room
[12:55:26] ShoichiSakane joins the room
[12:58:05] Cullen Jennings joins the room
[13:00:47] nriou joins the room
[13:01:06] Cullen Jennings leaves the room
[13:01:18] angelo.castellani joins the room
[13:01:57] mcharlesr joins the room
[13:02:17] Robert Cragie joins the room
[13:02:36] Zhen Tsao joins the room
[13:03:51] <sal> Link Format (slides at http://tools.ietf.org/agenda/81/slides/core-5.ppt )
[13:07:17] linyi joins the room
[13:07:27] <linyi> good morning
[13:08:06] <sal> Link Format ready for IESG
[13:08:42] martin.thomson joins the room
[13:08:42] josephyee joins the room
[13:08:55] <sal> CoAP presentation http://tools.ietf.org/agenda/81/slides/core-4.ppt
[13:08:55] stpeter joins the room
[13:09:02] kepeng_li\40jabber.org joins the room
[13:09:30] <stpeter> klaus.hartke and others -- if you have comments that you want us to proxy to the meeting, please preface with "MIC"
[13:10:04] ari joins the room
[13:10:34] obergmann joins the room
[13:11:52] Steffi joins the room
[13:11:53] babongo joins the room
[13:12:01] yi.jiazi joins the room
[13:13:35] ꈲ joins the room
[13:13:56] nestor.tiglao joins the room
[13:14:09] <stpeter> hi Nestor! :)
[13:15:07] obergmann leaves the room: Replaced by new connection
[13:15:08] obergmann2 joins the room
[13:17:19] <linyi> it would be helpful to include slide number in the future presentation. it will help jabber scribe.
[13:17:30] <linyi> slide: Content Type Negotiation
[13:17:37] <stpeter> yes, always include the slide number :)
[13:21:51] ShoichiSakane leaves the room
[13:22:23] <ꈲ> MIC: There is no difference in interoperability between getting an error (as with critical) and getting an unwanted content-type back
[13:23:41] <stpeter> ꈲ = Carsten :)
[13:23:51] <ꈲ> Oh, let me change that...
[13:24:01] <kepeng_li\40jabber.org> the difference is, if the server returns unwanted content-type, it is waste of transmission resource
[13:24:04] <sal> ok... I'll wait for the change
[13:24:17] josephyee leaves the room
[13:24:21] <sal> OK
[13:25:07] <sal> cabo?
[13:25:27] <ꈲ> kepeng_li\40jabber.org: the waste will be rather less than the scenario where messages are sent twice.
[13:25:35] <linyi> even for elective, it may not be needed.
[13:25:36] josephyee joins the room
[13:25:57] <ꈲ> sal: No, I just tried to change my handle.
[13:25:59] <ꈲ> Which doesn't work.
[13:26:07] <sal> cabo do you want me go to the mic or not?
[13:26:13] <ꈲ> Yes, please. Sorry.
[13:27:05] ShoichiSakane joins the room
[13:27:34] ꈲ leaves the room
[13:27:42] cabo joins the room
[13:28:41] <angelo.castellani> cabo: but suppose that I put a critical Accept option in a multicast request. in that case only the nodes supporting the wanted content-type will respond. it could be useful
[13:29:24] <cabo> Yes — it could be. It is always hard to decide which things to leave out. If that use case gets more interest, we can always
[13:29:30] <cabo> add a critical version of that option later.
[13:29:44] <angelo.castellani> ok
[13:29:59] <kepeng_li\40jabber.org> it is strange to have two options, one is elective, one is critical
[13:30:18] <angelo.castellani> but it depends upon the semantic you want.
[13:30:30] <angelo.castellani> it is quite different
[13:30:45] <cabo> HTTP has both versions, too, except that that semantics is expressed by a "*"
[13:31:08] <angelo.castellani> can't we have the Accept: * too?
[13:31:21] <kepeng_li\40jabber.org> OK, i will check HTTP and then come back
[13:32:05] <angelo.castellani> Accept is critical, but if I can live with even different representations I will always provide an Accept: * at the end
[13:32:15] <cabo> angelo.castellani: Yes, we'd have to reserve one ct value for * (it's just a number)
[13:32:40] <cabo> It is still strange to send a critical option when you don't need it processed.
[13:32:41] <angelo.castellani> probably in this case we don't even need the elective accept option
[13:33:11] <angelo.castellani> however if the server does not support it, this will be a problem..
[13:33:58] <kepeng_li\40jabber.org> agree with Casten
[13:34:09] <stpeter> Tero Kivinen at the mic
[13:34:15] josephyee leaves the room
[13:34:44] monden joins the room
[13:39:21] <kepeng_li\40jabber.org> I think we still need more considerations about this, whether two, or choose one, at least, not clear to me which way is better
[13:40:18] <martin.thomson> that is what options is for
[13:41:28] <stpeter> Michael Richardson at the mic
[13:43:54] <stpeter> cabo: do you have any opinion in the matter?
[13:44:09] <cabo> Yes, the opinion is in the draft :-)
[13:44:16] <stpeter> heh
[13:45:15] josephyee joins the room
[13:46:17] nestor.tiglao leaves the room
[13:46:48] <cabo> [The server can always pretend to not support the Accept :-),so I can have my version of the behavior, too]
[13:47:15] <cabo> slide#?
[13:47:20] <kepeng_li\40jabber.org> last slide
[13:47:30] <cabo> which says "WGLC?"
[13:47:33] nestor.tiglao joins the room
[13:47:34] <sal> yes
[13:47:40] <martin.thomson> cabo: exactly
[13:47:47] <cabo> thx
[13:48:17] nestor.tiglao leaves the room
[13:49:30] nestor.tiglao joins the room
[13:53:35] <Robert Cragie> There is a distinction here between key management for application peers and key management for network access. I agree with Bob re. keys for network access but once in a secure network there may be scope for brokering pre-shared keys for application peers
[13:56:38] <stpeter> Robert Cragie: do you want us to take that comment to the mic?
[13:56:56] <Robert Cragie> Yes please
[13:58:13] mycom joins the room
[14:01:01] <ShoichiSakane> we should consider not only key management protocol for coap, but also other layer and protocol. otherwise, we have to implement different key management protocol for different modules into a single device. that is terrible for a constrained device. this is not an issue for core-wg only.
[14:01:46] <kepeng_li\40jabber.org> ShoichiSakane +1
[14:02:03] <stpeter> ShoichiSakane: shall i relay that to the mic?
[14:02:05] <Robert Cragie> @Shoici: Agree, whch is why we tried to standardise on TLS in ZigBee at the application and for network access
[14:02:13] <ShoichiSakane> plz, thnx
[14:03:12] <martin.thomson> in response to the last question - there is some protection against copy&paste in TLS-PSK. it doesn't have perfect forward security, but the PSK is only used for authentication
[14:03:18] <stpeter> Ohba-san at the mic
[14:04:51] <kepeng_li\40jabber.org> Bob at mic
[14:04:56] MStJohns joins the room
[14:05:36] igarashi joins the room
[14:06:06] <cabo> HHUMMMM
[14:06:12] <ShoichiSakane> HUM
[14:06:18] <Robert Cragie> HUMM
[14:06:44] <sal> presentation on Block: http://tools.ietf.org/agenda/81/slides/core-3.ppt
[14:06:55] <sal> Current Status
[14:07:09] <stpeter> BTW presentations are at https://datatracker.ietf.org/meeting/81/materials.html#wg-core
[14:07:26] stpeter has set the subject to: CoRE WG | http://tools.ietf.org/wg/core/ | IETF 81 | slides at https://datatracker.ietf.org/meeting/81/materials.html#wg-core
[14:08:17] stpeter has set the subject to: CoRE WG | http://tools.ietf.org/wg/core/ | IETF 81 | slides at https://datatracker.ietf.org/meeting/81/materials.html#wg-core | audio at http://ietf81streaming.dnsalias.net/ietf/ietf805.m3u
[14:08:20] <sal> Work Needed
[14:08:53] <cabo> Indeed, a rewrite is needed.
[14:09:43] <stpeter> I like "Block1" and "Block2" -- it has a Dr. Seuss sound to it :)
[14:15:22] <stpeter> Salvatore at the mic
[14:15:55] <cabo> Good luck in solving the keepalive problem...
[14:16:08] <linyi> l like Block0 and Block1 (my chinese name means 0 and 1)
[14:16:31] <linyi> Linyi = Lin (0) + Yi (1)
[14:16:53] <linyi> so call me 01 is also ok. easy for western people?
[14:17:11] <obergmann2> not for computer scientists ;-)
[14:17:31] <obergmann2> i.e. not a problem, of course
[14:18:02] <linyi> obviously not born for IPV6. i have no idea of ipv6 when i was given this name:)
[14:18:23] <angelo.castellani> linyi: it's a binary name! nice :)
[14:18:35] <linyi> yup, lightweight
[14:18:53] <stpeter> we can call him "one-bit"
[14:19:10] <linyi> uummm
[14:19:34] <stpeter> I think "linyi" is easier....
[14:19:36] <stpeter> ok
[14:19:38] <stpeter> next presenter
[14:19:45] <stpeter> finally Zach gets a break
[14:19:59] <sal> HTTP Mapping presentation
[14:20:26] <stpeter> Angelo Castellani
[14:21:58] <sal> Cross-protocol proxies taxonomy
[14:22:23] <MStJohns> slide url?
[14:22:49] <sal> presentation at: http://tools.ietf.org/agenda/81/slides/core-10.pdf
[14:23:08] <MStJohns> tnx
[14:23:31] <linyi> Peter leans Chinese start from my name. Because the pronunciation of "linyi" is the same for Chinese 01.
[14:23:36] <sal> cross-protocol URI
[14:23:47] mycom leaves the room
[14:24:39] <linyi> i think protocol URI mapping is quite straightforward
[14:26:25] <Robert Cragie> @linyi: There are 10 types of people in the world. Those who understand binary and those who don't :-)
[14:26:30] <stpeter> Zhen Cao at the mic
[14:26:34] S7365468EEE7F6 joins the room
[14:26:42] <stpeter> Michael Richardson at the mic
[14:27:53] <sal> URI mapping
[14:28:44] <sal> URI mapping examples
[14:29:45] stpeter just sent a message to the ietf@ietf.org list about slide numbers... :)
[14:31:10] <cabo> stpeter: see also http://wiki.tools.ietf.org/group/wgchairs/wiki/MeetingAV
[14:31:55] <sal> Dynamic URI mapping (TODO)
[14:32:06] <kepeng_li\40jabber.org> Csten, I notice that my slides are not on the server, can you put them there?
[14:32:37] <cabo> kepeng_li\40jabber.org: moment, please
[14:35:41] S7365468EEE7F6 leaves the room
[14:35:55] <sal> HTTP-CoaP caching and congestion
[14:36:59] <martin.thomson> http://dev.w3.org/html5/spec/Overview.html#custom-handlers
[14:37:25] <martin.thomson> that's the link for registering a specific scheme handler in the browser. You might find that Copper already uses it
[14:37:29] <sal> HTTP-CoAP v4/v6 use case
[14:38:52] <sal> HTTP unicast --> CoAP multicast
[14:39:38] <cabo> kepeng_li\40jabber.org: fixed
[14:40:32] <martin.thomson> I wont get up to say this, but I find the idea that the proxy "knows stuff" to be concerning
[14:40:53] <martin.thomson> unless this information is discoverable, the amount of configuration required is going to be a burden
[14:41:18] <kepeng_li\40jabber.org> thanks, Casten
[14:41:40] <cabo> martin.thomson: Yep, that is a violation of the principle of not putting application knowledge into the network.
[14:41:43] <ShoichiSakane> The HC proxy understands whether an URI identifies a multicast *listner*, doesn't it ?
[14:42:12] mhp joins the room
[14:42:21] <martin.thomson> I'm OK with the fact that the URI might identify a multicast group somehow
[14:42:22] monden leaves the room
[14:42:55] <martin.thomson> so you have to be careful how these are presented
[14:43:25] monden joins the room
[14:43:30] <babongo> martin: at a given point the proxy is going to learn that a given uri maps to a multicast ipv[64] address...
[14:43:41] <sal> Security Consideration
[14:44:07] <ShoichiSakane> ic,thx
[14:44:34] <martin.thomson> babongo: it depends on how and when that knowledge is gained as to whether it's a problem or not
[14:45:27] <martin.thomson> it also depends on whether it's a proxy, or a specific server that provides a CoAP bridging service
[14:46:20] <martin.thomson> proxy implies intermediation only (with protocol translation in this case), providing a specific service is not really proxying/intermediation
[14:50:42] <cabo> Please say your names… I recognize most people, but not all...
[14:51:25] zdshelby joins the room
[14:52:52] <cabo> Note that some implementation experience is also going into the LWIG draft.
[14:53:14] <kepeng_li\40jabber.org> i hope i said my names
[14:53:26] <cabo> kepeng_li\40jabber.org: you did, thanks
[14:53:27] <stpeter> cabo: I am sitting by the mic and I try to type people's names into the chatroom
[14:53:46] <cabo> http://tools.ietf.org/agenda/81/slides/core-0.pdf <http://tools.ietf.org/agenda/81/slides/core-10.pdf>
[14:53:55] <zdshelby> Right, I think that draft-castellani-core-http-coap-mapping is more about protocol advice
[14:54:00] <sal> Legacy, Non-IP techonology
[14:54:11] angelo.castellani leaves the room
[14:54:32] <zdshelby> Bad Jari - no IP...
[14:54:37] <ShoichiSakane> implementation experience should be discussed at lwig. this draft is probably useful as an experimental document in order to deploy CoAP.
[14:55:53] <zdshelby> Some aspects of proxy implementation definitely belong in LWIG, and already there are CoAP aspects there. But much belong in CoRE...
[14:55:58] <sal> Highlights form the Implementation
[14:56:13] <kepeng_li\40jabber.org> agree with Zach
[14:56:19] <stpeter> this is page 5 (but the page numbers are small)
[14:57:17] <sal> page 6
[14:57:36] <stpeter> are these slides online?
[14:57:48] <stpeter> I thought I saw Jari working on them a few minutes ago :)
[14:57:55] <linyi> me too
[14:58:00] <linyi> we spied on it
[14:58:02] <stpeter> :)
[14:58:32] <zdshelby> Slides are here: http://tools.ietf.org/agenda/81/slides/core-0.pdf
[14:59:05] <sal> page 7
[14:59:14] Steffi leaves the room
[14:59:35] angelo.castellani joins the room
[14:59:52] tiff joins the room
[14:59:55] <stpeter> zdshelby: correct
[15:03:42] mycom joins the room
[15:10:26] <cabo> senml?
[15:12:17] <zdshelby> SenML + well-known resource types (rt=core-sensor, rt=core-actuator etc.)
[15:12:47] behcet.sarikaya joins the room
[15:13:10] <Robert Cragie> This may be out of scope for the CoAP part and more appropriate for LWIG but are there considerations for multiple caches? In a zero configuration model there may be many nodes which can act as the cache node and therefore may introduce multiple messages into the system. There may need to be some protocol to arbitrate amongst the caches to elect one which represents the sleepy sensor
[15:13:42] <stpeter> Robert Cragie: "MIC"?
[15:13:54] <zdshelby> Akbar
[15:14:17] <Robert Cragie> No - it's quite convoluted
[15:14:20] <stpeter> Robert Cragie: "Do you want me to channel that comment to the MIC"?
[15:14:21] <stpeter> ok
[15:14:42] <stpeter> Robert Cragie: perhaps ping Jari directly
[15:14:59] <Robert Cragie> Will do
[15:16:06] <stpeter> Samita Chakrabarti at the mic
[15:16:07] <martin.thomson> is there any case for negotiating or advertising the sleep-wake cycle of a device?
[15:16:26] <cabo> martin.thomson: MACs do that.
[15:16:38] <zdshelby> I have a CoAP server up on the IETF network if anybody wants to test at coap://130.129.18.59 or coap://[2001:df8::16:9227:e4ff:feea:72de]
[15:16:57] <martin.thomson> yeah, but that relies on the peers being on the same segment
[15:17:32] <sal> I don't think there is anything on CoAP at the moment
[15:17:47] <cabo> martin.thomson: The question is really whether that complexity needs to be carried out of L2
[15:18:04] <martin.thomson> fair point
[15:18:12] <stpeter> Zhen Cao
[15:18:19] <stpeter> (agenda change)
[15:18:40] <stpeter> http://www.ietf.org/proceedings/81/slides/core-1.pdf
[15:20:07] <zdshelby> I like "Drowsy" - like almost sleeping :-)
[15:20:17] <stpeter> :)
[15:20:23] <mcharlesr> doopey.
[15:20:32] <stpeter> I always heard it as "sleepy nodes" instead of "sleeping nodes"
[15:20:32] martin.thomson leaves the room
[15:20:48] <mcharlesr> Jari's implemention is in fact sneezy.
[15:20:53] <stpeter> heh
[15:20:58] <zdshelby> LoL
[15:21:30] <mcharlesr> And, once a node has security, I guess it becomes bashful.
[15:21:42] <stpeter> or happy
[15:22:20] <mcharlesr> I think that a happy node is one that is pleased to meet you, and very willing to comply to any request you send.
[15:23:40] <mhp> Getting the security right is reserved for Doc, though
[15:23:58] <stpeter> Snow White and the Seven Nodes?
[15:24:14] <mcharlesr> .. do we have seven unique use cases?
[15:24:23] <zdshelby> Re-charter?
[15:25:05] behcet.sarikaya leaves the room
[15:28:52] nestor.tiglao leaves the room
[15:28:52] mycom leaves the room
[15:29:03] <kepeng_li\40jabber.org> i don't see any changes on the CoAP protocol level
[15:29:17] <sal> me neither
[15:29:51] igarashi leaves the room
[15:29:56] josephyee leaves the room
[15:30:00] yi.jiazi leaves the room
[15:30:21] sal leaves the room
[15:30:23] zdshelby leaves the room
[15:30:33] nriou leaves the room
[15:30:37] mhp leaves the room
[15:30:37] Robert Cragie leaves the room
[15:30:59] ShoichiSakane leaves the room
[15:30:59] Zhen Tsao leaves the room
[15:30:59] obergmann2 leaves the room
[15:31:00] <stpeter> session over
[15:31:07] <stpeter> afternoon session to follow in 1.5 hours
[15:31:16] stpeter leaves the room: Disconnected: connection closed
[15:31:22] MStJohns leaves the room
[15:31:29] tiff leaves the room
[15:31:52] ari leaves the room
[15:32:22] mcharlesr leaves the room
[15:32:52] monden leaves the room
[15:32:54] monden joins the room
[15:32:56] mycom joins the room
[15:37:38] babongo leaves the room
[15:41:08] angelo.castellani leaves the room
[15:42:22] mycom leaves the room
[15:43:58] kepeng_li\40jabber.org leaves the room
[15:45:22] monden leaves the room
[15:47:00] linyi leaves the room: Computer went to sleep
[16:02:51] MStJohns joins the room
[16:05:46] martin.thomson joins the room
[16:09:11] martin.thomson leaves the room
[16:24:52] MStJohns leaves the room
[16:36:50] MStJohns joins the room
[16:47:56] mcharlesr joins the room
[16:48:23] cabo leaves the room
[16:48:27] cabo joins the room
[16:49:53] MStJohns leaves the room
[16:50:40] MStJohns joins the room
[16:57:08] nriou joins the room
[16:58:27] <cabo> So, which audio stream is it?
[16:58:37] martin.thomson joins the room
[16:59:10] <nriou> http://ietf81streaming.dnsalias.net/ietf/ietf801.m3u
[16:59:25] <cabo> Ah, now it works.
[16:59:33] <cabo> was 404.
[17:00:34] linyi joins the room
[17:00:45] <linyi> good afternoon
[17:00:57] monden joins the room
[17:01:17] arikk joins the room
[17:01:28] mycom joins the room
[17:03:40] kepeng_li\40jabber.org joins the room
[17:04:29] martin.thomson leaves the room
[17:04:38] martin.thomson joins the room
[17:05:14] obergmann2 joins the room
[17:06:23] mycom leaves the room
[17:06:41] angelo.castellani joins the room
[17:07:29] mycom joins the room
[17:08:11] nestor.tiglao joins the room
[17:08:23] mycom leaves the room
[17:08:25] mycom joins the room
[17:10:33] stpeter joins the room
[17:11:16] <cabo> Block0, Block1
[17:11:33] <stpeter> cabo: ;-)
[17:11:46] babongo joins the room
[17:12:38] sal joins the room
[17:13:03] Zhen Tsao joins the room
[17:13:19] <stpeter> oh, the audio is different for this session
[17:13:21] stpeter finds the URL
[17:13:52] <stpeter> http://ietf81streaming.dnsalias.net/ietf/ietf801.m3u
[17:14:03] stpeter has set the subject to: CoRE WG | http://tools.ietf.org/wg/core/ | IETF 81 | slides at https://datatracker.ietf.org/meeting/81/materials.html#wg-core | audio at http://ietf81streaming.dnsalias.net/ietf/ietf801.m3u
[17:14:04] <klaus.hartke> we can specify one mti mechanism to establish observation relationships now (GET request) and add more for sleepy devices later (static observation relationships, etc)
[17:14:32] <stpeter> klaus.hartke: that seems sensible
[17:16:50] kivinen joins the room
[17:19:24] martin.thomson leaves the room
[17:23:55] <stpeter> Hannes Tschofenig at the mic
[17:28:28] <kepeng_li\40jabber.org> Since the line is cut, in fact, i have two questions: 1) can we achieve partially update, from the syntax, it seems to be difficult; 2) does it have influence to the link-format document, because it is mentioned in the ppt.
[17:29:58] <cabo> 1 — we could always add PATCH to CoAP :-)
[17:30:31] <cabo> 2 — not the format. But there will be attributes. So this increases the urgency to get a registry going.
[17:30:49] zdshelby joins the room
[17:30:56] <kepeng_li\40jabber.org> get it ,thanks ,cabo
[17:32:57] <kepeng_li\40jabber.org> http://www.ietf.org/id/draft-lynn-core-discovery-mapping-01.txt
[17:33:35] <cabo> slides = http://www.ietf.org/proceedings/81/slides/core-7.pdf ?
[17:34:11] <kepeng_li\40jabber.org> yes
[17:34:38] <kepeng_li\40jabber.org> slide 4
[17:36:37] bush35284 joins the room
[17:37:00] <bush35284> i will echo the minutes i took here to make sure i capture something correct
[17:37:12] <bush35284> bush35284 is Linyi (01)
[17:37:37] <bush35284> Minutes for Core (Wednesday Afternoon)
1. Charter Review
Peter suggested it maybe reasonable to allow several months work on block draft.
Linyi suggested it make sense to merge the size option draft into block draft if it is accepted as WG item.
[17:37:43] <bush35284> 2. Core Resource Directory Draft (Zach)
There is a related EU project SENSI (2008-2010) for this feature.
Hannes Tschofenig:
• Which part will be standardized in the RD architecture? There is different IOP need in different parts.
• Is the interface between the RDS and sensor or device? What does client means?
Kepeng Li:
• Can we achieve partially update, from the syntax, it seems to be difficult;
• Does it have influence to the link-format document, because it is mentioned in the ppt
[17:37:56] <stpeter> Alex Mayrhofer (sp?) at the mic
[17:38:40] <kepeng_li\40jabber.org> slide 5
[17:41:27] <kepeng_li\40jabber.org> should this draft be an informational draft?
[17:41:34] <kepeng_li\40jabber.org> instead of standard track?
[17:41:51] <stpeter> Akbar presenting
[17:41:54] <kepeng_li\40jabber.org> group communicatin now
[17:41:58] <bush35284> 3. DNS-Based Service Discovery (Kerry Lynn)
Kepeng: Should this be informational?
No other serious issues were raised.
[17:43:50] <kepeng_li\40jabber.org> slide 2,core-11.ppt
[17:44:13] Linyi Tian joins the room
[17:44:23] <Linyi Tian> i am back:)
[17:44:37] <Linyi Tian> was unable to type:(
[17:44:48] bush35284 leaves the room
[17:46:32] <kepeng_li\40jabber.org> slide 4
[17:47:24] MStJohns leaves the room
[17:52:04] jariarkko joins the room
[17:52:10] sal leaves the room
[17:52:21] <kepeng_li\40jabber.org> Kerry Lynn at mic just now
[17:52:29] <Linyi Tian> Peter: could you please help record this action for me since i am not familiar with this.
[17:52:53] <jariarkko> Please tell me how we are doing in terms of the agenda. I'm in HOMENET, but I want to come to CORE when its time for my presentation on security.
[17:53:22] <kepeng_li\40jabber.org> i guess we will run out of time, next is size option
[17:53:34] <Linyi Tian> we are on group comm
[17:54:47] <cabo> Behcet?
[17:55:34] <stpeter> linyi: I don't think there is an action item yet
[17:55:41] <kepeng_li\40jabber.org> Behcet Sarikaya at mic
[17:56:20] <cabo> re the groupcomm draft: We still appear to be in the information collection phase. Now people have to build things out of this information.
[17:56:38] <Linyi Tian> i heard cullen mentioned we could have an action related to kerry's comment
[17:57:49] <stpeter> linyi: ask Cullen at the mic
[17:58:02] <Linyi Tian> ok, i will confirm with him
[17:58:18] <Linyi Tian> thanks , peter
[17:58:27] <stpeter> linyi: he says no action item, other than people providing comments on the list
[17:58:27] <Linyi Tian> 4. Group Communication (Akbar)
Kerry: xxxx (was not captured)
It was proposed to have application multicast, why now we changed to IP layer multicast?
Akbar: We investigated the different options: IP Multicast, Overlay Multicast and CoAP Application Level Group Management. Finally we come to the conclusion that we should just do IP Multicast.
Zach: Do you think that multicast will cause congestion control? In the base spec, we have already used IP multicast.
[17:58:39] <stpeter> Kepeng Li presenting
[18:02:15] <cabo> 1) I like the basic approach
[18:02:53] kepeng_li\40jabber.org leaves the room
[18:03:08] <cabo> 2) We need to separate the HEAD (send no data) function from the size indication
3) We need to provide the end-points with hints on when to send this and when not.
[18:03:54] <zdshelby> cabo--tzi--org: +1
[18:04:01] <Linyi Tian> 5. Size Option (Kepeng Li)
Hum:
(1) WG should work on this: some hum
(2) Not sure: some hum
(3) Objections: no hum
[18:04:57] <cabo> 1) I like the basic approach
2) we could misuse timeout=0 as HEAD
[18:05:15] <cabo> er, excuse me, I mean, no response required.
[18:05:49] <cabo> We can do this down the road
[18:08:02] <Linyi Tian> Request timeout (Kepeng Li)
Milliseconds or mibiseconds: Mibisectonds
Cabo:
• I like the basic approach
• We cold misuse timeout=0 as HEAD
Zach: I am not convinced we need this. It is better to see more implementations
[18:08:22] kepeng_li\40jabber.org joins the room
[18:11:59] <Linyi Tian> i think request timeout is similar with Accept header
[18:12:07] <Linyi Tian> it is just the recommendation
[18:18:08] <stpeter> Kerry at the mic
[18:20:50] <Linyi Tian> 7. Building Control (Peter)
Zach: I think the idea of forcing the sensors in the group to have the same path should be carefully considered. An alternative way is to have a proxy in between.
Peter: Put the proxy in between will cause delay.
Ed: Where the DNS server is? Who is administrative it in that scenario?
Kerry: In commercial applications, you can delegate DNS resource.
Anders: For large buildings you will have administrative DNS server.
Kerry: It is also possible to add DNS records in existing DNS.
[18:22:23] mycom leaves the room
[18:22:25] <Linyi Tian> what's this ? i didnt see it in online agenda
[18:22:29] <kepeng_li\40jabber.org> now bootstrping
[18:22:44] <kepeng_li\40jabber.org> http://www.ietf.org/id/draft-ohba-core-eap-based-bootstrapping-00.txt
[18:23:10] <cabo> Slides not in meeting repo?
[18:23:22] <cabo> What are they called?
[18:23:26] <Linyi Tian> i didn't see slides too
[18:23:28] <zdshelby> Nope
[18:25:46] <kepeng_li\40jabber.org> so it will be difficult for Casten. :-)
[18:27:02] <kepeng_li\40jabber.org> I like Zach's presentation, it is short, and just includes important issues
[18:27:20] <jariarkko> how are doing on time now? will you run out of time, or will I have time to speak? if so, when?
[18:27:29] <kepeng_li\40jabber.org> this afternoon, the presentations are too long, and no time for discussion
[18:27:52] <kepeng_li\40jabber.org> Now it is boostraping
[18:28:10] <kepeng_li\40jabber.org> jariarkko, i guess you have no time for security
[18:28:23] <cabo> I see jari at about 1445
[18:28:33] <cabo> Why wouldn't that work?
[18:28:33] <jariarkko> ok
[18:29:56] <kepeng_li\40jabber.org> we have another one before security, SOAP over CoAP, maybe we are on time
[18:30:10] <cabo> (Security is work we actually are chartered for. Guido will be fast, I hope…)
[18:30:43] <kepeng_li\40jabber.org> yes, it is difficult and important
[18:30:57] <zdshelby> Guido is not here. the agenda was old
[18:31:24] <zdshelby> Jari is up next when he managed to get here.
[18:31:33] <cabo> Oh, good.
[18:31:49] <zdshelby> Good, except we are missing Jari :-0
[18:32:13] <jariarkko> coming now
[18:34:02] <kepeng_li\40jabber.org> Cullen is uploading the presentation for EAP
[18:35:24] arikk leaves the room
[18:35:31] <kepeng_li\40jabber.org> Jari's turn, security now
[18:35:42] <cabo> core-9.pdf
[18:35:54] <kepeng_li\40jabber.org> yes
[18:36:59] arikk joins the room
[18:37:22] <kepeng_li\40jabber.org> slide 4
[18:39:39] mycom joins the room
[18:41:08] behcet.sarikaya joins the room
[18:43:24] jariarkko leaves the room
[18:45:11] <kepeng_li\40jabber.org> slide 8
[18:46:42] <kepeng_li\40jabber.org> Yoshihiro Ohba @ mic

[18:46:53] <kepeng_li\40jabber.org> Hennes @mic now
[18:49:11] angelo.castellani leaves the room
[18:56:21] <cabo> Mike?
[18:56:40] Linyi Tian leaves the room
[18:56:51] <zdshelby> Oscar @ Mic
[18:57:15] <cabo> Inaudible even with my insane compressor setup.
[18:58:19] Linyi Tian joins the room
[18:58:19] behcet.sarikaya leaves the room
[19:00:21] zdshelby leaves the room
[19:00:51] <Linyi Tian> 8. Bootstrapping (Yoshihiro)
Oscar has some suggestions.
9. CoAP securety (Jari)
Yoshihiro: This identity is the client device identity. Consider the mutual authentication, how this can be done?
Hennes: The different trust model leads to different solutions. This is the application layer solution. I am wondering how this can form a big picture for different trust models in terms of standardization.
Jari: We are proposing architecture that provides a practical, minimal-configuration approach to smart object security.
Jari clarified the proposal is mainly on the provision part.
[19:01:17] Zhen Tsao leaves the room
[19:01:24] nestor.tiglao leaves the room
[19:02:25] kivinen leaves the room
[19:02:28] obergmann2 leaves the room
[19:03:17] nriou leaves the room
[19:04:18] klaus.hartke leaves the room
[19:04:24] arikk leaves the room
[19:05:24] mycom leaves the room
[19:05:51] <kepeng_li\40jabber.org> Meeting is over
[19:06:12] Linyi Tian leaves the room: Computer went to sleep
[19:07:24] kepeng_li\40jabber.org leaves the room
[19:08:42] mcharlesr leaves the room
[19:09:14] mcharlesr joins the room
[19:09:17] nestor.tiglao joins the room
[19:09:33] babongo leaves the room
[19:10:19] cabo leaves the room
[19:12:36] nestor.tiglao leaves the room
[19:16:05] arikk joins the room
[19:16:15] arikk leaves the room
[19:25:24] monden leaves the room
[19:27:15] martin.thomson joins the room
[19:29:04] martin.thomson leaves the room
[19:29:13] martin.thomson joins the room
[19:34:18] martin.thomson leaves the room
[19:51:39] mcharlesr leaves the room
[19:56:54] martin.thomson joins the room
[20:02:24] martin.thomson leaves the room
[20:03:30] monden joins the room
[20:21:10] angelo.castellani joins the room
[20:21:12] angelo.castellani leaves the room
[20:55:06] martin.thomson joins the room
[20:55:30] martin.thomson leaves the room
[21:21:55] monden leaves the room
[23:11:11] monden joins the room
[23:19:13] stpeter leaves the room: Disconnected: connection closed
[23:23:39] monden leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!