Re: [Dots] Genart last call review of draft-ietf-dots-rfc8782-bis-05

[[e-mail]]

Hi Dale, 

Thank you for the careful review. Much appreciated!

The changes to take into account your review can be tracked at: https://tinyurl.com/8782bis-latest. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Dale Worley via Datatracker [mailto:[e-mail]]
> Envoyé : mardi 23 mars 2021 01:42
> À : [e-mail]
> Cc : [e-mail]; [e-mail]; last-
> [e-mail]
> Objet : Genart last call review of draft-ietf-dots-rfc8782-bis-05
> 
> Reviewer: Dale Worley
> Review result: Ready with Issues
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed by
> the IESG for the IETF Chair.  Please treat these comments just like
> any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document:  draft-ietf-dots-rfc8782-bis-05
> Reviewer:  Dale R. Worley
> Review Date:  2021-03-22
> IETF LC End Date:  2021-03-22
> IESG Telechat date:  unknown
> 
> Summary:
> 
>     This draft is on the right track but has open issues, described
> in
>     the review.
> 
> I've provided a long list of minor editorial issues, and a short list
> of technical issues.  I suspect that the technical issues have been
> resolved in the practices of the community and that their apparent
> status as problems stems from not getting the wording properly
> aligned with practice.
> 
> Major issues:
> 
> The condition of two DOTS mitigation requests overlapping depends on
> addresses (and alternatives to them) but as defined in section 4.4.1,
> does NOT depend on port numbers.  However, other parts of the text
> seem to presume that port numbers are involved in testing for
> overlapping.  The correct choice needs to be established and the text
> made consistent.

Med: Port numbers are not considered separately as they should be bound to an IP address/FQDN/etc in order to be considered as overlapping. 

> 
> Does the requesting of a mitigation only withdraw overlapping
> mitigations that were requested using the same signal channel, or is
> the effect global?  If a mitigation request with trigger-mitigation =
> false is activated by ending of a signal channel, does reestablishing
> the channel withdraw it? 

Med: It is withdrawn if it is overlapping with a mitigation that is placed when the session is recovered. Stopping the mitigation just because the session is recovered is suboptimal in some cases as the attack may not cease.  


 (Naively I thought it would, but that isn't
> stated.)  If so, how are the former and the current signal channels
> correlated, given that cuid collisions can prevent them from using
> the same common identifiers?  Indeed, the text does not make it clear
> how a mitigation that is triggered by the ending of a signal channel
> can be withdrawn, other than by the expiration of its timer.
> 
> Minor issues:
> 
> The 4.09 response is used to report cuid conflicts, but also various
> other conflicts.  Given that cuid conflicts require specific
> processing, and can happen when other conflicts could also be
> reported, it seems to me that for cuid conflicts, you want that the
> response MUST include conflict-information.

Med: We have the following: 

   The response includes enough information for a DOTS client to
                ^^^^^^^^
   recognize the source of the conflict as described below in the
   'conflict-information' subtree with only the relevant nodes listed:

and


   4.09 (Conflict)  is returned by the DOTS server if the DOTS server
      detects that a request conflicts with a previous request.  The
      response body is formatted using "application/dots+cbor", and
      contains the "conflict-clause" (Section 4.4).
      ^^^^^^^^

Update to use MUST as it seems you have doubts about the intended meaning. 

> 
> In section 4.4.1 there is a discussion of a configuration where a
> client communicates through two different gateways to one same server
> using a different certificate to communicate with each gateway.  The
> text discusses a configuration where we want the two transaction
> streams to be treated as one by the client and server.  It seems to
> me that this is an unusual situation which can only succeed if both
> the client and server have specific configuration for it.  As a
> consequence, the situation doesn't need to be discussed in this
> document.

Med: It is needed to be taken into account as it has implication on how per-domain policies are enforced. 

  Conversely, the default result of this topology is that
> the client and server treat both transactions streams separately (and
> perhaps neither of them is aware of the overall topology).  It seems
> like this case should work correctly without any special
> considerations, and so does not need to be documented specifically,
> either.

Med: Clients do not need to be aware of the topology. Servers need some setup as they need to trust the content of 'cdid' supplied by gateways.

> 
> The overall framework for signal channel configuration is not clear.
> By default, I assume that the client sets the channel configuration,
> constrained by the limits on parameter values imposed by the server,
> and that these values apply to communication in both directions (when
> applicable).  The text in 4.5 and 4.5.1 is consistent with this
> model.
> However text in 4.5.2 talks about "agents" changing configuration
> values, which implies it's possible for the server to set channel
> configuration.

Med: Changes can be at the initiative of the server to restrict for example a parameter value range (or even a worse case of the server lost the configuration state of a client). We do need means to avoid stale configuration. 

  There is discussion in section 4.5.3 of a server
> sending "a validity time with a configuration it sends", which makes
> no sense if only the client can change the configuration -- the
> configuration won't change until the client changes it.

Med: See above.

  Also "the
> update of the configuration data if a change occurs at the DOTS
> server side".  The model needs to be established, and the text
> aligned with it.
> 
> Nits/editorial comments:
> 
> Global editorial issues:
> 
> There is a lot of special terminology, and it would help if
> definitions were gathered in section 2.  Additionally, this would
> help reveal where the text uses undefined synonyms of defined terms,
> several cases of which I have spotted.
> 
> There are issues involving "Observe".  One is at the start of section
> 4.4, where the text refers to "subscribe"

Med: There is one single occurrence of "subscribe" in the document. I made this change: s/to subscribe/to receive asynchronous.

, but that is not the term
> used in CoAP, indeed CoAP deliberately avoids that term.  Also,
> unless one is familiar with CoAP, one thinks GET has no side-effects,
> and thus cannot possibly establish a subscription.

Med: Not sure there is an issue here as we can define "application" (DOTS) terms independently of the underlying CoAP, but removed the "subscribe" occurrence as it is used only once. 

  There are related
> issues in sections 4.4.2.1 and 4.4.2.2 that left me wondering for
> which GET requests Observe was mandatory and/or permitted and what
> values (0 and/or 1) were permitted. 

Med: We meant: the support is mandatory. See below. 

 I think it would help to start
> 4.4.2.1 with an overview discussion of the permitted/required uses of
> Observe in DOTS GET requests.
> 
> It would help to have adjectives for a mitigation request with
> trigger-mitigation = false, and for a mitigation request with
> trigger-mitigation = true.
> 
> It seems that "deactivating" a mitigation request is used as an
> undefined synonym of "withdrawing" it, but (on my first two reads), I
> thought it meant "delete".

Med: It is not "delete", but passing it from an "active" state to a "deactivate" state. It is not removed by the server.

  At this point, I suspect that the words
> hide complexity which has not been made explicit:  the client
> "requests" a mitigation with trigger-mitigation = false, but the loss
> of the channel "activates" it.

Med: Yes. 

  Worse, "activation" causes the
> actions that are described as being caused by "requesting" a
> mitigation with trigger-mitigation = true.  A description of the
> states, the transitions between them, and the verbs to describe them
> should be given, perhaps in section 2.
> 
> Section 4.4.1 is 16 pages long and really should be cut into a number
> of subsections.

Med: This is a fair one. See the updated structure. 

> 
> Section 4.4.1 contains two parallel but different
> definitions/discussions of conflict-information.  Not being in a
> position to print the document, I can't quite make out what is going

Med: This organization is motivated by the need to pick the relevant information for the case that is discussed for each of them. 

> on, but I suspect some reorganization of the section is in order to
> replace the two partial definitions with one complete one.  (This
> might be connected with the entries in section 9 and/or section
> 10.3.) The two parallel definitions are partially excerpted below,
> and both have the problem that the contextual text says that the
> response will include

Med: It says "includes" which more affirmative. We changed it MUST for clarity.

 "enough information for a DOTS client to
> recognize ...", but the definition of conflict-information states
> that it is optional:

Med: It is "optional" in sense that a DOTS response may not include it compared to mandatory attributes that are always present. That's said, I see your concern. Fixed. 

> 
> -----
> 
>    The response includes enough information for a DOTS client to
>    recognize the source of the conflict as described below in the
>    'conflict-information' subtree with only the relevant nodes
> listed:
> 
>    conflict-information:  Indicates that a mitigation request is
>       conflicting with another mitigation request.  This optional
>       attribute has the following structure:
> 
> -----
> 
>    For both 2.01
>    (Created) and 4.09 (Conflict) responses, the response includes
> enough
>    information for a DOTS client to recognize the source of the
> conflict
>    as described below:
> 
>    conflict-information:  Indicates that a mitigation request is
>       conflicting with another mitigation request(s) from other DOTS
>       client(s).  This optional attribute has the following
> structure:
> 
> -----

Med: There is no conflict between these two excerpts. 

> 
> Detailed editorial issues:
> 
> (Note that some of these are summarized in a clearer way above.)
> 
> 1.  Introduction
> 
> The example of Figure 1 is introduced by this paragraph:
> 
>    An example of a network diagram that illustrates a deployment of
> DOTS
>    agents is shown in Figure 1.  In this example, a DOTS server is
>    operating on the access network.  A DOTS client is located on the
> LAN
>    (Local Area Network), while a DOTS gateway is embedded in the CPE
>    (Customer Premises Equipment).
> 
> But the example also includes a DOTS gateway, and would have been
> clearer to me if the statement introducing DOTS gateways was made
> before the start of the example rather than after it:
> 
>    The DOTS client can
>    communicate directly with a DOTS server or indirectly via a DOTS
>    gateway.

[Med] Rearranged the text. 

> 
> 3.  Design Overview
> 
>    support for asynchronous Non-confirmable messaging
> 
> It might be worth noting here or in section 2 that "Non-confirmable"
> (and "Confirmable") are CoAP technical terms.

[Med] The text is clear that this is a **CoAP** feature:

    The many features of CoAP (expectation of packet loss, 
    support for asynchronous Non-confirmable messaging 

That's said, updated the terminology section to state that the reader should be familiar with the terms defined in 7252.

> 
>    Absent such mutual agreement, the DOTS
>    signal channel MUST run over port number 4646 as defined in
>    Section 10.1, for both UDP and TCP.
> 
> It might be worth stating this port number is for both the client and
> the server to use (or that 4646 is just the listening port for
> servers).

[Med] OK. Added a note that 4646 is the listening port number for servers. 

> 
>    Also, the DOTS server may rely on the signal
>    channel session loss to trigger mitigation for preconfigured
>    mitigation requests (if any).
> 
> This doesn't carry quite the right idea.  What is really going on is
> that the DOTS client may configure mitigation requests that will be
> automatically acted upon by the server if the signal channel session
> is lost.  This is a required facility of the server, but it may be
> relied upon by the client.

[Med] That’s is why we have "(if any)" in the text. 

> 
>    DOTS signaling can happen with DTLS over UDP and TLS over TCP.
> 
> s/can happen/can use/ or perhaps "can happen over".

[Med] Went with "can use". Thanks. 

> 
>    In deployments where multiple DOTS clients are enabled in a
> network
>    (owned and operated by the same entity) ...
> 
> I think you want something like "In deployments with multiple DOTS
> clients in a single network and administrative domain ...".

[Med] Works for me. I went with this change: 

" in a single network and administrative domain (called, DOTS client domain)"

> 
>    o  Port Control Protocol (PCP) [RFC6887] or Session Traversal
>       Utilities for NAT (STUN) [RFC8489] may be used to retrieve the
>       external addresses/prefixes and/or port numbers.
> 
> Would be clearer if it is "may be used by the client to retrieve
> ...", as the preceding paragraph is about the translator and here we
> are talking about the client without explicitly mentioning it.

[Med] OK.

> 
> 4.4.  DOTS Mitigation Methods
> 
>    GET:    DOTS clients may use the GET method to subscribe to DOTS
>            server status messages or to retrieve the list of its
>            mitigations maintained by a DOTS server (Section 4.4.2).
> 
> Unless one is aware of the "Observe" option of CoAP, using GET to
> establish a subscription seems impossible, as it is a side-effect.
> The reader could be warned by wording like:
> 
>    GET:    DOTS clients may use the GET method to retrieve the list
>            of its mitigations maintained by a DOTS server (Section
>            4.4.2), or (using the CoAP Observe option [RFC7641]) to
>            subscribe to DOTS server status messages.
> 

[Med] We don't want to overload the text with these details at this stage. The goal is only provide a summary of the functionality. I updated the text as follows: 

   GET:    DOTS clients may use the GET method to retrieve the list of
           its mitigations maintained by a DOTS server (Section 4.4.2)
           or to subscribe to DOTS server status messages
           (Section 4.4.2.1).

> --
> 
>    Mitigation requests MUST NOT be delayed
>    because of checks on probing rate (Section 4.7 of [RFC7252]).
> 
> How does this sentence connect with the preceding sentences of the
> paragraph?  Also, what does "probing" refer to?

[Med] "probing rate" is a CoAP parameter (hence the pointer to 7252) that indicates the average data rate that must not be exceeded by an endpoint. Mitigation requests may be delayed by probing rate checks. This text is to relax that behavior for mitigation requests. 

  I suspect you mean
> that mitigation requests can be Non-confirmable and would by default
> fall under the rules of the preceding sentences, but you don't want
> that.  So the sentence could be clarified as "However, mitigation
> requests MUST NOT be delayed by these limitations."
> 
> 4.4.1.  Request Mitigation
> 
>          with the trailing "=" removed from the encoding
> 
> Should be 'the trailing two "="', 'the trailing "="s', or similar,
> since the base64 encoding of a string of 16 bytes will always end in
> two "=".

[Med] Added "two".  

> 
>          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.
> 
> The error code 4.09 has other defined uses in the signal channel.
> Given the special and "global" action needed based on this error
> code, there must be an unambiguous way for the client to identify
> cuid collision.  Unfortunately, there is no "session initiation
> handshake"
> message for which a 4.09 response would be unambiguous.  It seems
> like the best choice is to look for conflict-information in the
> response, since it has a conflict-cause value "CUID Collision".  But
> conflict-information is optional.  I recommend making conflict-
> information mandatory in this situation.  However, see my comments at
> the end of the section regarding the lack of clarity whether
> conflict-information is mandatory or optional.

[Med] Already discussed above. We do have the following:

   4.09 (Conflict)  is returned by the DOTS server if the DOTS server
      detects that a request conflicts with a previous request.  The
      response body is formatted using "application/dots+cbor", and
      contains the "conflict-clause" (Section 4.4).

> 
>          If the 'mid' value has reached 3/4 of (2^(32) - 1) (i.e.,
>          3221225471) and no attack is detected, the DOTS client MUST
>          reset 'mid' to 0 to handle 'mid' rollover.
> 
> It sounds like, but does not say explicitly, that mid rollover
> automatically invalidates any active high-mid mitigation request

[Med] Rollover does not happen if an ".. attack is detected", which covers the case of an active mitigation. 

, and
> thus, if the client wants to maintain any existing request, it must
> recreate them (necessarily with small mid values).  This needs to be
> clarified.

[Med] The sentence right after the one you cited, covers the case of preconfigured mitigations:

         If the DOTS client
         maintains mitigation requests with preconfigured scopes, it
         MUST recreate them with the 'mid' restarting at 0.

> 
>       The default value of the parameter is 'true' (that is, the
>       mitigation starts immediately).  If 'trigger-mitigation' is not
>       present in a request, this is equivalent to receiving a request
>       with 'trigger-mitigation' set to 'true'.
> 
> The second sentence is completely redundant, but I suspect that a
> practical need for it has been discovered.

[Med] This is to avoid ambiguous implementation behaviors.  

> 
>          ... or the 'cuid' was generated from a rogue DOTS client.
> 
> Probably s/from/by/.

[Med] Fixed. 

> 
> But it seems that there is a valid situation where duplicate cuids
> are plausible, when two DOTS clients are using the same certificate
> to peer with a server because that certificate is what the server
> administrator provided to peer with the server.  I don't know if that
> is worth mentioning here, though.
> 
>          If a DOTS client is provisioned, for example, with distinct
>          certificates as a function of the peer server-domain DOTS
>          gateway, distinct 'cdid' values may be supplied by a server-
>          domain DOTS gateway.  The ultimate DOTS server MUST treat
> those
>          'cdid' values as equivalent.
> 
> I'm having a hard time following this, probably because I am not
> familiar with the language used to describe these situations.  I
> think it means

[Med] You got it. That wasn't that hard :-)

> 
>          If a DOTS client is provisioned, for example, with distinct
>          certificates to use to peer with distinct server-domain DOTS
>          gateways that peer to the same DOTS server, distinct 'cdid'
>          values may be supplied by the gateways to the server.  The
>          ultimate DOTS server MUST treat those 'cdid' values as
>          equivalent.
> 
> The final normative statement is clear, but it isn't clear to me how
> the server can implement that, unless it is provisioned with the
> knowledge that the two certificates are used by the same client.

[Med] This is deployment-specific. Tagging two cdids as equivalent can be based on local information (including what can be gathered at other layers by the gateways) or during the initialization of the service. That knowledge is needed to identify resources that are bound to a client domain. These considerations are out of scope.       

> 
> More subtly, if the server must treat them as equivalent,
> dependencies between transactions in one transaction stream apply to
> the union of the transaction streams through the two servers.  E.g.
> the rule that mid is nearly-monotonic and the consequences thereof.
> Handling this correctly requires that the client knows that
> transactions through the two gateways will be handled equivalently by
> one same server, and that seems to require that the client also be
> configured with particular knowledge.

[Med] Multi-homing considerations are out of scope and are discussed in a separate document. 

> 
> It seems to me that there are actually two cases (1) a "dumb" case
> where the client happens to access the same server through two
> gateways, but neither the client nor the server knows that.  In that
> case, the signal channel protocol "just works" normally. (2) a
> "smart"
> case where both the client and serve must know that access through
> the two gateways is considered equivalent (but the gateways do not
> need to know).  In that case, as long as both the client and server
> agree on this equivalence, the signal channel protocol also "just
> works".
> 
> It's not clear that it is necessary to document here the "smart"
> case, as the needed adjustments are logically determined by the
> intended use case.  If it is not needed, the quoted paragraph is
> probably best omitted, because trying to implement it generally would
> tend to cause the "dumb" case to fail.

[Med] The case is mentioned here as per-domain policies may fail if the server does not treat these cdids as equivalent. 

> 
>    If the mitigation request
>    contains the 'alias-name' and other parameters identifying the
> target
>    resources (such as 'target-prefix', 'target-port-range', 'target-
>    fqdn', or 'target-uri'), the DOTS server appends the parameter
> values
>    in 'alias-name' with the corresponding parameter values in
> 'target-
>    prefix', 'target-port-range', 'target-fqdn', or 'target-uri'.
> 
> This sentence is not connected with any other processing

[Med] This is to help with "duplicate mitigation requests" mentioned in the sentence right before the one you quoted. 

 -- what use
> is the concatenated value put to?  Also, the processing described
> will NOT be done if alias-name is not present,

[Med] Yeah, that's why we have: "If the mitigation request .."

 suggesting that in
> some way it is optional.  Also, the phrase "the parameter values in
> 'alias-name'" is undefined, as alias-name is an opaque string value.

[Med] This text is to be linked with this one: 

   The DOTS server couples the DOTS signal and data channel sessions
   using the DOTS client identity and optionally the 'cdid' parameter
   value, so the DOTS server can validate whether the aliases conveyed
   in the mitigation request were indeed created by the same DOTS client
   using the DOTS data channel session.  If the aliases were not created
   by the DOTS client, the DOTS server MUST return 4.00 (Bad Request) in
   the response.

alias-name is a pointer to the following parameter values defined in the data channel:

        |  |  +--rw alias* [name]
        |  |     +--rw name                 string
        |  |     +--rw target-prefix*       inet:ip-prefix
        |  |     +--rw target-port-range* [lower-port]
        |  |     |  +--rw lower-port    inet:port-number
        |  |     |  +--rw upper-port?   inet:port-number
        |  |     +--rw target-protocol*     uint8
        |  |     +--rw target-fqdn*         inet:domain-name
        |  |     +--rw target-uri*          inet:uri


> I suspect that some aspect of the processing has not been described.
> 
> Perhaps the meaning is that an alias is always configured as a set of
> values for the other parameters, and that if a request contains both
> an alias name and other parameters, the effective request is formed
> by merging the two sets of parameter values.  Though if that is
> meant, some provision must be made for the situation where the alias
> gives a value for a parameter that is contradicted by an explicit
> parameter in the request.
> 
>    If the DOTS server does not find the 'mid' parameter value
> conveyed
>    in the PUT request in its configuration data [it may interpret it
>    in a certain way]
> 
> It's not clear what is going on here, as "mid=..." is a mandatory
> part of the Uri-Path, and any such request must be rejected.

[Med] This is not about the presence of "mid" in the request, but about no state is found for this mid in the server's configuration:  

   If the DOTS server does not find the 'mid' parameter value conveyed
   in the PUT request in its configuration data
                        ^^^^^^^^^^^^^^^^^^^^^^                     
> 
>    A DOTS server could reject mitigation requests when it is
>    near capacity or needs to rate-limit a particular client, for
>    example.
> 
> This should be a separate paragraph,

[Med] It is related to handling new requests. Will maintain it. 

 as it applies more broadly than
> the conditions of the first sentence of the paragraph.  Also, it
> probably merits s/could/MAY/.

[Med] OK for me.

> 
>    Two mitigation requests from a DOTS
>    client have overlapping scopes if there is a common IP address, IP
>    prefix, FQDN, URI, or alias.
> 
> Probably worth stating explicitly that a common port number is NOT a
> factor in determining overlapping scopes.

[Med] Ports overlapping is also considered but this is a subcase of common IP prefix/FQDN/... This is covered in the next para: 

      conflict-scope:  Characterizes the exact conflict scope.  It may
         include a list of IP addresses, a list of prefixes, a list of
         port numbers, a list of target protocols, a list of FQDNs, a
         ^^^^^^^^^^^^
         list of URIs, a list of aliases, or a 'mid'.  

> 
>    If the DOTS server receives a mitigation request that overlaps
> with
>    an active mitigation request, but both have distinct 'trigger-
>    mitigation' types, the DOTS server SHOULD deactivate (absent
> explicit
>    policy/configuration otherwise) the mitigation request with
> 'trigger-
>    mitigation' set to 'false'.
> 
> I'm pretty sure I don't know what this means.  What does "deactivate"
> mean?

[Med] This means that the request with 'trigger-mitigation' set to false won't be activated. The request won't be removed/delete, but just its state will change.  

  The first time I read it, I thought it meant "delete", The
> second time, I suspected it meant the opposite action of "activate",
> which is what happens to a trigger-mitigation = false mitigation when
> the signal channel is lost.  The third time, I was wondering why the
> reestablishment of the signal channel didn't automatically cause the
> trigger-mitigation = false mitigation to be deactivated.

[Med] That case is covered in the sentence right after the one you quoted. The one you quoted covers also a case where a preconfigured request is received (for some reason) while a mitigation is active. 

> 
>       conflict-scope:  Characterizes the exact conflict scope.  It
> may
>          include a list of IP addresses, a list of prefixes, a list
> of
>          port numbers, a list of target protocols, a list of FQDNs, a
>          list of URIs, a list of aliases, or references to
> conflicting
>          ACLs (by an 'acl-name', typically [RFC8783]).
> 
> Note this text includes a "list of port numbers", but port numbers
> are not a factor in conflicts.

[Med] Ports are not taken separately as IP addresses and so one. There are returned only if there is a conflict of IP address, URI, FQDN, etc. 

> 
> Also, is it really intended that this parameter is, effectively, only
> human-readable, since there is no particular way to specify what type
> of datum the value contains?

[Med] The type is indicated by the cbor key: 

           |        |  |  +-- conflict-scope
           |        |  |     +-- target-prefix*       inet:ip-prefix
           |        |  |     +-- target-port-range* [lower-port]
           |        |  |     |  +-- lower-port    inet:port-number
           |        |  |     |  +-- upper-port?   inet:port-number
           |        |  |     +-- target-protocol*     uint8
           |        |  |     +-- target-fqdn*         inet:domain-name
           |        |  |     +-- target-uri*          inet:uri
           |        |  |     +-- alias-name*          string
           |        |  |     +-- acl-list* [acl-name]
           |        |  |     |  +-- acl-name    leafref
           |        |  |     |  +-- acl-type?   leafref
           |        |  |     +-- mid?                 uint32


> 
> 4.4.2.  Retrieve Information Related to a Mitigation
> 
>     +-----------+----------------------------------------------------
> +
>     |         4 | Attack has exceeded the mitigation provider
> |
>     |           | capability.
> |
>     +-----------+----------------------------------------------------
> +
> 
> "mitigation provider" is used in a few places but it appears that the
> intended term is "mitigator".

[Med] The current text is more generic as a request may involve more than one mitigator, including recursive mitigation. 

> 
>     +-----------+----------------------------------------------------
> +
>     |         6 | Attack mitigation is now terminated.
> |
>     +-----------+----------------------------------------------------
> +
> 
> It seems like code 6 includes codes 5 and 7.  Is this ambiguity
> intended?  I suspect the text that is actually wanted is "DOTS client
> has withdrawn the mitigation request and the attack mitigation is now
> terminated."  There is a parallel issue in section 10.6.2.

[Med] '6' will be sent righter after '5' (as requests are not immediately terminated). Hence, the generic description of '6'. Will maintain the current wording. 

> 
> 4.4.2.1.  DOTS Servers Sending Mitigation Status
> 
>    DOTS
>    implementations MUST use the Observe Option for both 'mitigate'
> and
>    'config' (Section 4.2).
> 
> It's not clear what "MUST use the Observe Option" means.  Does it
> mean that clients MUST use it in GET requests for 'mitigate' and
> 'config'?

[Med] The text points to 4.2 where 'mitigate' and 'config' operations are introduced. We don't talk about GETs as this is explained in this section.

> If so, is the client allowed to use "Observe: 1", despite that this
> section only discusses the "Observe: 0" case?  Or does it just mean
> that servers must implement it, and thus respond correctly if a
> client sends it?

[Med] I went with this change: s/use/support.

> 
> 4.4.2.2.  DOTS Clients Polling for Mitigation Status
> 
>    In such case, the DOTS client recalls the mitigation request by
>    issuing a DELETE request for this mitigation request (Section
> 4.4.4).
> 
> The term "recall" is used in a few places but it seems like the
> correct term is "withdraw" (section 4.4.4).

[Med] Changed. 

> 
> 4.4.3.  Efficacy Update from DOTS Clients
> 
> In what way is an "efficacy update" different from an "update"?

[Med] It is different as it is "used to convey the mitigation efficacy update" (excerpt from the first sentence).

  Can
> "efficacy" be removed without loss, or is it a term of art for
> updates to mitigation requests sent during attacks?
> 
> It appears that an update is an "efficacy update" if and only if
> "attack-status" is present.  This should be stated at the beginning
> of the section, as otherwise it's a mystery what distinguishes
> "efficacy updates".

[Med] Good point. Rearranged the text. 

> 
> 4.4.4.  Withdraw a Mitigation
> 
>    Once the request is validated, the DOTS server immediately
>    acknowledges a DOTS client's request to withdraw the DOTS signal
>    using 2.02 (Deleted) Response Code with no response payload.
> 
> s/DOTS signal/DOTS mitigation request/

[Med] OK

> 
> 4.5.  DOTS Signal Channel Session Configuration
> 
>    d.  Acceptable signal loss ratio: Maximum retransmissions,
>        retransmission timeout value, and other message transmission
>        parameters for Confirmable messages over the DOTS signal
> channel.
> 
> What are the names of these parameters in the signal-config
> structure?

[Med] Updated to:

   d.  Acceptable signal loss ratio: Maximum retransmissions ('max-
       retransmit'), retransmission timeout value ('ack-timeout'), and
       other message transmission parameters for Confirmable messages
       over the DOTS signal channel.

> 
>    As such, the transmission-related
>    parameters ('missing-hb-allowed' and acceptable signal loss ratio)
>    are negotiated only for DOTS over unreliable transports.
> 
> It seems this could be said more clearly by listing the permitted
> fields:  "only the 'heartbeat-interval' parameter [or whatever] is
> negotiated for DOTS over reliable transports".

[Med] That's a possible approach, but we prefer to express it in reference to unreliable transport as this is our preferred transport for the DOTS signal channel. 

> 
> 4.5.1.  Discover Configuration Parameters
> 
>    At least one of the attributes 'heartbeat-interval', 'missing-hb-
>    allowed', 'probing-rate', 'max-retransmit', 'ack-timeout', and
> 'ack-
>    random-factor' MUST be present in the PUT request.  Note that
>    'heartbeat-interval', 'missing-hb-allowed', 'probing-rate', 'max-
>    retransmit', 'ack-timeout', and 'ack-random-factor', if present,
> do
>    not need to be provided for both 'mitigating-config', and 'idle-
>    config' in a PUT request.
> 
> Must both the mitigating and idle configuration sections be present
> in the PUT?

[Med] No. This is implied by the existing text but as it seems this is not that clear, I added: 

    A request does not need to include both
   'mitigating-config' and 'idle-config' attributes.

  Does the requirement "At least one..." apply to both
> sections together or each section alone? 

[Med] It applies independently of the parent container as we don't precise under idle or mitigate. 

 If e.g. missing-hb-allowed
> is present in one section but not the other, the wording gives a
> vague suggestion that the same value is implicitly provided for the
> other section.  Is this true?

[Med] Not sure what in the current text suggests this. If no value is supplied, the default one set buy the server will be used:

   The DOTS agents MUST use the negotiated
   values for message transmission parameters and default values for
   non-negotiated message transmission parameters.

> 
>    The PUT request with a higher numeric 'sid' value overrides the
> DOTS
>    signal channel session configuration data installed by a PUT
> request
>    with a lower numeric 'sid' value.  To avoid maintaining a long
> list
>    of 'sid' requests from a DOTS client, the lower numeric 'sid' MUST
> be
>    automatically deleted and no longer available at the DOTS server.
> 
> Does this mean that the PUT with the higher sid installs what values
> it provides on top of the current configuration, or does it mean that
> the previous PUT's effect is entirely removed, that is, parameters
> not given in the higher-sid PUT take their default values?  Note that
> the latter is resistant to problems from lost PUT requests but the
> former is not.

[Med] The entire old config is removed and the new one installed. I added this NEW text to further insist in this: 

   That is, the configuration
   parameters that are included in the PUT request with a higher numeric
   'sid' value will be used instead of the DOTS server's defaults.

> 
>    o  If the DOTS server finds the 'sid' parameter value conveyed in
> the
>       PUT request in its configuration data and if the DOTS server
> has
>       accepted the updated configuration parameters, 2.04 (Changed)
> MUST
>       be returned in the response.
> 
> Given the earlier statement "'sid' values MUST increase monotonically
> (when a new PUT is generated by a DOTS client to convey the
> configuration parameters for the signal channel).", if a server
> receives a PUT with the same sid as a previous PUT then the client is
> misbehaving and the server should send an error response.

[Med] We are tolerant here and allow to update the configuration. 

> 
>    A DOTS client may issue a GET message with a 'sid' Uri-Path
> parameter
>    to retrieve the negotiated configuration.
> 
> Does this sid value matter, or is only its presence important?

[Med] It is not mandatory but a client may lose a state and want to check whether a sid it maintains is the one at the server. 'sid' is also used for config refresh as discussed in next section.  

  Also,
> you probably want to expand this to "a GET message for 'config' with
> a 'sid' Uri-Path parameter ...".

[Med] OK.

> 
> 4.5.3.  Configuration Freshness and Notifications
> 
> The underlying processing is not made clear.  Roughly, it seems that
> the idea is the server has the right to change the configuration
> unilaterally at any time, but if the client does a GET of the
> configuration, the server is required to commit that it won't change
> the configuration given in the response within Max-Age Option
> seconds.
> 
> Or is this talking about a mechanism where the server can, at its
> initiative, tell the client how the client should behave?  Which is
> completely different from section 4.5.2 where the client tells the
> server how to behave.

[Med] This section is about how the client can be aware about configuration changes at the server side: this can be done by forcing the client to send a request (max-age), periodically polling the server, use of Observe. 

I'm not sure which part of the text is not clear. 

> 
> 4.5.4.  Delete DOTS Signal Channel Session Configuration
> 
>    Upon bootstrapping or reboot, a DOTS client MAY send a DELETE
> request
>    to set the configuration parameters to default values.  Such a
>    request does not include any 'sid'.
> 
> I would take it as assumed that when the (D)TLS connection is
> established, that is, when the DOTS signal channel session is
> initiated, it has the default configuration parameters.  Thus the
> DELETE described here is guaranteed to have no effect.  But perhaps
> the intention is that the signal channel is conceptualized as
> persisting longer than the (D)TLS connection, and (perhaps)
> associated with the cuid/cdid value.  If so, that should be stated
> clearly.

[Med] New (D)TLS connections may be established by the client during an attack because the OLD one can't be revived. The configuration does need to be deleted and reverted back to the default. These are deployment and implementation details that are not needed to be in the document.  

> 
> 4.6.  Redirected Signaling
> 
>    If a DOTS server wants to redirect a DOTS client to an alternative
>    DOTS server for a signal session, then the Response Code 5.03
>    (Service Unavailable) will be returned in the response to the DOTS
>    client.
> 
> What is "the response"? 

[Med] Changed to "... will be returned to the DOTS client"

 It seems that this is only sensible if the
> session is just being established, but there doesn't seem to be a
> specific session-initiation message.  If you really mean that the
> server can redirect the session in response to any request, it would
> be helpful to state that directly.

[Med] This is covered here: 

   The DOTS server can return the error Response Code 5.03 in response
   to a request from the DOTS client or convey the error Response Code
   5.03 in a unidirectional notification response from the DOTS server.

and also: 

   A Max-Age Option set to '0' may be returned for redirecting
   mitigation requests.  Such a value means that the redirection applies
   only for the mitigation request in progress.

  Also, you need to specify whether
> the connection to the alternate server is a new session (with
> independent state) or whether it is expected to be a continuation of
> the existing session (carrying the same state).

[Med] This is covered here:

   When the DOTS client receives a 5.03 response with an alternate
   server included, it considers the current request to have failed, but
   it SHOULD try resending the request to the alternate DOTS server.

> 
> 4.7.  Heartbeat Mechanism
> 
>    For
>    example, if a DOTS client receives a 2.04 response for its
> heartbeat
>    messages but no server-initiated heartbeat messages, the DOTS
> client
>    sets 'peer-hb-status' to 'false'.  The DOTS server then will ...
> 
> There is a lot of detail left out here, as there are messages and
> events involved that are not mentioned explicitly.  I think what is
> meant is "For example, if a DOTS client receives a 2.04 response for
> its heartbeat messages but no server-initiated heartbeat messages,
> the DOTS client sets 'peer-hb-status' to 'false' in its next
> heartbeat message.  Upon receiving that message, the DOTS server then
> will ..."

[Med] Good suggestion.

> 
> It might be useful to explicitly state that the bodies of responses
> to heartbeat requests are empty.
> 
> 6.  YANG/JSON Mapping Parameters to CBOR
> 
> It might help the implementors to tell whether this is the same as
> section 6 of RFC 8782 or not.

[Med] We do have the following in Section 3:

   These
   modifications are made with the constraint to avoid changes to the
   mapping table defined in Table 5 of [RFC8782] (see also Section 6).

> 
> 10.1.  DOTS Signal Channel UDP and TCP Port Number
> 
>    IANA has assigned the port number 4646 (the ASCII decimal value
> for
>    ".." (DOTS)) ...
> 
> Ow!

[Med] :-)

_________________________________________________________________________________________________________________________

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.