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

Commentary: This solves issue ( " nobody really knows what the parameter is for " ) by removing the parameter altogether . 
 We are not clear on how to use " res"in a lookup query . For example , what does xx represent in this query ? GET /example / rd - lookup - gp?res = xx I could n't find text to explain . Is it expected to be the address of a resource , like href or anchor+href ? 
 Hi  , From version 04 to the current version the ? res has undergone a change In the -10 example the return is < coap://[FDFD::123]:/res/0;rt = sensor;ct=60 where I might have expected < coap://[FDFD::123]:/0;rt = sensor;ct=60 But I can not check because we do not know the contents of the RD and hypothesizing now : ? res = xx would have returned nothing unless there was an entry like < coap://[FDFD::123]:/xx/0;rt = sensor;ct=60 and even more confusing we have something called resource - param . In an earlier e - mail Christian already suggested to modify that to link - param if I remember correctly . So yes , I can concur with you and agreeing with the existence of confusion .    schreef op 2017 - 05 - 05 16:01 : 
 The last I had in mind about the parameter a short mention in the phone call -- to me it looked like a relic whose role has been superseded by ins et al . It is now the first time I perceive it as a parameter that does anything with the path . What is the intended overall purpose of res= ? And what do you mean by the contents of the RD ? 
 Hi  , I assume this a sequel to my answer to  . May be not ..... The contents of the RD are all the information about ep , resources , etc . stored into the RD by whatever means . My speculation about res = xx means that it indicates filtering on resource paths which start with /xx/ ......  
 For such filtering , there is already , which is covered by the query parameter referencing RFC 6690 . of the RD " : I see . Going through all the references in the document , it seems to me that the examples you mentioned are not about the lookup parameter , but just the arbitrary resource names in the pagination example . I 'd suggest removing the parameter altogether ( PR ) unless its use resurfaces . 
 I think " res " ( for resource ) may be useful as a link target attribute for tagging resources , and in that context could also be used as a lookup parameter . If we do n't plan to create " res " as a target attribute we should remove it from the document . If we do want to define a new target attribute , maybe we can come up with something more descriptive than " res " ...
Paragraph (version A):
resource (optional).  Used for domain, group, endpoint and
resource lookups.
Draft: draft-ietf-core-resource-directory

Commentary: Observe , ETag and possible future mechanisms are stated to be generally usable , but phrased as a " like with any other resource " , because there is no need to actually define something new here . 
 Merged as agreed in the last call . I 'll address your comments in a different issue as I think they do n't relate directly to that PR . 
 It would be good to provide a way for clients to receive notifications upon updates of an RD . 
 Is this something we need to specify ? IMO it 'd be orthogonal to the interface description -- if the RD advertises a , any client can try to observe the presence of endpoints . 
 So we should just say that such a lookup can be tried with observe , and that the link attribute " obs " is a good way to provide a hint . Any future optimized collection observe would probably use RD as a prominent example , so we can expect RD implementers to pick this up later .
Paragraph (version B):
Clients that are interested in a lookup result repeatedly or
continuously can use mechanisms like ETag caching, resource
observation (RFC7641), or any future mechanism that might allow more
efficient observations of collections.  These are advertised,
detected and used according to their own specifications and can be
used with the lookup interface as with any other resource.
Draft: draft-ietf-core-resource-directory

Commentary: This pull request contains edits to resolve my comments earlier ; these here address the uncontroversial points . 
 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 . 
 There has been confusion about the semantics of an absent in the presence of transient ports ( first paragraphs , 5.3 HTTP example ) . Proposed solution : more explicit wording about con= being practically required when transient ports are used . 
 The wording has already been strengthened in -10 ; can be closed when the examples are adapted . 
 Closing comment was missing on ; keeping the issue open until  's comments in are resolved .
Paragraph (version A):
The location of the LWM2M Server and RD base URI path is provided by
the LWM2M Bootstrap process, so no dynamic discovery of the RD is
used.  LWM2M Servers and endpoints are not required to implement the
./well-known/core resource.
Paragraph (version B):
The location of the LWM2M Server and RD base URI path is provided by
the LWM2M Bootstrap process, so no dynamic discovery of the RD is
used.  LWM2M Servers and endpoints are not required to implement the
/.well-known/core resource.