jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-core-senml

Commentary: Why was 80 bytes chosen instead of , say , 50 bytes or 64 bytes or 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
The design goal is to be able to send simple sensor measurements in
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.
The design goal is to be able to send simple sensor measurements in
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.
Draft: draft-ietf-core-senml

Commentary: ( we have underscores for that )
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
system understands, the system SHOULD NOT use this object.  This
allows the version number to indicate that the object contains
mandatory to understand fields.  New version numbers can only be
defined in an RFC that updates this specification or it successors.
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
system understands, the system SHOULD NOT use this object.  This
allows the version number to indicate that the object contains
structure or semantics that is different from what is defined in the
present document beyond just making use of the extension points
provided here.  New version numbers can only be defined in an RFC
that updates this specification or it successors.
Draft: draft-ietf-core-senml

Commentary: Is there a reason we keep it for label registrations ? 
 Good point ; same considerations apply to both . Will fix . 
 From  's review : New entries can be to the registration by either Expert 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 do n't care much . 
 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 . 
 The dual policy was fixed with the latest commit . Although perhaps we want to have more guidelines for the expert to follow ?
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.
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.
Draft: draft-ietf-core-senml

Commentary: The actually change looks good to me and if we fail to get all the examples correctly generated , do n't worry , we can clean that up during WGLC
The resulting concatenated name MUST consist only of characters out
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.
The resulting concatenated name MUST consist only of characters out
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.
Draft: draft-ietf-core-senml

Commentary: 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 do n't like them , I can live with it as it is .
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).
Draft: draft-ietf-core-senml

Commentary: 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
a definite length byte string (type 2) .
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.
For streaming SensML in CBOR representation, the array containing
the records SHOULD be an CBOR indefinite length array while for
non streaming SenML, a definite length array MUST be used.
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).
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.
For streaming SensML in CBOR representation, the array containing
the records SHOULD be a CBOR indefinite length array while for
non-streaming SenML, a definite length array MUST be used.
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
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.
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
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.
Draft: draft-ietf-core-senml

Commentary: Added SenML Label definition and unified tag / attribute terminology . 
 LGTM
The basic design is an array with a series of measurements.  The
following example shows two measurements made at different times.
The value of a measurement is in the "v" tag, the time of a
measurement is in the "t" tag, the "n" tag has a unique sensor name,
and the unit of the measurement is carried in the "u" tag.
To keep the messages small, it does not make sense to repeat the "n"
tag in each SenML Record so there is a concept of a Base Name which
is simply a string that is prepended to the Name field of all
elements in that record and any records that follow it.  So a more
compact form of the example above is the following.
In the above example the Base Name is in the "bn" tag and the "n"
tags in each Record are the empty string so they are omitted.
The basic design is an array with a series of measurements.  The
following example shows two measurements made at different times.
The value of a measurement is given by the "v" attribute, the time of
a measurement is in the "t" attribute, the "n" attribute has a unique
sensor name, and the unit of the measurement is carried in the "u"
attribute.
To keep the messages small, it does not make sense to repeat the "n"
attribute in each SenML Record so there is a concept of a Base Name
which is simply a string that is prepended to the Name field of all
elements in that record and any records that follow it.  So a more
compact form of the example above is the following.
In the above example the Base Name is in the "bn" attribute and the
"n" attributes in each Record are the empty string so they are
omitted.
A short name used in SenML Records to denote different SenML
attributes (e.g., "v" for "value").
The SenML Stream is represented as a sensml tag that contains a
series of senml tags for each SenML Record.  The SenML Fields are
represents as XML attributes.  The following table shows the mapping
of the SenML labels, which are used for the attribute name, to the
attribute types used in the XML senml tags.
The SenML Stream is represented as a sensml tag that contains a
series of senml tags for each SenML Record.  The SenML attributes are
represented as XML attributes.  The following table shows the mapping
of the SenML labels, which are used for the attribute name, to the
attribute types used in the XML senml tags.
Draft: draft-ietf-core-senml

Commentary: See email from paul L Nov1 to media - types Hello Cullen , it seems to me that all the content - types you have been describing about senML are candidate content types to be exchanged over the clipboard of a normal mobile or desk computer ; e.g. from a reading app to another , … Do you agree on this ? If yes , then I ’d like to recommend to add : MacOS Uniform Type Identiers   Name for each of the content - types . If there is earlier experience in this realm , probably this should be taken , otherwise , I can probably suggest some clipboard names . Standardising such at the Media - Type declaration level allows to set a reference frame so that other implementations can follow , just as the content - type name . For examples of including this in the media - type registration , see that of SVG or MathML . thanks in advance .  
 At IETF 97 was " probably should do this " - see 
 See MathML at 
 On the UTI , currently only apple can declare ones in the public space ( see ) . I do not see how to request one . There is a bunch of extra info apple would need to add to the OS to really make this work outlined in 
 Windows clipboard info at ( v = vs.85).aspx 
 Makes sense ; no need for a clipboard format for the streaming and compressed versions actually .
The following registrations are done following the procedure
specified in RFC6838 and RFC7303.
The following registrations are done following the procedure
specified in RFC6838 and RFC7303.  Clipboard formats are defined for
the JSON and XML form of lists but do not make sense for streams or
other formats.
Draft: draft-ietf-core-senml

Commentary: Make sure the way we use schemaID match how it is defined in EXI . ( See email from     10 , 2016 )
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.
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.
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
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
contain information about where to find out more information about
this label.
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
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
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
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.
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
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.
Draft: draft-ietf-core-senml

Commentary: 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
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.
Draft: draft-ietf-core-senml

Commentary: 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  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
Only the UTF-8 form of JSON is allowed.  Characters in the String
Value are encoded using the escape sequences defined in RFC7159.
Characters in the Data Value are base64 encoded with URL safe
alphabet as defined in Section 5 of RFC4648.
Only the UTF-8 form of JSON 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.
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) .
A SenML Pack or Stream can also be represented in XML format as
defined in this section.  The following example shows an XML example
for the same sensor measurement as in co-ex.
A SenML Pack or Stream can also be represented in XML format as
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.
Draft: draft-ietf-core-senml

Commentary: When we convert from between formats , no information should be lost
Systems receiving measurements MUST be able to process the range of
floating point numbers that are representable as an IEEE double-
precision floating-point numbers IEEE.754.1985.  The number of
significant digits in any measurement is not relevant, so a reading
of 1.1 has exactly the same semantic meaning as 1.10.  If the value
has an exponent, the "e" MUST be in lower case.  The mantissa SHOULD
be less than 19 characters long and the exponent SHOULD be less than
5 characters long.  This allows time values to have better than micro
second precision over the next 100 years.
Systems receiving measurements MUST be able to process the range of
floating point numbers that are representable as an IEEE double
precision floating point numbers IEEE.754.1985.  The number of
significant digits in any measurement is not relevant, so a reading
of 1.1 has exactly the same semantic meaning as 1.10.  If the value
has an exponent, the "e" MUST be in lower case.  The mantissa SHOULD
be less than 19 characters long and the exponent SHOULD be less than
5 characters long.  This allows time values to have better than micro
second precision over the next 100 years.
For JSON Numbers, the CBOR representation can use integers,
floating point numbers, or decimal fractions (CBOR Tag 4); the
common limitations of JSON implementations are not relevant for
these.  For the version number, however, only an unsigned integer
is allowed.
For JSON Numbers, the CBOR representation can use integers,
floating point numbers, or decimal fractions (CBOR Tag 4); however
a representation SHOULD be choosen such that when the CBOR value
is converted back to an IEEE double precision floating point
value, it has exactly the same value as the original Number.  For
the version number, only an unsigned integer is allowed.
Draft: draft-ietf-core-senml

Commentary: Clarify semantics of base time 0 ( " now " ) 
 For base time , draft already has If either the Base Time or Time value is missing , the missing attribute is considered to have a value of zero .
If only one of the Base Sum or Sum value is present, the missing
attribute is considered to have a value of zero.  The Base Sum and
Sum values are added together to get the sum of measurement.  If
neither the Base Sum or Sum are present, then the measurement does
not have a sum value.
Draft: draft-ietf-core-senml

Commentary: Indefinite length for the streaming mode , definite otherwise .
For streaming SensML in CBOR representation, the array containing
the records SHOULD be an CBOR indefinite length array while for
non streaming SenML, a definite length array MUST be used.