Question:
As planned in the last authors' meeting: et should become just one of the registrable endpoint attributes (registry is already being prepared as RD parameter registry, but needs some work) lookup should allow using any of those registered attributes lookup should define how endpoint attributes are used in resource lookups (after all, should be possible even though none of the resource links actually carry that attribute) This PR is not final as it is, but will track my branch as I'm assembling (and possibly rewriting/rebasing) commits for this change.
et is not used by Fairhair, but that should not influence the text, I think
The bulk of the announced changes is now in the pull request; I'll go through it one more time myself before I merge it into master. (I might still add a big reshuffling change to the lookup interface, because the text has grown in the past by always inserting paragraphs, and they're not necessarily in a logical overall sequence.)
NAME I only just now merged the current state of the branch into master, the rebuild just completed.
See-Also: Some of what could be the review of this PR has come up in URL
I don't see any reason to keep this section as pointed out during the last telco. When it is removed some examples i Registration update must be changed. The request GET /rd/4521 should change to GET /rd-lookup/ep?href=rd/4521
Apologies, that will not return the links of the endpoint The request GET /rd/4521 should change to GET /rd-lookup/res?ep=/rd/4521 or GET /rd-lookup/res?ep=node1 I am afraid we need to stay with ep name, difficult to use /rd/4521 as ep identifier.
The equivalent requests would be GET /rd-lookup/res?ep=node1 and GET /rd-lookup/res?href=/rd/4521 (where the link has neither the ep=node1 nor the href=/rd/4521 link parameter, but its registration does).
I think that we don't need the GET as long as there are no PATCHes (and I recently saw we don't even define PUT for the registration resource). The discussion has shown that this is one of the points where our understanding of resolved and unresolved addresses is tested: Can we have a resource whose content is "unresolved link-format" to operate on? Or do we need to resolve the links even in there, and any PATCH format would need to work semantically from a shared understanding of both the RD and the client? NAME you wanted to meditate on that; have you found deeper truth, or a path there?
This weird indeed: In my understanding this means return all link resource paths with ep name node1 and GET /rd-lookup/res?href=skins/larry/rd/4521 means return all link resource paths with href is skins/larry/rd/4521 and will be empty chrysn schreef op 2017-10-30 13:03:
returns resources that either have as their own link href, or are contained in an endpoint or group with that href. This was introduced in because we do not have (due to the extensibility of the link attributes and the lack of a definitive registry) a partition on attribute names that clearly states that one attribute can only be on a group, another only on an endpoint and a third only on a resource. Thus, we need to expect matches from either level -- and once we already have to do this, we can just as well do it with href because it's treated like any other attribute. IMO the alternatives to this would be either having registries set up to partition the names so every query parameter is clearly an endpoint, group or resource attribute (probably not going to happen with resource attributes, as requested and denied in RFC5988bis), or we'd need a more complex lookup language than RFC6690-style search -- something like so we could be explicit there. (See also URL )
Ok, you go faster than my shadow. As long as the text covers the example, and the intention is clear. I will need to read the finished text again. chrysn schreef op 2017-10-30 16:29:
(Moving some comments here from EMail to keep track:) [Peter] I thought we agreed to remove section 5.4.3, [Christian] I had that taken down as "we should think about it some more"; I do expect that interfact to only become useful when we have a way to patch it.
Given the current direction of lookup with construction of absolute URI, we can leave section 5.4.3 in
The "RD Parameters" subregistry is set up in the IANA considerations, but only referenced at the registration interface. The lookup interface allows lookup by parameters of the same names (and page and count are exclusively used for lookup), but doesn't make a reference to the iana-registry. Next steps (→CA): Add a reference to lookup interface description (and reviewing that text, decide on whether that does create linkage to any other existing registry).

the link-format payload to register. The endpoint MUST include the endpoint name and MAY include the <del> registration parameters d, lt, et and extra-attrs, in the POST request as per registration.  The context of the registration is taken from the requesting server's URI. </del> <ins> registration parameters d, lt and extra-attrs, in the POST request as per registration.  The context of the registration is taken from the requesting server's URI. </ins> The endpoints MUST be deleted after the expiration of their lifetime. Additional operations cannot be executed because no registration


Question:
As planned in the last authors' meeting: et should become just one of the registrable endpoint attributes (registry is already being prepared as RD parameter registry, but needs some work) lookup should allow using any of those registered attributes lookup should define how endpoint attributes are used in resource lookups (after all, should be possible even though none of the resource links actually carry that attribute) This PR is not final as it is, but will track my branch as I'm assembling (and possibly rewriting/rebasing) commits for this change.
et is not used by Fairhair, but that should not influence the text, I think
The bulk of the announced changes is now in the pull request; I'll go through it one more time myself before I merge it into master. (I might still add a big reshuffling change to the lookup interface, because the text has grown in the past by always inserting paragraphs, and they're not necessarily in a logical overall sequence.)
NAME I only just now merged the current state of the branch into master, the rebuild just completed.
See-Also: Some of what could be the review of this PR has come up in URL
I don't see any reason to keep this section as pointed out during the last telco. When it is removed some examples i Registration update must be changed. The request GET /rd/4521 should change to GET /rd-lookup/ep?href=rd/4521
Apologies, that will not return the links of the endpoint The request GET /rd/4521 should change to GET /rd-lookup/res?ep=/rd/4521 or GET /rd-lookup/res?ep=node1 I am afraid we need to stay with ep name, difficult to use /rd/4521 as ep identifier.
The equivalent requests would be GET /rd-lookup/res?ep=node1 and GET /rd-lookup/res?href=/rd/4521 (where the link has neither the ep=node1 nor the href=/rd/4521 link parameter, but its registration does).
I think that we don't need the GET as long as there are no PATCHes (and I recently saw we don't even define PUT for the registration resource). The discussion has shown that this is one of the points where our understanding of resolved and unresolved addresses is tested: Can we have a resource whose content is "unresolved link-format" to operate on? Or do we need to resolve the links even in there, and any PATCH format would need to work semantically from a shared understanding of both the RD and the client? NAME you wanted to meditate on that; have you found deeper truth, or a path there?
This weird indeed: In my understanding this means return all link resource paths with ep name node1 and GET /rd-lookup/res?href=skins/larry/rd/4521 means return all link resource paths with href is skins/larry/rd/4521 and will be empty chrysn schreef op 2017-10-30 13:03:
returns resources that either have as their own link href, or are contained in an endpoint or group with that href. This was introduced in because we do not have (due to the extensibility of the link attributes and the lack of a definitive registry) a partition on attribute names that clearly states that one attribute can only be on a group, another only on an endpoint and a third only on a resource. Thus, we need to expect matches from either level -- and once we already have to do this, we can just as well do it with href because it's treated like any other attribute. IMO the alternatives to this would be either having registries set up to partition the names so every query parameter is clearly an endpoint, group or resource attribute (probably not going to happen with resource attributes, as requested and denied in RFC5988bis), or we'd need a more complex lookup language than RFC6690-style search -- something like so we could be explicit there. (See also URL )
Ok, you go faster than my shadow. As long as the text covers the example, and the intention is clear. I will need to read the finished text again. chrysn schreef op 2017-10-30 16:29:
(Moving some comments here from EMail to keep track:) [Peter] I thought we agreed to remove section 5.4.3, [Christian] I had that taken down as "we should think about it some more"; I do expect that interfact to only become useful when we have a way to patch it.
Given the current direction of lookup with construction of absolute URI, we can leave section 5.4.3 in
The "RD Parameters" subregistry is set up in the IANA considerations, but only referenced at the registration interface. The lookup interface allows lookup by parameters of the same names (and page and count are exclusively used for lookup), but doesn't make a reference to the iana-registry. Next steps (→CA): Add a reference to lookup interface description (and reviewing that text, decide on whether that does create linkage to any other existing registry).

Endpoint and group lookups result in links to the selected registration resource and group resources.  Endpoint registration resources are annotated with their endpoint names (ep), domains (d, <del> if present), context (con), endpoint type (et, if present) and lifetime (lt, if present).  Additional endpoint attributes are added as link attributes to their endpoint link unless their specification says otherwise.  Group resources are annotated with their group names (gp), domain (d, if present) and multicast address (con, if present). </del> <ins> if present), context (con) and lifetime (lt, if present).  Additional endpoint attributes are added as link attributes to their endpoint link unless their specification says otherwise.  Group resources are annotated with their group names (gp), domain (d, if present) and multicast address (con, if present). </ins> While Endpoint Lookup does expose the registration resources, the RD does not need to make them accessible to clients.  Clients SHOULD NOT


Question:
As planned in the last authors' meeting: et should become just one of the registrable endpoint attributes (registry is already being prepared as RD parameter registry, but needs some work) lookup should allow using any of those registered attributes lookup should define how endpoint attributes are used in resource lookups (after all, should be possible even though none of the resource links actually carry that attribute) This PR is not final as it is, but will track my branch as I'm assembling (and possibly rewriting/rebasing) commits for this change.
et is not used by Fairhair, but that should not influence the text, I think
The bulk of the announced changes is now in the pull request; I'll go through it one more time myself before I merge it into master. (I might still add a big reshuffling change to the lookup interface, because the text has grown in the past by always inserting paragraphs, and they're not necessarily in a logical overall sequence.)
NAME I only just now merged the current state of the branch into master, the rebuild just completed.
See-Also: Some of what could be the review of this PR has come up in URL
I don't see any reason to keep this section as pointed out during the last telco. When it is removed some examples i Registration update must be changed. The request GET /rd/4521 should change to GET /rd-lookup/ep?href=rd/4521
Apologies, that will not return the links of the endpoint The request GET /rd/4521 should change to GET /rd-lookup/res?ep=/rd/4521 or GET /rd-lookup/res?ep=node1 I am afraid we need to stay with ep name, difficult to use /rd/4521 as ep identifier.
The equivalent requests would be GET /rd-lookup/res?ep=node1 and GET /rd-lookup/res?href=/rd/4521 (where the link has neither the ep=node1 nor the href=/rd/4521 link parameter, but its registration does).
I think that we don't need the GET as long as there are no PATCHes (and I recently saw we don't even define PUT for the registration resource). The discussion has shown that this is one of the points where our understanding of resolved and unresolved addresses is tested: Can we have a resource whose content is "unresolved link-format" to operate on? Or do we need to resolve the links even in there, and any PATCH format would need to work semantically from a shared understanding of both the RD and the client? NAME you wanted to meditate on that; have you found deeper truth, or a path there?
This weird indeed: In my understanding this means return all link resource paths with ep name node1 and GET /rd-lookup/res?href=skins/larry/rd/4521 means return all link resource paths with href is skins/larry/rd/4521 and will be empty chrysn schreef op 2017-10-30 13:03:
returns resources that either have as their own link href, or are contained in an endpoint or group with that href. This was introduced in because we do not have (due to the extensibility of the link attributes and the lack of a definitive registry) a partition on attribute names that clearly states that one attribute can only be on a group, another only on an endpoint and a third only on a resource. Thus, we need to expect matches from either level -- and once we already have to do this, we can just as well do it with href because it's treated like any other attribute. IMO the alternatives to this would be either having registries set up to partition the names so every query parameter is clearly an endpoint, group or resource attribute (probably not going to happen with resource attributes, as requested and denied in RFC5988bis), or we'd need a more complex lookup language than RFC6690-style search -- something like so we could be explicit there. (See also URL )
Ok, you go faster than my shadow. As long as the text covers the example, and the intention is clear. I will need to read the finished text again. chrysn schreef op 2017-10-30 16:29:
(Moving some comments here from EMail to keep track:) [Peter] I thought we agreed to remove section 5.4.3, [Christian] I had that taken down as "we should think about it some more"; I do expect that interfact to only become useful when we have a way to patch it.
Given the current direction of lookup with construction of absolute URI, we can leave section 5.4.3 in
The "RD Parameters" subregistry is set up in the IANA considerations, but only referenced at the registration interface. The lookup interface allows lookup by parameters of the same names (and page and count are exclusively used for lookup), but doesn't make a reference to the iana-registry. Next steps (→CA): Add a reference to lookup interface description (and reviewing that text, decide on whether that does create linkage to any other existing registry).

that the registry will receive between 5 and 50 registrations in total over the next years. <ins> 9.4. The Endpoint Type parameter is described as follows: An endpoint registering at an RD can describe itself with endpoint types, similar to how resources are described with Resource Types in RFC6690.  An endpoint type is expressed as a string, which can be either a URI or one of the values defined in the Endpoint Type subregistry; it SHOULD be shorter than 63 bytes.  Endpoint types can be passed in the "et" query parameter as part of extra-attrs at the Registration step, are shown on endpoint lookups using the "et" target attribute, and can be filtered for using "et" as a search criterion in resource and endpoint lookup.  Multiple endpoint types are given as separate query parameters or link attributes. Note that Endpoint Type differs from Resource Type in that it uses multiple attributes rather than space separated values.  As a result, Resource Directory implementations automatically support correct filtering in the lookup interfaces from the rules for unknown endpoint attributes. This specification establishes a new sub-registry under "CoRE Parameters" called "Endpoint Type".  The registry properties (required policy, requirements, template) are identical to those of the Resource Type parameters in RFC6690.  The registry is initially empty. </ins> 10. Two examples are presented: a Lighting Installation example in lt-ex


Question:
This allows registration without endpoint names, which is important for clients that only keep their absolutely essential cryptographic state (see URL, which this closes). The wording in simple registration was changed to not repeat the individual parameters of registration but to only refer there.
Currently, we prescribe that the registering endpoint needs to identify itself with at least an endpoint name, while we allow the RD to be configured to assign a domain based on its configuration. We could allow the endpoint identifier to be absent as well, at least in principle (eg. make it a "SHOULD be set" but no syntactical requirement on its presence), and the RD's configuration then would need to set an endpoint name (like it can now do with a domain), or the RD would refuse the registration like it can now do for unauthenticated hosts. (The RD interface right now doesn't allow a 4.01 Unauthorized response, even though the security considerations indicate that that can happen.) This would allow endpoints that have just enough persistent state to have their cryptographic identity in form of a PSK to register at the RD. Note that for those cases (and PSK seems not to be too uncommon in the CoRE security scenarios), the RD already needs to have received (or have a way to fetch) configuration about that key, which easily can contain a default (or the only permissible) endpoint name for that key. I'd write a pull request to that respect unless controversial discussion about this starts here. (This was fleshed out from in a discussion with Pekka Nikander during ACM ICN about very constrained devices).
First, domain is optional. The RD should not invent a domain for registrations that did not include a domain parameter. If the RD sets the endpoint name, then a client should be able to learn it from the registration resource, which will then depend on the implementation of read from the rd resource returning the registration parameters in the link for the registration resource, and/or the inclusion of a "self" link in the registration resource that includes "ep" as a link attribute.
Currently, we say that "When this parameter is elided, the RD MAY associate the endpoint with a configured default domain." (And it doesn't say that that default would be the absent domain). It'd need to learn it from the registration resource's metadata (because the registration resource contains right what the host posted, and a self-link would be semantically ambiguous there), but it can be looked up like that: POST /rd: ;rt="temp" Created, Location: /registration/42 GET /rd-lookup/ep?href=/registration/42 Content: ;con="coaps://your-address";ep="what-i-decided" I doubt that those nodes would be really interested in doing that (I reckon they'd even tend to do simple registrations which won't even tell them their registration resource), but they can. Best regards Christian
To add to my example, the client could just as well have asked to get the same result, although I'd recommend that a client in that situation should use the query instead. NAME would that lookup interface address your concerns? Unless not, I'd go ahead and write a patch that allows such behavior (but makes it clear that this can only be used where explicitly configured or allowed in a given setting).
The changes in implement the proposed. With many things now using registration resources rather than names (cf. ), I frankly don't see a reason to mandate names anywhere (Why would a group need a name? The operations don't require it, and we sure can store one if the user desires; same for the end point…), but I won't stir that any further (we should finish rather than starting such discussions; I'd be game for it, but milestones says hurry), as just allowing the name to be configured is sufficient for the ACM ICN use case.

RD registration URI (mandatory).  This is the location of the RD, as obtained from discovery. <del> Endpoint name (mandatory).  The endpoint name is an identifier that MUST be unique within a domain.  The maximum length of this parameter is 63 bytes. </del> <ins> Endpoint name (mostly mandatory).  The endpoint name is an identifier that MUST be unique within a domain.  The maximum length of this parameter is 63 bytes.  If the RD is configured to recognize the endpoint (eg. based on its security context), the endpoint can elide the endpoint name, and assign one based on the configuration. </ins> Domain (optional).  The domain to which this endpoint belongs. The maximum length of this parameter is 63 bytes.  When this


Question:
This allows registration without endpoint names, which is important for clients that only keep their absolutely essential cryptographic state (see URL, which this closes). The wording in simple registration was changed to not repeat the individual parameters of registration but to only refer there.
Currently, we prescribe that the registering endpoint needs to identify itself with at least an endpoint name, while we allow the RD to be configured to assign a domain based on its configuration. We could allow the endpoint identifier to be absent as well, at least in principle (eg. make it a "SHOULD be set" but no syntactical requirement on its presence), and the RD's configuration then would need to set an endpoint name (like it can now do with a domain), or the RD would refuse the registration like it can now do for unauthenticated hosts. (The RD interface right now doesn't allow a 4.01 Unauthorized response, even though the security considerations indicate that that can happen.) This would allow endpoints that have just enough persistent state to have their cryptographic identity in form of a PSK to register at the RD. Note that for those cases (and PSK seems not to be too uncommon in the CoRE security scenarios), the RD already needs to have received (or have a way to fetch) configuration about that key, which easily can contain a default (or the only permissible) endpoint name for that key. I'd write a pull request to that respect unless controversial discussion about this starts here. (This was fleshed out from in a discussion with Pekka Nikander during ACM ICN about very constrained devices).
First, domain is optional. The RD should not invent a domain for registrations that did not include a domain parameter. If the RD sets the endpoint name, then a client should be able to learn it from the registration resource, which will then depend on the implementation of read from the rd resource returning the registration parameters in the link for the registration resource, and/or the inclusion of a "self" link in the registration resource that includes "ep" as a link attribute.
Currently, we say that "When this parameter is elided, the RD MAY associate the endpoint with a configured default domain." (And it doesn't say that that default would be the absent domain). It'd need to learn it from the registration resource's metadata (because the registration resource contains right what the host posted, and a self-link would be semantically ambiguous there), but it can be looked up like that: POST /rd: ;rt="temp" Created, Location: /registration/42 GET /rd-lookup/ep?href=/registration/42 Content: ;con="coaps://your-address";ep="what-i-decided" I doubt that those nodes would be really interested in doing that (I reckon they'd even tend to do simple registrations which won't even tell them their registration resource), but they can. Best regards Christian
To add to my example, the client could just as well have asked to get the same result, although I'd recommend that a client in that situation should use the query instead. NAME would that lookup interface address your concerns? Unless not, I'd go ahead and write a patch that allows such behavior (but makes it clear that this can only be used where explicitly configured or allowed in a given setting).
The changes in implement the proposed. With many things now using registration resources rather than names (cf. ), I frankly don't see a reason to mandate names anywhere (Why would a group need a name? The operations don't require it, and we sure can store one if the user desires; same for the end point…), but I won't stir that any further (we should finish rather than starting such discussions; I'd be game for it, but milestones says hurry), as just allowing the name to be configured is sufficient for the ACM ICN use case.

requests at the requesting server's default discovery URI to obtain the link-format payload to register. <del> The endpoint MUST include the endpoint name and MAY include the registration parameters d, lt and extra-attrs, in the POST request as per registration.  The context of the registration is taken from the requesting server's URI. </del> <ins> The endpoint includes the same registration parameters in the POST request as it would per registration.  The context of the registration is taken from the requesting server's URI. </ins> The endpoints MUST be deleted after the expiration of their lifetime. Additional operations cannot be executed because no registration


Question:
From Stephane:
Shouldn't the CA / cert hierarchy be a point of control? For example, KZ is requiring users to install their CA, to allow them to MITM all traffic: URL Another example of CA abuse is ROA whacking, RPKI manipulation, etc.: URL
Also got this feedback from Will Scott:

Internet Backbone: If a censor controls the gateways into a region, they can filter undesirable traffic that is traveling into and out of the region by sniffing and mirroring at the relevant <del> exchange points.  Censorship at this point-of-control is most </del> <ins> exchange points.  Censorship at this point of control is most </ins> effective at controlling the flow of information between a region and the rest of the Internet, but is ineffective at identifying content traveling between the users within a region. Internet Service Providers: Internet Service Providers are perhaps <del> the most natural point-of-control.  They have a benefit of being </del> <ins> the most natural point of control.  They have a benefit of being </ins> easily enumerable by a censor paired with the ability to identify the regional and international traffic of all their users.  The censor's filtration mechanisms can be placed on an ISP via


Question:
From Stephane:
Shouldn't the CA / cert hierarchy be a point of control? For example, KZ is requiring users to install their CA, to allow them to MITM all traffic: URL Another example of CA abuse is ROA whacking, RPKI manipulation, etc.: URL
Also got this feedback from Will Scott:

than potentially excluding content, users, or uses of their service. <ins> Certificate Authorities: Authorities that issue cryptographically secured resources can be a significant point of control. Certificate Authorities that issue certificates to domain holders for TLS/HTTPS or Regional/Local Internet Registries that issue Route Origination Authorizations to BGP operators can be forced to issue rogue certificates that may allow compromises in confidentiatlity guarantees - allowing censorship software to engage in identification and interference where not possible before - or integrity degrees - allowing, for example, adversarial routing of traffic. </ins> At all levels of the network hierarchy, the filtration mechanisms used to detect undesirable traffic are essentially the same: a censor sniffs transmitting packets and identifies undesirable content, and


Question:
From Stephane:
Shouldn't the CA / cert hierarchy be a point of control? For example, KZ is requiring users to install their CA, to allow them to MITM all traffic: URL Another example of CA abuse is ROA whacking, RPKI manipulation, etc.: URL
Also got this feedback from Will Scott:

domain all other DNS servers will be unable to properly forward and cache the site.  Domain name registration is only really a risk where undesirable content is hosted on TLD controlled by the censoring <del> country, such as .cn or .ru Anderson-2011. </del> <ins> country, such as .cn or .ru Anderson-2011 or where legal processes in countries like the United States result in domain name seizures and/ or DNS redirection by the government Kopel-2013. </ins> 6.3.


Question:
NAME done; see change. P.S. GitHub lets you make suggestions using the little +/- icon in the inline comment UX :)
Pulling this conversation out of : It's clear that there's demand for error codes scoped to the API, without creating documentation pages for each code and linking to them in the field. There are many ways that implementers could do this, from linking to non-existent URLs to URNs to tags URIs, etc. It would be useful if the specification included examples of this, and made a clear recommendation for this case.
We (well, mostly NAME have made some good progress on the other issues raised out of but we haven't looked at this one yet. As strawman to get this moving, how about: we register a URN namespace id, and we recommend that non-dereferenceable URIs should be URNs using that, namespaced with an appropriate domain and raw type id, for example: . Would that work? It would give us a clear solution to recommend, which is explicit but easy to read, with minimal extra complexity or overhead for implementers (imo). I don't have examples, but I suspect there are other standards elsewhere that would appreciate having a problem id namespace for URNs as well. I don't love using a domain for namespacing a non-locator, but I think some namespacing is preferable, and I'm not sure what other namespaces would be suitable. Alternatives very welcome :smile:
We penciled in the URI prefix for registered types as "URL" in , but that was not finalised. I think registering one or more problems as exemplars is a good path forward for this and other issues (e.g., as discussed in ). We need to be very careful to set a good example in them, which means we need good candidates; I'm thinking 'JSON Validation Error' and 'XML Validation Error' might be appropriate (perhaps along with corresponding wellformedness errors). If we choose a urn, I suspect there will be considerable pressure to use or something similar, as per .
my understanding of the "urn:ietf:params" namespace is that it is meant to be used for parameters managed/defined by IETF specs. i think the original's suggestion intent was to have a "safe prefix" for a namespace which then would be "unmanaged" with some conventions around that, such as using domains names. i think the idea of giving examples (and even a suggested namespace along with conventions for using it) is a good one. that way we can clearly support both scenarios: if you're planning on making documentation available, use a resolvable URI but keep in mind that this best should be managed in a way so that it works for a good number of years. if you're planning on just identifying problem types, use a non-resolvable URI, and here's a recipe for doing it.
:+1: exactly I think is relevant in that it would be helpful to everybody if we can follow our own recommendations in our own problem id registry, but it's otherwise independent.
the difficulty may be that IETF has an institutional approach for managing parameters (urn:ietf:params:http-problems mentioned by NAME above), whereas most orgs minting problem types probably won't have one and won't create one. which may lead to us to saying three things about what kind of URI to use: check out common problem types registered under urn:ietf:params:http-problems and consider reusing one if it fits. use URIs when creating dereferencable problem type identifiers. when using non-dereferencable problem type identifiers be clear about that by using non-dereferencable URIs, and here's an URN-based recipe how to do that.
Ah, I see, ok. Yes, that makes sense, and given that the 3 part recommendation seems reasonable to me.
to be used for parameters managed/defined by IETF specs. No, it's for parameter name spaces managed by IETF documents -- which this would be. We could also give an example that uses a URI.
that's what i wanted to say. so these URIs/examples would just cover the common problem types that would be managed by the spec. which then would be for those other types that people/orgs are minting and where they say these are not resolvable, right? i think for those terry proposed a URN namespace instead of tag URIs, but either way it simply would help to state the use case ("your own types, not intended to be resolvable") and provide a recipe ("here's one way to do it"). the main point seems to be: the spec should mention both "common types" which may even get a registry, and "private types" which probably are using a different namespace, and we could suggest one pattern for doing that.

possible, and that when relative URIs are used, they include the full path (e.g., "/types/123"). <ins> The type URI can also be a non-resolvable URI.  For example, the tag URI scheme RFC4151 can be used to uniquely identify problem types: Non-resolvable URIs ought not be used when there is some future possibility that it might become desireable to do so.  For example, if the URI above were used in an API and later a tool was adopted that resolves type URIs to discover information about the error, taking advantage of that capability would require switching to a resolvable URI, thereby creating a new identity for the problem type and thus introducing a breaking change. </ins> 3.1.2. The "status" member is a JSON number indicating the HTTP status code


Question:
Tweaks to add the D values, explanations about D, etc.
We might want to check that the subsequent registries all have an appropriate value in the column.

Changed the registry policy to: <del> Updated the "Reference" to also refer to this document. </del> <ins> Updated the "Reference" to refer to this document instead of RFC8447. </ins> See expert-pool for additional information about the designated expert pool.


Question:
Tweaks to add the D values, explanations about D, etc.
We might want to check that the subsequent registries all have an appropriate value in the column.

Add a "Recommended" column with the contents as listed below. This table has been generated by marking Standards Track RFCs as <del> "Y" and all others as "N".  The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126. IESG Approval is REQUIRED for a Y->N transition. </del> <ins> "Y", "truncated_hmac" (4) and "connection_id (deprecated)" (53) as "D", and all others as "N".  The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126.  IESG Approval is REQUIRED for a Y->N, Y->D, and D->Y|N transitions. </ins> IANA [SHALL update/has added] the following notes: The extensions added by I-D.ietf-tls-rfc8446bis are omitted from the <del> above table; additionally, token_binding is omitted, since RFC8472 specifies the value of the "Recommended" column as for this extension. </del> <ins> above table.  Likewise, extensions defined after RFC8447 are also not listed in the table as those RFCs specify the value of the extension's "Recommended"; extensions points defined after RFC8447 include token_binding, compress_certificate, record_size_limit, pwd_protect, pwd_clear, password_salt, ticket_pinning, tls_cert_with_extern_psk, delegated_credentials, supported_ekt_ciphers, connection_id, external_id_hash, external_session_id, quic_transport_parameters, ticket_request, and dnssec_chain. </ins> I-D.ietf-tls-rfc8446bis also uses the TLS ExtensionType Values registry originally created in RFC4366.  The following text is from


Question:
Tweaks to future proof document.
Spencer had the following comment: I found the reference to MMUSIC WG in When a new codec is specified, and the SDP for the new codec is specified in the MMUSIC WG, no other standardization should be required for it to be possible to use that in the web browsers. to be odd. MMUSIC may be around forever, but this work might be refactored at some point in the future. Is the point that When SDP for a new codec is specified, no other standardization should be required for it to be used in the web browsers. Or is there another way to say this? I'm also wondering if the statement is true for any WebRTC endpoint, not just browsers.

gateway to convert between the signaling on the web side to the SIP signaling may be needed. <del> When a new codec is specified, and the SDP for the new codec is specified in the MMUSIC WG, no other standardization should be required for it to be possible to use that in the web browsers. Adding new codecs which might have new SDP parameters should not change the APIs between the browser and Javascript application. As soon as the browsers support the new codecs, old applications written before the codecs were specified should automatically be able to use the new codecs where appropriate with no changes to the JS applications. </del> <ins> When an SDP for a new codec is specified, no other standardization should be required for it to be possible to use that in the web browsers.  Adding new codecs which might have new SDP parameters should not change the APIs between the browser and Javascript application.  As soon as the browsers support the new codecs, old applications written before the codecs were specified should automatically be able to use the new codecs where appropriate with no changes to the JS applications. </ins> The particular choices made for WebRTC, and their implications for the API offered by a browser implementing WebRTC, are described in I-


Question:
From Ben Campbell's review:
Second point is fixed by . I'm not sure the third point is an improvement.
SSL is used exactly once, as part of the acronym "TURN/SSL". This is also the first mention of TURN, but the second was much more convenient to attach the expansion to. Given that it was so awkward to attach them, I included a new section listing the "used protocols" instead.

elements described. TCP RFC0793.  This is used for HTTP/WebSockets, as well as for <del> TURN/SSL and ICE-TCP. </del> <ins> TURN/TLS and ICE-TCP. </ins> For both protocols, IPv4 and IPv6 support is assumed.


Question:
From Ben Campbell's review:
Second point is fixed by . I'm not sure the third point is an improvement.
SSL is used exactly once, as part of the acronym "TURN/SSL". This is also the first mention of TURN, but the second was much more convenient to attach the expansion to. Given that it was so awkward to attach them, I included a new section listing the "used protocols" instead.

This specification does not assume that the implementation will have access to ICMP or raw IP. <ins> The following protocols may be used, but can be implemented by a WebRTC endpoint, and are therefore not defined as "system-provided interfaces": TURN - Traversal Using Relays Around NAT, STUN - Session Traversal Utilities for NAT, ICE - Interactive Connectivity Establishment, RFC5245 TLS - Trasnsport Layer Security, DTLS - Datagram Transport Layer Security, RFC6347. </ins> 3.2. Web applications running in a WebRTC browser MUST be able to utilize


Question:
As described in URL
In the Dallas presentation on “transports” you stated that the reference to proxy authentication would be restored (See URL) but it does not seem to have happened. This is an oversight. (Noted by Andy Hutton)

The WebRTC implementation MAY support accessing the Internet through an HTTP proxy.  If it does so, it MUST support the "connect" header <del> as specified in I-D.ietf-httpbis-tunnel-protocol. </del> <ins> as specified in I-D.ietf-httpbis-tunnel-protocol, and proxy authentication as described in Section 4.3.6 of RFC7231 and RFC7235 MUST also be supported. </ins> 3.5.


Question: I've found a few typos and fixed some sentences that didn't quite make sense. I don't think the meaning has been changed in any significant way.

4. <del> This section describes a typical RTCWeb session and shows how the </del> <ins> This section describes a typical WebRTC session and shows how the </ins> various security elements interact and what guarantees are provided to the user.  The example in this section is a "best case" scenario in which we provide the maximal amount of user authentication and


Question: I've found a few typos and fixed some sentences that didn't quite make sense. I don't think the meaning has been changed in any significant way.

the calling service via HTTPS and so know the origin with some level of confidence.  They also have accounts with some identity provider. This sort of identity service is becoming increasingly common in the <del> Web environment in technologies such (BrowserID, Federated Google Login, Facebook Connect, OAuth, OpenID, WebFinger), and is often provided as a side effect service of a user's ordinary accounts with some service.  In this example, we show Alice and Bob using a </del> <ins> Web environment (with technologies such as BrowserID, Federated Google Login, Facebook Connect, OAuth, OpenID, WebFinger), and is often provided as a side effect service of a user's ordinary accounts with some service.  In this example, we show Alice and Bob using a </ins> separate identity service, though the identity service may be the same entity as the calling service or there may be no identity service at all.


Question: I've found a few typos and fixed some sentences that didn't quite make sense. I don't think the meaning has been changed in any significant way.

freshness", i.e., allowing Alice to verify that Bob is still prepared to receive her communications so that Alice does not continue to send large traffic volumes to entities which went abruptly offline.  ICE <del> specifies periodic STUN keepalizes but only if media is not flowing. Because the consent issue is more difficult here, we require RTCWeb </del> <ins> specifies periodic STUN keepalives but only if media is not flowing. Because the consent issue is more difficult here, we require WebRTC </ins> implementations to periodically send keepalives.  As described in Section 5.3, these keepalives MUST be based on the consent freshness mechanism specified in I-D.muthu-behave-consent-freshness.  If a


Question: I've found a few typos and fixed some sentences that didn't quite make sense. I don't think the meaning has been changed in any significant way.

NOT be permitted to control the local ufrag and password, though it of course knows it. <del> While continuing consent is required, that ICE RFC5245; Section 10 keepalives STUN Binding Indications are one-way and therefore not sufficient.  The current WG consensus is to use ICE Binding Requests for continuing consent freshness.  ICE already requires that implementations respond to such requests, so this approach is maximally compatible.  A separate document will profile the ICE timers to be used; see I-D.muthu-behave-consent-freshness. </del> <ins> While continuing consent is required, the ICE RFC5245; Section 10 keepalives use STUN Binding Indications which are one-way and therefore not sufficient.  The current WG consensus is to use ICE Binding Requests for continuing consent freshness.  ICE already requires that implementations respond to such requests, so this approach is maximally compatible.  A separate document will profile the ICE timers to be used; see I-D.muthu-behave-consent-freshness. </ins> 5.4.


Question: I've found a few typos and fixed some sentences that didn't quite make sense. I don't think the meaning has been changed in any significant way.

5.6. In a number of cases, it is desirable for the endpoint (i.e., the <del> browser) to be able to directly identity the endpoint on the other side without trusting only the signaling service to which they are </del> <ins> browser) to be able to directly identify the endpoint on the other side without trusting the signaling service to which they are </ins> connected.  For instance, users may be making a call via a federated system where they wish to get direct authentication of the other side.  Alternately, they may be making a call on a site which they


Question: I've found a few typos and fixed some sentences that didn't quite make sense. I don't think the meaning has been changed in any significant way.

identity on a site they do trust (such as a social network.) Recently, a number of Web-based identity technologies (OAuth, <del> BrowserID, Facebook Connect), etc. have been developed.  While the </del> <ins> BrowserID, Facebook Connect etc.) have been developed.  While the </ins> details vary, what these technologies share is that they have a Web- based (i.e., HTTP/HTTPS) identity provider which attests to your identity.  For instance, if I have an account at example.org, I could


Question: I've found a few typos and fixed some sentences that didn't quite make sense. I don't think the meaning has been changed in any significant way.

The precise information from the signaling message that must be cryptographically bound to the user's identity and a mechanism for <del> carrying assertions in JSEP messages. sec.jsep-binding </del> <ins> carrying assertions in JSEP messages.  This is specified in sec.jsep-binding. </ins> The interface to the IdP. sec.protocol-details specifies a specific protocol mechanism which allows the use of any identity


Question: I've found a few typos and fixed some sentences that didn't quite make sense. I don't think the meaning has been changed in any significant way.

The specific IdP protocol which the IdP is using.  This is a completely opaque IdP-specific string, but allows an IdP to <del> implement two protocols in parallel.  This value may be the empty string. </del> <ins> implement multiple protocols in parallel.  This value may be the empty string. </ins> Each IdP MUST serve its initial entry page (i.e., the one loaded by the IdP proxy) from a RFC5785.  The well-known URI for an IdP proxy


Question: I've found a few typos and fixed some sentences that didn't quite make sense. I don't think the meaning has been changed in any significant way.

who have not implemented WebRTC at all, WebRTC implementations need to be more careful. <del> Consider the case of a call center which accepts calls via RTCWeb. </del> <ins> Consider the case of a call center which accepts calls via WebRTC. </ins> An attacker proxies the call center's front-end and arranges for multiple clients to initiate calls to the call center.  Note that this requires user consent in many cases but because the data channel


Question: I've found a few typos and fixed some sentences that didn't quite make sense. I don't think the meaning has been changed in any significant way.

6.4.1. Fundamentally, the IdP proxy is just a piece of HTML and JS loaded by <del> the browser, so nothing stops a Web attacker o from creating their own IFRAME, loading the IdP proxy HTML/JS, and requesting a signature.  In order to prevent this attack, we require that all signatures be tied to a specific origin ("rtcweb://...") which cannot be produced by content JavaScript.  Thus, while an attacker can instantiate the IdP proxy, they cannot send messages from an appropriate origin and so cannot create acceptable assertions.  I.e., the assertion request must have come from the browser.  This origin check is enforced on the relying party side, not on the authenticating party side.  The reason for this is to take the burden of knowing which origins are valid off of the IdP, thus making this mechanism extensible to other applications besides WebRTC.  The IdP simply needs to gather the origin information (from the posted message) and attach it to the assertion. </del> <ins> the browser, so nothing stops a Web attacker from creating their own IFRAME, loading the IdP proxy HTML/JS, and requesting a signature. In order to prevent this attack, we require that all signatures be tied to a specific origin ("rtcweb://...") which cannot be produced by content JavaScript.  Thus, while an attacker can instantiate the IdP proxy, they cannot send messages from an appropriate origin and so cannot create acceptable assertions.  I.e., the assertion request must have come from the browser.  This origin check is enforced on the relying party side, not on the authenticating party side.  The reason for this is to take the burden of knowing which origins are valid off of the IdP, thus making this mechanism extensible to other applications besides WebRTC.  The IdP simply needs to gather the origin information (from the posted message) and attach it to the assertion. </ins> Note that although this origin check is enforced on the RP side and not at the IdP, it is absolutely imperative that it be done.  The


Question: Pretty sure we'll get a GEN-ART reviewing say to not refer to the WG by name because it will get closed at some point. I basically stole the intro from overview and modified it slightly.

Abstract <del> The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for enabling real-time communications within user-agents using web technologies (commonly called "WebRTC").  This document defines the security architecture for WebRTC. </del> <ins> This document defines the security architecture for WebRTC, a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". </ins> 1.


Question:
As per Adam's comment, clarify that only the element() scheme of the XPointer Framework is supported (as that is the one that is required by RFC 7303).
LGTM

All SenML Records in a Pack MUST have the same version number.  This is typically done by adding a Base Version field to only the first <del> Record in the Pack. </del> <ins> Record in the Pack, or by using the default value. </ins> Systems reading one of the objects MUST check for the Version field. If this value is a version number larger than the version which the


Question:
As per Adam's comment, clarify that only the element() scheme of the XPointer Framework is supported (as that is the one that is required by RFC 7303).
LGTM

4.5.2. If the Record has no Unit, the Base Unit is used as the Unit.  Having <del> no Unit and no Base Unit is allowed. </del> <ins> no Unit and no Base Unit is allowed; any information that may be required about units applicable to the value then needs to be provided by the application context. </ins> 4.5.3.


Question:
As per Adam's comment, clarify that only the element() scheme of the XPointer Framework is supported (as that is the one that is required by RFC 7303).
LGTM

9.2. In addition to the SenML Fragment Identifiers described above, with <del> the XML and EXI SenML formats also the syntax defined in </del> <ins> the XML and EXI SenML formats also the syntax defined in the XPointer element() Scheme XPointerElement of the XPointer Framework </ins> XPointerFramework can be used.  (This is required by RFC7303 for media types using the "+xml" structured syntax suffix.  SenML allows this for the EXI formats as well for consistency.)


Question:
One possible way to address the problem with positive relative times
NAME Fixed
Looks like two of you are still working details of phrasing but I like where it is going and all looks about right to me.

Some devices have accurate time while others do not so SenML supports absolute and relative times.  Time is represented in floating point <del> as seconds.  Values greater than zero represent an absolute time relative to the Unix epoch (1970-01-01T00:00Z in UTC time) and the time is counted same way as the Portable Operating System Interface (POSIX) "seconds since the epoch" TIME_T.  Values of 0 or less represent a relative time in the past from the current time.  A simple sensor with no absolute wall clock time might take a </del> <ins> as seconds.  Values greater than or equal to 2*28 represent an absolute time relative to the Unix epoch.  Values less than 2*28 represent time relative to the current time. A simple sensor with no absolute wall clock time might take a </ins> measurement every second, batch up 60 of them, and then send the batch to a server.  It would include the relative time each measurement was made compared to the time the batch was sent in each


Question:
One possible way to address the problem with positive relative times
NAME Fixed
Looks like two of you are still working details of phrasing but I like where it is going and all looks about right to me.

All comparisons of text strings are performed byte-by-byte (and therefore necessarily case-sensitive). <ins> Where arithmetic is used, this specification uses the notation familiar from the programming language C, except that the operator "**" stands for exponentiation. </ins> 4. Each SenML Pack carries a single array that represents a set of


Question:
One possible way to address the problem with positive relative times
NAME Fixed
Looks like two of you are still working details of phrasing but I like where it is going and all looks about right to me.

If either the Base Time or Time value is missing, the missing field is considered to have a value of zero.  The Base Time and Time values <del> are added together to get the time of measurement.  A time of zero indicates that the sensor does not know the absolute time and the measurement was made roughly "now".  A negative value is used to indicate seconds in the past from roughly "now".  A positive value is used to indicate the number of seconds, excluding leap seconds, since the start of the year 1970 in UTC. </del> <ins> are added together to get the time of measurement. Values less than 268,435,456 (2*28) represent time relative to the current time.  That is, a time of zero indicates that the sensor does not know the absolute time and the measurement was made roughly "now".  A negative value indicates seconds in the past from roughly "now".  Positive values up to 2*28 indicate seconds in the future from "now".  Positive values can be used, e.g., for actuation use when the desired change should happen in the future but the sender or the receiver does not have accurate time available. Values greater than or equal to 2*28 represent an absolute time relative to the Unix epoch (1970-01-01T00:00Z in UTC time) and the time is counted same way as the Portable Operating System Interface (POSIX) "seconds since the epoch" . Therefore the smallest absolute time value that can be expressed (2*TIME_T28) is 1978-07-04 21:24:16 UTC. Because time values up to 2*28 are used for presenting time relative to "now" and Time and Base Time are added together, care must be taken to ensure that the sum does not inadvertently reach 2*28 (i.e., absolute time) when relative time was intended to be used. </ins> Obviously, "now"-referenced SenML records are only useful within a specific communication context (e.g., based on information on when


Question:
The link was missing from schema. After this is merged, all the example need to be regenerated.
Given we want the l to have a defined integer value in the CBOR table, I think a good approach is define the l attribute as a string here then say what goes in it in the other draft that defines link. This is also good for EXI.

A base value is added to the value found in an entry, similar to Base Time. <ins> A base sum is added to the sum found in an entry, similar to Base Time. </ins> Version number of media type format.  This attribute is an optional positive integer and defaults to 5 if not present.  [RFC Editor: change the default value to 10 when this specification is


Question:
The link was missing from schema. After this is merged, all the example need to be regenerated.
Given we want the l to have a defined integer value in the CBOR table, I think a good approach is define the l attribute as a string here then say what goes in it in the other draft that defines link. This is also good for EXI.

Base Unit is allowed. Value of the entry.  Optional if a Sum value is present, otherwise <del> required.  Values are represented using three basic data types, Floating point numbers ("v" field for "Value"), Booleans ("vb" for "Boolean Value"), Strings ("vs" for "String Value") and Binary Data ("vd" for "Data Value") .  Exactly one of these four fields MUST appear unless there is Sum field in which case it is allowed to have no Value field or to have "v" field. </del> <ins> required.  Values are represented using basic data types.  This specification defines floating point numbers ("v" field for "Value"), booleans ("vb" for "Boolean Value"), strings ("vs" for "String Value") and binary data ("vd" for "Data Value").  Exactly one value field MUST appear unless there is Sum field in which case it is allowed to have no Value field. </ins> Integrated sum of the values over time.  Optional.  This attribute is in the units specified in the Unit value multiplied by seconds.


Question:
The link was missing from schema. After this is merged, all the example need to be regenerated.
Given we want the l to have a defined integer value in the CBOR table, I think a good approach is define the l attribute as a string here then say what goes in it in the other draft that defines link. This is also good for EXI.

attributes to provide better information about the statistical properties of the measurement. <del> A SenML object is referred to as "expanded" if it does not contain any base values and has no relative times. </del> 4.4. <ins> Sometimes it is useful to be able to refer to a defined normalized format for SenML records.  This normalized format tends to get used for big data applications and intermediate forms when converting to other formats. A SenML Record is referred to as "resolved" if it does not contain any base values and has no relative times, but the the base values of the SenML Pack (if any) are applied to the Record.  That is, name and base name are concatenated, base time is added to the time of the Record, if Record did not contain Unit the Base Unit is applied to the record, etc.  In addition the records need to be in chronological order. TODO add example 4.5. </ins> SenML is designed to carry the minimum dynamic information about measurements, and for efficiency reasons does not carry significant static meta-data about the device, object or sensors.  Instead, it is


Question:
Fixes URL
This makes some of the examples very long. I preferred the presentation where all attributes of a Record are on a single line, when feasible. Especially for the "multiple data points" examples. Anyway, Michael's comment was about indentation, which I agree should be (and is now) fixed.
See email from Michael Koster "Formatting of JSON examples in SenML"


Question:
Fixes URL
This makes some of the examples very long. I preferred the presentation where all attributes of a Record are on a single line, when feasible. Especially for the "multiple data points" examples. Anyway, Michael's comment was about indentation, which I agree should be (and is now) fixed.
See email from Michael Koster "Formatting of JSON examples in SenML"


Question:
Fixes URL
This makes some of the examples very long. I preferred the presentation where all attributes of a Record are on a single line, when feasible. Especially for the "multiple data points" examples. Anyway, Michael's comment was about indentation, which I agree should be (and is now) fixed.
See email from Michael Koster "Formatting of JSON examples in SenML"

attributes to provide better information about the statistical properties of the measurement. <del> A SenML object is referred to as "expanded" if it does not contain any base values and has no relative times. </del> 4.4. <ins> Sometimes it is useful to be able to refer to a defined normalized format for SenML records.  This normalized format tends to get used for big data applications and intermediate forms when converting to other formats. A SenML Record is referred to as "resolved" if it does not contain any base values and has no relative times, but the the base values of the SenML Pack (if any) are applied to the Record.  That is, name and base name are concatenated, base time is added to the time of the Record, if Record did not contain Unit the Base Unit is applied to the record, etc.  In addition the records need to be in chronological order.  An example of this is show in resolved-ex. 4.5. </ins> SenML is designed to carry the minimum dynamic information about measurements, and for efficiency reasons does not carry significant static meta-data about the device, object or sensors.  Instead, it is


Question:
Fixes URL
This makes some of the examples very long. I preferred the presentation where all attributes of a Record are on a single line, when feasible. Especially for the "multiple data points" examples. Anyway, Michael's comment was about indentation, which I agree should be (and is now) fixed.
See email from Michael Koster "Formatting of JSON examples in SenML"

5.1. <del> TODO - Add example with string, data, boolean, and base value </del> 5.1.1. The following shows a temperature reading taken approximately "now"


Question:
Fixes URL
This makes some of the examples very long. I preferred the presentation where all attributes of a Record are on a single line, when feasible. Especially for the "multiple data points" examples. Anyway, Michael's comment was about indentation, which I agree should be (and is now) fixed.
See email from Michael Koster "Formatting of JSON examples in SenML"

5.1.4. <ins> The following shows the example from the previos section show in resolved format. 5.1.5. The following example shows a sensor that returns different data types. 5.1.6. </ins> The following example shows how to query one device that can provide multiple measurements.  The example assumes that a client has fetched information from a device at 2001:db8::2 by performing a GET


Question:
Set of small editorial tweaks and aligned fragment text with new way of positioning base values
LGTM ( other than we need to decide if we use field or attribute but we can do that as separate PR)

Characters in the String Value are encoded using a definite length text string (type 3).  Octets in the Data Value are encoded using <del> a definite length byte string (type 2) . </del> <ins> a definite length byte string (type 2). </ins> <del> For compactness, the CBOR representation uses integers for the map keys defined in tbl-cbor-labels.  This table is conclusive, i.e., there is no intention to define any additional integer map keys; any extensions will use string map keys.  This allows translators converting between CBOR and JSON representations to convert also all future labels without needing to update implementations. </del> <ins> For compactness, the CBOR representation uses integers for the labels, as defined in tbl-cbor-labels.  This table is conclusive, i.e., there is no intention to define any additional integer map keys; any extensions will use string map keys.  This allows translators converting between CBOR and JSON representations to convert also all future labels without needing to update implementations. </ins> For streaming SensML in CBOR representation, the array containing <del> the records SHOULD be an CBOR indefinite length array while for non streaming SenML, a definite length array MUST be used. </del> <ins> the records SHOULD be a CBOR indefinite length array while for non-streaming SenML, a definite length array MUST be used. </ins> The following example shows a dump of the CBOR example for the same sensor measurement as in co-ex.


Question:
Set of small editorial tweaks and aligned fragment text with new way of positioning base values
LGTM ( other than we need to decide if we use field or attribute but we can do that as separate PR)

The compressed form, using the byte alignment option of EXI, for the above XML is the following: <del> A small temperature sensor devices that only generates this one EXI </del> <ins> A small temperature sensor device that only generates this one EXI </ins> file does not really need an full EXI implementation.  It can simply hard code the output replacing the 1-wire device ID starting at byte 0x20 and going to byte 0x2F with it's device ID, and replacing the


Question:
Set of small editorial tweaks and aligned fragment text with new way of positioning base values
LGTM ( other than we need to decide if we use field or attribute but we can do that as separate PR)

first record is at position 1.  A range of records can be selected by giving the first and the last record number separated by a '-' character.  Instead of the second number, the '*' character can be <del> used to indicate the last Senml Record in the Pack.  A set of records </del> <ins> used to indicate the last SenML Record in the Pack.  A set of records </ins> can also be selected using a comma separated list of record positions or ranges. (We use the term "selecting a record" for identifying it as part of the fragment, not in the sense of isolating it from the Pack -- the record still needs to be interpreted as part of the Pack, e.g., using <del> the base values defined in record 1.) </del> <ins> the base values defined in earlier records) </ins> 9.1.


Question:
Set of small editorial tweaks and aligned fragment text with new way of positioning base values
LGTM ( other than we need to decide if we use field or attribute but we can do that as separate PR)

Extensions that add a label that is intended for use with EXI need to create a new XSD Schema that includes all the labels in the IANA <del> registry then allocate a new EXI schemaId value.  Moving to the next letter in the alphabet is the suggested way to create the new value for the EXI schemaId.  Any labels with previously blank ID values SHOULD be updated in the IANA table to have their ID set to this new schemaId value. </del> <ins> registry and then allocate a new EXI schemaId value.  Moving to the next letter in the alphabet is the suggested way to create the new value for the EXI schemaId.  Any labels with previously blank ID values SHOULD be updated in the IANA table to have their ID set to this new schemaId value. </ins> Extensions that are mandatory to understand to correctly process the Pack MUST have a label name that ends with the '_' character.


Question:
100 bytes? (Here again I'd remove the text about mesh networks.) mesh networks result in about 80 bytes of usable payload per packet without fragmentation. How about we say keeping it small is good and quote examples of 802.15.4 has about 80 byte payload and that LoRa has 51 byte of applications payload in long range mode and just remove any reference to "mesh"
I'm fine with suggestion above. I'm also fine with just leaving draft as is.
Addressed by PR

2. The design goal is to be able to send simple sensor measurements in <del> small packets on mesh networks from large numbers of constrained devices.  Keeping the total size of payload under 80 bytes makes this easy to use on a wireless mesh network.  It is always difficult to define what small code is, but there is a desire to be able to implement this in roughly 1 KB of flash on a 8 bit microprocessor. Experience with power meters and other large scale deployments has indicated that the solution needs to support allowing multiple measurements to be batched into a single HTTP or CoAP request.  This "batch" upload capability allows the server side to efficiently support a large number of devices.  It also conveniently supports batch transfers from proxies and storage devices, even in situations where the sensor itself sends just a single data item at a time.  The multiple measurements could be from multiple related sensors or from the same sensor but at different times. </del> <ins> small packets from large numbers of constrained devices.  Keeping the total size of payload small makes it easy to use SenML also in constrained networks, e.g., in a 6LoWPAN RFC4944.  It is always difficult to define what small code is, but there is a desire to be able to implement this in roughly 1 KB of flash on a 8 bit microprocessor.  Experience with power meters and other large scale deployments has indicated that the solution needs to support allowing multiple measurements to be batched into a single HTTP or CoAP request.  This "batch" upload capability allows the server side to efficiently support a large number of devices.  It also conveniently supports batch transfers from proxies and storage devices, even in situations where the sensor itself sends just a single data item at a time.  The multiple measurements could be from multiple related sensors or from the same sensor but at different times. </ins> The basic design is an array with a series of measurements.  The following example shows two measurements made at different times.


Question: Dave's comments: The issue is that neither of the above have an asterisk by them, so both are recommended and per Carsten’s definition of “units” during the meeting (i.e., where the reference point is separate from the units), then Kelvin and Celsius have the same units as they only vary by what the reference point is.

fields to provide better information about the statistical properties of the measurement. <ins> In summary, the structure of a SenML record is laid out to support a single measurement per record.  If multiple data values are measured at the same time (e.g., air pressure and altitude), they are best kept as separate records linked through their Time value; this is even true where one of the data values is more "meta" than others (e.g., describes a condition that influences other measurements at the same time). </ins> 4.4. Sometimes it is useful to be able to refer to a defined normalized


Question: Dave's comments: The issue is that neither of the above have an asterisk by them, so both are recommended and per Carsten’s definition of “units” during the meeting (i.e., where the reference point is separate from the units), then Kelvin and Celsius have the same units as they only vary by what the reference point is.

as mile, foot, light year are not allowed.  For most cases, the SI unit is preferred. <ins> (Note that some amount of judgement will be required here, as even SI itself is not entirely consistent in this respect.  For instance, for temperature ISO-80000-5 defines a quantity, item 5-1 (thermodynamic temperature), and a corresponding unit 5-1.a (Kelvin), and then goes ahead to define another quantity right besides that, item 5-2 ("Celsius temperature"), and the corresponding unit 5-2.a (degree Celsius).  The latter quantity is defined such that it gives the thermodynamic temperature as a delta from T0 = 275.15 K.  ISO 80000-5 is defining both units side by side, and not really expressing a preference.  This level of recognition of the alternative unit degree Celsius is the reason why Celsius temperatures exceptionally seem acceptable in the SenML units list alongside Kelvin.) </ins> Symbol names that could be easily confused with existing common units or units combined with prefixes should be avoided.  For example, selecting a unit name of "mph" to indicate something that


Question: Dave's comments: The issue is that neither of the above have an asterisk by them, so both are recommended and per Carsten’s definition of “units” during the meeting (i.e., where the reference point is separate from the units), then Kelvin and Celsius have the same units as they only vary by what the reference point is.

does not lose any information from the JSON value.  EXI uses the XML types. <del> New entries can be added to the registration by Expert Review as defined in RFC8126.  Experts should exercise their own good judgment but need to consider that shorter labels should have more strict review. </del> <ins> New entries can be added to the registration by either Expert Review or IESG Approval as defined in RFC8126.  Experts should exercise their own good judgment but need to consider that shorter labels should have more strict review.  New entries should not be made that counteract the advice at the end of considerations. </ins> All new SenML labels that have "base" semantics (see senml-base) MUST start with character 'b'.  Regular labels MUST NOT start with that


Question:
LGTM
I have a doubt about why an SRC for the CTR is needed at all and if a global counter for all streams would be equally secure in terms forming the IV or was due to implementation details to be able to have different context for each streams?
Because the key is used to encrypt all outgoing stream, we need a global counter for the IV to avoid counter reuse. If we use the frame counter only, then each stream will have their own counter and IV will collide
If the frame counter is global for the participant instead that per stream, i.e. increased whenever a new frame is encoded regarding the media stream, there would be no IV collision.
Correct. But I imagine this will be more complex to implement, having a single global counter across all media sources including audio and video
Prepared a PR to change it to a global counter, however I want to make sure I understand how the counter is maintained globally, If the frame N is encrypted in 3 different layers, they will have different counter values right? One potential benefit of having a global counter it will free up some bits in the header which we can use as a keyId (up to 16 keys) which is nice
Yes, each call to the frame encryptor which would require to atomically increment the counter. In the case of the simulcast, the same input image will produce N different encoded frames which would have their unique counter. Regarding the free bits, I was thinking in something like this: If x=0 then K is the key id ( 0-7) if x=1 then K is the length of the key that is inserted before the This would allow to avoid the extra byte for conferences with less than 9 participants. Another option would be to always use the KLEN/KEYID and reserve that bit for extensions in the future.
I like it :-)

encryption IV.  The frame counter must be unique and monodically increasing to avoid IV reuse. <del> The frame counter itself can be encoded in a variable length format to decrease the overhead, the following encoding schema is used The first byte in the header is fixed and contains the header metadata S 1 bit Signature flag, indicates the payload contains a signature of set. Reserved (4 bits) Reserved bits LEN (3 bits) The length of the CTR fields in bytes. CTR (Variable length) Frame counter up to 8 bytes long </del> <ins> As each sender will use their own key for encryption, so the SFrame header will include the key id to allow the receiver to identify the key that needs to be used for decrypting. Both the frame counter and the key id are encoded in a variable length format to decrease the overhead, so the first byte in the Sframe header is fixed and contains the header metadata with the following format: Signature flag (S): 1 bit This field indicates the payload contains a signature of set.  Counter Length (LEN): 3 bits This field indicates the length of the CTR fields in bytes.  Extended Key Id Flag (X): 1 bit Indicates if the key field contains the key id or the key length. Key or Key Length: 3 bits This field containts the key id (KID) if the X flag is set to 0, or the key length (KLEN) if set to 1. If X flag is 0 then the KID is in the range of 0-7 and the frame counter (CTR) is found in the next LEN bytes: Key id (KID): 3 bits The key id (0-7).  Frame counter (CTR): (Variable length) Frame counter value up to 8 bytes long. if X flag is 1 then KLEN is the length of the key (KID), that is found after the SFrame header metadata byte.  After the key id (KID), the frame counter (CTR) will be found in the next LEN bytes: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+----------------------+------------- ---------+ |S|LEN |1|KLEN | KID... (length=KLEN) | CTR... (length=LEN) | +-+-+-+-+-+-+-+-+----------------------+----------------------+ Key length (KLEN): 3 bits The key length in bytes.  Key id (KID): (Variable length) The key id value up to 8 bytes long.  Frame counter (CTR): (Variable length) Frame counter value up to 8 bytes long. </ins> 3.2.


Question:
LGTM
I have a doubt about why an SRC for the CTR is needed at all and if a global counter for all streams would be equally secure in terms forming the IV or was due to implementation details to be able to have different context for each streams?
Because the key is used to encrypt all outgoing stream, we need a global counter for the IV to avoid counter reuse. If we use the frame counter only, then each stream will have their own counter and IV will collide
If the frame counter is global for the participant instead that per stream, i.e. increased whenever a new frame is encoded regarding the media stream, there would be no IV collision.
Correct. But I imagine this will be more complex to implement, having a single global counter across all media sources including audio and video
Prepared a PR to change it to a global counter, however I want to make sure I understand how the counter is maintained globally, If the frame N is encrypted in 3 different layers, they will have different counter values right? One potential benefit of having a global counter it will free up some bits in the header which we can use as a keyId (up to 16 keys) which is nice
Yes, each call to the frame encryptor which would require to atomically increment the counter. In the case of the simulcast, the same input image will produce N different encoded frames which would have their unique counter. Regarding the free bits, I was thinking in something like this: If x=0 then K is the key id ( 0-7) if x=1 then K is the length of the key that is inserted before the This would allow to avoid the extra byte for conferences with less than 9 participants. Another option would be to always use the KLEN/KEYID and reserve that bit for extensions in the future.
I like it :-)

3- Authentication key to authenticate the encrypted frame and the media metadata <del> The IV is 128 bits long and calculated from the SRC and CTR field of the Frame header: </del> <ins> The IV is 128 bits long and calculated from the CTR field of the Frame header: </ins> 3.2.2.


Question:
LGTM
I have a doubt about why an SRC for the CTR is needed at all and if a global counter for all streams would be equally secure in terms forming the IV or was due to implementation details to be able to have different context for each streams?
Because the key is used to encrypt all outgoing stream, we need a global counter for the IV to avoid counter reuse. If we use the frame counter only, then each stream will have their own counter and IV will collide
If the frame counter is global for the participant instead that per stream, i.e. increased whenever a new frame is encoded regarding the media stream, there would be no IV collision.
Correct. But I imagine this will be more complex to implement, having a single global counter across all media sources including audio and video
Prepared a PR to change it to a global counter, however I want to make sure I understand how the counter is maintained globally, If the frame N is encrypted in 3 different layers, they will have different counter values right? One potential benefit of having a global counter it will free up some bits in the header which we can use as a keyId (up to 16 keys) which is nice
Yes, each call to the frame encryptor which would require to atomically increment the counter. In the case of the simulcast, the same input image will produce N different encoded frames which would have their unique counter. Regarding the free bits, I was thinking in something like this: If x=0 then K is the key id ( 0-7) if x=1 then K is the length of the key that is inserted before the This would allow to avoid the extra byte for conferences with less than 9 participants. Another option would be to always use the KLEN/KEYID and reserve that bit for extensions in the future.
I like it :-)

3.2.3. <del> The sending client maps the outgoing streams and give them unique indices: 0, 1,.. etc.  As mentioned above SFrame supports up to 16 outgoing stream.  After encoding the frame and before packetizing it, the necessary media metadata will be moved out of the encoded frame buffer, to be used later in the RTP header extension.  The encoded frame, the metadata buffer and the stream index are passed to SFrame encryptor which internally keeps track of the number of frames encrypted so far for that stream.  The encryptor constructs SFrame header using the stream index and frame counter and derive the encryption IV.  The frame is encrypted using the encryption key and the header, encrypted frame and the media metadata are authenticated using the authentication key.  The authentication tag is then truncated (If supported by the cipher suite) and prepended at the end of the ciphertext. </del> <ins> After encoding the frame and before packetizing it, the necessary media metadata will be moved out of the encoded frame buffer, to be used later in the RTP header extension.  The encoded frame and the metadata buffer are passed to SFrame encryptor which internally keeps track of the number of frames encrypted so far.  The encryptor constructs SFrame header using frame counter and key id and derive the encryption IV.  The frame is encrypted using the encryption key and the header, encrypted frame and the media metadata are authenticated using the authentication key.  The authentication tag is then truncated (If supported by the cipher suite) and prepended at the end of the ciphertext. </ins> The encrypted payload is then passed to a generic RTP packetized to construct the RTP packets and encrypts it using SRTP keys for the


Question:
LGTM
I have a doubt about why an SRC for the CTR is needed at all and if a global counter for all streams would be equally secure in terms forming the IV or was due to implementation details to be able to have different context for each streams?
Because the key is used to encrypt all outgoing stream, we need a global counter for the IV to avoid counter reuse. If we use the frame counter only, then each stream will have their own counter and IV will collide
If the frame counter is global for the participant instead that per stream, i.e. increased whenever a new frame is encoded regarding the media stream, there would be no IV collision.
Correct. But I imagine this will be more complex to implement, having a single global counter across all media sources including audio and video
Prepared a PR to change it to a global counter, however I want to make sure I understand how the counter is maintained globally, If the frame N is encrypted in 3 different layers, they will have different counter values right? One potential benefit of having a global counter it will free up some bits in the header which we can use as a keyId (up to 16 keys) which is nice
Yes, each call to the frame encryptor which would require to atomically increment the counter. In the case of the simulcast, the same input image will produce N different encoded frames which would have their unique counter. Regarding the free bits, I was thinking in something like this: If x=0 then K is the key id ( 0-7) if x=1 then K is the length of the key that is inserted before the This would allow to avoid the extra byte for conferences with less than 9 participants. Another option would be to always use the KLEN/KEYID and reserve that bit for extensions in the future.
I like it :-)

5.1.2. <del> The sender of a simulcast stream may use the same SRC for all the simulcast streams from the same media source or use a different SRC for each of them, in any case it is transparent to the SFU which will be able to perform the simulcast layer switching normally.  The senders are already able to receive different SRCs from different participants due to LastN and RTP Stream reuse, so supporting simulcast uses same mechanisms. </del> <ins> When using simulcast, the same input image will produce N different encoded frames (one per simulcat layer) which would be processed inpependently by the frame encryptor and assigned an unique counter for each. </ins> 5.1.3.


Question:
LGTM
I have a doubt about why an SRC for the CTR is needed at all and if a global counter for all streams would be equally secure in terms forming the IV or was due to implementation details to be able to have different context for each streams?
Because the key is used to encrypt all outgoing stream, we need a global counter for the IV to avoid counter reuse. If we use the frame counter only, then each stream will have their own counter and IV will collide
If the frame counter is global for the participant instead that per stream, i.e. increased whenever a new frame is encoded regarding the media stream, there would be no IV collision.
Correct. But I imagine this will be more complex to implement, having a single global counter across all media sources including audio and video
Prepared a PR to change it to a global counter, however I want to make sure I understand how the counter is maintained globally, If the frame N is encrypted in 3 different layers, they will have different counter values right? One potential benefit of having a global counter it will free up some bits in the header which we can use as a keyId (up to 16 keys) which is nice
Yes, each call to the frame encryptor which would require to atomically increment the counter. In the case of the simulcast, the same input image will produce N different encoded frames which would have their unique counter. Regarding the free bits, I was thinking in something like this: If x=0 then K is the key id ( 0-7) if x=1 then K is the length of the key that is inserted before the This would allow to avoid the extra byte for conferences with less than 9 participants. Another option would be to always use the KLEN/KEYID and reserve that bit for extensions in the future.
I like it :-)

sizes or frames per second.  In order to support it, the sender MUST encode each spatial layer of a given picture in a different frame. That is, an RTP frame may contain more than one SFrame encrypted <del> frame with same source (SRC) and incrementing frame counter. </del> <ins> frame with an incrementing frame counter. </ins> 5.2.


Question:
This: Changes the name of the draft (I made something up, but you are free to suggest a different name) Adds venue information to the draft (working group, area, stream, github, etc...) Updates some of the boilerplate stuff (README, CONTRIBUTING, .gitignore, Makefile) Adds workflows for CI with GitHub Actions Cleans up trailing whitespace (with ) so that the build runs cleanly Updates the Gemfile (I don't use this, but I tried to make it functional for those that do) From here, you should be able to create a first submission of a draft-ietf-sframe-enc-00 by pushing a tag of draft-ietf-sframe-enc-00 (or making a new release with that name).
Spec changes look ok since they are editorial/ NAME is this ready to go?
You should be able to merge this and use it straight away, if that is what you want to do (the only thing that might need attention is the proposed filename, which I just made up).

Secure Frame (SFrame) <del> draft-omara-sframe-01 </del> <ins> draft-ietf-sframe-enc-latest </ins> Abstract


Question:
moving into .
Ken, here is the reasoning for moving encryption functionality outside the SUIT manifest: When the firmware author needs to encrypt a payload for a specific recipient it needs to know its public key (for HPKE) or its symmetric key (for AES-KW). Since the firmware author does not typically know the recipients ahead of time, it cannot perform this encryption operation. What he can, however, do is to digitally sign the manifest (and thereby the firmware image) since it only requires its private key. Later the distribution system, before delivering the firmware to the devices, will encrypt the firmware images. It cannot modify the manifest anymore since otherwise the signature previously generated would be invalidated. Hence, any information regarding firmware encryption has to go into the envelope. I hope this makes sense. For this reason, I believe the current text in the document is correct.
I've misunderstood your intention. Are these correct? Author has the raw firmware image and creates by signing the with its signing key. Distribution System receives the raw firmware image and its from the Author, then encrypts the firmware. It appends to (outside the ). Device verifies the and decrypts encrypted firmware image using . My concern is that the would be untrusted because it locates outside the signature. How about this one? The order of suit-protection-wrappers array corresponds to the suit-components array in suit-common it can be if no decryption is required The Device can verify whether the decrypted firmware image is correct using the digest hash of raw firmware image the image digest and the image size are trusted because they are inside the though the s are untrusted because they are outside the The Author MUST aware that the firmware will be encrypted by Distribution System to create appropriate suit-install section
The distribution system is not untrusted but rather trusted to do the encryption of the plaintext firmware image and to distribute it to the intended recipients. If the author already knows the recipients ahead of time and has their public keys, then it can also encrypt the firmware image without relying on the distribution system. Hence, I do not believe that the wording that the distribution system is untrusted is correct. Note that the recipient will get to learn that the encryption has been applied by the distribution system since the encryption info is also signed. The recipient (device) can still check the signature of the manifest to verify whether the plaintext image has been unchanged. Hence, I don't see a problem with the approach
Btw, I agree with you that the manifest needs to carry a hash of the plaintext firmware and it also needs to contain instructions for matching the hash against a specific value. The reason why I believe that no commands for processing the encrypted payload are needed is simply because the encryption must happen before any of the other processing steps need to take place. Otherwise nothing can proceed. Is this the right approach? I don't know.
I wonder whether we should bring this up on the SUIT mailing list since it is an important design decision.
The term "untrusted" I used was ambiguous, but I meant the part was outside the signature. Before discussing in the mailing list let me confirm this: Distribution System is trusted case A-1) as a firmware server and a device management infrastructure case A-2) as a firmware server and a device management infrastructure, and also a manifest signer The firmware is encrypted by case B-1) the Author case B-2) the Distribution System With case A-2, the Distribution System can just update the manifest and then update the signature because Devices trusts its public key. With case B-1, the Author can create encrypted firmware and its manifest, so that there is no need Distribution System to modify the manifest. They work well with current SUIT Manifest, but our case does not especially with non-integrated payload. Am I correct?
I think you are saying that because a non-integrated payload requires a URI to be included in the manifest, which will then be integrity protected. Hence, the distribution system will not be able to change that URL and it will typically not have permissions to replace the content of the referenced file. Is this correct? FYI: I think it would be good to have examples of all these cases in the draft.
Here is what Øyvind proposes in URL
In the firmware encryption draft we have defined an extension to the envelope that indicates what encryption parameters are applied to which component. Here is the CDDL: Currently the text provides no explanation or an example of how this linkage works.
This aspect is related to URL and to the mailing list discussion URL
This issue is also related to URL
With in PR , this issue is solved.
SUITEncryptionInfo was defined in the past SUIT Manifest core document describing how to decrypt the firmware image, but in this document it may not be associated with any component. I will create a Pull Request to move SUITEncryptionInfo under the suit-manifest.
See also URL A new idea to leverage SUIT Dependency for Firmware Encryption has come up to my mind. Please review and make comments, especially for SUIT Manifest usage and security considerations. The Author creates firmware and its manifest The Distribution System encrypts the firmware and distribute it to Devices The Device fetches and decrypts encrypted firmware, then check and install it It introduces new section suit-security-wrapper holding SUITEncryptionInfo, which is appended by the Distribution System The Device decrypts the encrypted firmware with SUITEncryptionInfo and then check it with condition-image-match Distribution System cannot modify the URI in the manifest where the encrypted firmware is stored SUITEncryptionInfo is used without verification because it locates out of the Author's signature The Author and the Distribution System create manifest respectively Distribution System's manifest fetches encrypted firmware and decrypts it, and depends on Author's manifest Author's manifest check the decrypted firmware with condition-image-match The Device MUST trust both Author and Distribution System keys to verify manifests The Distribution System can freely set the URI to distribute encrypted firmware in Distribution System's manifest SUITEncryptionInfo is inside signature created by the Distribution System (Only important parts are shown in this example) (Only important parts are shown in this example) Best, Ken
Internet-Draft draft-ietf-suit-firmware-encryption-URL is now available. It is a work item of the Software Updates for Internet of Things (SUIT) WG of the IETF. Title: Encrypted Payloads in SUIT Manifests Authors: Hannes Tschofenig Russ Housley Brendan Moran David Brown Ken Takayama Name: draft-ietf-suit-firmware-encryption-URL Pages: 52 Dates: 2024-03-03 Abstract: This document specifies techniques for encrypting software, firmware, machine learning models, and personalization data by utilizing the IETF SUIT manifest. Key agreement is provided by ephemeral-static (ES) Diffie-Hellman (DH) and AES Key Wrap (AES-KW). ES-DH uses public key cryptography while AES-KW uses a pre-shared key. Encryption of the plaintext is accomplished with conventional symmetric key cryptography. The IETF datatracker status page for this Internet-Draft is: URL There is also an HTMLized version available at: URL A diff from the previous version is available at: https://author-URL Internet-Drafts are also available by rsync at: URL

4. <del> This specification introduces two extensions to the SUIT envelope and the manifest structure, as motivated in arch. The SUIT envelope is enhanced with a key exchange payload, which is carried inside the suit-protection-wrappers parameter, see envelope- fig.  One or multiple SUIT_Encryption_Info payload(s) are carried within the suit-protection-wrappers parameter.  The content of the SUIT_Encryption_Info payload is explained in AES-KW (for AES-KW) and in HPKE (for HPKE).  When the encryption capability is used, the suit-protection-wrappers parameter MUST be included in the envelope. The manifest is extended with a CEK verification parameter (called suit-cek-verification), see manifest-fig.  This parameter is optional and is utilized in environments where battery exhaustion attacks are a concern.  Details about the CEK verification can be found in cek- verification. </del> <ins> This specification introduces two extensions to the SUIT_Parameters, as motivated in arch. The SUIT manifest is enhanced with a key exchange payload, which is carried within the suit-directive-override-parameters or suit- directive-set-parameters for each encrypted payload.  One SUIT_Encryption_Info is carried with suit-parameter-encryption-info, see parameter-fig.  The content of the SUIT_Encryption_Info is explained in AES-KW (for AES-KW) and in HPKE (for HPKE).  When the encryption capability is used, the SUIT_Encryption_Info parameter MUST be included in the SUIT_Directive. A CEK verification parameter (called suit-parameter-cek- verification), see parameter-fig, also extends the manifest.  This parameter is optional and is utilized in environments where battery exhaustion attacks are a concern.  Details about the CEK verification can be found in cek-verification. </ins> 5.


Question:
Updating HTTP references to RFC9110 and RFC9112. Moving CoAP reference to normative to be consistent with other references.
; httpbis-messaging/-semantics/-cache are in the RFC editor queue and will be published before this document. URL
They actually have been published.
Thanks!

a RESTful API. Different protocols can be used with RESTful systems, but at the time <del> of writing the most common protocols are HTTP RFC7230 and CoAP </del> <ins> of writing the most common protocols are HTTP RFC9110 and CoAP </ins> RFC7252.  Since RESTful APIs are often lightweight and enable loose coupling of system components, they are a good fit for various Internet of Things (IoT) applications, which in general aim at


Question:
Updating HTTP references to RFC9110 and RFC9112. Moving CoAP reference to normative to be consistent with other references.
; httpbis-messaging/-semantics/-cache are in the RFC editor queue and will be published before this document. URL
They actually have been published.
Thanks!

3.5. <del> Section 4.3 of RFC7231 defines the set of methods in HTTP; </del> <ins> Section 9.3 of RFC9110 defines the set of methods in HTTP; </ins> Section 5.8 of RFC7252 defines the set of methods in CoAP.  As part of the Uniform Interface constraint, each method can have certain properties that give guarantees to clients.