Subject: [Gen-art] Genart last call review of draft-ietf-dots-rfc8782-bis-05

From: Dale Worley via Datatracker <[email-masked]>
Date: Mon, 22 Mar 2021 17:42:13 -0700

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.

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?  (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.

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.  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.

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.  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.  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", 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.  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.  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".  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.  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.

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

-----

   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:

-----

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.

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.

   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).

   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.

   DOTS signaling can happen with DTLS over UDP and TLS over TCP.

s/can happen/can use/ or perhaps "can happen over".

   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 ...".

   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.

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.

--

   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?  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 "=".

         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.

         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, 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.

      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.

         ... or the 'cuid' was generated from a rogue DOTS client.

Probably s/from/by/.

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

         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.

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.

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.

   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 -- what use
is the concatenated value put to?  Also, the processing described will
NOT be done if alias-name is not present, 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.
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.

   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, as it applies more broadly than
the conditions of the first sentence of the paragraph.  Also, it
probably merits s/could/MAY/.

   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.

   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?  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.

      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.

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?

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".

    +-----------+----------------------------------------------------+
    |         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.

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'?
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?

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).

4.4.3.  Efficacy Update from DOTS Clients

In what way is an "efficacy update" different from an "update"?  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".

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/

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?

   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".

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?  Does the requirement "At least one..." apply to both
sections together or each section alone?  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?

   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.

   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.

   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?  Also,
you probably want to expand this to "a GET message for 'config' with a
'sid' Uri-Path parameter ...".

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.

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.

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"?  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.  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).

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 ..."

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.

10.1.  DOTS Signal Channel UDP and TCP Port Number

   IANA has assigned the port number 4646 (the ASCII decimal value for
   ".." (DOTS)) ...

Ow!

[END]

---

From: <[email-masked]>
Date: Tue, 23 Mar 2021 12:38:20 +0000

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:[email-masked]]
> Envoyé : mardi 23 mars 2021 01:42
> À : [email-masked]
> Cc : [email-masked]; [email-masked]; last-
> [email-masked]
> Objet : Genart last call review of draft-ietf-dots-rfc8782-bis-05
> 
> Reviewer: Dale Worley
> 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.
> 

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. 

> 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
> 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:
> 

Med: We have the following: 

                ^^^^^^^^

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. 

> 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
> 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

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.

> 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
> 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:
> 
> definitions were gathered in section 2.  Additionally, this would
> help reveal where the text uses undefined synonyms of defined terms,
> 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
> values (0 and/or 1) were permitted. 

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

 I think it would help to start
> 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
> 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.
> 

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

> 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. 

> 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. 

>       client(s).  This optional attribute has the following

Med: There is no conflict between these two excerpts. 

>    communicate directly with a DOTS server or indirectly via a DOTS

[Med] Rearranged the text. 

> (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.

> the server to use (or that 4646 is just the listening port for

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

> relied upon by the client.

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

> s/can happen/can use/ or perhaps "can happen over".

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

> 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)"

> 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.

>            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).

> 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
> since the base64 encoding of a string of 16 bytes will always end in

[Med] Added "two".  

> 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).

> 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.

> 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.

[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
> familiar with the language used to describe these situations.  I
> think it means

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

> 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. 

> 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. 

> 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

[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

> 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.
> 
> 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
                        ^^^^^^^^^^^^^^^^^^^^^^                     
> This should be a separate paragraph,

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

 as it applies more broadly than
> probably merits s/could/MAY/.

[Med] OK for me.

> 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'.  

> 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
> 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. 

> 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. 

> 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

>     |           | capability.
> |

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

[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. 

> 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.

> that servers must implement it, and thus respond correctly if a
> client sends it?

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

> correct term is "withdraw" (section 4.4.4).

[Med] Changed. 

> 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?
> 
> "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. 

> s/DOTS signal/DOTS mitigation request/

[Med] OK

> What are the names of these parameters in the signal-config

[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.

> 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. 

> 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 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.

> misbehaving and the server should send an error response.

[Med] We are tolerant here and allow to update the 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.

> completely different from section 4.5.2 where the client tells the

[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. 

> 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.  

> What is "the response"? 

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

 It seems that this is only sensible if the
> 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 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.

> 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.
> 

[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).

>    IANA has assigned the port number 4646 (the ASCII decimal value

[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.