jiebi/CodeConvo huggingface dataset:
Code change:
any DHCP options would only be used together with SLAAC and DHCP for address configuration, respectivly. <ins> Terminology: Clarify that the CTs' installation events can occur multiple times. </ins> changes from -24 to -25 Large rework of section 7 (Security policies)

Related discussion:
text: Closes: URL See-Also: URL
From Benjamin Kaduk's comments: Is it? Paging NAME NAME and NAME as I honestly don't know. Trouble is: The way CTs come across in the examples, the CT goes in, does its job and leaves. But the RD's lifetimes are finite, and "Registrations in the RD are soft state and need to be periodically refreshed". So what happens when the time runs out?
A CT can indeed come in later to assist in a reconfiguration of the network/applications, e.g. adding a device, removing, or changing members of a group, or changing parameters of devices. When the CT performed a registration on behalf of an IoT device the expectation is that a very long lifetime will be picked, such that the CT doesn't have to come back to refresh. This looks problematic in case the RD state is easily lost - e.g. suppose it reboots and loses all such entries? Then there may be no CT around to send the entries to the RD again. (I would assume in this scenario that the CT's registration are more "permanent" so they would survive a reboot for example. Can be restored back from a database. In another project I work in the CT can perform such persistent registrations that survive reboots, using a special 'max' value of lifetime that signals persistent registration.)
Thanks, with that I can at least phrase an answer to the immediate question. Would it, in the deployments you describe, be conceivable that the CT is recalled on site on extraordinary events, like when the RD host is migrated to a different system or address? On the reboots, I hope that we are OK with the current situation that an RD would persist its state when it can, and administrators would not use the more volatile variety when they intend to configure long lifetimes. (If we aren't, we'd need to start thinking about negotiation of lifetimes, and that'd bring a new aspect of complexity I hope to avoid).
chrysn wrote: Hi. I thought I had commented on this somewhere already. A BRSKI-based "CT" would have a registrar which does not really leave. If we are talking about how I think that brski-async-enroll will work, then the CT will enter the no-internet-zone, do some connections, and then leave.
Code change:
any DHCP options would only be used together with SLAAC and DHCP for address configuration, respectivly. <ins> Terminology: Clarify that the CTs' installation events can occur multiple times. </ins> changes from -24 to -25 Large rework of section 7 (Security policies)

Related discussion:
text: (Think new home construction in a new suburb) The RD lifetimes could be finite, but a few years in duration. The home owner, upon getting the keys (physically and cryptographically), would of course, rekey the entire house, and now there would be a management system to update RD lifetimes. Thread has a CT. I have no idea how it works, but perhaps NAME could comment. Zigbee CHIP project is doing something, but it's all NDA for now. I think that, when the time runs out, if there is nothing else to manage the system, then it should fail. I think that's okay. I think that the timeouts won't be minutes, but months... yes, there are issues. I don't think that the RD document needs to cover them though. {Feel free to invite me to collaborate on a script for the sequel to Sneakers/Leverage/MissionImpossible/EnemyOfTheState. I suggest it star Tom Greene rather than WillSmith or TomCruise.}
I think that there is probably a followup document that provides a way to backup/restore RD host data. OPC UA told me that they have created a spec for device independent backup/restore of configuration data in the case of device failure, but I don't have the details yet.
This might fit into -- any exchange format between the RDs could also be re-used for persistence. (With the caveat that the receiving server would need to inhabit the same address as the original server, or otherwise it could not service registration updates.)
Well, could it be an anycast address so that the RD could be highly available?
I don't see this as a viable design for a deployment. A change of system/address/network in the backend should never require the CT to come in and redo commissioning operations on IoT devices. Feeding the 'new RD' with stored information from a database is what would be most useful here. This database could be all those entries of devices that the CT had scanned initially, not necessarily the full RD state. Or alternatively all RD entries with lifetime e.g. > 48 hours could be restored; other devices need to re-register. Those entries that were registered with the CT could have a 10-year lifetime for example.
HI all, There are many installation firms, all with their own procedures and tools.
Code change:
any DHCP options would only be used together with SLAAC and DHCP for address configuration, respectivly. <ins> Terminology: Clarify that the CTs' installation events can occur multiple times. </ins> changes from -24 to -25 Large rework of section 7 (Security policies)

Related discussion:
text: It is possible that an installation company deploys a CT during installation and takes it home afterwards. The contract might stipulate that he leaves behind a program to restart, update or refresh the network. It might be that an another company does the maintenance with another set of tools. Concerning duration, we may talk about years of operation without interruption. On other sites weekly upgrades may be necessary. At the end of the day, There are no general rules that may fix the CT behavior. I am afraid this does not help a lot and emphasizes that the CT example is just a likely example. Cheerio, Peter Esko Dijk schreef op 2020-10-21 09:02: Links: [1] URL [2] URL Thanks for addressing my DISCUSS and COMMENT feedback
Code change:
4.1.3. <del> [TODO] </del> <ins> The addTransceiver method adds a new RTPTransceiver to the PeerConnection.  If a MediaStreamTrack argument is provided, then the transceiver will be configured with that media type and the track will be attached to the transceiver.  Otherwise, the application MUST explicitly specify the type; this mode is useful for creating recvonly transceivers as well as for creating transceivers to which a track can be attached at some later point.  At the time of creation, the application can also specify a transceiver direction attribute, a set of MediaStreams which the transceiver is associated with (allowing LS group assignments), and a set of encodings for the media (used for simulcast as desccribed in sec.simulcast). </ins> 4.1.4.

Related discussion:
text: NAME
NAME PTAL
LG with nits
para break and typo comment were missed
In the current draft we have addTransceiver [TODO] We need this text before WGLC, so it's being added to the punchlist.
Code change:
voicemail). "rollback" is a special session description type implying that the <del> state machine should be rolled back to the previous stable state, as described in sec.rollback.  The contents MUST be empty. </del> <ins> state machine should be rolled back to the previous "stable" state, as described in sec.rollback.  The contents MUST be empty. </ins> 4.1.8.1.

Related discussion:
text: Various fixes for 60.2: Removed parens from API names, removed comment. - put the term stable in quotes, removed comment. - put the term sess-id in angle brackets to match SDP spec, removed comment. - made the tls-id attribute consistent with other SDP attributes, removed comment. - removed quotes from IceRestart option, removed comment.

"IceRestart" option / IceRestart option Justin: LGTM
tls-id value / "a=tls-id" value Justin: The source RFC seems to prefer "tls-id" when discussing values.
During the editing of the Cluster 238 docs, it was decided that it's author's choice when formatting SDP attributes. Although RFC 8842 uses the format '"tls-id" attribute', this document more consistently uses "a=attribute-name" format for SDP attributes, which is the format that the SDP spec [RFC8866] uses. I'll update this document to consistently use "a=tls-id"
sess-id / (Section 5.2.1, second bullet item) Justin: LGTM
the stable state (1 instance) / the "stable" state (3 instances) >(Also, should 'the previous stable state' be 'a previous stable state' (per Section 5.7) or 'the previous "stable" state'?) Justin: The quoted form is preferred, including the case of "previous stable state".
[Breaking up issue /60 into smaller bites] The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. Justin: There seems to be a pretty clear preponderance for the non-parenthetical form, so let's keep that. W3C also does not use (). Jean: We'll remove the parens (camelCase is sufficient formatting).
Code change:
A peer-reflexive remote candidate could be learned and constructed from the source transport address of the STUN Binding request as an ICE connectivity check.  The peer-reflexive candidate could share the <del> same address as a remote host ICE candidate that will be signaled or has been signaled, received and is in the process of name resolution. In addition to the elimination procedure of redundant candidates defined in Section 5.1.3 of RFC8445, which could remove constructed peer-reflexive remote candidates, the address of any existing peer- reflexive remote candidate should not be exposed to Web applications by ICE agents that implement this proposal, as detailed in Section #guidelines. </del> <ins> same address as a remote mDNS ICE candidate whose name is in the process of being resolved.  In addition to the elimination procedure of redundant candidates defined in Section 5.1.3 of RFC8445, which could remove constructed peer-reflexive remote candidates, the address of any existing peer-reflexive remote candidate should not be exposed to Web applications by ICE agents that implement this proposal, as detailed in Section #guidelines. </ins> 3.

Related discussion:
text: PR for
Seems all feedback is addresses?
Host ICE candidates, ICE host candidates, or something else?
Code change:
Resolver for any cases in which it would have otherwise used the Unencrypted Resolver.  If the Designated Resolver has a different IP address than the Unencrypted Resolver and the TLS certificate does <del> not cover the Unencrypted Resolver address, the client MUST NOT use the discovered Encrypted Resolver.  Additionally, the client SHOULD suppress any further queries for Designated Resolvers using this Unencrypted Resolver for the length of time indicated by the SVCB record's Time to Live (TTL). </del> <ins> not cover the Unencrypted Resolver address, the client MUST NOT automatically use the discovered Designated Resolver.  Additionally, the client SHOULD suppress any further queries for Designated Resolvers using this Unencrypted Resolver for the length of time indicated by the SVCB record's Time to Live (TTL). </ins> If the Designated Resolver and the Unencrypted Resolver share an IP <del> address, clients MAY choose to opportunistically use the Encrypted </del> <ins> address, clients MAY choose to opportunistically use the Designated </ins> Resolver even without this certificate check (opportunistic). <del> If resolving the name of an Encrypted Resolver from an SVCB record </del> <ins> If resolving the name of a Designated Resolver from an SVCB record </ins> yields an IP address that was not presented in the Additional Answers section or ipv4hint or ipv6hint fields of the original SVCB query, the connection made to that IP address MUST pass the same TLS certificate checks before being allowed to replace a previously known <del> and validated IP address for the same Encrypted Resolver name. </del> <ins> and validated IP address for the same Designated Resolver name. </ins> <del> 4.2. </del> <ins> 4.3. </ins> There are situations where authenticated discovery of encrypted DNS configuration over unencrypted DNS is not possible.  This includes

Related discussion:
text: Same comment for line 337/360 about referring to the resolver as Designated versus Encrypted (it's unmodified in this PR but based on your agreement with the other in-line comment it may need modified as well) I think we will need to add some text to the Security Considerations section to mention the security promise difference between following the MAY or not (for optional use of the unverifiable designation). However, we can close this PR without it and handle that in a new PR if that's preferable.
Code change:
the order of notifications, the client SHALL maintain a Notification Number for each Observation it registers.  The Notification Number is a non-negative integer containing the largest Partial IV of the <del> received notifications for the associated Observe registration (see replay-protection).  The Notification Number is initialized to the Partial IV of the first successfully received notification response to the registration request.  In contrast to RFC7641, the received Partial IV MUST always be compared with the Notification Number, which thus MUST NOT be forgotten after 128 seconds.  Further details of replay protection of notifications are specified in replay- protection. Clients can re-register observations to ensure that the observation is still active and establish freshness again (RFC7641 Section 3.3.1).  When an OSCORE protected observation is refreshed, not only the ETags, but also the partial IV (and thus the payload and OSCORE option) change.  The server uses the new request's Partial IV as the 'request_piv' of new responses. </del> <ins> received notifications for the associated Observe registration. Further details of replay protection of notifications are specified in replay-notifications. The Inner Observe in a response MUST either have the value of Observe in the original CoAP message or be empty.  The former is used to allow the server to set the Observe values to be received by the client.  In the latter case the overhead of the Observe value is saved and instead the least significant bytes of the Partial IV is used as Observe value, see replay-notifications.  The Outer Observe in the response may be needed for intermediary nodes to support multiple responses to one request.  The client MAY ignore the Outer Observe value. If the client receives a response to an Observe request without an Observe value, then it verifies the response as a non-Observe response, as specified in ver-res.  If the client receives a response to a non-Observe request with an Observe value, then it stops processing the message but keeps the observation alive, as specified in ver-res. </ins> 4.1.3.5.

Related discussion:
text: Back to one processing description Observe is now primarily inner Simplified processing Explicit cancellation by intermediary not supported
Code change:
5.2. <del> Cryptographic algorithm negotiation: Transport security protocols should permit applications to configure supported or enabled cryptographic algorithms. </del> <ins> Cryptographic algorithm negotiation (AN): Transport security protocols should permit applications to configure supported or enabled cryptographic algorithms. </ins> Transport dependency: None. Application dependency: Application awareness of supported or desired algorithms. <del> Application authentication delegation: Some protocols may </del> <ins> Application authentication delegation (AD): Some protocols may </ins> completely defer endpoint authentication to applications, e.g., to reduce online protocol complexity.

Related discussion:
text: WIP addressing . I don't want to pull this as-is: I just want comments on the format and usefulness of this. This closes the circle created by the list of protocol features in section 3, and indicates where we probably want more consistency and completeness in that list so the derivation of common optional features is more obvious.
Still a WIP. I have a bunch of comments as a result of doing this exercise: Feature availability for some protocol/feature combinations is not clear from the descriptions in the doc. Wireguard is IP encapsulation within UDP, but this is not stated anywhere in the doc. The set of features we list here should be called out or evident from the protocol features subsections under each protocol description. I think there's still some confusion in sections around symmetric authentication vs. signatures, i.e., AEAD-style authentication ("packets belong to this session") vs. PKI endpoint authentication ("this connection belongs to a peer I trust and is not being MITMed"). This may be a comment on the unfortunateness of the literature using "authenticated" for both.

Feature availability for some protocol/feature combinations is not clear from the descriptions in the doc. Can you give examples? Can you please open an issue to address this? See the other open pull request. :-) Where in particular are these things confused?
NAME ping!
Sorry, am away for the holiday weekend. The ones I have listed with a "?", for instance. I guessed on a few of the others, as well (e.g., configuration extensions for MinimalT). The right answer is for me to go back through this table and enumerate all the areas where the text isn't clear, and fix them. I'll file an issue. Will do. I'm not quite sure what I was thinking here. After reading it through again, I think I'm okay with how this is presented.
NAME can you please update this PR?
A few more questions: Is there any existing client puzzle/proof of work standardized for TLS or DTLS, or is URL as far as something's gotten? Same goes for IPsec; I can find no standardized version of any of these things. Should algorithms like TLS, DTLS, etc. that support native authentication but also can export a cryptographic channel binding be listed as supporting authentication delegation? My instinct is yes.
Code change:
5.2. <del> Cryptographic algorithm negotiation: Transport security protocols should permit applications to configure supported or enabled cryptographic algorithms. </del> <ins> Cryptographic algorithm negotiation (AN): Transport security protocols should permit applications to configure supported or enabled cryptographic algorithms. </ins> Transport dependency: None. Application dependency: Application awareness of supported or desired algorithms. <del> Application authentication delegation: Some protocols may </del> <ins> Application authentication delegation (AD): Some protocols may </ins> completely defer endpoint authentication to applications, e.g., to reduce online protocol complexity.

Related discussion:
text: NAME None that I'm aware of! Yes, I think that's correct.
NAME Will you be able to complete this PR this week?
Yes, though I could use some guidance on the ?'s in the table, if you have enough context to resolve them. Otherwise, I will do some digging.
NAME IKEv2+ESP/AD: Yes, via EAP(-TLS). IKEv2+ESP/AFN: Yes, via vendor and configuration payloads. SRTP+DTLS/CM: No. ZRTP: Omit, since it's a variant? WireGuard/CM: No, connections are bound to IP addresses. WireGuard/SC: No, session resumption is not supported. WireGuard/LHP: Yes, for transport packets only. MinimalT/AD: No. MinimalT/AFN: No. MinimalT/LHP: Yes. CurveCP/AD: No.
RFR.
Ship it.
It's probably easier and more consumable to encode the matrix of protocols providing a particular feature as a table.
I'm assigning this to you, Kyle. Will you have time to take a stab at it?
Yep, I'll work on it this afternoon.
Code change:
rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, and ed25519. <ins> TLS PskKeyExchangeMode Registry: Values with the first byte in the range 0-253 (decimal) are assigned via Specification Required RFC8126.  Values with the first byte 254 or 255 (decimal) are reserved for Private Use RFC8126.  This registry SHALL have a "Recommended" column.  The registry [shall be/ has been] initially populated psk_ke (0) and psk_dhe_ke (1).  Both SHALL be marked as "Recommended". </ins>

Related discussion:
text: It appears we should have included rules for populating a registry for the pskkeyexchange_modes extension.
Yes, an obvious oversight in our oversite. :) I approve.
+1
FWIW, +1
+1 to a new registry.
Yes, we should create a registry. But: We need to update the "this document defines a new registry" to match the new number of registries (two) the space of allowed values is only one byte, so we don't need to talk about "first byte"
Code change:
"batch_interval" is the batch interval of the request. <ins> "agg_param", an aggregation parameter for the VDAF being executed. </ins> "report_count" is the number of reports included in the aggregation. "checksum" is the checksum computed over the set of client reports. <del> "job_id" is the ID of the aggregation job. </del> This request MUST be authenticated as described in https-sender-auth. To handle the leader's request, the helper first ensures that the request meets the requirements for batch parameters following the

Related discussion:
text: AggregateShareReq should have an aggregation parameter field instead of aggregation job ID.
Thanks NAME for spotting this!
Code change:
All data sent with the same MessageContext object will be treated as belonging to the same Message, and will constitute an in-order series <del> until the endOfMessage is marked.  Once the end of the Message is marked, the MessageContext object may be re-used as a new Message with identical parameters. </del> <ins> until the endOfMessage is marked. </ins> 7.7.

Related discussion:
text: ... as suggested by NAME
The section on partial send says: "All data sent with the same MessageContext object will be treated as belonging to the same Message, and will constitute an in-order series until the endOfMessage is marked. Once the end of the Message is marked, the MessageContext object may be re-used as a new Message with identical parameters." Can we reconsider for a second if that is really the way we want to design this? This is really implicit and therefore an easy source for errors. I guess we could alternatively use an explicit message identifier...? Or the send action always return an identifier and for subsequent sends we input this identifier again? Or someone has a smarter idea?
I don't have my head buried in code like some others here (NAME NAME , ..), so I guess that these folks should speak up - but just from reading this, I agree that the current design sounds like an easy source for errors.
I'd prefer to just remove the part that mentions reusing the same object. That's an implementation detail (and a perf optimization). The rest seems correct.