rfc9569v5.txt | rfc9569.txt | |||
---|---|---|---|---|
skipping to change at line 441 ¶ | skipping to change at line 441 ¶ | |||
Version 0 is reserved as the initial state (empty/null). | Version 0 is reserved as the initial state (empty/null). | |||
* A tag identifies the content of a node. A tag has the same format | * A tag identifies the content of a node. A tag has the same format | |||
as the "tag" field in Section 10.3 of [RFC7285] and is valid only | as the "tag" field in Section 10.3 of [RFC7285] and is valid only | |||
within the scope of the resource. | within the scope of the resource. | |||
* Each edge is an update item. In particular, the edge from i to j | * Each edge is an update item. In particular, the edge from i to j | |||
is the update item to transit from version i to version j. | is the update item to transit from version i to version j. | |||
* The version is path independent, i.e., different paths arriving at | * The version is path independent, i.e., different paths arriving at | |||
the node associated with the same version have the same content). | the node associated with the same version have the same content. | |||
A concrete example is shown in Figure 2. There are seven nodes in | A concrete example is shown in Figure 2. There are seven nodes in | |||
the graph, representing seven different versions of the resource. | the graph, representing seven different versions of the resource. | |||
Edges in the figure represent the updates from the source version to | Edges in the figure represent the updates from the source version to | |||
the target version. Thick lines represent mandatory incremental | the target version. Thick lines represent mandatory incremental | |||
updates (e.g., ID103-104), dotted lines represent optional | updates (e.g., ID103-104), dotted lines represent optional | |||
incremental updates (e.g., ID103-105), and thin lines represent | incremental updates (e.g., ID103-105), and thin lines represent | |||
snapshots (e.g., ID0-103). Note that node content is path | snapshots (e.g., ID0-103). Note that node content is path | |||
independent: the content of node v can be obtained by applying the | independent: the content of node v can be obtained by applying the | |||
updates from any path that ends at v. For example, assume the latest | updates from any path that ends at v. For example, assume the latest | |||
skipping to change at line 504 ¶ | skipping to change at line 504 ¶ | |||
ID105-106 || | ID105-106 || | |||
\/ | \/ | |||
+======+ | +======+ | |||
tag: 6470983 -> | 106 | | tag: 6470983 -> | 106 | | |||
+======+ | +======+ | |||
Figure 2: TIPS Model Example | Figure 2: TIPS Model Example | |||
3.2. Updates Graph Modification Invariants | 3.2. Updates Graph Modification Invariants | |||
A server may change its updates graph (to compact it, to add nodes, | A server might change its updates graph (to compact it, to add nodes, | |||
etc.), but it must ensure that any resource state that it makes | etc.), but it will need to ensure that any resource state that it | |||
available is reachable by clients, either directly via a snapshot | makes available is reachable by clients, either directly via a | |||
(that is, relative to 0) or indirectly by requesting an earlier | snapshot (that is, relative to 0) or indirectly by requesting an | |||
snapshot and a contiguous set of incremental updates. Additionally, | earlier snapshot and a contiguous set of incremental updates. | |||
to allow clients to proactively construct URIs for future update | Additionally, to allow clients to proactively construct URIs for | |||
items, the ID of each added node in the updates graph must increment | future update items, the ID of each added node in the updates graph | |||
contiguously by 1. More specifically, the updates graph MUST satisfy | will need to increment contiguously by 1. More specifically, the | |||
the following invariants: | updates graph MUST satisfy the following invariants: | |||
Continuity: At any time, let ns denote the smallest non-zero version | Continuity: At any time, let ns denote the smallest non-zero version | |||
(i.e., <start-seq>) in the updates graph and let ne denote the | (i.e., <start-seq>) in the updates graph and let ne denote the | |||
latest version (i.e., <end-seq>). Then, any version in between ns | latest version (i.e., <end-seq>). Then, any version in between ns | |||
and ne MUST also exist. This implies that the incremental update | and ne MUST also exist. This implies that the incremental update | |||
from ni to ni + 1 exists for any ns <= ni <= ne, and all the | from ni to ni + 1 exists for any ns <= ni <= ne, and all the | |||
version numbers in the updates graph (except 0) constitute exactly | version numbers in the updates graph (except 0) constitute exactly | |||
the integer interval [ns, ne]. | the integer interval [ns, ne]. | |||
Feasibility: Let ns denote <start-seq> in the updates graph. The | Feasibility: Let ns denote <start-seq> in the updates graph. The | |||
skipping to change at line 566 ¶ | skipping to change at line 566 ¶ | |||
the request from the client to monitor the updates of an ALTO | the request from the client to monitor the updates of an ALTO | |||
resource, it creates a TIPS view resource and returns the | resource, it creates a TIPS view resource and returns the | |||
corresponding information to the client. The URI points to that | corresponding information to the client. The URI points to that | |||
specific TIPS-V instance, and the summary contains the <start-seq> | specific TIPS-V instance, and the summary contains the <start-seq> | |||
and <end-seq> of the updates graph and a server-recommended edge to | and <end-seq> of the updates graph and a server-recommended edge to | |||
consume first (e.g., from i to j). | consume first (e.g., from i to j). | |||
An ALTO client can then continuously pull each additional update with | An ALTO client can then continuously pull each additional update with | |||
the information. For example, the client in Figure 3 first fetches | the information. For example, the client in Figure 3 first fetches | |||
the update from i to j and then from j to j+1. Note that the update | the update from i to j and then from j to j+1. Note that the update | |||
item at "<tips-view-uri>/ug/<j>/<j+1>" may not yet exist, so the | item at "<tips-view-uri>/ug/<j>/<j+1>" might not yet exist, so the | |||
server holds the request until the update becomes available (i.e., | server holds the request until the update becomes available (i.e., | |||
long polling). | long polling). | |||
A server MAY close a TIPS view at any time (e.g., under high system | A server MAY close a TIPS view at any time (e.g., under high system | |||
load or due to client inactivity). In the event that a TIPS view is | load or due to client inactivity). In the event that a TIPS view is | |||
closed, an edge request will receive error code 404 (Not Found) in | closed, an edge request will receive error code 404 (Not Found) in | |||
response, and the client will have to request a new TIPS view URI. | response, and the client will have to request a new TIPS view URI. | |||
If resources allow, a server SHOULD avoid closing TIPS views that | If resources allow, a server SHOULD avoid closing TIPS views that | |||
have active polling edge requests or have recently served responses | have active polling edge requests or have recently served responses | |||
skipping to change at line 839 ¶ | skipping to change at line 839 ¶ | |||
support concurrent retrieval of multiple resources such as "my- | support concurrent retrieval of multiple resources such as "my- | |||
network-map" and "my-routingcost-map" using multiple HTTP/2 streams. | network-map" and "my-routingcost-map" using multiple HTTP/2 streams. | |||
The resource "update-my-costs-tips" provides an ALTO TIPS information | The resource "update-my-costs-tips" provides an ALTO TIPS information | |||
resource, and this is indicated by the media type "application/alto- | resource, and this is indicated by the media type "application/alto- | |||
tips+json". | tips+json". | |||
6. TIPS Management | 6. TIPS Management | |||
Upon request, a server sends a TIPS view to a client. This TIPS view | Upon request, a server sends a TIPS view to a client. This TIPS view | |||
may be created at the time of the request or may already exist | might be created at the time of the request or might already exist | |||
(either because another client has already created a TIPS view for | (either because another client has already created a TIPS view for | |||
the same requested network resource or because the server perpetually | the same requested network resource or because the server perpetually | |||
maintains a TIPS view for an often-requested resource). | maintains a TIPS view for an often-requested resource). | |||
6.1. Open Request | 6.1. Open Request | |||
An ALTO client requests that the server provide a TIPS view for a | An ALTO client requests that the server provide a TIPS view for a | |||
given resource by sending an HTTP POST body with the media type | given resource by sending an HTTP POST body with the media type | |||
"application/alto-tipsparams+json". That body contains a JSON object | "application/alto-tipsparams+json". That body contains a JSON object | |||
of the TIPSReq type, where: | of the TIPSReq type, where: | |||
skipping to change at line 941 ¶ | skipping to change at line 941 ¶ | |||
A server MUST NOT use the same URI for different TIPS views, | A server MUST NOT use the same URI for different TIPS views, | |||
either for different resources or for different request bodies to | either for different resources or for different request bodies to | |||
the same resource. URI generation is implementation specific; for | the same resource. URI generation is implementation specific; for | |||
example, one may compute a Universally Unique Identifier (UUID) | example, one may compute a Universally Unique Identifier (UUID) | |||
[RFC4122] or a hash value based on the request and append it to a | [RFC4122] or a hash value based on the request and append it to a | |||
base URL. For performance considerations, it is NOT RECOMMENDED | base URL. For performance considerations, it is NOT RECOMMENDED | |||
to use properties that are not included in the request body to | to use properties that are not included in the request body to | |||
determine the URI of a TIPS view, such as cookies or the client's | determine the URI of a TIPS view, such as cookies or the client's | |||
IP address, which may result in duplicated TIPS views in cases | IP address, which may result in duplicated TIPS views in cases | |||
such as mobile clients. However, this is not mandatory as a | such as mobile clients. However, this is not mandatory as a | |||
server may intentionally use client information to compute the | server might intentionally use client information to compute the | |||
TIPS view URI to provide service isolation between clients. | TIPS view URI to provide service isolation between clients. | |||
tips-view-summary: Contains an updates-graph-summary. | tips-view-summary: Contains an updates-graph-summary. | |||
The "updates-graph-summary" field contains the <start-seq> of the | The "updates-graph-summary" field contains the <start-seq> of the | |||
updates graph (in the "start-seq" field) and the <end-seq> that is | updates graph (in the "start-seq" field) and the <end-seq> that is | |||
currently available (in the "end-seq" field), along with a | currently available (in the "end-seq" field), along with a | |||
recommended edge to consume (in the "start-edge-rec" field). If | recommended edge to consume (in the "start-edge-rec" field). If | |||
the client does not provide a version tag, the server MUST | the client does not provide a version tag, the server MUST | |||
recommend the edge of the latest available snapshot. If the | recommend the edge of the latest available snapshot. If the | |||
skipping to change at line 1125 ¶ | skipping to change at line 1125 ¶ | |||
{....} | {....} | |||
Figure 12: Open Example with Digest Authentication | Figure 12: Open Example with Digest Authentication | |||
6.3.3. Example Using ALTO/SSE | 6.3.3. Example Using ALTO/SSE | |||
This section gives an example of receiving incremental updates of the | This section gives an example of receiving incremental updates of the | |||
TIPS view summary using ALTO/SSE [RFC8895]. Consider the "tips-sse" | TIPS view summary using ALTO/SSE [RFC8895]. Consider the "tips-sse" | |||
resource, as announced by the IRD in Figure 6, which provides ALTO/ | resource, as announced by the IRD in Figure 6, which provides ALTO/ | |||
SSE for the "update-my-cost-tips" resource; a client may send the | SSE for the "update-my-cost-tips" resource; a client might send the | |||
following request to receive updates of the TIPS view (authentication | following request to receive updates of the TIPS view (authentication | |||
is omitted for simplicity). | is omitted for simplicity). | |||
POST /updates/tips HTTP/1.1 | POST /updates/tips HTTP/1.1 | |||
Host: alto.example.com | Host: alto.example.com | |||
Accept: text/event-stream,application/alto-error+json | Accept: text/event-stream,application/alto-error+json | |||
Content-Type: application/alto-updatestreamparams+json | Content-Type: application/alto-updatestreamparams+json | |||
Content-Length: 76 | Content-Length: 76 | |||
{ | { | |||
skipping to change at line 1210 ¶ | skipping to change at line 1210 ¶ | |||
Section 7.3 for a concrete example. | Section 7.3 for a concrete example. | |||
7.2. Response | 7.2. Response | |||
If the request is valid (i.e., "ug/<i>/<j>" exists), the response is | If the request is valid (i.e., "ug/<i>/<j>" exists), the response is | |||
encoded as a JSON object whose data format is indicated by the media | encoded as a JSON object whose data format is indicated by the media | |||
type. | type. | |||
A client MAY conduct proactive fetching of future updates, by long | A client MAY conduct proactive fetching of future updates, by long | |||
polling updates that have not been provided in the directory yet. | polling updates that have not been provided in the directory yet. | |||
For such updates, the client MUST indicate all media types that may | For such updates, the client MUST indicate all media types that might | |||
appear. It is RECOMMENDED that the server allow for at least the | appear. It is RECOMMENDED that the server allow for at least the | |||
long polling of <end-seq> -> <end-seq + 1>. | long polling of <end-seq> -> <end-seq + 1>. | |||
Hence, the server processing logic MUST be: | Hence, the server processing logic MUST be: | |||
* If a resource with path "ug/<i>/<j>" exists, return content using | * If a resource with path "ug/<i>/<j>" exists, return content using | |||
encoding. | encoding. | |||
* Else, if long polling "ug/<i>/<j>" is acceptable, put request in a | * Else, if long polling "ug/<i>/<j>" is acceptable, put request in a | |||
backlog queue, then either a response is triggered when the | backlog queue, then either a response is triggered when the | |||
skipping to change at line 1277 ¶ | skipping to change at line 1277 ¶ | |||
Figure 15: Response to a GET Request | Figure 15: Response to a GET Request | |||
7.4. New Next Edge Recommendation | 7.4. New Next Edge Recommendation | |||
While intended TIPS usage is for the client to receive a recommended | While intended TIPS usage is for the client to receive a recommended | |||
starting edge in the TIPS summary, consume that edge, and then | starting edge in the TIPS summary, consume that edge, and then | |||
construct all future URIs by incrementing the sequence count by one, | construct all future URIs by incrementing the sequence count by one, | |||
there may be cases in which the client needs to request a new next | there may be cases in which the client needs to request a new next | |||
edge to consume. For example, if a client has an open TIPS view but | edge to consume. For example, if a client has an open TIPS view but | |||
has not polled in a while, the client may request the next logical | has not polled in a while, the client might request the next logical | |||
incremental URI; however, the server has compacted the updates graph, | incremental URI; however, the server has compacted the updates graph, | |||
so it no longer exists. Thus, the client MAY request a new next edge | so it no longer exists. Thus, the client MAY request a new next edge | |||
to consume based on its current version of the resource. | to consume based on its current version of the resource. | |||
7.4.1. Request | 7.4.1. Request | |||
An ALTO client requests that the server provide a next edge | An ALTO client requests that the server provide a next edge | |||
recommendation for a given TIPS view by sending an HTTP POST request | recommendation for a given TIPS view by sending an HTTP POST request | |||
with the media type "application/alto-tipsparams+json". The URL of | with the media type "application/alto-tipsparams+json". The URL of | |||
the request MUST have the following format: | the request MUST have the following format: | |||
skipping to change at line 1403 ¶ | skipping to change at line 1403 ¶ | |||
application layer or at the infrastructure layer. For example, an | application layer or at the infrastructure layer. For example, an | |||
ALTO server MAY set <tips-view-host> to different subdomains to | ALTO server MAY set <tips-view-host> to different subdomains to | |||
distribute TIPS views or simply use the same host of the TIPS | distribute TIPS views or simply use the same host of the TIPS | |||
information resource and rely on load balancers to distribute the | information resource and rely on load balancers to distribute the | |||
load. | load. | |||
TIPS allows a client to make concurrent pulls of incremental updates | TIPS allows a client to make concurrent pulls of incremental updates | |||
for the same TIPS view, potentially through different HTTP | for the same TIPS view, potentially through different HTTP | |||
connections. As a consequence, TIPS introduces additional | connections. As a consequence, TIPS introduces additional | |||
complexities when the ALTO server balances the load by distributing | complexities when the ALTO server balances the load by distributing | |||
the requests to a set of backend servers. For example, a request may | the requests to a set of backend servers. For example, a request | |||
be directed to the wrong backend server and get processed incorrectly | might be directed to the wrong backend server and get processed | |||
if the following two conditions both hold: | incorrectly if the following two conditions both hold: | |||
* these backend servers are stateful (i.e., the TIPS view is created | * these backend servers are stateful (i.e., the TIPS view is created | |||
and stored only on a single server); and | and stored only on a single server); and | |||
* the ALTO server is using Layer 4 load balancing (i.e., the | * the ALTO server is using Layer 4 load balancing (i.e., the | |||
requests are distributed based on the TCP 5-tuple). | requests are distributed based on the TCP 5-tuple). | |||
Thus, additional considerations are required to enable correct load | Thus, additional considerations are required to enable correct load | |||
balancing for TIPS, including: | balancing for TIPS, including: | |||
skipping to change at line 1561 ¶ | skipping to change at line 1561 ¶ | |||
service. | service. | |||
To avoid such attacks, the server MAY choose to limit the number of | To avoid such attacks, the server MAY choose to limit the number of | |||
active views and reject new requests when that threshold is reached. | active views and reject new requests when that threshold is reached. | |||
TIPS allows predictive fetching and the server MAY also choose to | TIPS allows predictive fetching and the server MAY also choose to | |||
limit the number of pending requests. If a new request exceeds the | limit the number of pending requests. If a new request exceeds the | |||
threshold, the server MAY log the event and return the HTTP status | threshold, the server MAY log the event and return the HTTP status | |||
429 (Too Many Requests). | 429 (Too Many Requests). | |||
It is important to note that the preceding approaches are not the | It is important to note that the preceding approaches are not the | |||
only possibilities. For example, it may be possible for a TIPS | only possibilities. For example, it might be possible for a TIPS | |||
server to use somewhat more clever logic involving TIPS view eviction | server to use somewhat more clever logic involving TIPS view eviction | |||
policies, IP reputation, rate-limiting, and compartmentalization of | policies, IP reputation, rate-limiting, and compartmentalization of | |||
the overall threshold into smaller thresholds that apply to subsets | the overall threshold into smaller thresholds that apply to subsets | |||
of potential clients. If service availability is a concern, ALTO | of potential clients. If service availability is a concern, ALTO | |||
clients MAY establish service level agreements with the ALTO server. | clients MAY establish service level agreements with the ALTO server. | |||
9.2. ALTO Client: Update Overloading or Instability | 9.2. ALTO Client: Update Overloading or Instability | |||
The availability of continuous updates can also cause overload for an | The availability of continuous updates can also cause overload for an | |||
ALTO client, in particular, an ALTO client with limited processing | ALTO client, in particular, an ALTO client with limited processing | |||
capabilities. The current design does not include any flow control | capabilities. The current design does not include any flow control | |||
mechanisms for the client to reduce the update rates from the server. | mechanisms for the client to reduce the update rates from the server. | |||
For example, TCP, HTTP/2, and QUIC provide stream and connection flow | For example, TCP, HTTP/2, and QUIC provide stream and connection flow | |||
control data limits, which might help prevent the client from being | control data limits, which might help prevent the client from being | |||
overloaded. Under overloading, the client MAY choose to remove the | overloaded. Under overloading, the client MAY choose to remove the | |||
information resources with high update rates. | information resources with high update rates. | |||
Also, under overloading, the client may no longer be able to detect | Also, under overloading, the client might no longer be able to detect | |||
whether information is still fresh or has become stale. In such a | whether information is still fresh or has become stale. In such a | |||
case, the client should be careful in how it uses the information to | case, the client should be careful in how it uses the information to | |||
avoid stability or efficiency issues. | avoid stability or efficiency issues. | |||
10. IANA Considerations | 10. IANA Considerations | |||
IANA has registered the following media types from the registry | IANA has registered the following media types from the registry | |||
available at [IANA-Media-Type]: | available at [IANA-Media-Type]: | |||
* application/alto-tips+json: as described in Section 6.2; | * application/alto-tips+json: as described in Section 6.2; | |||
skipping to change at line 1808 ¶ | skipping to change at line 1808 ¶ | |||
Design 3 (Dir + Data): R2 and R3 must remain together, though R1 | Design 3 (Dir + Data): R2 and R3 must remain together, though R1 | |||
might not be on the same server. | might not be on the same server. | |||
This document supports Designs 1 and 3. For Design 1, the ALTO | This document supports Designs 1 and 3. For Design 1, the ALTO | |||
server simply needs to always use the same host for the TIPS views. | server simply needs to always use the same host for the TIPS views. | |||
For Design 3, the ALTO server can set tips-view-host to a different | For Design 3, the ALTO server can set tips-view-host to a different | |||
server. Note that the deployment flexibility is at the logical | server. Note that the deployment flexibility is at the logical | |||
level, as these services can be distinguished by different paths and | level, as these services can be distinguished by different paths and | |||
potentially be routed to different physical servers by Layer 7 load | potentially be routed to different physical servers by Layer 7 load | |||
balancing. See Section 8.1 for a discussion on load balancing | balancing. See Section 8.1 for a discussion on load balancing | |||
considerations. Future documents may extend the protocol to support | considerations. Future documents could extend the protocol to | |||
Design 2. | support Design 2. | |||
Appendix B. Conformance with "Building Protocols with HTTP" (RFC 9205) | Appendix B. Conformance with "Building Protocols with HTTP" (RFC 9205) | |||
Best Current Practices | Best Current Practices | |||
This specification adheres fully to [RFC9205] as further elaborated | This specification adheres fully to [RFC9205] as further elaborated | |||
below: | below: | |||
* TIPS does not (as described in Section 3.1 of [RFC9205]): | * TIPS does not (as described in Section 3.1 of [RFC9205]): | |||
| ...redefine, refine, or overlay the semantics of generic | | ...redefine, refine, or overlay the semantics of generic | |||
skipping to change at line 1868 ¶ | skipping to change at line 1868 ¶ | |||
(Section 4.6 of [RFC9205]). | (Section 4.6 of [RFC9205]). | |||
* TIPS does not (as in Section 4.11 of [RFC9205]): | * TIPS does not (as in Section 4.11 of [RFC9205]): | |||
| ...make assumptions about the relationship between separate | | ...make assumptions about the relationship between separate | |||
| requests on a single transport connection; doing so breaks many of | | requests on a single transport connection; doing so breaks many of | |||
| the assumptions of HTTP as a stateless protocol and will cause | | the assumptions of HTTP as a stateless protocol and will cause | |||
| problems in interoperability, security, operability, and | | problems in interoperability, security, operability, and | |||
| evolution. | | evolution. | |||
The only relationship between requests is that a client must first | The only relationship between requests is that a client has to | |||
discover where a TIPS view of a resource will be served, which is | first discover where a TIPS view of a resource will be served, | |||
consistent with the URI discovery in Section 4.4.1 of [RFC9205]. | which is consistent with the URI discovery in Section 4.4.1 of | |||
[RFC9205]. | ||||
Appendix C. Push-Mode TIPS Using HTTP Server Push | Appendix C. Push-Mode TIPS Using HTTP Server Push | |||
TIPS allows ALTO clients to subscribe to incremental updates of an | TIPS allows ALTO clients to subscribe to incremental updates of an | |||
ALTO resource, and the specification in this document is based on the | ALTO resource, and the specification in this document is based on the | |||
current best practice of building such a service using basic HTTP. | current best practice of building such a service using basic HTTP. | |||
Earlier versions of this document had investigated the possibility of | Earlier versions of this document had investigated the possibility of | |||
enabling push-mode TIPS (i.e., by taking advantage of the server push | enabling push-mode TIPS (i.e., by taking advantage of the server push | |||
feature in HTTP/2 and HTTP/3). | feature in HTTP/2 and HTTP/3). | |||
skipping to change at line 1898 ¶ | skipping to change at line 1899 ¶ | |||
Appendix D. Persistent HTTP Connections | Appendix D. Persistent HTTP Connections | |||
Previous draft versions of this document use persistent HTTP | Previous draft versions of this document use persistent HTTP | |||
connections to detect the liveness of clients. However, this design | connections to detect the liveness of clients. However, this design | |||
does not conform well with the best current practices of HTTP. For | does not conform well with the best current practices of HTTP. For | |||
example, if an ALTO client is accessing a TIPS view over an HTTP | example, if an ALTO client is accessing a TIPS view over an HTTP | |||
proxy, the connection is not established directly between the ALTO | proxy, the connection is not established directly between the ALTO | |||
client and the ALTO server, but between the ALTO client and the proxy | client and the ALTO server, but between the ALTO client and the proxy | |||
and between the proxy and the ALTO server. Thus, using persistent | and between the proxy and the ALTO server. Thus, using persistent | |||
connections may not correctly detect the right liveness state. | connections might not correctly detect the right liveness state. | |||
Acknowledgments | Acknowledgments | |||
The authors of this document would like to thank Mark Nottingham and | The authors of this document would like to thank Mark Nottingham and | |||
Spencer Dawkins for providing invaluable reviews of earlier draft | Spencer Dawkins for providing invaluable reviews of earlier draft | |||
versions of this document; Adrian Farrel, Qin Wu, and Jordi Ros | versions of this document; Adrian Farrel, Qin Wu, and Jordi Ros | |||
Giralt for their continuous feedback; Russ White, Donald Eastlake | Giralt for their continuous feedback; Russ White, Donald Eastlake | |||
3rd, Martin Thomson, Bernard Adoba, Spencer Dawkins, Linda Dunbar, | 3rd, Martin Thomson, Bernard Adoba, Spencer Dawkins, Linda Dunbar, | |||
and Sheng Jiang for the directorate reviews; Martin Duke for the area | and Sheng Jiang for the directorate reviews; Martin Duke for the area | |||
director review; Francesca Palombini, Wesley Eddy, Roman Danyliw, | director review; Francesca Palombini, Wesley Eddy, Roman Danyliw, | |||
End of changes. 14 change blocks. | ||||
27 lines changed or deleted | 28 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |