jiebi/CodeConvo huggingface dataset:
Change:
I think that the current SenML draft is missing a note on JSON/CBOR differences in Data Value: While it is explicitly stated that vd is a base64 string in JSON and a binary-value in CBOR, the supposedly exhaustive list of differences in 6. fails to mention that no base64 encoding is done in CBOR. Suggested addition: o For Data Values, no base64url-encoding is done, as the data can be directly expressed as binary-value. Furthermore, I suggest that "Characters in the Data Value are base64 encoded" be expressed as "Bytes [...]" or "Octets are encoded [...]", to make the distinction to the character-based strings and binary data clearer. (The only context in which I'd name bytes of binary data "Character" are when speaking of a "char" in C). Best regards Christian
Indeed, characters should be called characters, and bytes should be called bytes. (In C, bytes are represented as uint8_t :-). s/can be/are/ (they are!)
Have a read of the PR I put in for this. I think it resolves the issue
Looks good to me (with the one typo fix)
typo fix

Discussion:
Only the UTF-8 form of JSON is allowed.  Characters in the String Value are encoded using the escape sequences defined in RFC7159. <del> Characters in the Data Value are base64 encoded with URL safe alphabet as defined in Section 5 of RFC4648. </del> <ins> Octets in the Data Value are base64 encoded with URL safe alphabet as defined in Section 5 of RFC4648. </ins> Systems receiving measurements MUST be able to process the range of floating point numbers that are representable as an IEEE double

value, it has exactly the same value as the original Number.  For the version number, only an unsigned integer is allowed. <ins> Characters in the String Value are encoded using a definite length text string (type 3).  Octets in the Data Value are encoded using a definite length byte string (type 2) . </ins> 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;

7. A SenML Pack or Stream can also be represented in XML format as <del> defined in this section.  The following example shows an XML example for the same sensor measurement as in co-ex. </del> <ins> defined in this section. Only the UTF-8 form of XML is allowed.  Characters in the String Value are encoded using the escape sequences defined in RFC7159. Octets in the Data Value are base64 encoded with URL safe alphabet as defined in Section 5 of RFC4648. The following example shows an XML example for the same sensor measurement as in co-ex. </ins> The SenML Stream is represented as a sensml tag that contains a series of senml tags for each SenML Record.  The SenML Fields are
Change:
Current text hints that you can use SenML also with actuators, but there is not much details about this yet.
+1 For actuators. But the ability to set any arbitrary value would be preferred - for example the coefficients of an analog sensor, or a flag to initiate a sensor update.
I did not get this into the -03 update but still plan to add it.
I did not get this into the -03 update but still plan to add it.
Comments on the examples

Discussion:
and has gotten two separate values as a result, a temperature and humidity measurement. <ins> 5.1.7. The following example show the SenML that could be used to set the current set point of a typical residential thermostat which has a temperature set point, a switch to turn on and off the heat, and a switch to turn on the fan override. In the following example two different lights are turned on.  It is assumed that the lights are on a 802.1BA network that can guarantee delivery of the messages to the two lights within 15 ms and uses 802.1AS for time synchronization.  The controller has set the time of the lights coming on to 20 ms in the future from the current time. This allows both lights to receive the message, wait till that time, then apply the switch command so that both lights come on at the same time. The following shows two lights being turned off using a non deterministic network that has a high odds of delivering a message in less than 100 ms and uses NTP for time synchronization.  The curent time is 1320078429.  The user has just turned off a light switch which is turning off two lights.  Both lights are dimmed to 50% brightness immediately to give the user instant feedback that something is changing.  However given the network, the lights will probably dim at somewhat different times.  Then 100 ms in the future, both lights will go off at the same time.  The instant but not synchronized dimming gives the user the sensation of quick responses and the timed off 100 ms in the future gives the perception of both lights going off at the same time. </ins> 6. The CBOR RFC7049 representation is equivalent to the JSON
Change:
Make sure the way we use schemaID match how it is defined in EXI. ( See email from Christian G - Oct 10, 2016 )

Discussion:
in the encoding.  For uses where extensions need to be preserved in EXI, the non-strict schema mode of EXI MAY be used. <del> The EXI header option MUST be included.  An EXI schemaID options MUST be set to the value of "a" indicating the scheme provided in this specification.  Future revisions to the schema can change this schemaID to allow for backwards compatibility.  When the data will be transported over CoAP or HTTP, an EXI Cookie SHOULD NOT be used as it simply makes things larger and is redundant to information provided in the Content-Type header. </del> <ins> The EXI header MUST include an "EXI Options", as defined in W3C.REC- exi-20140211, with an schemaId set to the value of "a" indicating the schema provided in this specification.  Future revisions to the schema can change the value of the schemaId to allow for backwards compatibility.  When the data will be transported over CoAP or HTTP, an EXI Cookie SHOULD NOT be used as it simply makes things larger and is redundant to information provided in the Content-Type header. </ins> The following is the XSD Schema to be used for strict schema guided EXI processing.  It is generated from the RelaxNG.

All new entries must define the Label Name, Label, and XML Type but the CBOR labels SHOULD be left empty as CBOR will use the string <del> encoding for any new labels.  The ID fields contains the EXI schemaID of the first Schema which includes this label or is empty if this label was not intended for use with EXI.  The Note field SHOULD </del> <ins> encoding for any new labels.  The ID fields contains the EXI schemaId value of the first Schema which includes this label or is empty if this label was not intended for use with EXI.  The Note field SHOULD </ins> contain information about where to find out more information about this label.

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.  Moving to the next letter in the alphabet is the suggested way to create the new 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 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> 11.3.
Change:
Added descriptive text about configuration/actuation usage
Addressing issue
Should there be explanation of the configuration usage?
This looks good to me. Two little tweeks but if you don't like them, I can live with it as it is.

Discussion:
format in the first place.  The relevant media type indicator is included in the Content-Type (ct=) attribute. <ins> 4.6. SenML can also be used for configuring parameters and controlling actuators.  When a SenML Pack is sent (e.g., using a HTTP/CoAP POST or PUT method) and the semantics of the target are such that SenML is interpreted as configuration/actuation, SenML Records are interpreted as a request to change the values of given resources (names) to given values at the given time(s). </ins> 5. The SenML labels (JSON object member names) shown in tbl-json-labels
Change:
The actually change looks good to me and if we fail to get all the examples correctly generated, don't worry, we can clean that up during WGLC

Discussion:
used with care or avoided as described in RFC7721. The resulting concatenated name MUST consist only of characters out <del> of the set "A" to "Z", "a" to "z", "0" to "9", "-", ":", ".", or "_" and it MUST start with a character out of the set "A" to "Z", "a" to "z", or "0" to "9".  This restricted character set was chosen so that these names can be directly used as in other types of URI including segments of an HTTP path with no special encoding and can be directly used in many databases and analytic systems.  RFC5952 contains advice on encoding an IPv6 address in a name. </del> <ins> of the set "A" to "Z", "a" to "z", "0" to "9", "-", ":", ".", "/", or "_" and it MUST start with a character out of the set "A" to "Z", "a" to "z", or "0" to "9".  This restricted character set was chosen so that these names can be directly used as in other types of URI including segments of an HTTP path with no special encoding and can be directly used in many databases and analytic systems.  RFC5952 contains advice on encoding an IPv6 address in a name. </ins> If the Record has no Unit, the Base Unit is used as the Unit.  Having no Unit and no Base Unit is allowed.
Change:
Why is there no sensml+cbor? (I can't really find where sensml+json is actually defined.) Is that really TODO?
sensml+json is defined in "Multiple Datapoints". Perhaps could be improved. That TODO was fixed in URL
That is an example, no? Where is the definition?
(In CBOR, SensML would just be a CBOR sequence. No need even for an array around that.) See also RFC 7464...

Discussion:
Magic number(s): none <del> File extension(s): senml </del> <ins> File extension(s): senml and sensml </ins> Macintosh file type code(s): none

Magic number(s): none <del> File extension(s): senml </del> <ins> File extension(s): senmlc </ins> Macintosh file type code(s): none

Magic number(s): none <del> File extension(s): senml </del> <ins> File extension(s): senmlx and sensmlx </ins> Macintosh file type code(s): none

Magic number(s): none <del> File extension(s): senml </del> <ins> File extension(s): senmle </ins> Macintosh file type code(s): none
Change:
Is there a reason we keep it for label registrations?
NAME Good point; same considerations apply to both. Will fix.
From Peter's review: or IESG Approval as defined in [RFC5226]. confusion.
It means that if something needs to happen and AD can make it happen without firing the expert which creates so much bad will that an AD would much rather wit 6 months for the expert to respond. All it says if the AD can do this or the expert can. I don't care much.
NAME Our AD had preference to have just Expert review in order for people to not think there are two paths but show clear preference. If things are slow, the IESG is next on the appeal path, so ADs can do it anyway.
Addressed by PR
Note that even with we still have the dual policy on the labels. Bug or feature?
On the "Our AD had preference to have just Expert review " ... I'm fine with this.
NAME The dual policy was fixed with the latest commit. Although perhaps we want to have more guidelines for the expert to follow?

Discussion:
strongly suggests a percentage (0..100) -- it is however NOT a percentage, but the absolute ratio! <del> New entries can be added to the registration by either Expert Review or IESG Approval as defined in RFC5226.  Experts should exercise their own good judgment but need to consider the following guidelines: </del> <ins> 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 the following guidelines: </ins> There needs to be a real and compelling use for any new unit to be added.

does not lose any information from the JSON value.  EXI uses the XML types. <del> New entries can be added to the registration by either Expert Review or IESG Approval as defined in RFC5226.  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 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. </ins> All new SenML labels that have "base" semantics (see senml-base) MUST start with character 'b'.  Regular labels MUST NOT start with that
Change:
target are such that SenML is interpreted as configuration/actuation"? And aren't configuration and actuation quite different use cases? These semantics need to be established out of band from SenML point of view. Could be something like CoRE interface type or LwM2M resource type that accepts SenML for this purpose. But we don't want to be prescriptive here. Perhaps giving example(s) is good approach
Addressed by PR

Discussion:
or PUT method) and the semantics of the target are such that SenML is interpreted as configuration/actuation, SenML Records are interpreted as a request to change the values of given (sub)resources (given as <del> names) to given values at the given time(s). </del> <ins> names) to given values at the given time(s).  The semantics of the target resource supporting this usage can be described, e.g., using I-D.ietf-core-interfaces.  Examples of actuation usage are shown in thermo-ex. </ins> 5.
Change:
I don't think we should not reference the inner/outer encryption, as we only define the e2ee encryption in the draft

Discussion:
7.2. The cipher suites defined in this draft use short authentication tags <del> for both inner and outer encryption, however it can easily support other ciphers with full authentication tag if the short ones are proved insecure. </del> <ins> for encryption, however it can easily support other ciphers with full authentication tag if the short ones are proved insecure. </ins> 8.
Change:
Add more information for how the CTR is used to derive the final IV
The current IV equation is IVCounter XOR SaltKey. This will lead to IV reuse across multiple blocks in AES-CTR for example Frame 0 AES(0) XOR Block0, AES(1) XOR Block1, AES(2) XOR Block2,... Frame 1 AES (1) XOR Block0, AES(2) XOR Block1, AES(3) XOR Block2,.. Frame 2 AES(2) XOR Block0, AES(3) XOR Block1, AES(4) XOR Block2,... The equation should be changed to shift the frame counter to high significant 8 bytes and the other 8 bytes will be zeros then do the XOR FrameCounter8 = DecodeVarIntIntoInt64(counter) FrameCounter16 = FrameCounter << 8 IV = FrameCounter16 XOR SaltKey
lgtm

Discussion:
media metadata The IV is 128 bits long and calculated from the CTR field of the <del> Frame header: </del> <ins> Frame header.  First the var int CTR is decoded into 16 bytes long field, where CTR fills the the 8 most significant bytes and low 8 bytes are always filled with zeros: </ins> 4.3.2.
Change:
This PR adds test vectors for SFrame encryption. A Go script is provided that implements the header encoding and the relevant encryption routines, generates test vectors for salient cases, and serializes them as Markdown or JSON. The Markdown version is included in the specification directly.

Discussion:
9. This document makes no requests of IANA. <ins> 10. This section provides a set of test vectors that implementations can use to verify that they correctly implement SFrame encryption and decryption.  For each ciphersuite, we provide: [in] The "base_key" value (hex encoded) [out] The "secret", "key", and "salt" values derived from the "base_key" (hex encoded) A plaintext value that is encrypted in the following encryption cases A sequence of encryption cases, including: [in] The "KID" and "CTR" values to be included in the header [out] The resulting encoded header (hex encoded) [out] The nonce computed from the "salt" and "CTR" values The ciphertext resulting from encrypting the plaintext with these parameters (hex encoded) An implementation should reproduce the output values given the input values.  Encryption with the input values and the plaintext should produce the ciphertext.  Decryption with the input values and the ciphertext should produce the plaintext. Line breaks and whitespace within values are inserted to conform to the width requirements of the RFC format.  They should be removed before use.  These test vectors are also available in JSON format at TestVectors. 10.1. 10.2. 10.3. 10.4. </ins>
Change:
I wasn't sure if CM was meant for "Counter Mode", if so, I thought using the standard terminology would be better... : )
I also originally got very confused by the CM acronym so definitely suggest taking the change.
NAME would you be able to rebase your commit?
NAME Should be good now. (~Note that I did not update the label in to avoid affecting the test vectors.~ Pushed a commit with updated test vectors.)
This PR looks good to me. I agree with the terminology change and the changes to the known-answer test generator. I re-ran the known-answer test generator locally and confirmed that it produced the test vectors in the PR.LGTM. This might conflict with URL depending on which PR gets merged first.

Discussion:
hash function: The AEAD encryption and decryption functions are then composed of <del> individual calls to the CM encrypt function and HMAC.  The resulting </del> <ins> individual calls to the CTR encrypt function and HMAC.  The resulting </ins> MAC value is truncated to a number of bytes "tag_len" fixed by the ciphersuite.
Change:
Move the pointer to docs for historical algorithms to the historic appendix. Correct the fact that this is now a WG document.

Discussion:
S/MIME receiving agents during certificate and CRL signature verification: <del> For 512-bit RSA with SHA-1 see RFC3279 and FIPS186-2 without Change Notice 1, for 512-bit RSA with SHA-256 see RFC4055 and FIPS186-2 without Change Notice 1, for 1024-bit through 3072-bit RSA with SHA-256 see RFC4055 and FIPS186-2 with Change Notice 1, and for 4096-bit RSA with SHA-256 see RFC4055 and RFC3447.  In either case, the first reference provides the signature algorithm's object identifier and the second provides the signature algorithm's definition. For 512-bit DSA with SHA-1 see RFC3279 and FIPS186-2 without Change Notice 1, for 512-bit DSA with SHA-256 see RFC5758 and FIPS186-2 without Change Notice 1, for 1024-bit DSA with SHA-1 see RFC3279 and FIPS186-2 with Change Notice 1, for 1024-bit through 3072 DSA with SHA-256 see RFC5758 and FIPS186-3.  In either case, the first reference provides the signature algorithm's object identifier and the second provides the signature algorithm's definition. </del> <ins> For 1024-bit through 3072-bit RSA with SHA-256 see RFC4055 and FIPS186-2 with Change Notice 1, and for 4096-bit RSA with SHA-256 see RFC4055 and RFC3447.  In either case, the first reference provides the signature algorithm's object identifier and the second provides the signature algorithm's definition. </ins> For RSASSA-PSS with SHA-256 see RFC4056. <ins> For ECDSA see RFC5758 and RFC6090.  The first reference provides the signature algorithm's object identifier and the second provides the signature algorithm's definition. For EdDSA see I-D.ietf-curdle-pkix and I-D.irtf-cfrg-eddsa.  The first reference provides the signature algorithm's object identifier and the second provides the signature algorithm's definition. </ins> 4.4. PKIX describes an extensible framework in which the basic certificate
Change:
Two sets of comments from Mark O, received after WGLC. One is a reference to the acknowledgement section, in which he would rather not see his name spelled out. The other is about residual risks of fronting server spoofing when only the hidden service is verified in TLS.

Discussion:
There are other classes of solutions in which the master secret is verified by verifying a certificate provided by the protected service.  These solutions offer more protection against a Man-In-The- <del> Middle attack by the fronting service. </del> <ins> Middle attack by the fronting service.  The downside is the the client will not verify the identity of the fronting service with risks discussed in {#frontingspoofing}, but solutions will have to mitigate this risks.  Overall, end-to-end TLS to the protected service is preferable. </ins> The fronting service could be pressured by adversaries.  By design, it could be forced to deny access to the protected service, or to

[1]. Thanks to Daniel Kahn Gillmor for a pretty detailed review of the <del> initial draft.  Thanks to Stephen Farrell, Mark Orchezowski, Martin Rex and Martin Thomson for their reviews. </del> <ins> initial draft.  Thanks to Stephen Farrell, Martin Rex Martin Thomson and employees of the UK National Cyber Security Centre for their reviews. </ins> 8.  References
Change:
The delayed merge of PR left a dangling reference in the markdown source. This is an attempt to fix the issue.

Discussion:
There are other classes of solutions in which the master secret is verified by verifying a certificate provided by the protected service.  These solutions offer more protection against a Man-In-The- <del> Middle attack by the fronting service.  The downside is the the client will not verify the identity of the fronting service with risks discussed in {#frontingspoofing}, but solutions will have to mitigate this risks.  Overall, end-to-end TLS to the protected service is preferable. </del> <ins> Middle attack by the fronting service.  The downside is that the client will not verify the identity of the fronting service, which enables fronting server spoofing attacks such as the "honeypot" attack discussed below.  Overall, end-to-end TLS to the protected service is preferable, but it is important to also provide a way to authenticate the fronting service. </ins> The fronting service could be pressured by adversaries.  By design, it could be forced to deny access to the protected service, or to
Change:
Trying to address the last comments (issue ).
NAME I hope this reflects our discussion.
Checking in after Roman's comments on the list.

Discussion:
httpfronting. This document does not present the design of a solution, but provides <del> guidelines for evaluating proposed solutions.  The need for related work on the encryption of the Application Layer Protocol Negotiation (ALPN) parameters of TLS is discussed in hiding-alpn. </del> <ins> guidelines for evaluating proposed solutions.  (The review of HTTP- level solutionsin httpfronting is not an endorsement of these solutions.)  The need for related work on the encryption of the Application Layer Protocol Negotiation (ALPN) parameters of TLS is discussed in hiding-alpn. </ins> 2.

They include: The SNI is probably also included in the general collection of <del> metadata by pervasive surveillance actors, for example to identify services used by surveillance targets. </del> <ins> metadata by pervasive surveillance actors RFC7258, for example to identify services used by surveillance targets. </ins> 2.2.

solutions that could quickly reach large scale deployments. Replacing clear text SNI transmission by an encrypted variant will <del> also thwart MITM interferences that are sometimes described as legitimate.  As explained in end-to-end, alternative solutions will have to be developed. </del> <ins> break or reduce the efficacy of the operational practices and techniques implemented in middle-boxes as described in snileak.  As explained in end-to-end, alternative solutions will have to be developed. </ins> 6.