Re: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)

["Konda, Tirumaleswar Reddy" <[e-mail]>]

Got it, Thanks for the clarifications.

Cheers,
-Tiru

> -----Original Message-----
> From: [e-mail]
> <[e-mail]>
> Sent: Monday, July 22, 2019 8:33 PM
> To: Konda, Tirumaleswar Reddy
> <[e-mail]>; Valery Smyslov
> <[e-mail]>; 'Benjamin Kaduk' <[e-mail]>; dots-
> [e-mail]; [e-mail]
> Subject: RE: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
> 
> Re-,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Konda, Tirumaleswar Reddy
> > [mailto:[e-mail]]
> > Envoyé : lundi 22 juillet 2019 16:02
> > À : BOUCADAIR Mohamed TGI/OLN; Valery Smyslov; 'Benjamin Kaduk';
> dots-
> > [e-mail]; [e-mail] Objet : RE: [Dots] Mirja's DISCUSS:
> > Pending Point (AD Help Needed)
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > > <[e-mail]>
> > > Sent: Monday, July 22, 2019 7:09 PM
> > > To: Konda, Tirumaleswar Reddy
> > > <[e-mail]>; Valery Smyslov
> > > <[e-mail]>; 'Benjamin Kaduk' <[e-mail]>; dots-
> > > [e-mail]; [e-mail]
> > > Subject: RE: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)
> > >
> > > This email originated from outside of the organization. Do not click
> > links or
> > > open attachments unless you recognize the sender and know the
> > > content is safe.
> > >
> > > Re-,
> > >
> > > > Yes, but 30 seconds of timeout looks too aggressive. I suggest we
> > > > use
> > > > 2 minutes (UDP uses 105 seconds) of heartbeat-interval.
> > >
> > > 30 seconds is recommended value for UDP (as this is our favorite
> > transport).
> >
> > I meant use 2 minutes for TCP (UDP heartbeat interval is 30 seconds,
> > and the timeout happens after 105 seconds).
> >
> 
> [Med] The reco we have for UDP was driven by NAT considerations. For TCP,
> why using 2 minutes is better than 5 minutes and so on? I'm afraid we don't
> have such argument. This is why I prefer to leave this deployment-specific.
> Please remember that using TCP as transport is not the recommended one.
> 
> > >
> > > If TCP is used, this falls into the following:
> > >
> > >       DOTS agents may
> > >       negotiate longer heartbeat-interval values to prevent any network
> > >       overload with too frequent keepalives.
> >
> > The above line is deployment specific not transport specific.
> 
> [Med] Deployment considerations cover transport ones.
> 
> > >
> > > Even if we include another recommended value for TCP, I'm afraid it
> > > is
> > not
> > > possible to reflect this in the YANG module:
> > >
> > >          leaf current-value {
> > >            type uint16;
> > >            units "seconds";
> > >            default "30";
> > >            description
> > >              "Current heartbeat-interval value.
> > >
> > >               '0' means that heartbeat mechanism is deactivated.";
> > >          }
> >
> > Yes, it is YANG limitation but not stop the protocol from giving a
> > recommendation for TCP.
> 
> [Med] The issue is that we need to be consistent: the parameter applies for
> all transport. We cannot set two defaults for it.
> 
> >
> > Cheers,
> > -Tiru
> >
> > >
> > > Cheers,
> > > Med
> > >
> > > > -----Message d'origine-----
> > > > De : Konda, Tirumaleswar Reddy
> > > > [mailto:[e-mail]]
> > > > Envoyé : lundi 22 juillet 2019 15:27 À : BOUCADAIR Mohamed
> > > > TGI/OLN; Valery Smyslov; 'Benjamin Kaduk';
> > > dots-
> > > > [e-mail]; [e-mail] Objet : RE: [Dots] Mirja's DISCUSS:
> > > > Pending Point (AD Help Needed)
> > > >
> > > > > -----Original Message-----
> > > > > From: [e-mail]
> > > > > <[e-mail]>
> > > > > Sent: Monday, July 22, 2019 4:32 PM
> > > > > To: Konda, Tirumaleswar Reddy
> > > > > <[e-mail]>; Valery Smyslov
> > > > > <[e-mail]>; 'Benjamin Kaduk' <[e-mail]>; dots-
> > > > > [e-mail]; [e-mail]
> > > > > Subject: RE: [Dots] Mirja's DISCUSS: Pending Point (AD Help
> > > > > Needed)
> > > > >
> > > > >
> > > > >
> > > > > Re-,
> > > > >
> > > > > Please see inline.
> > > > >
> > > > > Cheers,
> > > > > Med
> > > > >
> > > > > > -----Message d'origine-----
> > > > > > De : Konda, Tirumaleswar Reddy
> > > > > > [mailto:[e-mail]]
> > > > > > Envoyé : lundi 22 juillet 2019 12:25 À : BOUCADAIR Mohamed
> > > > > > TGI/OLN; Valery Smyslov; 'Benjamin Kaduk';
> > > > > dots-
> > > > > > [e-mail]; [e-mail] Objet : RE: [Dots] Mirja's DISCUSS:
> > > > > > Pending Point (AD Help Needed)
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Dots <[e-mail]> On Behalf Of
> > > > > > > [e-mail]
> > > > > > > Sent: Monday, July 22, 2019 3:16 PM
> > > > > > > To: Konda, Tirumaleswar Reddy
> > > > > > > <[e-mail]>; Valery Smyslov
> > > > > > > <[e-mail]>; 'Benjamin Kaduk' <[e-mail]>;
> > > > > > > dots- [e-mail]; [e-mail]
> > > > > > > Subject: Re: [Dots] Mirja's DISCUSS: Pending Point (AD Help
> > > > > > > Needed)
> > > > > > >
> > > > > > > This email originated from outside of the organization. Do
> > > > > > > not click
> > > > > > links or
> > > > > > > open attachments unless you recognize the sender and know
> > > > > > > the content is safe.
> > > > > > >
> > > > > > > Re-,
> > > > > > >
> > > > > > > Please see inline.
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Med
> > > > > > >
> > > > > > > > -----Message d'origine----- De : Konda, Tirumaleswar Reddy
> > > > > > > > [mailto:[e-mail]]
> > > > > > > > Envoyé : lundi 22 juillet 2019 10:58 À : BOUCADAIR Mohamed
> > > > > > > > TGI/OLN; Valery Smyslov; 'Benjamin Kaduk';
> > > > > > > dots-
> > > > > > > > [e-mail]; [e-mail] Objet : RE: [Dots] Mirja's
> > DISCUSS:
> > > > > > > > Pending Point (AD Help Needed)
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: [e-mail]
> > > > > > > > > <[e-mail]>
> > > > > > > > > Sent: Monday, July 22, 2019 12:38 PM
> > > > > > > > > To: Valery Smyslov <[e-mail]>; Konda,
> > > > > > > > > Tirumaleswar Reddy
> <[e-mail]>;
> > > > > > > > > 'Benjamin
> > > > > Kaduk'
> > > > > > > > > <[e-mail]>; [e-mail]; [e-mail]
> > > > > > > > > Subject: RE: [Dots] Mirja's DISCUSS: Pending Point (AD
> > > > > > > > > Help
> > > > > > > > > Needed)
> > > > > > > > >
> > > > > > > > > This email originated from outside of the organization.
> > > > > > > > > Do not click
> > > > > > > > links or
> > > > > > > > > open attachments unless you recognize the sender and
> > > > > > > > > know the content is safe.
> > > > > > > > >
> > > > > > > > > Hi Valery,
> > > > > > > > >
> > > > > > > > > Actually, we have clarified that (see for example,
> > > > > > > > > https://mailarchive.ietf.org/arch/msg/dots/21wgxXEy-
> > > > > > > > > vWecFZK9BeviBFMdnA)
> > > > > > > > >
> > > > > > > > > > All the message transmission parameters including
> > > > > > > > > > missing-hb- allowed are configurable using the DOTS
> > > > > > > > > > signal channel (see
> > > > > > > > > > draft-ietf-
> > > > > > > > > > dots-signal-channel-35#section-4.5) and these message
> > > > > > > > > > transmission parameter including the
> > > > > > > > > > missing-hb-allowed is only used for UDP
> > > > > > > > transport.
> > > > > > > > >
> > > > > > > > > We can add this NEW text to Section 4.5 If this would help:
> > > > > > > > >
> > > > > > > > >    When the DOTS signal channel is established over a
> > > > > > > > > reliable
> > > > > > transport
> > > > > > > > >    (e.g., TCP), there is no need for the reliability
> > > > > > > > > mechanisms
> > > > > > provided
> > > > > > > > >    by CoAP over UDP since the underlying TCP connection
> > provides
> > > > > > > > >    retransmissions and deduplication [RFC8323].  As
> > > > > > > > > such,
> > the
> > > > > > > > >    transmission-related parameters (missing-hb-allowed
> > > > > > > > > and
> > > > > > acceptable
> > > > > > > > >    signal loss ratio) are negotiated only for DOTS over
> > > > unreliable
> > > > > > > > >    transports.
> > > > > > > >
> > > > > > > > I propose to slightly modify the text as follows:
> > > > > > > >
> > > > > > > >     When the DOTS signal channel is established over a
> > > > > > > > reliable
> > > > > > transport
> > > > > > > >     (e.g., TCP), there is no need for the reliability
> > > > > > > > mechanisms
> > > > > > provided
> > > > > > > >     by CoAP over UDP since the underlying TCP connection
> > provides
> > > > > > > >     retransmissions and deduplication [RFC8323].  As a
> > > > > > > > reminder, Confirmable  and Non-confirmable message types
> > > > > > > > are specific to unreliable transport, and
> > > > > > > >     are not supported in CoAP over TCP.  As such, the message
> > > > > > > >     transmission-related parameters (missing heartbeats
> > > > > > > > allowed and acceptable
> > > > > > > >     signal loss ratio) are negotiated only for DOTS over
> > > > unreliable
> > > > > > > >     transports.
> > > > > > >
> > > > > > > [Med] OK. I went with the following:
> > > > > > >
> > > > > > >    When the DOTS signal channel is established over a
> > > > > > > reliable
> > > > transport
> > > > > > >    (e.g., TCP), there is no need for the reliability
> > > > > > > mechanisms
> > > > provided
> > > > > > >    by CoAP over UDP since the underlying TCP connection provides
> > > > > > >    retransmissions and deduplication [RFC8323].  As a
> > > > > > > reminder,
> > CoAP
> > > > > > >    over reliable transports does not support Confirmable or Non-
> > > > > > >    confirmable message types.  As such, the transmission-related
> > > > > > >    parameters (missing-hb-allowed and acceptable signal loss
> > > > > > > ratio)
> > > > are
> > > > > > >    negotiated only for DOTS over unreliable transports.
> > > > > >
> > > > > > Looks good.
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > If the CoAP ping us unacknowledged for a specific duration
> > > > > > > > (i.e. TCP user timeout expires), TCP will forcefully close
> > > > > > > > the connection, and the DOTS client will have
> > > > > > > >      to re-establish the TCP connection.
> > > > > > > >
> > > > > > >
> > > > > > > [Med] and made this change:
> > > > > > >
> > > > > > > OLD:
> > > > > > >    In DOTS over TCP, heartbeat messages MUST be exchanged
> > > > > > > between
> > > > > the
> > > > > > >    DOTS agents using the Ping and Pong messages specified in
> > > > > > > Section
> > > > 5.4
> > > > > > >    of [RFC8323].  That is, the DOTS agent sends a Ping
> > > > > > > message and
> > > > the
> > > > > > >    peer DOTS agent would respond by sending a single Pong
> > message.
> > > > > > >
> > > > > > > NEW:
> > > > > > >    In DOTS over TCP, heartbeat messages MUST be exchanged
> > > > > > > between
> > > > > the
> > > > > > >    DOTS agents using the Ping and Pong messages specified in
> > > > > > > Section
> > > > 5.4
> > > > > > >    of [RFC8323].  That is, the DOTS agent sends a Ping
> > > > > > > message and
> > > > the
> > > > > > >    peer DOTS agent would respond by sending a single Pong
> > message.
> > > > The
> > > > > > >    sender of a Ping message has to allow up to 'heartbeat-
> > interval'
> > > > > > >    seconds when waiting for a Pong reply.
> > > > > >
> > > > > > The last line does not look correct, the default
> > > > > > heartbeat-interval is
> > > > > > 30 seconds and the default user timeout is 5 minutes (TCP
> > > > > > connection will be closed only after 5 minutes, see
> > > > > > https://tools.ietf.org/html/rfc5482), 30 seconds looks
> > > > > > aggressive to determine the connection is lost.
> > > > > >
> > > > >
> > > > > [Med] This is a configurable parameter. When TCP is used, the
> > > > > server
> > > > will
> > > > > return the appropriate value to use.
> > > >
> > > > Yes, but 30 seconds of timeout looks too aggressive. I suggest we
> > > > use
> > > > 2 minutes (UDP uses 105 seconds) of heartbeat-interval.
> > > >
> > > > Cheers,
> > > > -Tiru
> > > >
> > > > >
> > > > > > Cheers,
> > > > > > -Tiru
> > > > > >
> > > > > > >    When a failure is detected by
> > > > > > >    a DOTS client, it proceeds with the session recovery
> > > > > > > following
> > > > the
> > > > > > >    same approach as the one used for unreliable transports.
> > > > > > >
> > > > > > > Better?
> > > > > > >
> > > > > > > > Cheers,
> > > > > > > > -Tiru
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Cheers,
> > > > > > > > > Med
> > > > > > > > >
> > > > > > > > > > -----Message d'origine----- De : Valery Smyslov
> > > > > > > > > > [mailto:[e-mail]] Envoyé :
> > > > > > > > > > samedi 20 juillet 2019 04:26 À : 'Konda, Tirumaleswar
> > > > > > > > > > Reddy'; BOUCADAIR Mohamed TGI/OLN; 'Benjamin Kaduk';
> > > > > > > > > > [e-mail];
> > > > > > > [e-mail] Objet :
> > > > > > > > > > RE: [Dots] Mirja's DISCUSS: Pending Point (AD Help
> > > > > > > > > > Needed)
> > > > > > > > > >
> > > > > > > > > > Hi Tiru,
> > > > > > > > > >
> > > > > > > > > > thank you for clarification regarding TCP. It seems
> > > > > > > > > > the this clarification somehow escaped from the
> > > > > > > > > > discussion with Mirja (at least I cannot recall it was
> mentioned).
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > > Valery.
> > > > > > > > > >
> > > > > > > > > > > Hi Valery,
> > > > > > > > > > >
> > > > > > > > > > > The message transmission parameters including
> > > > > > > > > > > missing-hb-allowed is only
> > > > > > > > > > for
> > > > > > > > > > > UDP transport (not for TCP). For the UDP, she is
> > > > > > > > > > > suggesting us to go
> > > > > > > > > > with a
> > > > > > > > > > > mechanism that checks both side of the connectivity
> > > > > > > > > > > using
> > > > > > > > > > > non-
> > > > > > > > > > confirmable
> > > > > > > > > > > message with ping and pong at the application layer
> > > > > > > > > > > instead of relying
> > > > > > > > > > on the
> > > > > > > > > > > CoAP ping/pong.
> > > > > > > > > > >
> > > > > > > > > > > Cheers,
> > > > > > > > > > > -Tiru
> > > > > > > > > > >
> > > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > > From: Dots <[e-mail]> On Behalf Of
> > > > > > > > > > > > Valery Smyslov
> > > > > > > > > > > > Sent: Friday, July 19, 2019 5:13 PM
> > > > > > > > > > > > To: [e-mail]; 'Benjamin Kaduk'
> > > > > > > > > > > > <[e-mail]>; [e-mail];
> > > > > > > > > > > > [e-mail]
> > > > > > > > > > > > Subject: Re: [Dots] Mirja's DISCUSS: Pending Point
> > > > > > > > > > > > (AD Help
> > > > > > > > > > > > Needed)
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Med,
> > > > > > > > > > > >
> > > > > > > > > > > > I believe Mirja's main point was that if you use
> > > > > > > > > > > > liveness check mechanism in the transport layer,
> > > > > > > > > > > > then if it reports that liveness check fails, then
> > > > > > > > > > > > it _also_ closes the transport
> > > > > > session.
> > > > > > > > > > > >
> > > > > > > > > > > > Quotes from her emails:
> > > > > > > > > > > > "Yes, as Coap Ping is used, the agent should not
> > > > > > > > > > > > only conclude that the DOTS signal session is
> > > > > > > > > > > > disconnected but also the Coap session and not
> > > > > > > > > > > > send any further Coap
> > > > messages
> > > > > anymore."
> > > > > > > > > > > >
> > > > > > > > > > > > and
> > > > > > > > > > > >
> > > > > > > > > > > > "Actually to my understanding this will not work.
> > > > > > > > > > > > Both TCP heartbeat and Coap Ping are transmitted
> reliably.
> > > > > > > > > > > > If you don’t receive an ack for these
> > > > > > > > > > > > transmissions you are not able to send any
> > > > > > > > > > > > additional messages and can only close the
> > > > > > connection."
> > > > > > > > > > > >
> > > > > > > > > > > > I'm not familiar with CoAP, but I suspect she's
> > > > > > > > > > > > right about TCP - if TCP layer itself doesn't
> > > > > > > > > > > > receive ACK for the sent data after several
> > > > > > > > > > > > retransmissions, the
> > > > connection is
> > > > > closed.
> > > > > > > > > > > >
> > > > > > > > > > > > As far as I understand the current draft allows
> > > > > > > > > > > > underlying liveness check to fail and has a
> > > > > > > > > > > > parameter to restart this check several times if this
> happens.
> > > > > > > > > > > > It seems that a new transport session will be
> > > > > > > > > > > > created in this case (at least if TCP is used). In
> > > > > > > > > > > > my reading of the draft this seems not been
> > > > > > > > > > > > assumed, it is assumed that the session remains
> > > > > > > > > > > > the same. So, I think that main Mirja's concern is
> > > > > > > > > > > > that it won't work
> > > > > > > > > > (at least
> > > > > > > > > > > with TCP).
> > > > > > > > > > > >
> > > > > > > > > > > > I didn't participate in the WG discussion on this,
> > > > > > > > > > > > so I don't know what was discussed regarding this issue.
> > > > > > > > > > > > If it was discussed and the WG has come to
> > > > > > > > > > > > conclusion that this is not an issue, then I
> > > > > > > > > > > > believe more text should be added to the draft so,
> > > > > > > > > > > > that people like Mirja, who didn't participate in
> > > > > > > > > > > > the discussion, don't have any concerns while
> > > > > > > > > > reading
> > > > > > > > > > > the draft.
> > > > > > > > > > > >
> > > > > > > > > > > > Regards,
> > > > > > > > > > > > Valery.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > > > From: [e-mail]
> > > > > > > > > > > > > <[e-mail]>
> > > > > > > > > > > > > Sent: Friday, July 19, 2019 9:57 AM
> > > > > > > > > > > > > To: Benjamin Kaduk ([e-mail])
> > > > > > > > > > > > > <[e-mail]>;
> > > > > > > > > > > > > dots- [e-mail]; [e-mail]
> > > > > > > > > > > > > Subject: Mirja's DISCUSS: Pending Point (AD Help
> > > > > > > > > > > > > Needed)
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi Ben, chairs, all,
> > > > > > > > > > > > >
> > > > > > > > > > > > > (restricting the discussion to the AD/chairs/WG)
> > > > > > > > > > > > >
> > > > > > > > > > > > > * Status:
> > > > > > > > > > > > >
> > > > > > > > > > > > > All DISCUSS points from Mirja's review were
> > > > > > > > > > > > > fixed, except the one discussed in this message.
> > > > > > > > > > > > >
> > > > > > > > > > > > > * Pending Point:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Rather than going into much details, I consider
> > > > > > > > > > > > > the following as the summary of the remaining
> > > > > > > > > > > > > DISCUSS point from
> > > > > > > Mirja:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > I believe there are flaws in the design. First
> > > > > > > > > > > > > > it’s a layer violation, but if more an
> > > > > > > > > > > > > > idealistic concern but usually designing in
> > > > > > > > > > > > > > layers is a good approach. But more
> > > > > > > > > > > > > > importantly, you end up with un-frequent
> > > > > > > > > > > > > > messages which may still terminate the
> > > > > > > > > > > > > > connection at some point, while what you want
> > > > > > > > > > > > > > is to simply send messages frequently in an
> > > > > > > > > > > > > > unreliable fashion but a low rate until the
> > > > > > > > > > attack is over.
> > > > > > > > > > > > >
> > > > > > > > > > > > > * Discussion:
> > > > > > > > > > > > >
> > > > > > > > > > > > > (1) First of all, let's remind that RFC7252 does
> > > > > > > > > > > > > not define how CoAP ping must be used. It does only
> say:
> > > > > > > > > > > > >
> > > > > > > > > > > > > ==
> > > > > > > > > > > > >       Provoking a Reset
> > > > > > > > > > > > >       message (e.g., by sending an Empty
> > > > > > > > > > > > > Confirmable
> > > > > > > > > > > > > message) is
> > > > > > > > > > also
> > > > > > > > > > > > >       useful as an inexpensive check of the
> > > > > > > > > > > > > liveness of an
> > > > > > > > endpoint
> > > > > > > > > > > > >       ("CoAP ping").
> > > > > > > > > > > > > ==
> > > > > > > > > > > > >
> > > > > > > > > > > > > How the liveness is assessed is left to
> > applications.
> > > > > > > > > > > > > So, there is
> > > > > > > > > > > > > ** no layer violation **.
> > > > > > > > > > > > >
> > > > > > > > > > > > > (2) What we need isn't (text from Mirja):
> > > > > > > > > > > > >
> > > > > > > > > > > > > > to simply send messages frequently in an
> > > > > > > > > > > > > > unreliable fashion but a low rate until the
> > > > > > > > > > > > > > attack
> > is over "
> > > > > > > > > > > > >
> > > > > > > > > > > > > It is actually the other way around. The spec says:
> > > > > > > > > > > > >
> > > > > > > > > > > > >   "... This is particularly useful for DOTS
> > > > > > > > > > > > >    servers that might want to reduce heartbeat
> > > > > > > > > > > > > frequency or
> > > > > > > > cease
> > > > > > > > > > > > >    heartbeat exchanges when an active DOTS
> > > > > > > > > > > > > client has not
> > > > > > > > requested
> > > > > > > > > > > > >    mitigation."
> > > > > > > > > > > > >
> > > > > > > > > > > > > What we want can be formalized as:
> > > > > > > > > > > > >  - Taking into account DDoS traffic conditions,
> > > > > > > > > > > > > a check to assess the liveness of the peer DOTS
> > > > > > > > > > > > > agent
> > > > > > > > > > > > > + maintain NAT/FW state on on-path
> > > > > > > > > > > > devices.
> > > > > > > > > > > > >
> > > > > > > > > > > > > An much more elaborated version is documented in
> > > > > > > > > > > > > SIG-004 of RFC
> > > > > > > > > > 8612.
> > > > > > > > > > > > >
> > > > > > > > > > > > > * My analysis:
> > > > > > > > > > > > >
> > > > > > > > > > > > > - The intended functionality is naturally
> > > > > > > > > > > > > provided by existing CoAP
> > > > > > > > > > > > messages.
> > > > > > > > > > > > > - Informed WG decision: The WG spent a lot of
> > > > > > > > > > > > > cycles when specifying the current behavior to
> > > > > > > > > > > > > be meet the requirements set
> > > > > > > > in
> > > > > > > > > RFC8612.
> > > > > > > > > > > > > - Why not an alternative design: We can always
> > > > > > > > > > > > > define messages with duplicated functionality,
> > > > > > > > > > > > > but that is not a good design approach
> > > > > > > > > > > > > especially when there is no evident
> > > > > > benefit.
> > > > > > > > > > > > > - The specification is not broken: it was
> > > > > > > > > > > > > implemented and
> > > > > > > > tested.
> > > > > > > > > > > > >
> > > > > > > > > > > > > And a logistic comment: this issue fits IMHO
> > > > > > > > > > > > > under the non-discuss criteria in
> > > > > > > > > > > > > https://www.ietf.org/blog/discuss-criteria-iesg-
> > > > > > > > > > > > > revi
> > > > > > > > > > > > > ew/#
> > > > > > > > > > > > > stan
> > > > > > > > > > > > > d-
> > > > > > > > > > > > undisc.
> > > > > > > > > > > > >
> > > > > > > > > > > > > * What's Next?
> > > > > > > > > > > > >
> > > > > > > > > > > > > As an editor, I don't think a change is needed
> > > > > > > > > > > > > but I'd like to hear from Ben, chairs, and the WG.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Please share your thoughts and whether you
> > > > > > > > > > > > > agree/disagree with the above analysis.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Cheers,
> > > > > > > > > > > > > Med
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > _______________________________________________
> > > > > > > > > > > > Dots mailing list
> > > > > > > > > > > > [e-mail]
> > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Dots mailing list
> > > > > > > [e-mail]
> > > > > > > https://www.ietf.org/mailman/listinfo/dots