jiebi/TextFlow huggingface dataset:
Original text:
not set a sector name in their registrations.  An RD can set a default sector name for registrations accepted under this policy, which is useful especially in a segmented setup where different <del> policies apply to different sectors. </del>  8.

Reviewer comments:
See-Also: URL Apart from pointing out the scope, this also comprehensively lists the few configuration options that are there for such an RD. Hi, Thank you for this document. I'm glad that the shepherd's writeup indicates that there are implementations since that indicates that there does appear to be value in standardizing this work, despite its long journey. My main comment (which I was considering raising as a discuss) is: Since this document is defining a new service, I think that this document would benefit on having a short later section on "Operations, Administration and Management". This document does seem to cover some management/administration considerations in various sections in a somewhat ad hoc way, but having a section highlighting those would potentially make it easier deploy.  Defining a common management model (or API) would potentially also make administration of the service easier, I don't know if that had been considered, and if useful could be done as a separate document. A few other comments: What happens if an endpoint is managing the registration and is upgraded to new hardware with a different certificate?  Would the updated endpoint expect to be able to update the registration?  Or would it have to wait for the existing registration to timeout (which could be a long time)? Nit: Perhaps reword the second sentence.  Otherwise it seems to conflict with the last sentence of the prior paragraph. The "SHOULD NOT" feels a bit strong to me, and I would prefer to see this as "MAY NOT".  In many cases, if the configuration is not too big then providing the full configuration makes it easy to guarantee that the receiver has exactly the correct configuration.  I appreciate that there are many cases where from an endpoint perspective it may want to keep the update small, but if I was doing this from a CT, I think that I would rather just resend the entire configuration, if it is not large. Just to check, is it correct that the anchor in the http link is also to coap://?  If this is wrong then there is a second example in the same section that also needs to be fixed.

Revised text:
not set a sector name in their registrations.  An RD can set a default sector name for registrations accepted under this policy, which is useful especially in a segmented setup where different  <ins> policies apply to different sectors.  The configuration of such a behavior, as well as any other configuration applicable to such an RD (i.e. the set of recognized authorities) is out of scope for this document. </ins> 8.
Original text:
The following example shows a client performing an endpoint type lookup: <del> The following example shows a client performing a domain lookup: </del> The following example shows a client performing a group lookup for all groups:

Reviewer comments:
These changes were talked about previously in Prague and allow preservation of link relationships. A new example based on the relevant RFC6690 example shows different relevant cases (with present in the registration) in the lookup interface. The latest suggestions of bringing the endpoint interface in line with that are not included yet.
RFC5988 (web linking) describes that a statement of in the context of A means that "A has a hosted resource at B, which has the attribute C=D" (with the implied "hosts" relationship from RFC6690). The repeated entries of the pattern currently drafted for the domain lookup interface (and the analogous group lookups) are bear no such meaning, and all provide statements about the same resource. In a way, they could be collapsed into (or ). Given it then talks about the currently used resource-directory (that is ), isn't that a more straightforward to express the desired information anyway?
See issue I think we need to include the group resource location, which is returned when a group is created, in the angle brackets or "href". I also believe we shod not specify a "domain" lookup because we decided to specify domain as an attribute of a registration. There is no domain table to do lookups on...

Revised text:
The following example shows a client performing an endpoint type lookup:  The following example shows a client performing a group lookup for all groups:
Original text:
The endpoint then finds one or more addresses of the directory server as described in simple_finding. <del> An endpoint can send (a selection of) hosted resources to a directory server for publication as described in simple_publishing. </del>  The directory server integrates the information it received this way into its resource directory.  It MAY make the information available

Reviewer comments:
Some minor text changes (commented per commit) I think are resonable and will merge soon unless someone speaks up against them.

Revised text:
The endpoint then finds one or more addresses of the directory server as described in simple_finding.  <ins> An endpoint finally asks the directory server to probe it for resources and publish them as described in simple_publishing. </ins> The directory server integrates the information it received this way into its resource directory.  It MAY make the information available
Original text:
Endpoint type (optional).  Used for group, endpoint and resource lookups. <del> Link attribute parameters (optional).  Any link target attribute as defined in Section 4.1 of RFC6690, used for resource lookups. </del>  application/link-format (optional)

Reviewer comments:
I think that rt is not an attribute of a registration; the first commit reflects that. (The second is more bycatch from that). Possibly we can simplify the whole section; as everything in the result is links, we're only applying the same link filtering that 6690 already specifies (plus pagination).
Absolutely right. After all commits by Christian, I will look at these examples again together with discovery text and other details. cabo schreef op 2017-10-19 16:57:

Revised text:
Endpoint type (optional).  Used for group, endpoint and resource lookups.  <ins> Link parameters (optional).  Any link parameter as defined in Section 4.1 of RFC6690, including href, used for resource lookups. </ins> application/link-format (optional)
Original text:
similar to example-discovery. A Resource Directory may optionally support HTTP.  Here is an example <del> of the same registration operation above, when done using HTTP. </del>  5.3.1. with the example resource look-up locations discovered in example- discovery:  The following example shows a client performing an endpoint type lookup:

Reviewer comments:
See individual commit messages
As we support the alternative serializations from draft-ietf-core-links-json, I'd like to add at least the numbers in the RD lookup examples.
Use TBD64 etc., as discussed in the call.

Revised text:
similar to example-discovery. A Resource Directory may optionally support HTTP.  Here is an example  <ins> of almost the same registration operation above, when done using HTTP and the JSON Link Format. </ins> 5.3.1. with the example resource look-up locations discovered in example- discovery: <ins> The same lookup using the CBOR Link Format media type: </ins> The following example shows a client performing an endpoint type lookup:
Original text:
registration resource.  The registration resource location thus returned is for the purpose of updating the lifetime of the registration and for maintaining the content of the registered <del> links, including updating and deleting links. </del>  4.00 "Bad Request" or 400 "Bad Request".  Malformed request. <del> 4.09 "Conflict" or 409 "Conflict".  Attempt to create a registration resource with ep and d value pair which is already present in an earlier created registration resource. </del> 5.03 "Service Unavailable" or 503 "Service Unavailable".  Service could not perform the operation.

Reviewer comments:
The description of the Registration interface describes it as idempotent, I think it should be idempotent on CoAP and not only on application level -- the same request results in the same response with no further state change. As to what happens when the re-registration arrives with a different set of links, there we have options; I went for "replaces the registration" here, but a 4.09 in that case would be just as valid an option. NAME that topic came up with the removal of the plurality removal at URL Do you agree with the basic proposition of "an unmodified request should be 2.04", and do you think replacing is the right way, or 4.09 if the links don't match?
Replacement is OK, given the removal of "addition of inks" with a POST. Conflicts are indeed impossible then.

Revised text:
registration resource.  The registration resource location thus returned is for the purpose of updating the lifetime of the registration and for maintaining the content of the registered  <ins> links, including updating and deleting links.  A registration with an already registered ep and d value pair responds with the same success code and Location as the original registration; the set of links registered with the endpoint is replaced with the links from the payload. </ins> 4.00 "Bad Request" or 400 "Bad Request".  Malformed request.  5.03 "Service Unavailable" or 503 "Service Unavailable".  Service could not perform the operation.
Original text:
detected and used according to their own specifications and can be used with the lookup interface as with any other resource.  The lookup interface is specified as follows: Client -> RD

Reviewer comments:
Unless takes a very surprising turn, I suggest reverting this: /rd-lookup/res (assuming it was discovered) always exists 2.03 is the wrong code this prescribes things already following from general observation Not reverting it yet awaiting the closure of .
chrysn schreef op 2018-01-31 12:26: Peter

Revised text:
detected and used according to their own specifications and can be used with the lookup interface as with any other resource. <ins> When resource observation is used, the following convention MUST be followed: When /rd-lookup/res does not exist, the response code 4.04 (Not Found) is returned and the request is not registered. When rd-lookup/res exists, the request is registered in the list of subjects and observers. When none of the links matches the filter, an empty payload with response code 2.03 (Valid) is returned. In all other cases, the set of matching links is returned in the payload with response code 2.05 (Content). Every time, the set of matching links changes, or the content of a matching link changes, the RD sends a notification with the matching link set. </ins> The lookup interface is specified as follows: Client -> RD
Original text:
application/link-format+cbor and application/link-format+json, respectively, as they are defined in I-D.ietf-core-links-json. ] <del> At the same location where URI discovery happens, a user who wants to debug interoperability issues can ask for additional information that might be available about the server using generic resource discovery techniques.  That information would typically be stored in an implementation information link (as described in I-D.bormann-t2trg- rel-impl): </del>  Note that depending on the particular server's architecture, such a link could be anchored at the server's root, at the discovery site

Reviewer comments:
This adds an example of how impl-info can be used to obtain implemetation software and version information. Closes: URL
But why would you want to do the latter, if not for the former or for some privacy-intrusive application? (Well, OK, netcraft style surveys. But these are not the motivation for documenting this, either.) Grüße, Carsten
The text in the RD spec suggests that debugging is needed and that debugging is possible thanks to the rel-impl relation. That is a bit strong: I can debug without the rel-impl relation. cabo schreef op 2018-01-31 17:27:
I was referring to generic use of .well-known/core as opposed to the formally limited interface ( described in the URI Discovery section. The pull request will be updated to address both concerns; thanks for the review.
Closed after immediate comments were addressed; it appears we're deep enough into the discussion of impl-info details that the direction is good.
There is a lot of confusing info in the first 4 lines. Debugging is not the problem, getting information about the implementation is. What are generic resource discovery techniques? We do have one specification called RD., and /.well-known/core The example is terse; Nice to know what the link means or is supposed to provide Thanks for the text; it helps to focus.

Revised text:
application/link-format+cbor and application/link-format+json, respectively, as they are defined in I-D.ietf-core-links-json. ]  <ins> A user can introspect the server for implementation information to ease debugging by using the URI discovery address as described in RFC6690 Section 4.  Information about the used software would typically be stored in an implementation information link (as described in I-D.bormann-t2trg-rel-impl): </ins> Note that depending on the particular server's architecture, such a link could be anchored at the server's root, at the discovery site
Original text:
inspect a copy of the information, usually mirrored by an optical splitter, making it an ideal pairing for DPI and Protocol Identification Weaver-2009 (this asynchronous version of a MITM is <del> ofen called a Man-on-the-Side (MOTS)).  RST Packet Injection also has the advantage of only requiring one of the two endpoints to accept the spoofed packet for the connection to be interrupted.  The </del>  difficult part of RST Packet Injection is spoofing "enough" correct information to ensure one end-point accepts a RST packet as legitimate; this generally implies a correct IP, port, and (TCP) As the name implies, sometimes manpower is the easiest way to figure out which content to block.  Manual Filtering differs from the common <del> tactic of building up blacklists in that is doesn't necessarily </del>  target a specific IP or DNS, but instead removes or flags content. Given the imprecise nature of automatic filtering, manually sorting through content and flagging dissenting websites, blogs, articles and

Reviewer comments:
A few more typos I found while I was reading this I-D.
Thanks again!

Revised text:
inspect a copy of the information, usually mirrored by an optical splitter, making it an ideal pairing for DPI and Protocol Identification Weaver-2009 (this asynchronous version of a MITM is  <ins> often called a Man-on-the-Side (MOTS)).  RST Packet Injection also has the advantage of only requiring one of the two endpoints to accept the spoofed packet for the connection to be interrupted.  The </ins> difficult part of RST Packet Injection is spoofing "enough" correct information to ensure one end-point accepts a RST packet as legitimate; this generally implies a correct IP, port, and (TCP) As the name implies, sometimes manpower is the easiest way to figure out which content to block.  Manual Filtering differs from the common  <ins> tactic of building up blacklists in that it doesn't necessarily </ins> target a specific IP or DNS, but instead removes or flags content. Given the imprecise nature of automatic filtering, manually sorting through content and flagging dissenting websites, blogs, articles and
Original text:
This key exchange algorithm is the same as ECDHE_ECDSA except that the server's certificate MUST contain an RSA public key authorized for signing, and that the signature in the ServerKeyExchange message <del> must be computed with the corresponding RSA private key.  The server certificate MUST be signed with RSA. </del>  2.3. resultant shared secret as the premaster secret.  All ECDH calculations are performed as specified in alg_computes. <del> Note that while the ECDHE_ECDSA and ECDHE_RSA key exchange algorithms require the server's certificate to be signed with a particular signature scheme, this specification (following the similar cases of DHE_DSS, and DHE_RSA in the TLS base documents) does not impose restrictions on signature schemes used elsewhere in the certificate chain.  (Often such restrictions will be useful, and it is expected that this will be taken into account in certification authorities' signing practices.  However, such restrictions are not strictly required in general: Even if it is beyond the capabilities of a client to completely validate a given chain, the client may be able to validate the server's certificate by relying on a trusted certification authority whose certificate appears as one of the intermediate certificates in the chain.) </del>  3. 3.1. To use this authentication mechanism, the client MUST possess a <del> certificate containing an ECDSA-capable public key and signed with ECDSA. </del>  The client proves possession of the private key corresponding to the certified key by including a signature in the CertificateVerify

Reviewer comments:
TLS 1.1 and earlier required the signature algorithm in the certificate to match that of the public key. TLS 1.2 removed this restriction. Since RFC 4492 predated TLS 1.2 it reflected the same restriction. Here we remove it.

Revised text:
This key exchange algorithm is the same as ECDHE_ECDSA except that the server's certificate MUST contain an RSA public key authorized for signing, and that the signature in the ServerKeyExchange message  <ins> must be computed with the corresponding RSA private key. </ins> 2.3. resultant shared secret as the premaster secret.  All ECDH calculations are performed as specified in alg_computes.  <ins> This specification does not impose restrictions on signature schemes used anywhere in the certificate chain.  The previous version of this document required the signatures to match, but this restriction, originating in previous TLS versions is lifted here as it had been in RFC 5246. </ins> 3. 3.1. To use this authentication mechanism, the client MUST possess a  <ins> certificate containing an ECDSA-capable public key. </ins> The client proves possession of the private key corresponding to the certified key by including a signature in the CertificateVerify
Original text:
5.1.1. <del> RFC 4492 defined 25 different curves in the NamedCurve registry for use in TLS.  Only three have seen any use.  This specification is deprecating the rest (with numbers 1-22).  This specification also deprecates the explicit curves with identifiers 0xFF01 and 0xFF02. It also adds the new curves defined in CFRG-Curves and CFRG-EdDSA. The end result is as follows: </del>  Note that other specification have since added other values to this enumeration. RFC4492, the predecessor of this document has already defined the IANA registries for the following: <del> NamedCurve </del>  ECPointFormat ECCurveType For each name space, this document defines the initial value assignments and defines a range of 256 values (NamedCurve) or eight <del> values (ECPointFormat and ECCurveType) reserved for Private Use.  Any additional assignments require IETF Review. </del>  <del> NOTE: IANA, please update the registries to reflect the new policy name. </del>  NOTE: RFC editor please delete these two notes prior to publication.

Reviewer comments:
See Sean Turner's message IETF review is too onerous - use "specification required" instead.

Revised text:
5.1.1.  <ins> RFC 4492 defined 25 different curves in the NamedCurve registry (now renamed the "Supported Groups" registry, although the enumeration below is still named NamedCurve) for use in TLS.  Only three have seen much use.  This specification is deprecating the rest (with numbers 1-22).  This specification also deprecates the explicit curves with identifiers 0xFF01 and 0xFF02.  It also adds the new curves defined in CFRG-Curves and CFRG-EdDSA.  The end result is as follows: </ins> Note that other specification have since added other values to this enumeration. RFC4492, the predecessor of this document has already defined the IANA registries for the following:  <ins> Supported Groups </ins> ECPointFormat ECCurveType For each name space, this document defines the initial value assignments and defines a range of 256 values (NamedCurve) or eight  <ins> values (ECPointFormat and ECCurveType) reserved for Private Use.  The policy for any additional assignments is "Specification Required". The previous version of this document required IETF review. </ins>  <ins> NOTE: IANA, please update the registries to reflect the new policy. </ins> NOTE: RFC editor please delete these two notes prior to publication.
Original text:
IANA is requested to assign two values from the NamedCurve registry with names eddsa_ed25519(TBD3) and eddsa_ed448(TBD4) with this document as reference.  IANA has already assigned the value 29 to <del> ecdh_x25519, and the value 30 to ecdh_x448(TBD2). </del>  IANA is requested to assign one value from SignatureAlgorithm Registry with name eddsa(TBD5) with this document as reference.

Reviewer comments:
Should remove the "TBD2" after ecdh_x448.
Looks good to me. Thanks.

Revised text:
IANA is requested to assign two values from the NamedCurve registry with names eddsa_ed25519(TBD3) and eddsa_ed448(TBD4) with this document as reference.  IANA has already assigned the value 29 to  <ins> ecdh_x25519, and the value 30 to ecdh_x448. </ins> IANA is requested to assign one value from SignatureAlgorithm Registry with name eddsa(TBD5) with this document as reference.
Original text:
1. <del> Elliptic Curve Cryptography (ECC) has emerged as an attractive public-key cryptosystem, in particular for mobile (i.e., wireless) environments.  Compared to currently prevalent cryptosystems such as RSA, ECC offers equivalent security with smaller key sizes.  This is illustrated in the following table, based on Lenstra_Verheul, which gives approximate comparable key sizes for symmetric- and asymmetric- key cryptosystems based on the best-known algorithms for attacking them. Smaller key sizes result in savings for power, memory, bandwidth, and computational cost that make ECC especially attractive for constrained environments. </del> This document describes additions to TLS to support ECC, applicable to TLS versions 1.0 RFC2246, 1.1 RFC4346, and 1.2 RFC5246.  The use of ECC in TLS 1.3 is defined in I-D.ietf-tls-tls13, and is explicitly

Reviewer comments:
Removed two paragraphs and a table full of motivation about why ECC is great. In 2016 this is no longer needed. ECC is already mainstream.
+1

Revised text:
1.  This document describes additions to TLS to support ECC, applicable to TLS versions 1.0 RFC2246, 1.1 RFC4346, and 1.2 RFC5246.  The use of ECC in TLS 1.3 is defined in I-D.ietf-tls-tls13, and is explicitly
Original text:
ECPointFormat ECCurveType  For each name space, this document defines the initial value assignments and defines a range of 256 values (NamedCurve) or eight values (ECPointFormat and ECCurveType) reserved for Private Use.  The Added TLS 1.2 to references. Moved RFC 4492 authors to acknowledgements. Removed list of required reading for ECC. 

Reviewer comments:
if both draft-ietf-tls-iana-registry-updates and this draft add TLS to the registry names then all the registry will have a consistent naming scheme.
Ship it
Shipped
LGTM

Revised text:
ECPointFormat ECCurveType <ins> IANA is requested to prepend "TLS" to the names of the previous three registries. </ins> For each name space, this document defines the initial value assignments and defines a range of 256 values (NamedCurve) or eight values (ECPointFormat and ECCurveType) reserved for Private Use.  The Added TLS 1.2 to references. Moved RFC 4492 authors to acknowledgements. Removed list of required reading for ECC. <ins> Prepended "TLS" to the names of the three registries defined in the IANA Considerations section. </ins>