From 3114c37bbef514e1b7eb578b4c16968f7f503cb8 Mon Sep 17 00:00:00 2001 From: ID Bot Date: Thu, 5 Sep 2024 21:59:02 +0000 Subject: [PATCH] Script updating gh-pages from 04dd314. [ci skip] --- .../draft-ietf-core-groupcomm-bis.html | 141 ++++++++++-------- .../draft-ietf-core-groupcomm-bis.txt | 44 +++++- 2 files changed, 120 insertions(+), 65 deletions(-) diff --git a/christian-post-wglc-review/draft-ietf-core-groupcomm-bis.html b/christian-post-wglc-review/draft-ietf-core-groupcomm-bis.html index 979be13..a4e8f81 100644 --- a/christian-post-wglc-review/draft-ietf-core-groupcomm-bis.html +++ b/christian-post-wglc-review/draft-ietf-core-groupcomm-bis.html @@ -1999,54 +1999,66 @@

It is possible for CoAP endpoints to discover application groups and CoAP groups from the CoAP servers that are members of such groups, by using a GET request targeting the /.well-known/core resource.

As discussed below, such a GET request may be sent to the IP multicast address of an already known CoAP group associated with one or more application groups; or to the "All CoAP Nodes" multicast address, thus targeting all reachable CoAP servers in any CoAP group. Also, the GET request may specify a query component, in order to filter the application groups of interest.

These particular details concerning the GET request depend on the specific discovery action intended by the client and on application-specific means used to encode names of application groups and CoAP groups, e.g., in group URIs and/or CoRE target attributes used with resource links.

-

The following discusses a number of methods to discover application groups and CoAP groups, building on the following assumptions. First, application group names are encoded in the path component of Group URIs (see Section 2.2.1.2), using the path segment "gp" as designated delimiter. Second, the type of an application group is encoded in the CoRE Link Format attribute "rt" of a group resource with a value "g.<GROUPTYPE>".

-

Full examples for the different methods are provided in Appendix C.

+

The following discusses a number of methods to discover application groups and CoAP groups, building on the following assumptions.

+

Full examples for the different methods are provided in Appendix C.

+ -

Note that the specific way of using the above methods, including the ways shown by the examples in Appendix C.4, is application-specific. That is, there is currently no standard way of encoding names of application groups and CoAP groups in group URIs and/or CoRE target attributes used with resource links. In particular, the discovery of application groups and CoAP groups through the RD mentioned in Section 2.2.3.1 is only defined for use with an RD, i.e., not directly with CoAP servers as group members.

+

Note that the specific way of using the above methods, including the ways shown by the examples in Appendix C.4, is application-specific. That is, there is currently no standard way of encoding names of application groups and CoAP groups in group URIs and/or CoRE target attributes used with resource links. In particular, the discovery of application groups and CoAP groups through the RD mentioned in Section 2.2.3.1 is only defined for use with an RD, i.e., not directly with CoAP servers as group members.

@@ -2876,6 +2888,10 @@

Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., and R. Höglund, "Group Object Security for Constrained RESTful Environments (Group OSCORE)", Work in Progress, Internet-Draft, draft-ietf-core-oscore-groupcomm-22, , <https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-22>.
+
[Resource.Type.Link.Target.Attribute.Values]
+
+IANA, "Resource Type (rt=) Link Target Attribute Values", <https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#rt-link-target-att-value>.
+
[RFC1122]
Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, , <https://www.rfc-editor.org/rfc/rfc1122>.
@@ -3398,9 +3414,10 @@

Figure 11 provides an example where a CoAP client discovers all the application groups associated with a specific CoAP group.

As a result, the client gains knowledge of: i) the set of servers that are members of the specified CoAP group and member of any of the associated application groups; ii) for each of those servers, the name of the application groups where the server is a member and that are associated with the CoAP group.

Each of the servers S1 and S2 is identified by the IP source address of the CoAP response. If the client wishes to discover resources that a particular server hosts within a particular application group, it may use unicast discovery request(s) to this server, i.e., to its respective unicast IP address. Alternatively the client may use the discovered group resource type (e.g., rt=g.light) to infer which resources are present below the group resource.

+

The semantics "g.<GROUPTYPE>" for the values of the attribute "rt" is exclusively intended to support examples in this document. To be effectively usable, such Resource Type values have to be registered in the "Resource Type (rt=) Link Target Attribute Values" IANA registry [Resource.Type.Link.Target.Attribute.Values] within the "Constrained RESTful Environments (CoRE) Parameters" registry group.

-
+ 
    // Request to all members of the CoAP group
    Req: GET coap://grp.example:5685/.well-known/core?rt=g.*
@@ -3511,9 +3528,10 @@ 

 C.4. Members of any Application Group in the Network
         

 
Figure 14 provides an example where a CoAP client discovers the CoAP servers that are members of any application group configured in the 6LoWPAN wireless mesh network of the client, and the CoAP group associated with each application group. In this example, the scope is realm-local to address all servers in the current 6LoWPAN wireless mesh network of the client.

+
The semantics "g.<GROUPTYPE>" for the values of the attribute "rt" is exclusively intended to support examples in this document. To be effectively usable, such Resource Type values have to be registered in the "Resource Type (rt=) Link Target Attribute Values" IANA registry [Resource.Type.Link.Target.Attribute.Values] within the "Constrained RESTful Environments (CoRE) Parameters" registry group.

 

 

-          

+          

 
    // Request to realm-local members of any application group
    Req: GET coap://[ff03::fd]/.well-known/core?rt=g.*
@@ -3549,11 +3567,11 @@ 

 Discovery of the resources and members of any application group, and of the associated CoAP group
           

 

-
Alternatively, some applications may use the "rt" attribute on a parent resource to denote support for a particular REST API to access child resources.

-
For instance, Figure 15 provides a different example where a custom Link Format attribute "gpt" is used to denote the group type within the scope of the application/system. An alternative, shorter encoding (not shown in the figure) is to use only the value "1" for each "gpt" attribute, in order to denote that the resource is of type application group. In that case, information about the semantics/API of the group resource is disclosed only via the "rt" attribute as shown in the figure.

+
Alternatively, some applications may use the "rt" attribute on a parent resource to denote support for a particular REST API to access child resources.

+
For instance, Figure 15 provides a different example where a custom Link Format attribute "gpt" is used to denote the group type within the scope of the application/system. An alternative, shorter encoding (not shown in the figure) is to use only the value "1" for each "gpt" attribute, in order to denote that the resource is of type application group. In that case, information about the semantics/API of the group resource is disclosed only via the "rt" attribute as shown in the figure.

 

 

-          

+          

 
    // Request to realm-local members of any application group
    Req: GET coap://[ff03::fd]/.well-known/core?gpt=*
@@ -4290,37 +4308,40 @@ 

         

 
    
 
  • 
-            
    Made RFC 7967 a normative reference.
    
+            
    Clarified that rt=g.<GROUPTYPE> is used just as an example.
    
 
    • 
           
  • 
-            
    Generalized resending of a group request with different Message ID.
    
+            
    Made RFC 7967 a normative reference.
    
 
    • 
           
  • 
-            
    Switched SHOULD to MAY on changing port number from group request to response.
    
+            
    Generalized resending of a group request with different Message ID.
    
 
    • 
           
  • 
-            
    Further generalized the handling of multiple responses from the same server to the same request.
    
+            
    Switched SHOULD to MAY on changing port number from group request to response.
    
 
    • 
           
  • 
-            
    Clarifications on response suppression.
    
+            
    Further generalized the handling of multiple responses from the same server to the same request.
    
 
    • 
           
  • 
-            
    Mentioned PROBING_RATE as a means to enforce congestion control.
    
+            
    Clarifications on response suppression.
    
 
    • 
           
  • 
-            
    Consideration on how eventual consistency from Observe compensates for lost notifications.
    
+            
    Mentioned PROBING_RATE as a means to enforce congestion control.
    
 
    • 
           
  • 
-            
    Admitted resource retrieval through consecutive group requests with the Block2 Option.
    
+            
    Consideration on how eventual consistency from Observe compensates for lost notifications.
    
 
    • 
           
  • 
-            
    Clarified relation with TCP/TLS/WebSockets.
    
+            
    Admitted resource retrieval through consecutive group requests with the Block2 Option.
    
 
    • 
           
  • 
-            
    Clarified security on the different legs with a proxy.
    
+            
    Clarified relation with TCP/TLS/WebSockets.
    
 
    • 
           
  • 
-            
    Editorial improvements.
    
+            
    Clarified security on the different legs with a proxy.
    
+
    • 
+          
  • 
+            
    Editorial improvements.
    
 
    • 
         

 
diff --git a/christian-post-wglc-review/draft-ietf-core-groupcomm-bis.txt b/christian-post-wglc-review/draft-ietf-core-groupcomm-bis.txt
index a9c8127..f52e9e1 100644
--- a/christian-post-wglc-review/draft-ietf-core-groupcomm-bis.txt
+++ b/christian-post-wglc-review/draft-ietf-core-groupcomm-bis.txt
@@ -883,11 +883,24 @@ Table of Contents
 
    The following discusses a number of methods to discover application
    groups and CoAP groups, building on the following assumptions.
-   First, application group names are encoded in the path component of
-   Group URIs (see Section 2.2.1.2), using the path segment "gp" as
-   designated delimiter.  Second, the type of an application group is
-   encoded in the CoRE Link Format attribute "rt" of a group resource
-   with a value "g.".
+
+   *  Application group names are encoded in the path component of Group
+      URIs (see Section 2.2.1.2), using the path segment "gp" as
+      designated delimiter.
+
+   *  The type of an application group is encoded in the value of the
+      CoRE Link Format attribute "rt" of a group resource.
+
+      As exclusively intended to support examples throughout this
+      document, the following considers such values for the attribute
+      "rt" to have the semantics "g.", where GROUPTYPE
+      denotes the type of the application group in question.
+
+      To be effectively usable, such Resource Type values have to be
+      registered in the "Resource Type (rt=) Link Target Attribute
+      Values" IANA registry [Resource.Type.Link.Target.Attribute.Values]
+      within the "Constrained RESTful Environments (CoRE) Parameters"
+      registry group.
 
    Full examples for the different methods are provided in Appendix C.
 
@@ -2846,6 +2859,11 @@ Table of Contents
               August 2024, .
 
+   [Resource.Type.Link.Target.Attribute.Values]
+              IANA, "Resource Type (rt=) Link Target Attribute Values",
+              .
+
    [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
               Communication Layers", STD 3, RFC 1122,
               DOI 10.17487/RFC1122, October 1989,
@@ -3449,6 +3467,13 @@ C.1.  Application Groups Associated with a CoAP Group
    discovered group resource type (e.g., rt=g.light) to infer which
    resources are present below the group resource.
 
+   The semantics "g." for the values of the attribute "rt" is
+   exclusively intended to support examples in this document.  To be
+   effectively usable, such Resource Type values have to be registered
+   in the "Resource Type (rt=) Link Target Attribute Values" IANA
+   registry [Resource.Type.Link.Target.Attribute.Values] within the
+   "Constrained RESTful Environments (CoRE) Parameters" registry group.
+
       // Request to all members of the CoAP group
       Req: GET coap://grp.example:5685/.well-known/core?rt=g.*
 
@@ -3553,6 +3578,13 @@ C.4.  Members of any Application Group in the Network
    is realm-local to address all servers in the current 6LoWPAN wireless
    mesh network of the client.
 
+   The semantics "g." for the values of the attribute "rt" is
+   exclusively intended to support examples in this document.  To be
+   effectively usable, such Resource Type values have to be registered
+   in the "Resource Type (rt=) Link Target Attribute Values" IANA
+   registry [Resource.Type.Link.Target.Attribute.Values] within the
+   "Constrained RESTful Environments (CoRE) Parameters" registry group.
+
       // Request to realm-local members of any application group
       Req: GET coap://[ff03::fd]/.well-known/core?rt=g.*
 
@@ -3918,6 +3950,8 @@ Appendix E.  Document Updates
 
 E.1.  Version -11 to -12
 
+   *  Clarified that rt=g. is used just as an example.
+
    *  Made RFC 7967 a normative reference.
 
    *  Generalized resending of a group request with different Message