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

[Lars Eggert <[e-mail]>]

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 <[e-mail]> 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
> 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]
> 
> 
> 
> --
> last-call mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/last-call