Minutes for CORE at IETF-91
minutes-91-core-1
| Meeting Minutes | Constrained RESTful Environments (core) WG | |
|---|---|---|
| Date and time | 2014-11-12 19:00 | |
| Title | Minutes for CORE at IETF-91 | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2014-11-14 |
minutes-91-core-1
CoRE @ IETF91
Chairs:
Andrew Mcgregor <andrewmcgr@google.com>
Carsten Bormann <cabo@tzi.org>
Structured minutes: TO DO
______
Raw notes follow:
Notes taken by (insert your name here):
- Matthias Kovatsch
- René Hummen
- Andrew McGregor
- Dominique Barthel also (browser crashed)
- Michael Koster
TUESDAY, November 11, 2014
1520-1720 Afternoon Session II
Coral 2 APP *** core Constrained RESTful Environments WG
** Intro, Status etc. (3 min)
15:20-15:30 Intro
Note-Well, Blue Sheets, Scribes, etc.
Agenda bashing
WG Status:
- Published: RFC 7390 (was draft-ietf-core-groupcomm-25)
- @IESG (AD evaluation): draft-ietf-core-observe-15
- Last Call to do: draft-ietf-core-block-16
- Charter work needed to resume
draft-ietf-core-resource-directory - Milestones
** WG docs: HTTP-CoAP Mapping (Presenter: Akbar)
15:30-15:45 HTTP mapping
draft-ietf-core-http-mapping-05 (15 min)
- since IETF90, addressed Tickets #366, #375 and comment from
Yusuke - Focus on reverse cross-proxy - Ticket #366 -> CoRE
Link Format: By default no
payload mapping; mapped Link Format could be provided at
the proxy's /.well-known/core resource
- Ticket #375 -> Diagnostic messages: ?
- Comments: Transcoding might lose schema inlined in EXI/XML
Q&A:
Carsten: Link mapping is hard and not new
Specific problem:
Content-Type/-Encoding string vs Content-Format
ID can become a problem when endpoints evolve
but proxy does not
Klaus has ongoing experiment where he
automatically scans IANA registry and generates
CF IDs; maybe IANA can do this in the future?
What about new media types?
10000 media types already out there
what do we do with them?
Could define X-coap mappings
Need a round on the mailing list to discuss this
Running experiment to scal new mediatypes and build content-format
registry Can we ask IANA to run a tool or maintain translations?
Matthias: yes a mapping database would be useful (Background reading:
draft-castellani-core-advanced-http-mapping-04 (0 min))
Objective:
· Review solutions to Tickets #366, #375 and comment from
Yusuke (check) · Are we ready for WGLC? (still some open
issues(?)) Didn't I hear Carsten say "one more iteration on the
mailing list"?
** not yet WG docs: Resource Directory (Presenter: Zach Shelby)
15:45-16:25 Resource Directory (ZS)
draft-ietf-core-resource-directory-02* (40 min)
-- this draft missed the deadline
-- this draft is a WG document but outside the charter
Objective:
- Review -02 updates, in particular DNS-SD integration
- DNS-SD mapping is done
- several tickets closed
- Hypercat hypermedia catalog use case by Koster
- DDOS considerations added
- need advanced examples from the WG like storing other types
- Fixed registration update mechanism:
Getting more RESTlike with link registration and update (refresh)
- Binding EP names to certs
- missing 4.04 responses added for missing resources
- Change 63 byte EP name max to SHOULD in draft
- Using POST instead of PUT for registration update/refresh
and allowing link updates on refresh
- Future work: Advanced examples will be contributed by Matthias,
Peter - need >= 3 expert reviewers, at least one from OMA (Tim?)
Q&A:
Kepeng Li: EP identifier unique?
Zach: For RD, EP name is bound to the security
identifier; independent from IP, even protocol
(HTTP/CoAP)
Doesn't solve the problem of response coming from
different protocol binding vs. request
Kepeng: How to deal with conflicts?
Zach: If you are authorized, identity belongs to you and
all new registrations (not re-reg.) replace the existing
registration
without security, you can't even detect that multiple
devices use same EP ID
- Future work: Collection interface to manage the link
collection (per endpoint registered)
GET, add a link, replace a link, remove a link
Could use the management location returned in the
registration response as the collection resource
Don't invent a PATCH mechanism for CoAP in this draft,
stick to the goal at hand, collection of links (separate
draft but try to avoid needing it)
Matthias: Conflict error message 4.09 in OMA LWM2M, but
recommend not define 4.09 in -rd
Zach: way behind on IANA registration of codes, terms and media
types Peter VanDerStok: How do we do this charter upgrade?
Carsten: Create a new charter wait for tomorrow management
meeting Bert Greevenbosch: Synchronization with OMA? they only
implement part of RD Zach: this discussion is not part of that
question OMA used an early version, put into LWM2M 1.x Zach: OMA
spec diverges and defines a lot of stuff needed to be registered
w/IANA for example urn:oma:XXXX Should help this along Akbar R:
Recharter - include alt transports and other stuff Carsten: need
to discuss before making the proposal. CoAP over TCP, SMS, other
priorities Akbar: agree, we need to look at the overall set of
for the recharter Tim Carey: Building OneM2M to OMA LWM2M
interworking, may need to make sure there is backward compatible
operation to not break this interworking Look closely at what the
gaps are to insure a close integration. May need to take into
account in this draft, change things if needed Mathias K: how
many implementations already out there ? Zach: would say around
10. Mathias: not sure all correct, were some mistakes in 1.0,
already into backward compatibility Zach: Bring comments to OMA
Get all the input and do a full review Carsten: could have
deprecated features Matthias: One implementation replaced links
with PUT, which could recur if it's left in the spec as an option
Discussion about compatibility issues. is it already in
production? Zach states yes. Volunteers to review : Hannes T,
Yong-Geun Hong, Matthias K., Bert G., Akbar R., Simon Lemay
** related: "ACE for resource directory" (presenter: Bert
Greevenbosch) 16:25-16:45 Resource Directory (BG)
draft-greevenbosch-ace-resource-directory-00 (20 min)
Objective:
- Discuss how security could work for the RD
- Possibly derive input for ACE
The draft considers issues with auth access to RD and distills
Review of RD functionality registers links from resource
servers Architecture slide showing registration and
discovery
RD is also a CoAP server and endpoints are client role
Q&A:
Zach: What is the problem we're trying to solve? There is
already a way to authorize EP for registration ACE doesn't
try to solve that problem
Is it used to auth access after rd-lookup operation discovers
resource? Zach: Is this solving the unsolved device-to-device
resource access authorization problem after look-up in RD?
Bert: generic problem is auth a coap client to a coap server, Ace
solves this, could apply to RD operations as well as
resources themselves
Bert: ACE can do the authorization to register with an RD. Goal is to
find out if ACE will work for RD as well. However, RD is not
constrained and could do authentication on its on.
Zach: Rd is a server but has some unique propertiesand may have a
different auth
Hannes: Thought RD would be treated as classic client/server
interaction with an existing security relationship, would it
first interact with
Akbar: RD has unique properties, maybe like a search engine. Does
everyone who wants to use it need authorization?
Bert: Depends on the type of RD: open, public ones or closed,
e.g. building-specific RD. ACE can help to define who may
use the RD.
Requirements 5-7 for registration including delegating clients
REQ 8-10 for querying Rules and auth for part of the
endpoint collection to be authorized to some clients, not
others
René Hummen: Is this still about registration or about
look-up? Should ACE authorize queries to RD or be used to
authorize device-to-device communication subsequent to
look-up?
Zach: Problem is that this problem is very generic. We need
to understand how ACE works first. This could also be done
with ACLs. Keep in mind that RDs can also support HTTP
clients, which their own world ot authentication. For
example, resources may be auth as a group in some enterprise
envs
Bert: ACE does not have a ready solution but we can start to
figure out how it could work, basically as a use case.
Zach: More important to figure out how (to authorize)
accessing the resource will work after the look-up.
Carsten: My fault that this was presented here (as it is an
ACE use case), but this should be closely followed in this
WG. Thinking about the different kinds of authorization that
are required could help defining the RD itself.
Need to think about this clearly and build a clear model of how auth
works in these different situations around RD
Zach: Yes, but a lot of this is implementation-specific
(e.g., domain-based, endpoint-based). It goes too far to say
"you MUST use this to implement RD."
Keping Li: Interesting use case as a constrained client
contacts an unconstrained resource server (so far not
considered in ACE).
Dave Robin: Interesting use case as ACE matures, say 2 devices need to
communicate and have auth already, this RD should understand
what they already negotiated through a separate entity and
allow registration based on pre established trust
Dave Robin: Interesting for registering devices that the RD
has never seen before. E.g., via bearer token from ACE
telling RD, "you can trust this device"
Zach: Enterprise environments often have the need for AAA
servers, but there are many solutions and it is a bit early
to define something in this WG.
Tim Carey: there needs to be some way an EP can say who can
use it's resources and how, i.e. the authority may be with
the EP The point is threat the framework for this ought to be
in the draft. So implementations can use the framework.
Zach: this could take 4 years to specify, could be a rat
hole that takes a long time to sort out more sophisticated
auth patterns and methods.
Could for example specify use of ACLs that specify which
clients can access a resource, but maybe not the discovery
process itself. Should specify that RD is responsible for
managing resource Access but maybe not it's own internal
resources.
Dave Robin: maybe the rathole can be shallow. Ex, one concept could be
scope, could be obtained before attempting access as in
Oauth2. THe RD could give auth hints about scope, realm,
etc. that could prequalify a client.
Zach: OK, but... RFC6690 has link extension that anyone could define,
so it could be done in link relations
Matthias: It's also about device identity framework for the RD
registration interfaces (just pointers, not solutions)
Carsten: Don't want to forward RD draft until these issues are
resolved, need to understand basic reqs for RD auth before
going forward
** WG docs: Links-JSON (Chairs)
16:45-16:47 Links-JSON (chairs)
draft-ietf-core-links-json-02 (2 min)
-- we tabled this waiting for implementation experience.
Objective:
- Are we there yet?
Andrew: Is there any implementation experience.
Zach: Some but not specifically with this version. Don't see
any problems, since it is only a format.
We have an implementation but uses a different mapping
Bert:(missed the comment)
Barry Leiba channeling David via Jabber: questions about what resource
directory provides link quality, timeout
Zach: timestamp? there is a timeout (Koster: lifetime) but
not timestamps
Carsten (hat off): Why is the content-format (ct) a string
and not a number? is the only discussion we have ever had
about this. Can we have a last call?
Hum in favor
** WG docs: Core-Interfaces (chairs)
16:47-16:49 Core-Interfaces (chairs)
draft-ietf-core-interfaces-01 (2 min)
-- this draft is expired -- reason?
Objective:
- Status check
Carsten: What is needed? is it stable or does it need updating?
Zach: Lower priority draft, needs a little more work. LWM2M
URI template should be added as an alt resource design,
removing pmin, pmax
Carsten: who would review (5 incl. Carsten) who would edit?
Koster would add OMW LWM2M template
Zach low priority but things keep coming up
Carsten: not discarding, not accelerating, want to see an improvement
** Alternative Transports (Hannes Tschofenig) (due to OAuth conflict
on Wednesday) 16:49-17:04
draft-fossati-dtls-over-gsm-sms (15 min)
Hannes: Use case is secure CoAP messaging over SMS in M2M
deployments (requirement for end-to-end security pointed out
in STIR WG)
Challenges are latency and fragmentation (140 Byte payload
size) losing one TPDU requires retransmission of all in the
flight.
Timers need to be properly set, too short breaks and too long adds
latency Work in progress: PSK works with 4-6 T-PDUs (one per flight),
X.509 rarely works, takes minutes when it does Need feedback where
this work would fit best. It is not changing DTLS, only guidance.
Carsten: Good, needed work. Should be done in DICE. How does
CoRE represent the fact that DTLS is used over SMS -- UI
design!
Kepeng: CoAP-over-SMS solves security as well (should go in
there)? Best align this work
?: Why does X.509 rarely complete? Transmission or
computation time?
Hannes: No problem of computation. Transmission timers need
to be cranked up, which creates the minutes delay.
It seems to be the result of losing TPDUs and having to retransmit
flights Derek Atkins: Have you considered OpenPGP? Hannes: ?
...caching... problem is that 20 SMS are needed for a handshake
Akbar: What did the test do? SIM enabled? Hannes: Sending from device
to server, SIM card enabled Andrew McG (co-chair hat off): X.509
Latency is not fatal, not completing is. Can it be fixed through
better timer settings? Hannes: Yes... Good thing is that once the
process completes, the result is cached and can be reused for
resumption.
PSK works fine, X.509 didn't, PGP may be a good solution
** CoAP-PubSub (Michael Koster)
17:04-17:20
draft-koster-core-coap-pubsub-00
Moved to Wednesday: did not fit in the session time.
WEDNESDAY, November 12, 2014
0900-1130 Morning Session I
Kahili 1/2 APP *** core Constrained RESTful Environments WG
** Intro (3 min)
09:00-09:03
** 6TiSCH network management with CoAP (Thomas Watteyne)
Thomas provides quick intro to 6TiSCH. Communication between
meshed nodes occurs using a time/frequency schedule. This
scheduling needs to be installed in the network.
There usually is a PCE that computes the schedule and needs
to talk to each node to install it. We want to use a REST
interface, CoAP seems like a good choice.
We want the nodes to report on changing link quality of
other event, so restore will be convenient.
Not everybody should be allowed to mess with the schedule, so ACE is
of interest too. One 6Tisch describes the features that need to be
managed. Another draft describes the resource structure. Right now
have defined our own structure (using /6t path root), but might use
something already standardized elsewhere if appropriate. Seeking
advice on that. Zach: The resource design here is like what was
recommended in coap-resources, for ad-hoc. Where that doesn't work
is for widespread interoperability; in that case you need a very
well-understood format, because this will have to tie into network
management systems, etc. Leaves two options: comi, or OMA object
formats. Thomas: For sure, we'll look into this, we were doing this
because comi wasn't ready.
** CoRE Management: CoMI (Presenter: Peter Vanderstok)
09:02-09:45 CoMI (PV)
draft-vanderstok-core-comi-05
Objective:
- Is this starting to be viable?
- Decide on way forward
- use CoAP for management instead of SNMP to
save on stack size for devices already implementing CoAP
- replace from XML/EXI to JSON/CBOR (done last IETF)
- automated tranlation from SMI/YANG to RESTconf possible
- alignment with RESTconf
- Security via DTLS
Ari: relationship between CoMI and OMA Lightweight?
Zach: OMA Lightweight about device management not for
network management. Different purpose.
Tim: Concern -> need for two agents (device and network
management). However, main difference only in resources.
Zach: Very similar. Much code overlap for the two
agents. Similar encoding, security, etc.
Ari: subtle differences. Make them explicit in the draft!
Carsten: Need for modularity to cater to different scenarios.
- Designed for small resource names (hash of name string to number) ->
descriptions can be retrieved via /Moduri indirection
- Possibility to only query sub-hierarchies in YANG module
- Rehashing with different prefix in case of hash collision for
different resources on same device -> notify client about
added prefix during discovery
Zach: Don't try to support all encoding schemes possible.
- Discovery via /.well-known/core
Carsten: Need to extend charter to take on CoMI.
Who has read? -> 12
Who wants to review? -> 8
Who wants to implement? -> 6
Against? -> None
=> Consider draft in next charter update
6TiSCH-CoAP informal meeting in Rainbow 3pm this afternoon.
** Alternative Transports, continued
09:45-10:15
draft-silverajan-core-coap-alternative-transports-06
draft-savolainen-core-coap-websockets-02
draft-bormann-core-coap-tcp-01
draft-tschofenig-core-coap-tcp-tls-01
draft-becker-core-coap-sms-gprs-05
Objective:
- Decision making on TCP bikesheds
- Decide on way forward
Carsten presents the connection model, CoAP over TCP. one
assumption is that "observe" will only work over one same
TCP connection.
Zach: might be an issue to rely on a connection staying open
for days/weeks, pretty much renders this useless.
Carsten: ok, maybe negotiate first TCP connection, and have
connection identifier that re-identifies the CoAP session
for subsequent TCP connections.
Zach: actually TLS session might help.
Numbers of ways to do delimiting. But implementers
comfortable with fixed length. Efficient, makes delimiting
independent from parsing.
Discussed length of Length field. Picked 2 bytes, like UDP.
Zach: is 64KiB enough for everyone? What about 256KiB Flash
device and need to do firmware update?
Carsten/Zach: why not do block transfer? Does not want to.
Andrew: what are the practical use cases right now? block
solves the pb for extra uses
Carsten: Agrees that more discussion is required for length
field size.
Using CoAP over UDP, just want to do the same thing over TCP.
Take home point.
Last discussion was how to handle 4-byte header. No more
there. Saves 2 bits in bit filed. 2 bits could be used to
indicate 4-byte vs. 2-byte length field.
Two options for message encoding are shown. Could not come
up with convincing argument for either one over the other.
Zach: no strong opinion, but option b might confuse
people. It "feels like CoAP" but isn't CoAP.
Carsten: sounds like pretty good argument for option a.
Rendez-vous, URI: uri protocol would be coap+tcp,
opinion?. On TLS, uri would be coaps+tcp, not coap+tls.
Keep in mind TCP connections fully pipelined, implementation
has to handle the case of multiple requests in flight.
René: Close connection instead of RST in case of error would
have the same semantics as closing a TCP connection for
long-term CoAP connections.
Next step is to write this up and get feedback on the
mailing list. Since we had this discussion multiple times,
we should be able to fast-track this.
Remote presentation from Teemu/Bill (coap-alternative
transports) handled by Carsten
Globally all other transports. Agreed on coap+xxx// format.
Not a standards track document, merely informational for
people inside the WG working on alternative transport for
CoAP.
Who has read a recent version? 2. Of which, who thinks ready
for adoption? no hand
Who willing to review? 5 people (but I don't know them by name)
Kepeng : need to add to the charter first, like CoMI?
Carsten objects, thinks it's in the charter.
Zach: opinion that CoAP/transport is in charter.
Carsten: ok, will do charter check.
Andrew: TCP is in charter, not sure about others.
Barry: I think you can consider other transports in charter,
nobody is going to argue.
Carsten: will now ask for adoption on mailing list and proceed
Kepeng CoAP/SMS
presents changes from -03.
asks for adoption
Carsten: who wants this at all? do we have the parts to glue
this together?
Carsten: would like that DTLS over SMS and CoAP over SMS use
similar mechanisms. Have you had discussion with Hannes?
Kepeng: Not yet.
Zach: we need a binding in the spec. Because OMA does this,
we need a document that describes it.
Carsten: seems best thing would be to research this a little
more. SMS expertise concentrated in this WG, nice. Work
closely with DICE.
Zach (DICE chair): DICE not chartered to do this. Carsten:
could do the encoding here, and profile in DICE.
Zach: could be acceptable to specify a profile saying don't
use X.509 because it will never finish. (René: Talked to
Hannes after DICE meeting. X.509 most probably didn't finish
because of inappropriate timer values. Could potentially be
fixed. Needs further investigation.)
Carsten: WGLC went out yesterday at DICE. Catch it.
Before WG adoption here, need to define profile work in DICE.
** Avoiding responses to POST and PUT (Presenter: Abhijan
Bhattacharyya) 10:15-10:25 No-Response (AB)
draft-tcs-coap-no-response-option-07
Objectives:
· With the modifications in the most recent draft, is the
proposed option now the right way to solve the problem(s)?
- no new technical comments since Toronto meeting
- resolved token-reuse issue
Carsten: Who has read? 2
Who wants to review in WGLC? 2
** endpoint IDs (Presenter: Oliver Kleine)
10:25-10:45
draft-kleine-core-coap-endpoint-id-01
draft-li-core-coap-node-id-option-01
- problem: update notifications to observation request
cannot be correlated if server IP address has changed
- especially problematic for multicast
Akbar: so far not possible to combine observe with multicast
Ari: would DTLS help?
Oliver: NoSec mode used.
Zach: Safe to assume that security is used in a real-world
scenario. CoAP explicitly recommends DTLS with raw
public keys. You can assume existence of cryptographic
binding.
Oliver: Use case -> tracking of postal package does not require
security. Kepeng: But there is NoSec mode. Zach: NoSec mode is
isolated scenarios with L2 sec. Ari: Only applicable to NoSec
scenarios? Oliver: Yes. - presents stateless as well as stateful
solutions (introduce stable end-point ID) Carsten: What happens if
client ID changes? Especially, if
both client and server change their IP address
simultaneously (e.g., network renumbering)
Oliver: Solution focuses only on server IP changes.
draft-hong-core-coap-endpoint-unit-id-01 (presenter:
Yong-Geun Hong)
- didn't really get it. ?enable querying of multiple resources in one
CoAP message?
Carsten: Who has read any of the end-point drafts? 8
Who willing to review? 6
** patience (Kepeng Li)
10:45-10:55
draft-li-core-coap-patience-option-05
- presents patience option
Carsten: Read? 4
Review in WGLC? (Didn't hear)
Need this? 5
Carsten: What are the use cases?
?: Would like to see use cases as well. No time information available.
Kepeng: Already some considerations in the draft.
** CoAP Congestion Control (Presenter: Carles Gomez)
10:55-11:15
draft-bormann-core-cocoa-02 (20 min)
Objective:
· Discuss additional measurements
· Gauge progress
- presents experiment results of different RTO mechanisms for GPRS
links - CoCoA now publicly available for Californium Matthias: You
can try different RTO mechanisms in Californium. - back to
experiments Carsten: important question for CC: does it break
anything? Ari: where are clients in eval scenarios? Carles: behind
GPRS link. Ari: More complex if mixed scenario (also more CoAP
end-points on Ethernet network). Needs further
investigation.
- shows that all algorithms improve RTO in uncongested
scenario compared to default CoAP and similarly increase
RTO in case of congestions
- Results
- CoCoA typically improves on default CoAP
- too simplistic RTT-based approaches underperform
- TCP-oriented RTO approaches also outperform default CoAP
- CoCoA performs similar if slightly better than TCP-oriented RTO
approaches
- Call for implementation and evaluation + feedback for IETF 92
Zach: Important to get timeouts right. also across different transports.
Zach: how about constrained routers? server load? e.g. LWM2M
servers? how much better is this wrt standard CoAP.
Zach: supportive of this work. This is something this WG needs to do.
Ari: Important work. What about mixed scenarios with CoCoA and default
CoAP? Carles: Not yet considered. Ari: What about footprint and
run-time memory consumption of the different solutions? Carles: will
send implementation info (mem footprint, ...) to the mailing list.
Kepeng: in last IETF, some transport experts recommended to look at
existing work. How is this reflected in your draft? Carles: this RTO
algorithms response to these comments. Evaluated Linux ROT and Peak
Hopper wrt Basic RTO. They are considered state of the art. Cocoa is
performing at least as well as these. Carles: At next IETF, will show
similar results for 15.4 multi-hop networks, if possible. Carsten:
let's do the measurements and come back. Carsten: Clarification ->
Other algorithms will not be included in the draft as they seemingly do
not bring any extra benefit over CoCoA to the table.
** CoAP PubSub (Michael Koster)
used to be CoAP-MQ.
support for battery powered nodes, sleepy nodes, etc.
Work in progress is to simplify and clarify document.
uses Resource Directory to register PubSub endpoints, new attributes.
Topic creation is separate from endpoint registration.
Next steps: update draft to reflect consensus on the changes, work on security
model and considerations.
Carsten: Read: (Carsten didn't say)I saw maybe 8-10
Review: 6
Against: 0
?: Where is sleeping information kept?
Michael: Not stored anywhere. Maybe need to be managed. Probably in the
RD. Carsten: don't want to enter into discussion of sleepy node
mechanism again
here. Bring this to the mailing list.
?: terminology conflict. Producer/Consumer, not PubSub
Tim: Allow for topics?
Michael: topic are registered at endpoints
(René: thought he said that registration of topics was unclear how
to do)
** Flextime
11:15-11:30 Flextime
· Open Mike
Carsten: CoRE WG backlog?
Zach: compiled backlog list in wiki. Weights (level of
interest to WG) and goals (time to IESG). Some of this is
obvious, like some WG documents. Next, CoAP/TCP and RD,
even though not WG documents. Comi, JSON, senml need
work. co-authors of senml too busy, would need co-authors
No point in adding other low priority items to the list, there are
already many. What do people think? Is this useful? Other way of
doing it? Then we can talk about content.
Akbar: I find it useful, but no single team, different team. Works with that
as well? Zach: We have WG. So believes could work.
Ari: Good to make priorities explicit. Roughly agrees with the current items.
Zach: This is just a brain exercise. No commitment.
Matthias: good .. to get running code... implementation
experience... (how does this relates to backlog ????)
Kepeng: Add a generic "options" draft as low priority item.
Carsten:
Zach: we are now at the deployment phase. Multiple implementations
needed. High priority items should be deployed or at the verge of being
deployed. We don't need to wait for this to become RFC to implement.
Zahch: will see how to maintain this list. Help from the WG chairs?
Carsten: no official tool for the WG chair, but useful.
Carsten: Backlog is useful thing to have, but not binding as initiated by
chairs (at this point?). Still, good to have for overview.
11:36 adjourns