Minutes for CORE at interim-2012-core-1
minutes-interim-2012-core-1-1
| Meeting Minutes | Constrained RESTful Environments (core) WG | |
|---|---|---|
| Title | Minutes for CORE at interim-2012-core-1 | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2012-05-25 |
minutes-interim-2012-core-1-1
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?