Minutes CORE WG IETF 83.5 We take notes by typing them into the agenda items listed below. Note taker for the first half: Sye Loong -- thanks! Note takers for the second half: Esko Dijk and Klaus Hartke -- thanks! Attendees: Cullen Jennings Carsten Bormann Barry Leiba Bert Greevenbosch Jeroen Hoebeke Jouni Korhonen Kepeng Li Klaus Hartke Matthias Kovatsch Pete Resnick Sye Loong Keoh Salvatore Loreto Thomas Fossati (?) Yan Wang Zach Shelby Esko Dijk We have used the outline of the agenda (everything indented below) to type in the notes between the numerous items on the list. 2012-05-16 14:30Z..17:30Z CoRE Virtual Interim 2012-05-16 Below, find a rough agenda for disposing of 39 tickets. The guesses for the times are probably somewhat optimistic, so we may not even get to the end of all tickets. Still: Per draft, we distinguish: -- check defined resolution and go ahead (~ 2 min per) The ticket has a defined resolution with non-trivial impact. We should check that this is what we want to do. -- discuss (~ 10 min per) The ticket is still in need of a defined resolution. -- tickets with a clear way forward (optional) (~ 1 min per) There is some relatively straightforward work to do, but not necessarily here -- speak up if you think discussion is needed. -- tickets that need more work on the mailing list (~ 1 min per) Next interim. In reverse alphabetical order: * Call to order (10 min) 14:30Z..14:40Z -- Notetakers etc. -- Technical issues -- Agenda bashing * Observe (49 min) 14:40Z..15:29Z -- check defined resolution and go ahead (2 min) #225 Explain why it is not always possible to react to a RST that is in reply to a NON (editorial minor) (See #221 below) -- discuss (40 min) #204 Introduce a minimal version of Pledge (protocol enhancement major) Klaus presents his elaborated slides. Salvatore: solution does not take into consideration of proxy? Klaus: it does support proxy - see example in slides Cullen: Different things are being communicated. Interest. How old data is. How long data might be valid for. Carsten: optimistic freshness extension (Taipei) tried to map interest into freshness, that didn't really work. This tries to come up with the right names for things first and than we can map that to messages. Cullen: minimum time for which the data will not change. time after which you are sure it *will* change. Carsten: Originally we had a lifetime that expressed how long the client might be interested -- we never knew what value to set it to, so we removed it and made it boolean (probably a good decision). Different issue: does the server still know the client is interested, and what is the amount of time for which the server is willing to commit to something. Vial: let application to decide which mechanism to use. Zach: not sure we need the information how old data is. Klaus: could be useful information, but also could be in the payload. Cullen, Zach: agree; put timestamps into the payload. Carsten: if we use timestamps, there might need to be some sort of common time between nodes/time synchronization. Carsten: In the examples, it is always the Server that provides the time frames -- is that right? Cullen: sounds workable. [there is a period of high packet loss in the speech connectivity in the next __ minutes] Carsten: Have a couple of people work on this, e.g. Matthias, Zach, Klaus, and report to the mailing list. Cullen: also need solve the problem of understanding when the client has gone away. Problem: to detect proxy has lost interest. Cullen: look at a use case where max_age is 0, data is continuously changing Salvatore: we probably need more time to think about this. Conclusion: put a proposal based on the text in the coap-misc draft, and improve the text, so that people can look at the text (in a revised coap-misc) before it is incorporated into the working group document. Matthias: takes action to create a list of problems to be solved, what is in scope, terms, etc... together with Klaus. Carsten: and please really focus on giving names to the concepts so we know what we are talking about. Klaus & Matthias to go to work on this in the week starting 21st. (Summary: Time did not suffice to come to a solution with folks on call but will take to list.) #217 how fast must the observe clock be able to go? (protocol enhancement major) Cullen: need to know what's the retransmission window in the network. All we have to do is have a sequence number; and make sure the sequence number does not wrap within the time window. Carsten: originally, each observation relationship had its own sequence number. People commented: constrained devices may not want to keep state information for each observation relationship, so we have been targeting a solution using a single system wide counter. (The sequence number now might wrap while you are not looking; so we need a timer to forget about it. We now have a system wide constant that is a quotient of that time and the maximum change rate.) Cullen: I want a 1000 Hz change rate Carsten: Now, instead of using system wide counter, we could move to a per resource counter. Matthias: we don't have to limit it to 16 bits. Carsten: how do you know how long it is? Matthias: You just don't wrap. Takes action to explain his solution to the group. [This is now in: http://www.ietf.org/mail-archive/web/core/current/msg03331.html] (Some more discussion about fractional representations.) Discussion about time a message stays in the network. Carsten: You need about 10+8+2=20 bits for 1000 Hz even if you limit to 2**8 seconds. (Ticket #201 later..) Did not come to a solution with folks on call but looking forward to get some proposal on the list. #220 Should observe support time series data? (protocol enhancement minor) (Some more discussion about non-cacheable data, see #204) Carsten: record every single change in a reliable way? Hard to do. Jeroen clarified that this ticket is misinterpreting his comment and that the item raised is really about notifications with a Max-Age of zero which will be resolved in ticket #204. #227 Make aborting the previous transaction optional (protocol enhancement minor) Cullen: implemented it. We didn't realize we needed to do this. Matthias: hard to access this information in strongly layered implementation Cullen: So you have to add the interfaces Carsten: Do we need to make this a MUST? This is between "protect the network" and "quality of implementation". Your congestion control state would not allow you to start a new transaction before the old has been completed/aborted. Leading to a head-of-line problem... But the CC language is a bit too weak to lead people into noticing that they are having the problem -- that's why we wrote that in the first place. -> consensus to convert this into a "quality of implementation" note. -- tickets with a clear way forward (optional) (7 min) Carsten: It's clear what has to be done, but it still has to be done. #219 Clarify that observe is about eventual consistency (editorial minor) #221 Occasionally sending CON is not just a security consideration (protocol defect minor) Cullen: define how frequently this has to be done. Negotiate or write it into spec? Carsten: The side that is interested in the outcome is also the side that sets the parameter. Cullen: But there is also the network that is interested in these messages stopping. Saying it is a protocol constant, and it is less than infinity, is not sufficient. Carsten: We have CC to make sure the network is happy. (One interesting case: I observe something and suddenly get this deluge of messages. That's where negotiation would help.) Cullen: sending observations into a black hole forever should not happen. Carsten: CC should not allow that to happen. Cullen: is no longer a congestion control issue at 1/min Need to define what does it mean by "occasionally", what is the time frame? once a day? Zach: I might not send a notification for a week? Carsten: You only have to send the CON if you actually send a notification. It would say you MUST send a CON instead of just NONs at least once a day. -> consensus at least approximately once a day #223 Fix reordering detection condition description (editorial minor) #234 Editorial updates to -observe examples (editorial minor) #235 Avoid extending the base standard retransmission rules (other technical minor) #236 Clarify the semantics of the "obs" link target attribute (other technical minor) #237 Multicast -> reference groupcomm draft (editorial minor) -- tickets that need more work on the mailing list (none) * CoAP (59 min) 15:29Z..16:28Z -- check defined resolution and go ahead (22 min) #202 Remove the 270 byte artificial limit (protocol defect minor) Cullen: discuss first whether we need limits or not. You need some limits; problems with malloc() in constrained implementations. Carsten: One global limit: 1152 (max size of CoAP message), big number, but ~ 270 Matthias: We should have the general mechanism for larger options instead of a special one just for Proxy-Uri. Carsten: protocol design 101: policy (small messages) vs. mechanism (encode length). Nailing down policy in mechanism loses. Leaving in an artificial limit because we like small messages loses. Zach: Yes, but there should be a limit. Carsten: We need per option limits on lengths of the option, not a limit on the mechanism itself Zach notes a problem of parsing elective options that are longer than an end-point can parse. Do we need support for options up to length aprox 1034 ? Discussion is concatenating Proxy-URI options vs one Proxy-URI with longer length. (Discussion about parsing cut-up option vs. just passing around a pointer into the buffer; about generating Proxy-Uris with variable-length components that then need to be cut up at unrelated points.) Zach Proposal: Go with the any URI can use the longer length encoding method. Proxy URI will limit less than 1023. Carsten: make the max option length (e.g., 1034) different from from the max length we choose for Proxy-Uri (e.g., 1023), because the former is not the reason for the latter. Bert proposal: can we use 2 bytes for length extension, 64K option size? Carsten: Hard to put the bits for controlling this somewhere. Cullen: concatenating Proxy-URI options seems to be ok. (Could lose the fixed boundaries.) Matthias: don't break compatibility with the rest of the Internet... Zach: let's do Matthias' proposal, which people have had time to look at, limit it to 1034, and limit Proxy-Uri to 1023. (Without 1034 limit, it becomes harder to ignore elective options.) Cullen: can live with Zach's proposal (No objections.) -> Conclusion: write up Zach's proposal (strawman text) & check on list [Note: Google Maps for example has URLs > 270] #213 Path/Query options minimum length (protocol defect minor) ok #214 Adopt vendor-defined option into core-coap (protocol enhancement minor) Cullen: why can't the vendor just go to IANA and get a (option) number? Expect IESG/IETF pushback on a vendor-defined option. (Discussion about liberating policy for option number registry.) Cullen: We should have an experimental code point. Carsten: This is reserving 14 for this, and providing a mechanism minimizing the probability of a collision. See TCP options... Joe Touch has made essentially the same proposal. (Discussion about HTTP X- and SIP P- options. We don't want their problems.) Carsten: We have IETF review, as there is a very limited set of option numbers that are "good" (reachable). (Confusion with the media type registry, which is more relaxed: 1 or 2 bytes; we kept the 1-byte case for ourselves.) No consensus yet for vendor option as proposed in coap-misc. -> Cullen will post an alternate proposal to the list. #218 Mostly obvious section 5.10.8 fixes (other technical minor) ok #222 RawPublicKey identifier (protocol enhancement minor) Carsten: This proposal introduces a dependency on the [draft-ni], which is not even a WG draft yet. Let's make that decision consciously. Cullen: That draft might be done before CoAP... Zach: the other options are worse. -> Ok, best way forward it seems. #228 Proxying of multicast requests (protocol enhancement minor) Zach: would rather do multicast in groupcomm draft, not here. Carsten: we should say something about it (editorial ticket), and leave the details for groupcomm draft. -> Collect multicast-related information into one section, without anticipating groupcomm. Define meaning of group address in URI first; do details of proxying in groupcomm. -> Also to do: Clarify here that mcast group = mcast IP address. #229 Move sections 10-10.2. out of the "Security Considerations" (editorial minor) ok (Carsten: The ~ 21st of Ari's great editorial comments -- we won't make tickets out of all of them.) #232 Clarify inclusion of Location options in a 2.01 (Created) response (editorial minor) Change is ok. Discussion on the level of the requirement SHOULD, MAY or MUST. Carsten: Quality of Implementation SHOULD? Cullen: HTTP servers often don't return the location. -> MAY seems best for sending 2.01; the text in 5.9.1.1 seems fine otherwise. #233 Response codes with payload inconsistency (editorial trivial) ok #239 Always reserve option delta 15 (other technical minor) Carsten: Burden on the receiver to distinguish the two cases; most implementers have told me they won't send it either; so let's rule it out. ok -- discuss (30 min) #201 Clarify use of retransmission window for duplicate detection (editorial minor) Carsten: This is the basis for message ID reuse rules. Come up with a small set of numbers, just like TCP fixed up a MSL. Carsten made a proposal of 256 seconds. Everyone seems to agree that there should be a number. Discussion on the range of window length. Cullen: <= 256. Zach: < 256. (Nobody thinks a higher number is needed.) What is the minimum number? Carsten: for retransmission, current spec puts value around 60 sec (calculate from protocol constants). -> Action Point Carsten: clarify on the ML, the 3 different numbers (conceptually) that are relevant here. Then (Zach?) propose a number. #215 editorial issues around Congestion Control (editorial major) Carsten: there's additional info, Michael Scharf remarked why we don't follow the UDP protocol guidelines of RFC5405 (BCP). Separate two issues: 1. We should follow established IETF procedure (TCP-friendly). 2. Can we solve the research problem of being friendly to large limited-bandwidth network; probably not. Action point Cullen: proposals for how the congestion control should work; very hard problem, we are unlikely to get it completely right. Action point: Carsten does the ticket (editorial work); later we see if that can work. #230 Multiple Location options need to be processed as a unit (protocol defect minor) There is text in coap-misc-16 section 6 that people need to read before we can discuss this in further detail. * Wrap-up, planning (15 min) 17:15Z..17:30Z Make blocks of completed/obvious tickets that are going to be put into action; define resolution; confirm on ML. Use interims to discuss tickets that need discussion; about every 2-3 weeks. Next interim: June 4. around 13:30Z [actual: 13:00Z..15:00Z] ------------------------------------------------------- Items we didn't get to: -- tickets with a clear way forward (optional) (5 min) #207 Add advice on default values for critical options (editorial minor) #212 Option numbers 14, 28, 42, ... reserved but usable (editorial minor) #224 Clarify the concept of end-point (editorial major) #216 IANA: get Multicast addresses (other technical major) #226 Clarify which language addresses intermediaries in general vs. forward proxies specifically (other technical major) -- tickets that need more work on the mailing list (2 min) #231 Splitting/combining Location options (other technical minor) #238 Proxy terminology (editorial minor) * Block (9 min) 16:28Z..16:37Z -- check defined resolution and go ahead (6) #203 Restrict the potential combinations of Block1 and Block2 (protocol defect major) #210 Disentangle Block and Token (protocol defect major) #211 Signal provisional responses (atomic Block1) in the response code (protocol defect major) -- discuss (0) -- tickets with a clear way forward (optional) (3) #206 Clarify that atomic Block1 transfers match per token *and* endpoint (editorial major) #205 Clarify that Size does not modify the request semantics beyond adding the size information (editorial minor) #209 Add potential attacks to security considerations (editorial minor) -- tickets that need more work on the mailing list * Non-tickets (38 min) 16:37Z..17:15Z What do we want to do here, *if* we really have that time? Link-Format?