Skip to main content

Minutes for CORE at IETF-interim-2010-core-1
minutes-interim-2010-core-1-00

Meeting Minutes Constrained RESTful Environments (core) WG
Date and time 2010-08-25 07:00
Title Minutes for CORE at IETF-interim-2010-core-1
State Active
Other versions plain text
Last updated 2011-12-02

minutes-interim-2010-core-1-00
2010-08-15 CoRE Webex meeting
nominally 15-17 UTC (with some Webex glitches, running later)

Chairs: Cullen Jennings and Carsten Bormann
Recording massaged into minutes by Carsten Bormann.

Agenda (all times are nominal UTC)

15:00 Webex wrangling, Agenda, Status
15:10 1 – core CoAP                             ZS
15:20 1 – Subscription option (-observe)        KH
15:25 1 – Block option (-block)                 CB
15:35 1 – coap-misc                             CB
15:55 1 – Sleeping Nodes                        AR
16:10 2 – Bootstrap approach                    BS
16:25 1/2 – CoAP Usage                          PV
16:40 Planning
17:00 End of call

At 15:55, people on the conference call were:
Carsten Bormann (CB),
Akbar Rahman (AR),
Angelo Castellani (AC),
Behcet Sarikaya (BS),
Colin O'Flynn (CO),
Dale Seed (DSe),
Don Sturek (DSt),
Edward Hill (EH),
Gilman Tolle (GT),
Guang Lu (GL),
Jonathan Hui (JH),
Kerry Lynn (KL),
Klaus Hartke (KH),
Markus Becker (MB),
Paul Duffy (PD),
Peter Bigot (PB),
Ralph Droms (RD),
Rene Struik (RS),
Robert Moskowitz (RGM),
Zach Shelby (ZS),
Cullen Jennings (CJ)

---------------------------------

Slides are at:

       http://www.ietf.org/proceedings/78/slides/core-1.pdf

(Times are nominal UCT:)

15:00 Webex wrangling, Agenda, Status

CB welcomes the participants and introduces the agenda (slides 1-5).

15:10 1 – core CoAP                             ZS

While ZS fights with Webex, CB starts introducing the tickets
(slide 8).

ZS takes over:
   #6 -- we don't really have a date option, so let's drop that.
   #18, #19 just some improvements on the text (see ML)
   #20 -- virtual server capability, little controversy
   #21 -- ZS to work with Mark Nottingham (who was nice enough to
          volunteer to help) to write that
   #22 -- work needed, input expected from RS
   #23 -- virtual server capability: needs discussion (w/ CB,
          Peter(?)); accommodate that without forcing all devices to
          have that capability
   #24 -- needs discussion; CB suggested solution; finish this on the
          list.

ZS: Summary: We need to work on security, and fix the Uri-Authority.
    Asks for comments -- none.

(Slide 9):

ZS: divide functions between core coap (coap-02) and block, observe.
    Maastricht also had discussion about link-format; Mark suggested
    to define that as a MIME-type in a separate draft.  Makes sense to
    separate that out as well.
    Asks for comments and concerns.
CB: Summary: Split, and for each of the new documents we'll need to
    decide whether these become WG documents.  Asks for comments about
    the number of documents.
RD: What is the concern -- too many, too few?
CB: Avoid a SIP-like situation with hundreds of documents.
    Separate out things that might change on different time scales.

15:20 1 – Subscription option (-observe)        KH

(Slides 10...20, not discussed in detail)
CB: draft-hartke-coap-observe resubmitted yesterday; cut it down to
    half the size by removing rationale that probably was excessive.
    Ready for adoption as WG document?
KL: Curious whether there is time pressure to do that now?
CB: What do we gain by deferring?
KL: More time to digest.
CB: We'll verify on the mailing list anyway?
KL: So here we decide what to ask online?
CB: All decisions in a meeting need to be verified on the ML.
CJ: So, should we ask on the ML, should we adopt it?
AR: I'm in favor, I think it is ready.
ZS: I definitely think is is ready for WG document, some work needs to
    be done, good start.
CJ: Who wants to do substantial work on this document?
    -> A few people in favor, no objections. Take it to the list.

15:25 1 – Block option (-block)                 CB

(Slides 21...24, not discussed in detail)
CB: The other document that was split off:
    draft-bormann-core-coap-block.
    More or less required for larger items.
    We have some interop results.  Critical option.
    No other proposals how to solve this.
KL: Concern, not sure whether that is addressed: Non-idempotent
    requests such as POST; cf. Appletalk Transaction Protocol; I
    didn't get the promised draft done.
CB: More difficult to do for POST; if you want to do a POST, you have
    to reassemble the whole representation before atomically acting on
    that; no way around that; needs Token option to disambiguate
    multiple concurrent POST transactions.  The final interaction
    triggers the non-idempotent work.
KL: You would also need to understand at the server end whether the
    reply is lost, the client would need to retry, and the transaction
    layer would need to respond with the same reply (and not pass the
    request to the application layer again).
CB: Matter of implementation, but there is a transaction ID to make
    sure you are not executing the request twice.
KL: So my question is: If we want to implement a RESTful protocol;
    it seems to be necessary for POST to support non-idempotent
    operations; include that in the main document.
CB: This may be a comment on the core document; this may need more
    text on non-idempotent operations; little intersection with -block.
ZS: Kerry, we do need more text in the main document, let's fix that
    in coap-02.
KL: If we have options at the transaction layer; do we have multiple
    options or do we fit everything into into one?
CB: ???
KL: Could support non-idempotent operations by adding a bit; seems
    wasteful.
CB: We have a request code that tells you PUT/POST/GET, so you already
    know whether this is idempotent.
??: Slightly different option than we had before.
KL: Yes
CB: Did not see a need to separate out these options; all options are
    different in some way; that one dimension of difference is maybe
    not more interesting than the other ones.
KL: I'll try to get a draft out, for three issues at the transaction
    layer:
    1) larger than MTU
    2) idempotent vs. non-idempotent
    3) adjustment of transaction timers
CJ: Thanks.  When?
KL: By Monday.

15:35 1 – coap-misc                             CB

(Time is running late: 3645)
CB: coap-misc is next on the agenda.  Maybe it is worth discussing
    KL's point first before we go into details of coap-misc.
CB: Except for one: (Introduces proposed Duration Type, slide 27).
    Feedback from implementers that it may be too complicated, so I
    provided code that shows it is not complicated at all.
PB: Anti-complexity: Not closed under subtraction; the value I get may
    not be correct.  A simple integer is more correct.
CB: You still have to round to one second.
PB: I'm not concerned with a second; but with the larger rounding errors.
CB: Do you have an example where that matters?
PB: 0xCF and 0xDF have a two-hour time difference.
CB: Round down?
PB: Repeatedly asking rounds down each time?
CB: You wouldn't do that again on every request -- this is a wire
    format, not the internal representation.
PB: If I ask again, I lose 6 hours.
CB: This is for life-times etc., you never will squeeze out the last
    second. The imprecision is -12.5 %.
PB: Variable length integer should be straightforward.
CB: Agreed, not much more code.
    Let's discuss this on the list.

(Slide 29..32 not discussed in detail)
CB: Some more options in coap-misc that are for the taking if they are
    needed.  Let's move on.

15:55 1 – Sleeping Nodes                        AR

(Slide 34)
AR: (Slide 35): Three requirements: Req 3, sleeping nodes; Req 4:
    caching for sleeping nodes; Req 9: multicast
    Some more work needs to be done.
    (Slide 36): use-case with a sleeping node 1; node 1 and proxy will
    need to exchange sleep schedule.  If node 1 asks for data from
    node 2 (proxied via HTTP), node 1 may sleep while the HTTP
    transfer happens.  Proxy will only send out the response back to
    node 1 once that wakes up again.  This works if node 1 and proxy
    exchange sleep schedule.
    (Slide 37): similar case, again useful for a proxy to know the
    sleep schedule of a node that it is trying to proxy a request to.
    This would need something like a long-pool or a retry-after on the
    HTTP side.
    (Slide 38): In what format should the sleep schedule be, and how
    should the nodes synchronize?  Cf. 802.15.4e.
CB: That would be nice because CoAP would not have to do anything --
    but proxy and node 1 may not be neighbors, so they don't share an
    802.15.4e relationship to share information.  There is some
    cross-layer thing going on; we can't completely solve this in
    CoAP.
AR: Agree.
    (Slide 39): Multicast.  Scenario: HTTP to CoAP proxy; if a single
    HTTP request is going out per multicast on the CoAP side:
    (Slide 40): What do the URIs on the HTTP side look like?
    How to relay back multiple responses to the HTTP side?
    vs. Congestion Control (Lars' document)?
    What about sleeping nodes?
    (Slide 41): Conclusion 1: If the proxy node has an updated
    schedule, it can optimize by buffering requests/responses.
    (Slide 42): Conclusion 2: It is not clear how to map a unicast
    HTTP request to a multicast request/set of responses in CoAP.
    (Slide 43): If WG agrees, we can move from problem statement to
    detailed solutions.
KL: I was co-author with Peter Vanderstok.  Questions that appear
    separate turn out to be interrelated.  Sleeping nodes interact
    with buffering proxies.  Assumption that sleeping nodes wake up on
    a schedule may not hold.  I would prefer to see multicast to move
    to a separate document; even though multicast interrelates with URIs.
AR: Multicast in a separate document makes a lot of sense.
    Re synchronous assumptions: That was one scenario; sleep schedule
    could change; we don't want to preclude that; point is valid.
KL: Opportunity to look at this in terms of proxying information.
    Does the proxy ever respond right away?
AR: In our draft we have one scenario.
KL: We need to resist designing solutions for every single problem
    before examining how they might be related.  E.g., consider the
    problem deciding which proxy might be able to answer in place for a
    sleeping node.
AR: What documents should be written to handle this.
KL: I guess I'm neutral on that.
ZS: Most of my comments are in line with Kerry's; we should spend some
    time to scope what we do want to solve.  Multicast: Maybe start
    with the more basic problems (i.e., between nodes in the same
    network).
AR: OK, two documents, one for multicast, describe problems some more.
ZS: Way to explore the different scenarios.  We could come up with a
    huge number of problems that might be nice to solve.
CB: When you split off the multicast document, think in terms of group
    communication and not just multicast -- some group communications
    requirements might map to multicast, some others to the way
    proxies work.
KL: Even group addressing has implications all the way into REST.
    There is no concept in REST of a group address...
CJ: (Need to wrap up.)
AR: Thank, I think I understand all the recommendations.

16:10 2 – Bootstrap approach                    BS

CJ: Time: 20 minutes left -- in the call -- stay another 1/2 hour?
(Multiple:) Yes.
CJ: Stay relatively in time with the next two items.

(Slide 45...)
BS: Colin is the main editor
    (Slide 47:) Overview
    (Slide 48:) What is bootstrapping: box of nodes to functioning network
    (Slide 49:) What is it not (service/resource discovery)
    (Slide 50:) Problems
    (Slide 51:) Existing Solutions
    (Slide 52/53/54:) Proposed Architecture; different sequences of
    key establishment; bootstrap protocol: actual messages for
    bootstrapping.
    (Slide 55:) Charter says security bootstrapping, bootstrapping
    requires input from other layers than just CoAP.
    (Slide 56:) Next steps: Get input from other groups, e.g. ZigBee.
    So this should not be a Proposed Standard, but maybe an
    architecture document (informational).  Feedback?
CB: back to Slide 45: The charter actually says what we need to do.
BS: very relevant to our draft.
RS: In the charter it mentions, universal method for joining nodes
    together, but we also need state transitions during the life
    cycle; one may need to do bootstrapping more than once during the
    life cycle.  How do we want to fit bootstrapping into the whole
    CoRE effort?
CJ: As a chair, my feeling is that obviously the bootstrapping is
    somewhat intertwined with the security; these are hard topics that
    I wish we made more progress on -- long-term impact on our
    schedule.  What do we need to do next to make progress?
BS: comment on current draft, direction from chairs
CJ: Informational/BCP; I can provide some generic advice when we use
    these things.  An architecture document would typically be
    informational...
BS: We would need to change charter...
CJ: change the milestone.  If you can't implement the mechanism
    document without referring to the architecture, the latter needs
    to be PS.  Netconf is the example for that.
    Figure out what to do and then chairs figure out what to do.
    Changing milestones is easy, changing substance of charter is much
    harder.
BS: Are we on the right track?
CJ: This is mostly a technical question. Process-wise, we are OK, if
    the technical direction is OK.
    Any comments -- none.
RS: One more note: On the charter it says one mandatory universal
    method; but this may impose a constraint on the device.  In an
    application domain, people may want to disable it...
CJ: BCP 61(?): it is mandatory to implement a reasonably strong
    security mechanism for an IETF protocol.
    It would be OK to say "Servers have to do A and B, clients have to
    do A or B", but the point is that we should be able to interop.
CB: We have to move on.

16:25 1/2 – CoAP Usage                          PV

(Slide 58: 9030)
KL: Peter couldn't be here; I'll try to speak to the high points.
    Bring forward some building automation use cases, so we aren't
    just driven by smart grid.
    (Slide 59:) Speak to groups of nodes simultaneously; series of
    unicast messages, but in some applications like lighting control,
    there is a concept of synchrony.
    Scheme+URI is involved in service discovery.
    Naming authority could apply to group of nodes.  A or AAAA record
    could reference a multicast address.
    (Slide 60:) sending PUT to a number of nodes, reducing number of
    packets
    (Slide 61:) group of nodes
    (Slide 62:) BACnet, LONtalk; could have phased introduction of
    CoAP: e.g., PUT an application/DALI message to a light.
    (Slide 63:) Size of URI; Path specifies resource; scheme +
    authority would represent a CoAP service access point; at the WG
    meeting last time Stuart Cheshire made a point of service access
    points potentially supporting multiple services; e.g. a print
    server with multiple queues; a host with multiple sensors.
    What is the notion of a device?
    Is there a one-to-one correspondence between devices and hosts?
    There could be many virtual devices per physical device.
    (Slide 64:) Batteryless devices; this is a stake in the ground:
    Controller nodes should not necessarily be sleeping devices (PUT
    to sleeping device might be out of scope)
    (Slide 65:) Peter would like to see something along the line of
    reliable multicast, but there may be multiple ways to get that.
CB: Useful to separate in our mind group addressing from multicast as
    a mechanism (vs. distributed agreement protocols).  Multicast is
    just a way to get efficient transfer for group addressing.
KL: Peter has identified at least one situation where he needs
    multicast: Simultaneous transfer to a group of nodes.
    Of course, multicasting is not supported in HTTP.  From a REST
    standpoint, a multicast request is equivalent to multiple unicast
    requests. Obviously, a lot more discussion is needed.
CB: I like that this draft is grounded in real-world applications.
    We need these reality checks, with actual buildings and actual
    light switches.  Go on designing a system with CoAP in mind and
    see which features are missing.
KL: I am also participating in BACnet/IP working group.  We are
    examining how to move BACnet to a native IP approach (as opposed
    to tunneling).  I want to make them more aware of what CoAP is
    doing and v.v. -- not saying that they necessarily need to converge.
CJ: Would you we willing to write email back and forth to BACnet and
    to us -- being more aware would be good.
KL: Sure.  I gave a presentation at last BACnet meeting about CoAP.
CJ: Really helpful, thank you.


16:40 Planning

CB: Do we want to do this again?
    (Slide 67:) My proposal ...
AR: Very useful, I like the proposal.
KL: I agree.  How frequently
CB: My proposal was approximately once a month.
    More frequently?
    Less frequently?
KL: Monthly is about right.
    Three meetings between every WG.
??: One more before Beijing.
CJ: Let's check the rules.
    Try running them monthly.
    We are heavily biased by just asking everybody who came here :-)
PB: one month is good.
CB: So, one month it is.
    The documents progressing in parallel is good way forward; we
    should see new versions within the next couple of weeks.
    Anything else re planning?  -- no.
    Thank you for this meeting

17:00 End of call

(All times are nominal UTC, actual was about 0.5 h later.)