Subject: [Dots] Martin Duke's No Objection on draft-ietf-dots-rfc8782-bis-07: (with COMMENT)

From: Martin Duke via Datatracker <[email-masked]>
Date: Tue, 01 Jun 2021 15:39:38 -0700

Martin Duke has entered the following ballot position for
draft-ietf-dots-rfc8782-bis-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dots-rfc8782-bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for addressing Michael Tuexen's TSVART review.

As I did not review RFC8782, I'm taking this opportunity to review the entire
document, rather than just the bis. I found numerous clarity issues:

(4.4.1.1) How do DOTS servers detect a CUID collision? I believe Sec. 7
explains this is based on client authentication, but mentioning it here would
be helpful.

In the "mid" definition: s/no attack is detected/no attack is underway

In the "target_fqdn" definition. The text appears to assume a DNS resolution;
is there a not a use case where the DOTS server would rely on e.g. SNI
inspection and not defend an entire IP address that had multiple domains?

"lifetime" definition: The text says the DOTS server MAY reject unlimited
lifetime, which implies that it MUST accept any finite lifetime. I presume you
mean to say that DOTS servers are free to set a policy limit on the maximum
allowable lifetime?

(4.4.1.2) "cdid" definition: The example in Fig. 9 does not have a cdid that
matches the cuid. The text indicates that these might not match if a
client-side gateway added the cdid, but then later says that "only the first
on-path server-domain DOTS gateway can  insert a 'cdid' value." After reading
this a few times, I think what you are saying is (a) clients MUST NOT add cdid;
(b) client-side gateways SHOULD add them; (c) the first server-side gateway
MUST strip them and then add their own; and (d) subsequent server side gateways
MUST NOT change the cdid. Is this correct? Either way, it could be expressed
less confusingly.

(4.4.1.3) Fig. 11: Where does the second cuid come from? Is this generated by
the server on behalf of the client? If so, I recommend s/a new request with a
new 'cuid'/a new request with a new, server-provided 'cuid'

When extending the lifetime, does the new lifetime field measure from the
initial trigger or from the moment of extension? If the former, a change in the
lifetime value is mandatory, not "potential." If the latter, how does the
server distinguish this from a duplicate request?

(4.4.2) Fig. 14 uses a string to represent the status instead of one of the
values in Table 3.

(4.4.3) Same with Fig. 16 and Table 4.

(4.4.2.1) If updates are non-confirmable, how does the client know if it's
gotten out of sync on state updates?

(4.5.1) What is the unit of probing rate?

(8) s/should/SHOULD, s/must/MUST throughout.

---

From: <[email-masked]>
Date: Wed, 2 Jun 2021 09:49:45 +0000

Hi Martin,

Thank you for the review. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Martin Duke via Datatracker [mailto:[email-masked]]
> Envoyé : mercredi 2 juin 2021 00:40
> À : The IESG <[email-masked]>
> Cc : [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Objet : Martin Duke's No Objection on draft-ietf-dots-rfc8782-bis-
> 07: (with COMMENT)
> 
> When responding, please keep the subject line intact and reply to
> all email addresses included in the To and CC lines. (Feel free to
> cut this introductory paragraph, however.)
> 
> 
> As I did not review RFC8782, I'm taking this opportunity to review
> the entire document, rather than just the bis. I found numerous
> clarity issues:

[Med] It is always valuable to have fresh eyes to review. So, thanks! 

> 
> (4.4.1.1) How do DOTS servers detect a CUID collision? I believe
> Sec. 7 explains this is based on client authentication, but
> mentioning it here would be helpful.

[Med] We do already have the following at the end of 4.4.1.1:

   In both DOTS signal and data channel sessions, the DOTS client MUST
   authenticate itself to the DOTS server (Section 8).  The DOTS server
   MAY use the algorithm presented in Section 7 of [RFC7589] to derive
   the DOTS client identity or username from the client certificate.
   The DOTS client identity allows the DOTS server to accept mitigation
   requests with scopes that the DOTS client is authorized to manage.

Do you prefer if this text is mentioned earlier? 

> In the "mid" definition: s/no attack is detected/no attack is

[Med] The OLD wording is more appropriate as an attack may be underway but not detected. 

> 
> In the "target_fqdn" definition. The text appears to assume a DNS
> resolution; is there a not a use case where the DOTS server would
> rely on e.g. SNI inspection and not defend an entire IP address that
> had multiple domains?

[Med] The resolution is needed for scope validation and conflict handling purposes. That's said, nothing prevents the mitigator to use the name to put in place application-specific countermeasures. We don't call out those as RFC8811 sets the scope as follows: 

   The scope of the DOTS specifications is the interfaces between the
   DOTS client and DOTS server.  The interfaces to the attack target and
   the mitigator are out of scope of DOTS.  Similarly, the operation of
   both the attack target and the mitigator is out of scope of DOTS.
   Thus, DOTS specifies neither how an attack target decides it is under
   DDoS attack nor does DOTS specify how a mitigator may actually
   mitigate such an attack.  

> 
> "lifetime" definition: The text says the DOTS server MAY reject
> unlimited lifetime, which implies that it MUST accept any finite
> lifetime.

[Med] No. This text is about the behavior when indefinite lifetime is requested. The full text is as follows:

      A lifetime of negative one (-1) indicates indefinite lifetime for
      the mitigation request.  The DOTS server MAY refuse an indefinite
      lifetime, for policy reasons; the granted lifetime value is
      returned in the response.  DOTS clients MUST be prepared to not be
      granted mitigations with indefinite lifetimes.

In all cases, it is the server who decides about the actual lifetime:

      The DOTS server MUST always indicate the actual lifetime in the
      response and the remaining lifetime in status messages sent to the
      DOTS client.

This is indicated also in the refresh request: 

   For a mitigation request to continue beyond the initial negotiated
                                                   ^^^^^^^^^^^^^^^^^^
   lifetime, the DOTS client has to refresh the current mitigation
   ^^^^^^^^ 
   request by sending a new PUT request.

 I presume you mean to say that DOTS servers are free to
> set a policy limit on the maximum allowable lifetime?

[Med] That's one implementation option. Other options would be:
* honor any finite lifetime but set a max only when indefinite lifetime is requested. 
* Use a max value for requested finite lifetimes and another max if indefinite lifetime is requested   

We don't include such details as these are implementation- and deployment-specific. 

> 
> (4.4.1.2) "cdid" definition: The example in Fig. 9 does not have a
> cdid that matches the cuid.

[Med] Which is OK.

 The text indicates that these might not
> match if a client-side gateway added the cdid,

[Med] The client-domain gateways do not insert the cdid. What we say is the following:

      The 'cdid' generated by a server-domain
      gateway is likely to be the same as the 'cuid' except the case
      in which the DOTS message was relayed by a client-domain DOTS
      gateway or the 'cuid' was generated by a rogue DOTS client.

Please note that the text talks about "relayed" not "inserted". If a request is relayed by a client-domain gateway, the cuid that will be presented by the client is != from the cdid that will be generated by the server-domain gateway. This is because the client certificate != the client-domain gateway certificate. 

 but then later says
> that "only the first on-path server-domain DOTS gateway can  insert
> a 'cdid' value." After reading this a few times, I think what you
> are saying is (a) clients MUST NOT add cdid;
> (b) client-side gateways SHOULD add them;

[Med] Actually no because such information is not trusted: 

      DOTS servers MUST ignore 'cdid' attributes that are directly
      supplied by source DOTS clients or client-domain DOTS gateways.

 (c) the first server-side
> gateway MUST strip them and then add their own; and (d) subsequent
> server side gateways MUST NOT change the cdid. Is this correct?
> Either way, it could be expressed less confusingly.

[Med] I'm not sure a modification is needed because I suspect the confusion came from interpreting "relayed" as "inserted".

Please let us know if any enhancement is needed. Will be more than happy to consider it. Thanks.   

> 
> (4.4.1.3) Fig. 11: Where does the second cuid come from? Is this
> generated by the server on behalf of the client? If so, I recommend
> s/a new request with a new 'cuid'/a new request with a new, server-
> provided 'cuid'

[Med] The new cuid is generated by the client as per the following in Section 4.4.1.1: 

      DOTS servers MUST return 4.09 (Conflict) error code to a DOTS
      peer to notify that the 'cuid' is already in use by another
      DOTS client.  Upon receipt of that error code, a new 'cuid'
      MUST be generated by the DOTS peer (e.g., using [RFC4122]).

> 
> When extending the lifetime, does the new lifetime field measure
> from the initial trigger or from the moment of extension?

[Med] The latter. FWIW, the description of "lifetime" includes the following: 

      Upon the expiry of this lifetime, and if the
      request is not refreshed, the mitigation request is removed.  The
      request can be refreshed by sending the same request again.

That is, the lifetime will be decremented till it reaches 0 (i.e., expire). That’s why we have: 

   For a mitigation request to continue beyond the initial negotiated
                                        ^^^^^^
   lifetime, the DOTS client has to refresh the current mitigation
   request by sending a new PUT request.  This PUT request MUST use the
   same 'mid' value, and it MUST repeat all the other parameters as sent
   in the original mitigation request apart from a possible change to
   the 'lifetime' parameter value.  In such a case, the DOTS server MAY
   update the mitigation request, and a 2.04 (Changed) response is

"possible change" is used here to cover the case where the client decides to use adjust the lifetime as a function of the mitigation operations (e.g., use long lifetime).

 If the
> former, a change in the lifetime value is mandatory, not
> "potential." If the latter, how does the server distinguish this
> from a duplicate request?

[Med] This is done at the CoAP level (Message ID, in particular). FWIW, this is reminded in the document:

   As a reminder, the Message ID
   (Section 3 of [RFC7252]) is changed each time a new CoAP request is
   sent, and the Token (Section 5.3.1 of [RFC7252]) is randomized in
   each CoAP request.

> 
> (4.4.2) Fig. 14 uses a string to represent the status instead of one
> of the values in Table 3.

[Med] That figure is correct because:

(1) Section 4.4 says the following: 

   JSON encoding of YANG modeled data [RFC7951] is used to illustrate
   the various methods defined in the following subsections.  Also, the
   examples use the Labels defined in Sections 10.6.2, 10.6.3, 10.6.4,
   and 10.6.5.

(2) enum values are mapped to string (JSON). 

   +---------------------+--------------+------+-------------+--------+
   | Parameter Name      | YANG Type    | CBOR | CBOR Major  | JSON   |
   |                     |              | Key  | Type &      | Type   |
   |                     |              |      | Information |        |
   +=====================+==============+======+=============+========+
   | status              | enumeration  | 16   | 0 unsigned  | String |

> (4.4.3) Same with Fig. 16 and Table 4.

[Med] Idem as previous one. 

> 
> (4.4.2.1) If updates are non-confirmable, how does the client know
> if it's gotten out of sync on state updates?

[Med] The client can follow 4.4.2.2:

   The DOTS client can send the GET request at frequent intervals
   without the Observe Option to retrieve the configuration data of the
   mitigation request and non-configuration data (i.e., the attack
   status).  DOTS clients MAY be configured with a policy indicating the
   frequency of polling DOTS servers to get the mitigation status.

> (4.5.1) What is the unit of probing rate?

[Med] bytes/second. This is indicated, e.g., in the YANG module: 

       leaf current-value {
         type uint16;
         units "byte/second";
         default "5";
         description
           "Current probing-rate value.";
       }

I updated 4.5.1 to mention it there as well. Thanks.

> (8) s/should/SHOULD, s/must/MUST throughout.

[Med] We don't use the normative language here as this is redundant with what is in Section 7.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Martin Duke <[email-masked]>
Date: Wed, 2 Jun 2021 09:38:36 -0700

Hi Mohamed,

I agree with most of your responses, and below only include where I think
we need further discussion.

On Wed, Jun 2, 2021 at 2:49 AM <[email-masked]> wrote:

>       MUST be generated by the DOTS peer (e.g., using [RFC4122]).

That's not what I read from Fig. 11. The conflict response has a cuid that
has not previously appeared in the exchange. Maybe Fig. 11 is wrong?

>       request can be refreshed by sending the same request again.

OK, can we state this explicitly rather than imply it?

Thank you.

> [Med] We don't use the normative language here as this is redundant with

I was unable to find another mention of much of the material in this
paragraph:

The DOTS server should support certificate-based client
   authentication.  The DOTS client should respond to the DOTS server's
   TLS CertificateRequest message with the PKIX certificate held by the
   DOTS client.  DOTS client certificate validation must be performed
   per [RFC5280 <https://datatracker.ietf.org/doc/html/rfc5280>], and
the DOTS client certificate must conform to the
   [RFC5280 <https://datatracker.ietf.org/doc/html/rfc5280>]
certificate profile.  If a DOTS client does not support TLS
   client certificate authentication, it must support client
   authentication based on pre-shared key or raw public key.

in particular, the the last "must" does not obviously appear elsewhere,
unless you're rephrasing it substantially.

---

From: <[email-masked]>
Date: Wed, 2 Jun 2021 17:56:45 +0000

Re-,

Please see inline.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Martin Duke
Envoyé : mercredi 2 juin 2021 18:39
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
Cc : [email-masked]; [email-masked]; [email-masked]; The IESG <[email-masked]>; [email-masked]
Objet : Re: [Dots] Martin Duke's No Objection on draft-ietf-dots-rfc8782-bis-07: (with COMMENT)

Hi Mohamed,

I agree with most of your responses, and below only include where I think we need further discussion.

> s/a new request with a new 'cuid'/a new request with a new, server-

[Med] The new cuid is generated by the client as per the following in Section 4.4.1.1<http://4.4.1.1>:

That's not what I read from Fig. 11. The conflict response has a cuid that has not previously appeared in the exchange. Maybe Fig. 11 is wrong?

[Med] The example does not depend on previous ones but I understand that it is better if a cuid used in previous examples is used here as well. Updated the example to use the cuid used in previous figures.

Please note that the “conflict response” does not include a cuid.

OK, can we state this explicitly rather than imply it?
[Med] Sure. I made two changes:

(1)
OLD:
  Upon the expiry of the negotiated lifetime, and if the request is…
NEW:
  Upon the expiry of the negotiated lifetime (i.e., the remaining lifetime reaches '0'), and if the request is

(2)

OLD:
the DOTS server MAY update the mitigation request

NEW:
the DOTS server MAY update the mitigation request by setting the remaining lifetime to the newly negotiated lifetime

You can also track these changes (and others) at: https://tinyurl.com/8782bis-latest.

       leaf current-value {
         type uint16;
         units "byte/second";
         default "5";
         description

Thank you.

I was unable to find another mention of much of the material in this paragraph:

   per [RFC5280<https://datatracker.ietf.org/doc/html/rfc5280>], and the DOTS client certificate must conform to the

   [RFC5280<https://datatracker.ietf.org/doc/html/rfc5280>] certificate profile. If a DOTS client does not support TLS

   authentication based on pre-shared key or raw public key.
in particular, the the last "must" does not obviously appear elsewhere, unless you're rephrasing it substantially.
[Med] That “must” is covered by this part (MUST + last bullet):

   Implementations compliant with this profile MUST implement all of the
   following items:

   o  DTLS record replay detection (Section 3.3 of [RFC6347]) or an
      equivalent mechanism to protect against replay attacks.

   o  DTLS session resumption without server-side state to resume
      session and convey the DOTS signal.

   o  At least one of raw public keys [RFC7250] or PSK handshake
      [RFC4279] with (EC)DHE key exchange.  This reduces the size of the
      ServerHello.  Also, this can be used by DOTS agents that cannot
       obtain certificates.

The other ones are covered in the first paragraphs of Section 7.1.

---

From: Martin Duke <[email-masked]>
Date: Wed, 2 Jun 2021 12:12:10 -0700

On Wed, Jun 2, 2021 at 10:56 AM <[email-masked]> wrote:

> *[Med] The example does not depend on previous ones but I understand that
> it is better if a cuid used in previous examples is used here as well.
> Updated the example to use the cuid used in previous figures. *
>
>
>
> *Please note that the “conflict response” does not include a cuid. *
>

I cannot reconcile your statement with Figure 11:

     (2) Message body of the 4.09 (Conflict) response
       from the DOTS server

     Header: PUT (Code=0.03)
     Uri-Path: ".well-known"
     Uri-Path: "dots"
     Uri-Path: "mitigate"
     Uri-Path: "cuid=f30d281ce6b64fc5a0b91e"
     Uri-Path: "mid=12"

The rest looks good.

---

From: <[email-masked]>
Date: Wed, 2 Jun 2021 19:34:09 +0000

Re-,

Please see inline.

Cheers,
Med

De : Martin Duke [mailto:[email-masked]]
Envoyé : mercredi 2 juin 2021 21:12
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
Cc : [email-masked]; [email-masked]; [email-masked]; The IESG <[email-masked]>; [email-masked]
Objet : Re: [Dots] Martin Duke's No Objection on draft-ietf-dots-rfc8782-bis-07: (with COMMENT)

On Wed, Jun 2, 2021 at 10:56 AM <[email-masked]<mailto:[email-masked]>> wrote:

       from the DOTS server

     Header: PUT (Code=0.03)

     Uri-Path: ".well-known"

     Uri-Path: "dots"

     Uri-Path: "mitigate"

     Uri-Path: "mid=12"

[Med] The full figure is as follows:

==

     Header: PUT (Code=0.03)

     Uri-Path: ".well-known"

     Uri-Path: "dots"

     Uri-Path: "mitigate"

     Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"

     Uri-Path: "mid=12"

     (1) Request with a conflicting 'cuid'

     {

       "ietf-dots-signal-channel:mitigation-scope": {

          "scope": [

             {

               "conflict-information": {

                 "conflict-cause": "cuid-collision"

                }

             }

           ]

        }

     }

       from the DOTS server

     Header: PUT (Code=0.03)

     Uri-Path: ".well-known"

     Uri-Path: "dots"

     Uri-Path: "mitigate"

     Uri-Path: "mid=12"

     (3) Request with a new 'cuid'

               Figure 11: Example of Generating a New 'cuid'

==

The response body corresponds to the second part, that is:

==

     {

       "ietf-dots-signal-channel:mitigation-scope": {

          "scope": [

             {

               "conflict-information": {

                 "conflict-cause": "cuid-collision"

                }

             }

           ]

        }

     }

       from the DOTS server

==

If you think this would be less confusing, we can move up the legends as follows:

==

     (1) Request with a conflicting 'cuid'

     Header: PUT (Code=0.03)

     Uri-Path: ".well-known"

     Uri-Path: "dots"

     Uri-Path: "mitigate"

     Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"

     Uri-Path: "mid=12"

       from the DOTS server

     {

       "ietf-dots-signal-channel:mitigation-scope": {

          "scope": [

             {

               "conflict-information": {

                 "conflict-cause": "cuid-collision"

                }

             }

           ]

        }

     }

     (3) Request with a new 'cuid'

     Header: PUT (Code=0.03)

     Uri-Path: ".well-known"

     Uri-Path: "dots"

     Uri-Path: "mitigate"

     Uri-Path: "mid=12"

               Figure 11: Example of Generating a New 'cuid'

==

The rest looks good.

[Med] Thank you.

---

From: Martin Duke <[email-masked]>
Date: Thu, 3 Jun 2021 07:28:59 -0700

Ah yes, I see it now.

Yes, putting the caption above is better.

On Wed, Jun 2, 2021 at 12:34 PM <[email-masked]> wrote:

> Re-,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Martin Duke [mailto:[email-masked]]
> *Envoyé :* mercredi 2 juin 2021 21:12
> *À :* BOUCADAIR Mohamed INNOV/NET <[email-masked]>
> *Cc :* [email-masked]; [email-masked]; [email-masked]; The IESG <
> [email-masked]>; [email-masked]
> *Objet :* Re: [Dots] Martin Duke's No Objection on
> draft-ietf-dots-rfc8782-bis-07: (with COMMENT)
>
>
>
>
>
>
>
> *[Med] The full figure is as follows: *
>
>
>
> *==*
>
> *     Header: PUT (Code=0.03)*
>
> *     Uri-Path: ".well-known"*
>
> *     Uri-Path: "dots"*
>
> *     Uri-Path: "mitigate"*
>
> *     Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"*
>
> *     Uri-Path: "mid=12"*
>
>
>
> *     (1) Request with a conflicting 'cuid'*
>
>
>
> *     {*
>
> *       "ietf-dots-signal-channel:mitigation-scope": {*
>
> *          "scope": [*
>
> *             {*
>
> *               "conflict-information": {*
>
> *                 "conflict-cause": "cuid-collision"*
>
> *                }*
>
> *             }*
>
> *           ]*
>
> *        }*
>
> *     }*
>
>
>
> *     (2) Message body of the 4.09 (Conflict) response*
>
> *       from the DOTS server*
>
>
>
> *     Header: PUT (Code=0.03)*
>
> *     Uri-Path: ".well-known"*
>
> *     Uri-Path: "dots"*
>
> *     Uri-Path: "mitigate"*
>
> *     Uri-Path: "cuid=f30d281ce6b64fc5a0b91e"*
>
> *     Uri-Path: "mid=12"*
>
>
>
> *     (3) Request with a new 'cuid'*
>
>
>
> *               Figure 11: Example of Generating a New 'cuid'*
>
> *==*
>
>
>
> *The response body corresponds to the second part, that is:  *
>
>
>
> *==*
>
> *     {*
>
> *       "ietf-dots-signal-channel:mitigation-scope": {*
>
> *          "scope": [*
>
> *             {*
>
> *               "conflict-information": {*
>
> *                 "conflict-cause": "cuid-collision"*
>
> *                }*
>
> *             }*
>
> *           ]*
>
> *        }*
>
> *     }*
>
>
>
> *     (2) Message body of the 4.09 (Conflict) response*
>
> *       from the DOTS server*
>
> *== *
>
>
>
> *If you think this would be less confusing, we can move up the legends as follows:  *
>
>
>
> *==*
>
>
>
> *     (1) Request with a conflicting 'cuid'*
>
>
>
> *     Header: PUT (Code=0.03)*
>
> *     Uri-Path: ".well-known"*
>
> *     Uri-Path: "dots"*
>
> *     Uri-Path: "mitigate"*
>
> *     Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"*
>
> *     Uri-Path: "mid=12"*
>
>
>
> *     (2) Message body of the 4.09 (Conflict) response*
>
> *       from the DOTS server*
>
>
>
> *     {*
>
> *       "ietf-dots-signal-channel:mitigation-scope": {*
>
> *          "scope": [*
>
> *             {*
>
> *               "conflict-information": {*
>
> *                 "conflict-cause": "cuid-collision"*
>
> *                }*
>
> *             }*
>
> *           ]*
>
> *        }*
>
> *     }*
>
>
>
> *     (3) Request with a new 'cuid'*
>
>
>
> *     Header: PUT (Code=0.03)*
>
> *     Uri-Path: ".well-known"*
>
> *     Uri-Path: "dots"*
>
> *     Uri-Path: "mitigate"*
>
> *     Uri-Path: "cuid=f30d281ce6b64fc5a0b91e"*
>
> *     Uri-Path: "mid=12"*
>
>
>
> *               Figure 11: Example of Generating a New 'cuid'*
>
>
>
> *==*
>
>
>
> The rest looks good.
>
> *[Med] Thank you. *
>