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

Commentary: The RFC editor will add in the missing comma . Maybe use the usual sequence ( confidentiality first ) . But all this is motherhood and apple pie anyway ... 
 LGTM - thanks
The SenML formats alone do not provide any security and instead rely
on the protocol that carries them to provide security.  Applications
using SenML need to look at the overall context of how these formats
will be used to decide if the security is adequate.  In particular
for sensitive sensor data and actuation use it is important to ensure
that proper security mechanisms are used.
The SenML formats alone do not provide any security and instead rely
on the protocol that carries them to provide security.  Applications
using SenML need to look at the overall context of how these formats
will be used to decide if the security is adequate.  In particular
for sensitive sensor data and actuation use it is important to ensure
that proper security mechanisms are used to provide, e.g.,
confidentiality, data integrity, and authentication as appropriate
for the usage.
Draft: draft-ietf-core-senml

Commentary: As per  '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
Record in the Pack.
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
Record in the Pack, or by using the default value.
If the Record has no Unit, the Base Unit is used as the Unit.  Having
no Unit and no Base Unit is allowed.
If the Record has no Unit, the Base Unit is used as the Unit.  Having
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.
Draft: draft-ietf-core-senml

Commentary: This should be a cleaned up version of , which somehow got messed up . 
 LGTM
In some usage scenarios of SenML, the implementations MAY store or
transmit SenML in a stream-like fashion, where data is collected over
time and continuously added to the object.  This mode of operation is
optional, but systems or protocols using SenML in this fashion MUST
specify that they are doing this.  SenML defines separate media types
to indicate Sensor Streaming Measurement Lists (SensML) for this
usage (see sec-sensml-json).  In this situation, the SensML stream
can be sent and received in a partial fashion, i.e., a measurement
entry can be read as soon as the SenML Record is received and does
not have to wait for the full SensML Stream to be complete.
In some usage scenarios of SenML, the implementations store or
transmit SenML in a stream-like fashion, where data is collected over
time and continuously added to the object.  This mode of operation is
optional, but systems or protocols using SenML in this fashion MUST
specify that they are doing this.  SenML defines separate media types
to indicate Sensor Streaming Measurement Lists (SensML) for this
usage (see sec-sensml-json).  In this situation, the SensML stream
can be sent and received in a partial fashion, i.e., a measurement
entry can be read as soon as the SenML Record is received and does
not have to wait for the full SensML Stream to be complete.
The following registrations are done following the procedure
specified in RFC6838 and RFC7303.  This document registers media
types for each serialization format of SenML (JSON, CBOR, and EXI)
and also media types for the same formats of the streaming use
(SensML).  Clipboard formats are defined for the JSON and XML form of
lists but do not make sense for streams or other formats.
The following registrations are done following the procedure
specified in RFC6838 and RFC7303.  This document registers media
types for each serialization format of SenML (JSON, CBOR, XML, and
EXI) and also an equivalent set of media types for the streaming use
(SensML, see sec-sensml).  Clipboard formats are defined for the JSON
and XML forms of SenML but not for streams or non-textual formats.
The reason there are both SenML and the streaming SensML formats is
that they are not the same data formats and they require separate
negotiation to understand if they are supported and which one is
being used.  The non streaming format is required to have some sort
of end of pack syntax which indicates there will be no more records.
Many implementations that receive SenML wait for this end of pack
marker before processing any of the records.  On the other hand, with
the streaming formats, it is explicitly not required to wait for this
end of pack marker.  Many implementations that produce streaming
SensML will never send this end of pack marker so implementations
that receive streaming SensML can not wait for the end of pack marker
before they start processing the records.  Given the SenML and
streaming SenML are different data formats, and requirement for
separate negotiation, a media type for each one is needed.
Draft: draft-ietf-core-senml

Commentary: EXI is XML so for consistency we should allow anything that is allowed for ( character ) XML for EXI as well . Make  ' point about content negotiation possibly leading to a format where xpointer does not apply and add the  workaround . 
 LGTM
In addition to the SenML Fragment Identifiers described above, with
the XML SenML formats also the syntax defined in XPointerFramework
can be used, as recommended by RFC7303.
Note that fragment identifiers are available to the client side only;
they are not provided in transfer protocols such as CoAP or HTTP.
Thus, they cannot be used by the server in deciding which media type
to send.  Where a server has multiple representations available for a
resource identified by a URI, it might send a JSON or CBOR
representation when the client was directed to use an XML/EXI
fragment identifier with this.  Clients can prevent running into this
problem by explicitly requesting an XML or EXI media type (e.g.,
using the CoAP Accept option) when XML/EXI-only fragment identifier
syntax is in use in the URI.
Draft: draft-ietf-core-senml

Commentary: I 'm fine with this .
Note that fragment identifiers are available to the client side only;
they are not provided in transfer protocols such as CoAP or HTTP.
Thus, they cannot be used by the server in deciding which media type
to send.  Where a server has multiple representations available for a
resource identified by a URI, it might send a JSON or CBOR
representation when the client was directed to use an XML/EXI
fragment identifier with this.  Clients can prevent running into this
problem by explicitly requesting an XML or EXI media type (e.g.,
using the CoAP Accept option) when XML/EXI-only fragment identifier
syntax is in use in the URI.
Draft: draft-ietf-core-senml

Commentary: Please see
Obviously, "now"-referenced SenML records are only useful within a
specific communication context (e.g., based on information on when
the SenML pack was sent) or together with some other context
information that can be used for deriving a meaning of "now"; the
expectation for any archival use is that they will be processed into
UTC-referenced records before that context would cease to be
available.  This specification deliberately leaves the accuracy of
"now" very vague as it is determined by the overall systems that use
SenML.  In a system where a sensor without wall-clock time sends a
SenML record with a "now"-referenced time over a high speed RS 485
link to an embedded system with accurate time that resolves "now"
based on the time of reception, the resulting time uncertainty could
be within 1 ms.  At the other extreme, a deployment that sends SenML
wind speed readings over a LEO satellite link from a mountain valley
might have resulting reception time values that are easily a dozen
minutes off the actual time of the sensor reading, with the time
uncertainty depending on satellite locations and conditions.
Draft: draft-ietf-core-senml

Commentary: PR proposes fixes
Integrated sum of the values over time.  Optional.  This field is
in the unit specified in the Unit value multiplied by seconds.
Integrated sum of the values over time.  Optional.  This field is
in the unit specified in the Unit value multiplied by seconds.
For historical reason it is named sum instead of integral.
The measurements support sending both the current value of a sensor
as well as an integrated sum.  For many types of measurements, the
sum is more useful than the current value.  For example, an
electrical meter that measures the energy a given computer uses will
typically want to measure the cumulative amount of energy used.  This
is less prone to error than reporting the power each second and
trying to have something on the server side sum together all the
power measurements.  If the network between the sensor and the meter
goes down over some period of time, when it comes back up, the
cumulative sum helps reflect what happened while the network was
down.  A meter like this would typically report a measurement with
the unit set to watts, but it would put the sum of energy used in the
"s" field of the measurement.  It might optionally include the
current power in the "v" field.
The measurements support sending both the current value of a sensor
as well as an integrated sum.  For many types of measurements, the
sum is more useful than the current value.  For historical reasons,
this field is called "sum" instead of "integral" which would more
accurately describe its function.  For example, an electrical meter
that measures the energy a given computer uses will typically want to
measure the cumulative amount of energy used.  This is less prone to
error than reporting the power each second and trying to have
something on the server side sum together all the power measurements.
If the network between the sensor and the meter goes down over some
period of time, when it comes back up, the cumulative sum helps
reflect what happened while the network was down.  A meter like this
would typically report a measurement with the unit set to watts, but
it would put the sum of energy used in the "s" field of the
measurement.  It might optionally include the current power in the
"v" field.
Despite the name sum, the sum field is not useful for applications
that maintain a running count of the number of times that an event
happened or keeping track of a counter such as the total number of
bytes sent on an interface.  Data like that can be sent directly in
the value field.
Draft: draft-ietf-core-senml

Commentary: A bit verbose in the seccons , but OK.LGTM
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, i.e., labels starting with the character 'b', except
for Version fields (see below), and has no relative times.  To
resolve the records, 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 the 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.
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.  Also, if SenML Records are used outside of a SenML
Pack, they need to be resolved first to ensure applicable base values
are applied.
A SenML Record is referred to as "resolved" if it does not contain
any base values, i.e., labels starting with the character 'b', except
for Version fields (see below), and has no relative times.  To
resolve the Records, the applicable base values of the SenML Pack (if
any) are applied to the Record.  That is, for the base values in the
Record or before the Record in the Pack, name and base name are
concatenated, base time is added to the time of the Record, if the
Record did not contain Unit the Base Unit is applied to the record,
etc.  In addition the records need to be in chronological order in
the Pack.  An example of this is show in resolved-ex.
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 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.  The base values are given negative CBOR labels
and others non-negative labels.
SenML Records are intended to be interpreted in the context of any
applicable base values.  If records become separated from the record
that establishes the base values, the data will be useless or, worse,
wrong.  Care needs to be taken in keeping the integrity of a Pack
that contains unresolved SenML Records (see resolved-records).
Draft: draft-ietf-core-senml

Commentary: Fragment ID text for SensML types was still referring to SenML types
Fragment identifier considerations: Fragment identification for
application/senml+json is supported by using fragment identifiers as
specified by RFC-AAAA.
Fragment identifier considerations: Fragment identification for
application/sensml+json is supported by using fragment identifiers as
specified by RFC-AAAA.
Fragment identifier considerations: Fragment identification for
application/senml+cbor is supported by using fragment identifiers as
specified by RFC-AAAA.
Fragment identifier considerations: Fragment identification for
application/sensml+cbor is supported by using fragment identifiers as
specified by RFC-AAAA.
Fragment identifier considerations: Fragment identification for
application/senml+xml is supported by using fragment identifiers as
specified by RFC-AAAA.
Fragment identifier considerations: Fragment identification for
application/sensml+xml is supported by using fragment identifiers as
specified by RFC-AAAA.
Fragment identifier considerations: Fragment identification for
application/senml-exi is supported by using fragment identifiers as
specified by RFC-AAAA.
Fragment identifier considerations: Fragment identification for
application/sensml-exi is supported by using fragment identifiers as
specified by RFC-AAAA.
Draft: draft-ietf-core-senml

Commentary: Looks good .
Units for a measurement value.  Optional.
Unit for a measurement value.  Optional.
Integrated sum of the values over time.  Optional.  This field is
in the units specified in the Unit value multiplied by seconds.
Integrated sum of the values over time.  Optional.  This field is
in the unit specified in the Unit value multiplied by seconds.
the units set to watts, but it would put the sum of energy used in
the "s" field of the measurement.  It might optionally include the
current power in the "v" field.
the unit set to watts, but it would put the sum of energy used in the
"s" field of the measurement.  It might optionally include the
current power in the "v" field.
Units should define the semantic information and be chosen
carefully. implementers need to remember that the same word may be
used in different real-life contexts.  For example, degrees when
measuring latitude have no semantic relation to degrees when
measuring temperature; thus two different units are needed.
Each unit should define the semantic information and be chosen
carefully.  Implementers need to remember that the same word may
be used in different real-life contexts.  For example, degrees
when measuring latitude have no semantic relation to degrees when
measuring temperature; thus two different units are needed.
Draft: draft-ietf-core-senml

Commentary: Alternatively we can have the same text 9 times instead of 8 
 Alexey confirmed in the CoRE session that this is OK , so let 's go forward with this . 
 The IANA types review list explicitly wanted all of this repeated because they do n't read the draft on the email and each type needs it 's own email . It is insane . So I would not make this change . LGTM
Note to RFC Editor - please remove this paragraph.  Note that a
request for media type review for senml+json was sent to the media-
types@iana.org on Sept 21, 2010.  A second request for all the types
was sent on October 31, 2016.
Note to RFC Editor - please remove this paragraph.  Note that a
request for media type review for senml+json was sent to the media-
types@iana.org on Sept 21, 2010.  A second request for all the types
was sent on October 31, 2016.  Please change all instances of RFC-
AAAA with the RFC number of this document.
See sec-privacy.  Further discussion of security properties can be
found in sec-iana-media.
Sensor data can contain a wide range of information ranging from
information that is very public, such as the outside temperature in a
given city, to very private information that requires integrity and
confidentiality protection, such as patient health information.  The
SenML format does not provide any security and instead relies on the
protocol that carries it to provide security.  Applications using
SenML need to look at the overall context of how this media type will
be used to decide if the security is adequate.
See also sec-privacy.
Draft: draft-ietf-core-senml

Commentary: Got lost from previous policy fix PR 
 Looks goodLGTM
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.
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.  New entries should not be made that counteract the advice at
the end of considerations.
Draft: draft-ietf-core-senml

Commentary:  's comments : The issue is that neither of the above have an asterisk by them , so both are recommended and per  ’s definition of “ units ” during the meeting ( i.e. , where the reference point is separate from the units ) , then  and  have the same units as they only vary by what the reference point is .
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).
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.
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.
Draft: draft-ietf-core-senml

Commentary: I like this .
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).
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 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 should not be made that
counteract the advice at the end of considerations.
Draft: draft-ietf-core-senml

Commentary: target are such that SenML is interpreted as configuration / actuation " ? And are n'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 LwM2 M resource type that accepts SenML for this purpose . But we do n't want to be prescriptive here . Perhaps giving example(s ) is good approach 
 Addressed by PR
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 (sub)resources (given as
names) to given values at the given time(s).
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 (sub)resources (given as
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.