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

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 26 May 2021 21:47:46 -0700

Hi Dale,

A bit thanks for your careful (as always) review.
Med, thanks for responding and updating the document.

I think there's just one point left that I want to comment on:

On Tue, Mar 23, 2021 at 12:38:20PM +0000, [email-masked] wrote:
> 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
> > 
[...]
> >   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.

This seems to imply that the session state indeed is preserved across the
change of server, since it is just "resending the request" without mention
of reestablishing aliases or other setup.  We probably should be more
explicit about what we expect to happen, here.

Thanks,

Ben

---

From: <[email-masked]>
Date: Thu, 27 May 2021 12:46:50 +0000

Hi Ben, Dale, all, 

> This seems to imply that the session state indeed is preserved across
> the change of server, since it is just "resending the request"
> without mention of reestablishing aliases or other setup.  We
> probably should be more explicit about what we expect to happen,
> here.

Sure. Added a note to explicit the expected behavior:
https://www.ietf.org/rfcdiff?url1=draft-ietf-dots-rfc8782-bis-06&url2=draft-ietf-dots-rfc8782-bis-07 

Cheers,
Med

> De : Dots [mailto:[email-masked]] De la part de Benjamin Kaduk
> Envoyé : jeudi 27 mai 2021 06:48
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
> Cc : [email-masked]; [email-masked];
> [email-masked]; Dale Worley <[email-masked]>; [email-masked]
> Objet : Re: [Dots] Genart last call review of draft-ietf-dots-
> rfc8782-bis-05
> 
> Hi Dale,
> 
> 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
> > >
> [...]
> This seems to imply that the session state indeed is preserved across
> the change of server, since it is just "resending the request"
> without mention of reestablishing aliases or other setup.  We
> probably should be more explicit about what we expect to happen,
> here.
> 
> Thanks,
> 
> Ben 

_________________________________________________________________________________________________________________________

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

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

---

From: Lars Eggert <[email-masked]>
Date: Mon, 31 May 2021 12:33:08 +0300

Dale, thank you for your extensive review. I have entered a No Objection ballot for this document based on the follow-up discussion.

Lars

> On 2021-3-23, at 2:42, Dale Worley via Datatracker <[email-masked]> wrote:
> 
> 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
> 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]
> 
> 
> 
> --
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call