Skip to main content

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?