Minutes IETF115: core
minutes-115-core-00
| Meeting Minutes | Constrained RESTful Environments (core) WG | |
|---|---|---|
| Date and time | 2022-11-07 13:00 | |
| Title | Minutes IETF115: core | |
| State | Active | |
| Other versions | markdown | |
| Last updated | 2022-11-24 |
IETF 115 — Agenda for Constrained RESTful Environments (CoRE) WG
[toc]
Chairs (core-chairs@ietf.org):
- Marco Tiloca (marco dot tiloca at ri dot se)
- Jaime Jiménez (jaime at iki dot fi)
- Carsten Bormann (cabo at tzi dot org)
Date and time: Monday, 7th of November 2022, 13:00 – 15:00 UTC
Meeting material: https://datatracker.ietf.org/meeting/115/session/core
Notes: https://notes.ietf.org/notes-ietf-115-core
Meetecho video stream:
https://meetings.conf.meetecho.com/ietf115/?group=core&short=core&item=1
Meetecho for onsite participants:
https://meetings.conf.meetecho.com/onsite115/?group=core&short=core&item=1
Audio stream: https://mp3.conf.meetecho.com/ietf115/core/1.m3u
Jabber: xmpp:core@jabber.ietf.org?join
Zulip stream: https://zulip.ietf.org/#narrow/stream/21-core
Minute takers: Bilhanan Silverajan, Rikard Höglund, Christian Amsüss,
Jaime Jiménez
Jabber scribe: Jaime Jiménez, Marco Tiloca
Monday, November 7, 2022
13:00 – 15:00 UTC
Numbers in parentheses are minutes of time allocated.
Intro, agenda, status (Chairs) (10)
- WG and document status
Presented slides:
https://datatracker.ietf.org/meeting/115/materials/slides-115-core-chairs-slides-01.pdf
MT presenting introduction and note well. Preliminaries done and agenda
accepted.
(Marco presenting slides with document status)
MT: RFC 9290 has been published (Concise problem Details for Constrained
Application Protocol (CoAP) APIs).
CB: HTTPbis RFC7807bis just finished IETF LC based on RFC 7807; its -bis
is completing only now so not the newest version used.
More general topic of dereferenceable identifiers and IANA is ongoing.
By the way, this contains Hebrew text, which slowed the publication
process significantly.
MT: draft-ietf-core-sid-19 is in IESG processing. AD followup coming.
Plan to discuss during the meeting week. It can be wrapped up soon.
MT: -core-comi, -yang-library and -oscore-groupcomm are waiting for
shepherd write-up; -conditional-attributes and -groupcomm-bis are in
WGLC; -dns-over-coap has been recently adopted; -groupcomm-proxy is
pending WG adoption call.
HREF (Carsten Bormann) (15)
Presented slides:
https://datatracker.ietf.org/meeting/115/materials/slides-115-core-href-cris-00.pdf
CB presenting
CB (p1): Now called CRIs ("href" is just draft name)
CB (p2): CRIs are an attempt to be concise with URIs. We have to build a
data model for URIs, and that's complicated, especially around dark
corners -- we don't care a lot, but we need to cover them in order to
make them first class citizens. CoAP(s) are easy though. CRIs are parsed
URIs (no need for URI parser anymore). It aims to use less bytes than a
URI.
CB (p3): One contribution to this conciseness is to have integer
representations as IDs for URI schemes.
CB (p4): The idea is to limit the points in time when the registration
of these scheme IDs can happen to: A) Initial pre-fill done by this
document; B) when a new URI scheme is registered. A wiki exists to
collect data for the initial pre-fill (see
http://github.com/core-wg/href/wiki/uri-schemes-that-we-want-numbers-for).
The question is whether this is the way to go or not.
CB (p5): During the Hackathon an idea came up, as the URI-scheme
registry already had a column added in the past (from RFC8615). So why
don't we add another column? Generally, we avoid impinging on someone
else's space, but in this case it may be alright.
FP (on chat): Or add a note to the IANA registry (and make sure IANA
asks the question) with a pointer to the new registry.
CB: Why having two tables if the information can go into one?
FP (on chat): The difference is that it would not be needed to change
the old registry, a note is less "invasive".
CB (p6): Remaining issues all have a resolution already in github and we
can use the next CoRE interim on November 23rd to finish this up.
CB (p7): Next steps are to discuss it at an interim on November 23rd.
Then submit version -12, do WGLC and profit from it.
Olle Johansson (on chat): For URI tests, check CURL blog
https://daniel.haxx.se/blog/2022/09/08/http-http-http-http-http-http-http/.
AK (on chat): It seems that the IANA registry is missing some (commonly
used?) schemes, like https://github.com/mqtt/mqtt.org/wiki/URI-Scheme
but perhaps here's a chance for more than one bird with one stone to
have such also in the URI registry.
CoRE Conditional Attributes (Bill Silverajan) (10)
Presented slides:
https://datatracker.ietf.org/meeting/115/materials/slides-115-core-conditional-attributes-for-constrained-restful-environments-00.pdf
BS presenting.
BS (p2): The current state is that the document has been in WGLC for a
while. We got a review from Marco. Issues have been opened based on this
review. 19 of them are now closed and 1 is still open.
BS (p3): Most issues were editorial. 1 was about changing a reference to
normative. Clarified draft talking about value changes and considering
state representations and changes. The still open issue requires a minor
code review.
BS (p4): We want to address the final issue. More reviews are welcome.
Should we request a review from the IoT directorate?
MT: I heard a person volunteered to review.
IR: Would be nice to have it reviewed by the IoT directorate. Please
send a request for it, I can review the document.
CoRE Target Attribute Registry (Carsten Bormann) (10)
Presented slides:
https://datatracker.ietf.org/meeting/115/materials/slides-115-core-target-attribute-registry-01.pdf
CB presenting.
CB (p1): The link-format has target attributes.
CB (p2): "rt" and "if" had registries for their values in RFC 6690, but
there is no registry for the attribute names as a whole. That was in the
spirit of RFC 5988 that does not attempt to coordinate the names of
attributes.
CB (p3): RFC8288 (i.e., 5988bis) says that serializations should
coordinate their attributes. So let's do that.
CB (p4): The idea is to add a sub-registry for Target Attributes, within
the CoRE Parameters registry. The registration policy will be "Expert
review", and specific instructions to the expert(s) are being defined.
These are: be frugal in allocation of very short names, "specification
desired", and allowed character set.
CB (p5): (Showing all the current pre-filled values)
CB (p5): Naturally, we put values from already published RFCs in the
pre-fill. We also have ongoing drafts, the plan for
draft-ietf-core-oscore-edhoc is to "race", and see which draft is
published first and thus can keep its registration text. As for
draft-tiloca-core-oscore-discovery, we intend to register the values
there.
MT: As per the allowed character set in page 4, we also have to replace
underscores with dashes. Both in the registrations and in the documents
triggering those.
CB: Yes (ABNF does not allow underscores).
ED: I support this draft. It's good to make the available to other
standards bodies. Regarding "Expert review", it is not a quick process.
CB: No good way for transparent sequence of messages between the expert,
IANA, the requester and other relevant parties.
ED: The request comes in and it is difficult to see if it was granted or
not. It's something to consider to be improved.
ED (on chat, after the meeting): This (seemingly) did not get acted upon
by the experts or IANA.
https://mailarchive.ietf.org/arch/msg/core-parameters/_Uk_7EMTIZF8qU0kp8tfSTNWIvU/
CA: Talking about target attributes (following RFC 8288). Should this
document state anything on the (registerable) target attributes'
semantics, precisely about whether these describe the link or the target
(in a link-independent fashion)? (If so, we can't reuse RFC 8288 as
defined in RFC 8288).
CB: I don't think we want to change RFC 8288.
CA: It would be about which attributes can be registered, not about
changing RFC 8288.
CB: Then it's my mistake to put 'title' under the heading of RFC 8288
(Web linking) in the slide.
CA: CoRAL will want to add a column for the mapping.
CB: Let's discuss this item later on (independently of the outcome of
this draft).
CA (on chat): About adding the column: I wouldn't hesitate to update
-target-attr in CoRAL; I might be hesitant to update RFC 3986 if I were
a CRI author.
CA (on chat): And on the topic of "it's surprising to see non-target
target attributes": That's why I've been behind CoRAL for some time, and
cursed RFC 6690 repeatedly :-)
CB (p6): This is still an individual draft. Next step is for WG
adoption, then WGLC and profit from it.
MT: I am open for adoption call soon. Any objections?
(none heard)
MT: We will start the WG Adoption Call this week.
Group OSCORE (Marco Tiloca) (15)
Presented slides:
https://datatracker.ietf.org/meeting/115/materials/slides-115-core-draft-ietf-core-oscore-groupcomm-00.pdf
MT presenting.
MT (p2): v-16 has been submitted, merging PR #98, which covers 4 things:
1) Improving response handling; 2) Downgrade MUST to SHOULD for using
the group mode to protect one-to-many requests; 3 & 4) Extended
editorials on security properties aligned in presentation style with
OSCORE, and features of the group mode inherited by the pairwise mode.
MT (p2): Early discussion with CA as document Shepherd. Appreciate
further comments from others.
MT: PR received very careful review from Rikard.
MT: Post cut-off open point about a possible new target attribute,
already discussed with Carsten in relation to -core-target-attr.
MT (p3): Use of group mode for one-to-many requests was a MUST, now it's
a SHOULD. A case in point as an exception is the case where a
deterministic request is sent to multiple servers at once (see
https://datatracker.ietf.org/doc/draft-amsuess-core-cachable-oscore/)
MT (p4): The handling of multiple responses from the same server needed
to be improved, as underspecified. This is due to text in
draft-ietf-core-groupcomm-bis that allows one server to respond multiple
times to a single multicast request, even if Observe is not involved.
The text in -groupcomm-bis was introduced and confirmed about 2 years
ago, and unchanged since.
MT (p5): Most things were okay already. The problem was for "multiple
non-notification responses" from the same server to the same group
request. Missing inclusion of PIV in responses following the first one
on the server side (thus causing AEAD nonce reuse). The client was not
performing ordering or replay check of responses.
MT (p6): That issue has now been fixed, using the same approach as is
taken for Observe notifications. Yet, the presentation of this approach
is separate and self-standing, since Observe is optional to support and
with its own terminology.
MT: New concept introduced "Non-notification group exchange": "exchange"
is used to mean an "Environment" (analogous to "Observation") associated
with one group request but tracking specifically the non-notification
responses. The server now MUST include its Partial IV in a response
(except the first one where it can be omitted). The client must enforce
replay checks and ordering of non-notification responses based on such
Partial IV values.
MT (p7): Further ancillary things needed to be defined beyond actual
message processing, but the same approach as for Observe could be taken
for those too.
CA: Didn't quite get why notifications need special handling compared to
other multiple responses (cf. core-responses which unifies the concepts)
MT: It's fundamentally the same handling, but presented as
self-standing. The idea was to keep Observe as a separate service
optional to support (as has been the case in OSCORE and Group OSCORE).
Alternatively, a true unification would require bigger restructuring and
can introduce confusion in the delta between Observe in OSCORE and
Observe in Group OSCORE.
CA: This feature is never negotiated right, so just a matter of
phrasing?
MT: Partly yes, uses slightly different terminology again to keep
Observe as a separate optional service. The reader can ignore parts
about Observe if not interested.
MT (post meeting): I didn't get the word "negotiation" during the
presentation. Indeed, this is not negotiated. It is just part of the
protocol and can boil down to phrasing.
CA: They would do same implementation as for Observe handling, to handle
the "non-notification group exchange"? I need to read document, but
seems like not a good idea to me. Even if it requires more editorial
work.
MT (post meeting): The idea was to keep two separate, logical
environments at least in the text. That's again in the interest of
keeping Observe a separate, optional service. From an implementation
point-of-view, if a client supports Observe, then almost all of the
client Observe code can be reused for this.
ED: You mentioned the server sending multiple responses. We wrote in
-groupcomm-bis that it can be a malicious server, or with a faulty
implementation or so? Do you consider a server that could send 2
responses (in a legitimate way)? For example because the resource
representation changes, and the server gives an "update", taking
advantage of the still active token.
MT: In groupcomm-bis, we considered the first things you mentioned, plus
a server that does not support message deduplication and receives a
group request that the client retransmits with the same Token and
message ID. But then the last examples you gave applies too.
ED: Not sure if the intent was to support a server sending multiple
responses, more like it may happen (duplicates messages). It seems that
the server should not willfully send multiple responses.
MT: On groupcomm-bis, it was totally left to the client application to
take a final decision on what to do with multiple responses. If they are
valid for the stack, the application must have received them.
ED: The client could also say "I am throwing away every 2nd and 3rd
response". The client may not want to process multiple responses for a
single request (for a specific Token).
MT: The stack at the client must be ready to have this happening. Group
OSCORE must support applications that are fine with multiple responses.
Then the application takes a final decision, whatever it is.
ED: I agree on checking for duplicates, but not sure about sending 2
non-duplicate responses on purpose as a server.
MT (post meeting): In order to check for duplicates in the stack, the
recent additions in Group OSCORE are required.
CA (on chat): Agree with what's being said: A client that doesn't expect
multiple responses will just consume the first only, and check whether
that's valid.
CA (on chat): Only if the client solicits multiple responses (by sending
Observe or whatever), it can opt in to the additional processing.
MT: To Christian's comment. The processing on the server side processing
is already general. It's really about adding a Partial IV to any
responses (with a possible exception for the first one), irrespective of
the response being a notification or not.
CA: There can be multiple ways a client solicits multiple responses (for
one request), so good to have a way of dealing with it.
MT: Yes this also comes up in other use cases.
MT: Can we expect more input on this from you Christian, i.e., text for
the draft or a Pull Request?
CA: I will provide some.
MT (p8): The OSCORE RFC defines the 'osc' target attribute (resource
ONLY accessible using OSCORE); of course it does not cover Group OSCORE.
So, we think of defining 'gosc', meaning a resource is accessible using
OSCORE and/or Group OSCORE. Rules in the interest of endpoints that
don't support Group OSCORE and 'gosc': If 'gosc' is specified, so must
'osc'. Endpoints not understanding 'gosc' ignore it anyway. 'gosc'
overshadows 'osc', which is ignored if 'gosc' is present.
MT: Any objections on defining 'gosc'?
(No comments against.)
MT: We'll define it and register it in the new registry proposed in
-core-target-attr.
MT (p9): Summarizing changes in v -16 based on PR #98. Plan to submit v
-17 with the target attribute 'gosc' defined; need to fix the response
handling based on the follow-up discussion. Then wait for Shepherd
review and write-up.
Profiling EDHOC for CoAP and OSCORE (Rikard Höglund) (10)
Presented slides:
https://datatracker.ietf.org/meeting/115/materials/slides-115-core-profiling-edhoc-for-coap-and-oscore-ietf-115-core-00.pdf
RH presenting.
RH (p2): Background slide providing recap of EDHOC and the optimized
request.
RH (p3): Updates since IETF 114. Version -05 submitted. IANA
considerations added, renewed the early registration of the EDHOC CoAP
Option number.
RH (p4): Moved performance considerations on using block-wise to an
Appendix. Expanded security considerations. More considerations on this
part for access control also added.
RH (p5): The target attributes that this document defines can be
registered in the new IANA registry defined in -core-target-attr.
Pre-fill the registry from Carsten's document with attributes from this
document. We may want to revise the names of these attributes to be
shorter and to start with a prefix suggesting that they are about EDHOC.
(No objections heard)
RH (p6): Proposal from David Navarro being tracked in the Github
repository to extend figure 1 by merging PR #7 (to add EDHOC
message_4). We plan to do this and also add a note clarifying below
that figure that EDHOC message 4 is optional.
(No objections heard)
RH (p7): The fundamental procedure of the optimized request and the
whole draft are stable; the document is aligned with the latest EDHOC v
-17. Proposal at this stage is to start Working Group Last Call.
Key Update for OSCORE - KUDOS (Rikard Höglund) (15)
Presented slides:
https://datatracker.ietf.org/meeting/115/materials/slides-115-core-key-update-for-oscore-kudos-ietf-115-core-00.pdf
RH presenting.
RH (p2): Recap. The draft contains 3 main parts: OSCORE Key Update
procedure (KUDOS); AEAD limit considerations; and OSCORE
Sender/Recipient ID update procedure.
RH (p3): Recapping how the KUDOS rekeying procedure works. Exchange of
nonces, built new Master Secret and Salt from that. Then new OSCORE
Security Context and OSCORE keys from that. The ID Context remains
unchanged.
RH (p4): Details of OSCORE flag bits have changed. Bit 15 indicates
KUDOS message, while now bit 0 instead of bit 1 is used for signaling a
second flag byte.
RH: Related to IANA considerations: defined meaning and registration of
flag bit 0; changed status of bit 1 from Reserved to Unassigned; defined
meaning and registration of flag bits 8, 16, ... 48.
RH: Plan to request soon for the registration of the flag bits 8, 16,
... 48, as extension bits.
RH (p5): Simplified method for the actual updating of the OSCORE
Security Context. This was discussed at a CoRE interim, and simplified
to not use EDHOC-KeyUpdate, but rather only one and simple method.
Hence, also no need to support EDHOC or be aware of its use. And no need
for "fallback" or negotiation if EDHOC-KeyUpdate is unavailable (e.g.,
since the EDHOC session is invalid).
RH (p6): Building on the above, the UpdateCtx function is also
generalized, and not locked to HKDF as key derivation function. It can
now support other possible future KDFs defined for OSCORE.
RH (p7): Defined ways that you can use EDHOC to signal support for
KUDOS. Defined EAD items for peers to signal each other for KUDOS
support and in which modes. The peers can indicate no KUDOS support,
only no-FS mode, or full (FS and no-FS) KUDOS support.
GS: Is it worth implementing this signaling in EDHOC? Is it necessary in
order to then use KUDOS?
RH: Even if you didn't have this signaling you could do a trial/error
approach to see if KUDOS works at all with the other peer. Or
trial-and-error for the FS mode first, and then for the no-FS mode if
need be. It is not something that KUDOS relies on. It is an extra
feature to gain pre-knowledge during an EDHOC execution, in case it is
happening anyway.
GS: There is a tradeoff between adding nice features and adding
complexities
RH: Agreed. Even if you support EDHOC, this signaling is not mandatory
to use.
RH (p8): Further updates from IETF 114. One is on avoid reusing the same
pair (AEAD nonce, key) in the client-initiated KUDOS. Clarify CAPABLE
and non-CAPABLE device support for KUDOS. (A CAPABLE device can store
information to disk, while a non-CAPABLE device cannot). A CAPABLE
device must support the FS mode and SHOULD support the no-FS mode. A
non-capable device MUST support the no-FS mode.
RH (p9): Related to the first point of the previous slide, there is an
open point for understanding Partial IV in responses. In the
client-initiated version of KUDOS, in Response 1 the server must include
its Partial IV, otherwise there is (AEAD nonce, key) reuse.
Fundamentally this is because of switching contexts between unprotected
requests and responses protection.
CA: Good thing to do to send Partial IV again.
RH: Agree, including the Partial IV is an easy fix.
RH: For now, this is an ad-hoc fix for the client-initiated version of
KUDOS. However, we plan to make the fix more general, and applicable to
any case where a response is protected with an OSCORE Security Context
different than the one used to protected the request.
(No objections heard)
CA (chat-only): To detail why I don't think that this is just "an ad-hoc
fix": I keep saying that you MUST ONLY EVER send a response on the
piggy-back nonce if you just removed that number from that replay window
for the key you're responding with. (Admittedly, that last detail I'm
only adding since reading this...).
RH (p10): Question to bring out is whether the document structure should
be split out into separate WG documents? Benefit of doing this split is
to have the document focused on KUDOS only, instead of on 3 separate
topics. For now we suggest splitting out the part about the AEAD limits,
and perhaps later on also the part about Sender/Recipient ID update once
it's completed.
RH (p11): Main next steps: Work on open points. General considerations
on when to include Partial IV in responses. Consider feedback from Rafa
Marin-Lopez on soft vs. hard limits. Work on the section about updating
OSCORE Sender/Recipient IDs.
MT: Is the conclusion of the splitting following the idea of slide 10 as
is?
CB: Yes.
GS: Good proposal to split out the part on the AEAD limits.
CB: Experience with a student group: They looked into a draft and RFC
page sizes, and decided to implement the smallest one. So let's try not
to create documents that appear more complex than they need to be.
MT: So we'll split out the part on AEAD limits as a separate WG
document; a possible split of the part on OSCORE IDs update will be
considered later on.
DNS over CoAP (Martine Lenders) (15)
Presented slides:
https://datatracker.ietf.org/meeting/115/materials/slides-115-core-dns-over-coap-doc-dns-messages-in-cbor-01.pdf
ML presenting.
ML (p3): Motive: We want to perform encryption of DNS messages.
ML (p4): DNS over CoAP (DoC) would give such encryption possibility, and
also block-wise support. Take advantage of the CoAP retransmission
mechanism.
ML (p5): Got feedback from DNSOP. (Slide covering feedback and
responses)
ML (p6): Next steps. For DoC: Address feedback, pick ID for
application/dns-message Content-Format. For DNS in constrained networks
guidance: see https://datatracker.ietf.org/doc/draft-lenders-dns-cns/ .
Is there value in this guidance?
CA: I recommend for the server to place a lookup resource at /.
ML: I agree.
BSch: It is possible to bootstrap a DNS over CoAP connection without
explicitly defining a path.
CB: If we can emulate DoH, that's fine. It is important to be reminded
that constrained discovery often will be on the RD and we can indicate
the path in that case.
CB: One possible outcome is that servers using RD discovery they'd use
any path; for those with a more limited discovery they're stuck with the
empty path.
ED: We could reserve a .well-known resource for this. I've seen that in
other WGs that you can then skip discovery (and the discovery takes a
round-trip). It's not that many bytes. I'm not sure that we can assume
that after getting an IP and port you can always assume it's at /.
(Maybe we can, see in the ANIMA WG; you discover an IP and port there).
ML: We also have the content format in there, but maybe that's not a
good idea. In our evaluation, we used /dns but that's 4 bytes.
ED: At least consider .well-known. A server can easily support multiple
ones.
(JJ: wondering why a content format is a bad idea?)
(CA: because it starts multiplexing based on something that's already
used for multiplexing extensions; like, if a future format is just
"CoRAL" or "JSON", whom will it go to?)
DNS messages in CBOR (Martine Lenders) (10)
Presented slides:
https://datatracker.ietf.org/meeting/115/materials/slides-115-core-dns-over-coap-doc-dns-messages-in-cbor-01.pdf
ML presenting (p9 of combined slide set).
ML: The drawback of DNS in constrained networks is that packet size
exceeds the PDU size, leading to fragmentation. We can reduce packet
size by using CBOR encoding and omitting redundant fields in DNS queries
and responses.
(Showing defined structure for DNS queries, DNS resource records, DNS
response in CDDL.)
ML: The basic example shows a compression rate of 400% for query. A more
complex example gives 305.9% for ANY query, but around 100% for the
response.
ML: Our proposal is to do Name and Address compression using Packed
CBOR. This improves the compression rate. Using global compression
contexts may improve things further. Is it worth it?
ML: Why not using SCHC? It assumes exchange of rules and thus an
established connection, which is usually not present for a DNS
Client->DNS Server.
ML: Next steps are to define more details on using Packed CBOR, e.g.,
the construction of the packing table and global compression contexts.
(JJ: Wondering if they use similar compression in DoH and why yes/no?)
(CA: When you're in HTTP you don't care so much about saving 50 bytes)
(JJ: per request! it is a big saving, no? does it put extra burden on
the DNS processing maybe?)
(CA: Not sure it's really a big saving. It's a packet either way, and
going into a HTTP request with headers, so it's diminishing. But on CoAP
and 6LoWPAN it's the difference between one or two packets.)
(JJ: IDK, it sounds like it could also be beneficial in DoH but I get
the point.)
BSch: There have been many attempts to re-phrasing DNS; DNSOP was
generally not friendly with these proposals. Go there first. Biggest
concern generally: About ossification -- if a new format cannot express
later messages losslessly, it's ossifying (creating devices that appear
to do DNS but actually do a subset). Generally, I don't see value. DNS
messages are almost always tiny fraction of the total bandwidth; saving
50% off DNS messages is not measurable in aggregate.
ML: I tend to disagree as it is not such little traffic.
ED: Normal DNS format has packing integrated; you can use it or not, but
it's all the same format, so it might be easier to handle. So it's
nothing that needs to be negotiated. The sender can decide to compress
or not, the receiver can restore.
ML: The idea is that the client might not support packed CBOR. So it's
negotiated.
ED: On laptop, running simulated DNS-SD nodes. Be aware of that use
case.
BSch (on chat): If clients signal which formats they support, the extra
bytes for that signal will eat into the savings from the compression.
CB: ad Ben: If you look at the percentage of DNS traffic, the total gain
is limited. But as in ML's first slides, environments with limited PDU
sizes have cost for using larger packets beyond a few bytes. The problem
is that you're using DNS in recovery from network failure, which is when
everyone else does it, and the network is impaired. If then the
adaptation layer starts fragmenting, performance drops. This creates the
boundary of ~80 bytes.
ML: What you can see also in the slide is that larger packets also
create more overhead due to the 6lowpan headers and we tried to avoid
this.
BSch: If you try to stay within these limits, a more appealing path is
to not provide a general-purpose representation, but instead to define a
very simple service ("name to IP").
ML: We also need to support DNS-SD, not just IP addresses but also other
records.
BSch: even then, look into API specifically for that use case.
CA (on chat): +1 on BSch's "not replace general purpose DNS but special
case"
MW: Why arguing against the compression of DNS messages?
BSch: I think that there is a cost and adding new things with small
benefits is a bad path forward. Specifically in this case, there are
alternative representations of DNS messages, for example in JSON.
Standardizing that is different as it hampers evolvability. Much space
can be saved when information is discarded, but discarding DNS
information is a sticky area.
CB: We have already the Resource Discovery service, so we don't need a
new one.
ED: What I work with is a Thread mesh (6lo based). Not too constrained
(still 2.4GHz, large band usage, no duty cycle limits; others are more
constrained). We use normal DNS and DNS-SD for registration and
querying. It already has some compression, and it's not much traffic in
total. Don't know if systems so constrained they use a single frame
would use DNS-SD at all. Maybe then there is no requirement to do all of
DNS.
AOB
MT: Interim meetings are scheduled. The interim on November 23rd can
focus on core-href, -core-target-attr and any further discussion on DNS
CBOR. The interim on December 7th can focus on -core-sid. After that, we
resume on January 18th.
Clapping.
FP: Went through CoRE errata. 10 reported, see
https://www.rfc-editor.org/errata_search.php?rec_status=2&wg_acronym=core&presentation=table.
Looking for agreement in the WG that they are treated correctly. I will
send a mail shortly.
Mail available at:
https://mailarchive.ietf.org/arch/msg/core/0VM6waLVW1v3B9ghF0EmUBeZZ3E/
Flextime (10)
Σ 120