Subject: Re: [Dots] WGLC on DOTS Signal Channel

From: kaname nishizuka <[email-masked]>
Date: Wed, 4 Apr 2018 09:27:13 +0900

Hi,

I have one clarification questions about sid in signal channel session configuration.

The draft says:
  At least one of the attributes ’heartbeat-interval’, ’missing-hb
allowed’, ’max-retransmit’, ’ack-timeout’, ’ack-random-factor’, and
  ’trigger-mitigation’ MUST be present in the PUT request.
  (snip)
  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.

assuming these are default values of a DOTS server:
  'heartbeat-interval'=30
  ’max-retransmit’=3

if these messages came to the DOTS server consecutively,
  1. sid=123, "heartbeat-interval"=10
  2. sid=456, ’max-retransmit’=5
in the final state, the first change should be discarded?:
  'heartbeat-interval'=30
  ’max-retransmit’=5
or accumulated?:
  'heartbeat-interval'=10
  ’max-retransmit’=5

so, the question is: should they be overridden by default values even if it is not specified?
I think the former is ideal behavior.
However, if so, the DOTS server is only required to keep the latest resource of the highest sid,
then there should be no difference between DELETE message with and without sid.

regards,
Kaname

On 2018/03/21 19:32, Roman Danyliw wrote:
> Hello!
>
> Consistent with our discussion at the London meeting, we are starting a working group last call (WGLC) for the DOTS Signal Channel draft:
>
> DOTS Signal Channel Specification
> draft-ietf-dots-signal-channel-18
> https://tools.ietf.org/html/draft-ietf-dots-signal-channel-18
>
> Please send comments to the DOTS mailing list -- feedback on remaining issues or needed changes; as well as endorsements that this draft is ready.
>
> This WGLC will end on April 6, 2018.
>
> Thanks,
> Roman
>
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: <[email-masked]>
Date: Wed, 4 Apr 2018 06:22:34 +0000

Hi Kaname, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:[email-masked]] De la part de kaname nishizuka
> Envoyé : mercredi 4 avril 2018 02:27
> À : [email-masked]
> Objet : Re: [Dots] WGLC on DOTS Signal Channel
> 
> Hi,
> 

[Med] The behavior to follow is covered by this text: 

   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.

And 

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

> then there should be no difference between DELETE message with and without

[Med] To delete a configuration, a client may send a DELETE with a valid 'sid' or a DELETE without supplying a 'sid'. 
Both are considered as valid in Section 4.5.4.

> > Consistent with our discussion at the London meeting, we are starting a
> working group last call (WGLC) for the DOTS Signal Channel draft:
> >
> > Please send comments to the DOTS mailing list -- feedback on remaining
> issues or needed changes; as well as endorsements that this draft is ready.
> >

---

From: kaname nishizuka <[email-masked]>
Date: Wed, 4 Apr 2018 15:56:37 +0900

Hi Med,

>     non-negotiated message transmission parameters.

Thanks, so, in my example, final state is
   'heartbeat-interval'=30 (reverted to default value)
   ’max-retransmit’=5
and the lower numeric 'sid' no longer exist in the DOTS server, right?

> Both are considered as valid in Section 4.5.4.
both are OK and have the same effect on DOTS server, right?

A DOTS server always keeps the latest sid only. A DOTS client always attempt to update it.
So there is no reason to use PUT, GET, DELETE with sid.
Why sid does exist is confusing me.

I'm afraid it was discussed on the ML but I'd like to know the rational of existence of sid.
```
  sid: Session Identifier is an identifier for the DOTS signal channel
  session configuration data represented as an integer. This
  identifier MUST be generated by DOTS clients. ’sid’ values MUST
  increase monotonically.
```
this is not convincing because always only one configuration is registered on DOTS server.
it will completely work without sid.

thanks,
Kaname

---

From: <[email-masked]>
Date: Wed, 4 Apr 2018 07:31:56 +0000

Re-,

Please see inline. 

Cheers,
Med

> De : kaname nishizuka [mailto:[email-masked]]
> Envoyé : mercredi 4 avril 2018 08:57
> À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
> >> so, the question is: should they be overridden by default values even if
> it
> >> is not specified?

[Med] Exactly. 

> >> However, if so, the DOTS server is only required to keep the latest
> resource
> >> of the highest sid,
> > [Med] To delete a configuration, a client may send a DELETE with a valid
> 'sid' or a DELETE without supplying a 'sid'.

[Med] Yes. 

> 
> A DOTS server always keeps the latest sid only.

[Med] Not the "latest" received sid...but the request with the higher sid. 

 A DOTS client always attempt
> to update it.

[Med] 'sid' is there to solve out of order configuration requests. The rationale is explained in slide 12 of https://datatracker.ietf.org/meeting/interim-2018-dots-01/materials/slides-interim-2018-dots-01-sessa-signal-channel-00.pdf

---

From: kaname nishizuka <[email-masked]>
Date: Wed, 4 Apr 2018 17:20:03 +0900

Hi Med,

Thank you for the clarification and the proper reference.
I can not assume that my DOTS client will do Out-of-Order Configuration Requests, but... I got understand that 'sid' is the solution to out of order configuration requests.

2 more questions:

1. GET with sid
On the slide 12, it is written in the table that 'sid' URI Parameter MUST NOT exist in GET.
However, In RFC7252:
5.8.1. GET
  The GET method retrieves a representation for the information that
  currently corresponds to the resource identified by the request URI.

So, I think the resource made by PUT in the exact URI path may be retrieved by GET.
I and Jon got consensus that the expected response of GET with sid is a "Figure 18: GET Configuration Response Body" like response with current value of that sid at the interop testing.
The current draft is not clear about this behavior.

2. how to get default values after several negotiations
GET without sid returns the current values.
The default values can be retrieved only just after bootsrapping or sending DELETE request.
(a DOTS client MAY send a DELETE request to set the configuration parameters to default values.)
I'd like to get the default values even after negotiations. Is there any way to get them?

thanks,
Kaname

---

From: <[email-masked]>
Date: Wed, 4 Apr 2018 09:28:43 +0000

Re-,

Thank you for  the comments. 

Please see inline.

Cheers,
Med

> Envoyé : mercredi 4 avril 2018 10:20
> I can not assume that my DOTS client will do Out-of-Order Configuration
> Requests, but... I got understand that 'sid' is the solution to out of order
> configuration requests.
> 
> 2 more questions:
> 
> 1. GET with sid

[Med] Actually, the GET in that slide refers to the case to discover configuration parameters when, for example, a client bootstraps. In such case, there is no 'sid' to play with.

> So, I think the resource made by PUT in the exact URI path may be retrieved

[Med] Agree. The signal channel specification does not change the RFC7252 behavior.

> I and Jon got consensus that the expected response of GET with sid is a
> "Figure 18: GET Configuration Response Body" like response with current value
> of that sid at the interop testing.

[Med] As I mentioned above, we are not changing the 7252 behavior. I can add this NEW text if it helps: 

   A DOTS client may issue a GET message with or without 'sid' parameter
   to retrieve the configuration parameters.  The response message body
   is the same as the one depicted in Figure 18.
 
> I'd like to get the default values even after negotiations. Is there any way

[Med] Default values are known to DOTS agents by design. That is a DOTS agent assumes the following default values: 

The RECOMMENDED values of transmission parameter
   values are ack-timeout (2 seconds), max-retransmit (3), ack-random-
   factor (1.5).  In addition to those parameters, the RECOMMENDED
   specific DOTS transmission parameter values are 'heartbeat-interval'
   (30 seconds) and 'missing-hb-allowed' (5).

When DOTS agents negotiate a given parameter, the negotiated value is used to override the default one. Otherwise, the default value is used. 

A DOTS client maintains a state whether a value was negotiated. As such, a DOTS client does not need to discover default values.

Did I missed something?

> >>>> then there should be no difference between DELETE message with and
> without
> >>>> sid.
> >>>>
> > [Med] 'sid' is there to solve out of order configuration requests. The
> rationale is explained in slide 12 of
> https://datatracker.ietf.org/meeting/interim-2018-dots-01/materials/slides-
> interim-2018-dots-01-sessa-signal-channel-00.pdf
> >
> >> this is not convincing because always only one configuration is registered
> on
> >> DOTS server.

---

From: kaname nishizuka <[email-masked]>
Date: Fri, 6 Apr 2018 14:40:13 +0900

Hi Med,

Please see inline.

thanks,
Kaname

>     is the same as the one depicted in Figure 18.
[kaname]
Referring to Figure 18 was not precise, sorry.
The GET with sid will include sid in response body according to YANG module(5.1, 5.2)

So, this would be more precise.

    A DOTS client may issue a GET message with or without 'sid' parameter
    to retrieve the configuration parameters.  The response message body
    follows the YANG module "ietf-dots-signal-channel" (Section 5.2).

>     (30 seconds) and 'missing-hb-allowed' (5).

[Kaname]
I thought each DOTS server could have its own default values because the default values by design is just a recommendation.

> A DOTS client maintains a state whether a value was negotiated. As such, a DOTS client does not need to discover default values.
[Kaname]
Yes, that's true.
What I thought was, from operational perspective, an operator may want to know the default values of the DOTS server before deleting the negotiated values.
But, I agree that is out of DOTS spec.

---

From: <[email-masked]>
Date: Fri, 6 Apr 2018 07:22:56 +0000

Hi Kaname, 

Please see inline. 

Cheers,
Med

> Envoyé : vendredi 6 avril 2018 07:40
> >> On the slide 12, it is written in the table that 'sid' URI Parameter MUST
> NOT
> >> exist in GET.
> > [Med] Actually, the GET in that slide refers to the case to discover
> configuration parameters when, for example, a client bootstraps. In such
> case, there is no 'sid' to play with.
> >
> >> However, In RFC7252:
> >> 5.8.1. GET
> >> So, I think the resource made by PUT in the exact URI path may be
> retrieved
> >> by GET.

[Med] I suggest to delete "or without" because this is already discussed in 4.5.1.

"A DOTS client may issue a GET message with 'sid' parameter to retrieve the configuration parameters."  

If we are silent about the response, this means that the client should accept both responses with or without 'sid' in the body. 

Do you want the text to be more specific, e.g.:
(1) always return sid in the response? If so, does the client uses that information for some processing?
(2) forbid to return the sid? The client will assume that the response matches the sid included in the request.
(3) allow for both cases. 

> >> The default values can be retrieved only just after bootsrapping or
> sending
> >> DELETE request.
> >> (a DOTS client MAY send a DELETE request to set the configuration
> parameters
> >> to default values.)
> >> I'd like to get the default values even after negotiations. Is there any
> way
> >> to get them?
> > [Med] Default values are known to DOTS agents by design. That is a DOTS
> agent assumes the following default values:
> >
> I thought each DOTS server could have its own default values because the
> default values by design is just a recommendation.
> 

[Med] One way to discover whether a sever uses non-recommended values as default is to issue a GET at bootstrap or after a DELTETE.

> > When DOTS agents negotiate a given parameter, the negotiated value is used
> to override the default one. Otherwise, the default value is used.
> >
> > A DOTS client maintains a state whether a value was negotiated. As such, a
> DOTS client does not need to discover default values.
> [Kaname]
> Yes, that's true.
> What I thought was, from operational perspective, an operator may want to
> know the default values of the DOTS server before deleting the negotiated
> values.
> >>>>>       of 'sid' requests from a DOTS client, the lower numeric 'sid'
> MUST
> >> be
> >>>> I'm afraid it was discussed on the ML but I'd like to know the rational
> of
> >>>> existence of sid.
> >>>> ```

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sat, 7 Apr 2018 04:58:14 +0000

Please see inline

> -----Original Message-----
> From: Dots [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Friday, April 6, 2018 12:53 PM
> To: kaname nishizuka <[email-masked]>; [email-masked]
> Subject: Re: [Dots] WGLC on DOTS Signal Channel
> 
> Hi Kaname,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > De : kaname nishizuka [mailto:[email-masked]] Envoyé : vendredi 6
> > avril 2018 07:40 À : BOUCADAIR Mohamed IMT/OLN; [email-masked] Objet :
> > Re: [Dots] WGLC on DOTS Signal Channel
> >
> > Hi Med,
> >
> > Please see inline.
> >
> > thanks,
> > Kaname
> >
> > >> De : kaname nishizuka [mailto:[email-masked]] Envoyé : mercredi 4
> > >> avril 2018 10:20 À : BOUCADAIR Mohamed IMT/OLN; [email-masked] Objet
> > >> : Re: [Dots] WGLC on DOTS Signal Channel
> > >>
> > >> Hi Med,
> > >>
> > >> I can not assume that my DOTS client will do Out-of-Order
> > >> Configuration Requests, but... I got understand that 'sid' is the
> > >> solution to out of
> > order
> > >> configuration requests.
> > >>
> > >> 2 more questions:
> > >>
> > >> 1. GET with sid
> > configuration parameters when, for example, a client bootstraps. In
> > such case, there is no 'sid' to play with.
> > >
> > >> However, In RFC7252:
> > >> 5.8.1. GET
> > > [Med] Agree. The signal channel specification does not change the
> > > RFC7252
> > behavior.
> > >
> > >> I and Jon got consensus that the expected response of GET with sid
> > >> is a "Figure 18: GET Configuration Response Body" like response
> > >> with current
> > value
> > > [Med] As I mentioned above, we are not changing the 7252 behavior. I
> > > can
> > add this NEW text if it helps:
> > >
> If we are silent about the response, this means that the client should accept
> both responses with or without 'sid' in the body.
> 

Configuration request/response are confirmable messages, DOTS client will know if its request is accepted by the server or not, don't see the need to return "sid" in the response.
However, "sid" is useful in the request, though the client sends configuration request in order, they may arrive
at the DOTS server out-of-order (requests may take different network paths).

Cheers
-Tiru

> 
> >
> > >> 2. how to get default values after several negotiations GET without
> > >> sid returns the current values.
> > I thought each DOTS server could have its own default values because
> > the default values by design is just a recommendation.
> >
> 
> [Med] One way to discover whether a sever uses non-recommended values as
> default is to issue a GET at bootstrap or after a DELTETE.
> 
> > What I thought was, from operational perspective, an operator may want
> > to know the default values of the DOTS server before deleting the
> > negotiated values.
> > >>>> De : kaname nishizuka [mailto:[email-masked]] Envoyé : mercredi
> > >>>> 4 avril 2018 08:57 À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
> > >>>>>> Envoyé : mercredi 4 avril 2018 02:27 À : [email-masked] Objet :
> > >>>>>> Re: [Dots] WGLC on DOTS Signal Channel
> > >>>>>>
> > >>>>>> Hi,
> > >>>>>>
> > >>>>>>      At least one of the attributes ’heartbeat-interval’,
> > >>>>>> ’missing-hb allowed’, ’max-retransmit’, ’ack-timeout’, ’ack-random-
> factor’, and
> > >>>>>>      The PUT request with a higher numeric ’sid’ value
> > >>>>>> overrides the
> > DOTS
> > >>>>>>      signal channel session configuration data installed by a
> > >>>>>> PUT
> > request
> > >>>>>>      2. sid=456, ’max-retransmit’=5 in the final state, the
> > >>>>>> first change should be discarded?:
> > >>>>>>      'heartbeat-interval'=30
> > >>>>>>      ’max-retransmit’=5
> > >>>>>> or accumulated?:
> > >>>>>>      'heartbeat-interval'=10
> > >>>>>>      ’max-retransmit’=5
> > >>>>>>
> > >>>>>> so, the question is: should they be overridden by default
> > >>>>>> values even
> > if
> > >>>> it
> > >>>>>> is not specified?
> > >>>>>       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
> > >>>>> [Med] To delete a configuration, a client may send a DELETE with
> > >>>>> a
> > valid
> > >>> [Med] Not the "latest" received sid...but the request with the
> > >>> higher
> > sid.
> > >>>
> > >>>>>>> Consistent with our discussion at the London meeting, we are
> > >>>>>>> starting
> > a
> > >>>>>> issues or needed changes; as well as endorsements that this
> > >>>>>> draft is
> > >>>> ready.

---

From: <[email-masked]>
Date: Tue, 10 Apr 2018 12:21:45 +0000

Re-,

To conclude this one, I confirm that I added this NEW text: 

    A DOTS client may issue a GET message with 'sid' parameter to retrieve the
    configuration parameters. The response does not need to include 'sid' in its 
    message body. 

Cheers,
Med

> De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
> Envoyé : samedi 7 avril 2018 06:58
> À : BOUCADAIR Mohamed IMT/OLN; kaname nishizuka; [email-masked]
> Objet : RE: [Dots] WGLC on DOTS Signal Channel
> 
> Please see inline
> 
> > (1) always return sid in the response? If so, does the client uses that
> information
> > for some processing?
> > (2) forbid to return the sid? The client will assume that the response
> matches the
> > sid included in the request.
> Configuration request/response are confirmable messages, DOTS client will
> know if its request is accepted by the server or not, don't see the need to
> return "sid" in the response.
> However, "sid" is useful in the request, though the client sends
> configuration request in order, they may arrive

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 10 Apr 2018 13:42:59 +0000

Hello!

The WGLC last call on this draft closed this past Friday, April 6.  Thank you for all of your input.  The authors continue to work on resolving comments/feedback and will publish a new draft that captures this input.

Thanks,
Roman

> From: Dots [mailto:[email-masked]] On Behalf Of Roman Danyliw
> Sent: Wednesday, March 21, 2018 6:33 AM
> To: [email-masked]
> Subject: [Dots] WGLC on DOTS Signal Channel
> 
> Hello!
>

---

From: kaname nishizuka <[email-masked]>
Date: Wed, 11 Apr 2018 14:36:27 +0900

Hi Med, Tiru,

 > If we are silent about the response, this means that the client should accept both responses with or without 'sid' in the body.
yes, agreed.

I'm OK with the NEW text.

Thank you!
Kaname

---

From: <[email-masked]>
Date: Wed, 18 Apr 2018 13:41:36 +0000

Hi Roman, 

Can I assume that the consensus is reached for this document and that the next step is to send it to IESG ? 

Thank you. 

Chees,
Med

> De : Dots [mailto:[email-masked]] De la part de Roman Danyliw
> Envoyé : mardi 10 avril 2018 15:43
> À : [email-masked]
> The WGLC last call on this draft closed this past Friday, April 6.  Thank you
> for all of your input.  The authors continue to work on resolving
> comments/feedback and will publish a new draft that captures this input.
> 
> Thanks,
> Roman
>