Subject: [Dots] Alissa Cooper's Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)

From: Alissa Cooper via Datatracker <[email-masked]>
Date: Wed, 01 May 2019 18:55:35 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-dots-signal-channel-31: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

= Section 3 =

"By default, a DOTS signal channel MUST run over port number TBD as
   defined in Section 9.1, for both UDP and TCP, unless the DOTS server
   has a mutual agreement with its DOTS clients to use a different port
   number.  DOTS clients MAY alternatively support means to dynamically
   discover the ports used by their DOTS servers (e.g.,
   [I-D.boucadair-dots-server-discovery])."

MUST implies an absolute requirement, so "MUST ... unless" is a problematic
construction. Furthermore, it doesn't make sense together with "MAY
alternatively," which indicates that port number discovery is an alternative to
the fixed to-be-assigned port.

I didn't have time to get very far into draft-boucadair-dots-server-discovery,
but it appears that it does not mandate support for any single discovery
mechanism for clients and servers to support. If so, that "alternatively" seems
like more of a problem, since it allows for there to be no interoperable
mechanism for clients to discover server ports. I think maybe what was intended
here was:

s/MUST/SHOULD/
s/MAY alternatively/MAY additionally/

= Section 4.4.1 =

(1)
"In deployments where server-domain DOTS gateways are enabled,
   identity information about the origin source client domain SHOULD be
   propagated to the DOTS server.  That information is meant to assist
   the DOTS server to enforce some policies such as grouping DOTS
   clients that belong to the same DOTS domain, limiting the number of
   DOTS requests, and identifying the mitigation scope.  These policies
   can be enforced per-client, per-client domain, or both.  Also, the
   identity information may be used for auditing and debugging purposes."

Does "identity information" just refer to cdid, or something else?

(2) The constructions "MUST ... (absent explicit policy/configuration
otherwise)" are problematic. I'm assuming these are meant to be SHOULDs.

= Section 13.1 =

I don't understand why RFC 7951 is a normative reference but
draft-ietf-core-yang-cbor is an informative reference.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

= Section 4.4.1 =

"The 'cuid' is intended to be stable when communicating with a
      given DOTS server, i.e., the 'cuid' used by a DOTS client SHOULD
      NOT change over time. "

Why is this the recommended behavior?

---

From: <[email-masked]>
Date: Thu, 2 May 2019 07:18:34 +0000

Hi Alissa, 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Alissa Cooper via Datatracker [mailto:[email-masked]]
> Envoyé : jeudi 2 mai 2019 03:56
> À : The IESG
> Cc : [email-masked]; Liang Xia; dots-
> [email-masked]; [email-masked]; [email-masked]
> Objet : Alissa Cooper's Discuss on draft-ietf-dots-signal-channel-31: (with
> DISCUSS and COMMENT)
> 
> construction.

[Med] It seems that you missed "By default, ". 

 Furthermore, it doesn't make sense together with "MAY
> I didn't have time to get very far into draft-boucadair-dots-server-

[Med] I updated that reference to I-D.ietf-dots-server-discovery. 

> s/MAY alternatively/MAY additionally/

[Med] I implemented the second change. 

> Does "identity information" just refer to cdid, or something else?

[Med] It refers to the information conveyed in cdid. 

> otherwise)" are problematic. I'm assuming these are meant to be SHOULDs.

[Med] I checked this wording with Ben.  

> draft-ietf-core-yang-cbor is an informative reference.

[Med] We used to have both as informative references, but unless I'm mistaken 7951 was moved to normative so that at least one method is supported.

[Med] because all resources/state of a DOTS client are bound to this identifier.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 2 May 2019 09:19:41 +0100

Hi,

> [Med] We used to have both as informative references, but unless I'm mistaken 7951 was moved to normative so that at least one method is supported.

As other IESG reviewers pointed out (better than my own description), having 2 non identical ways to encode the same information is going to cause interoperability problems. It also forces implementations to support both encodings and it makes draft-ietf-core-yang-cbor Normative.

I would encourage the WG to pick one mechanism. If it ends up being draft-ietf-core-yang-cbor, I am happy to progress it quick. (CORE WG is one of the WGs I am responsible for)

Best Regards,
Alexey

---

From: <[email-masked]>
Date: Thu, 2 May 2019 08:30:51 +0000

Re-,

Actually, there is no interoperability problem. 

The implementers do only need to look at tables 4 and 6:

   All parameters in the payload of the DOTS signal channel MUST be
   mapped to CBOR types as shown in Table 4.

Cheers,
Med

> De : Alexey Melnikov [mailto:[email-masked]]
> Envoyé : jeudi 2 mai 2019 10:20
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Alissa Cooper; The IESG; [email-masked]; Liang
> Xia; [email-masked]; [email-masked]
> Objet : Re: Alissa Cooper's Discuss on draft-ietf-dots-signal-channel-31:
> (with DISCUSS and COMMENT)
> 
> Hi,
> 
> > [Med] We used to have both as informative references, but unless I'm
> mistaken 7951 was moved to normative so that at least one method is
> supported.
> 
> As other IESG reviewers pointed out (better than my own description), having
> 2 non identical ways to encode the same information is going to cause
> interoperability problems. It also forces implementations to support both
> encodings and it makes draft-ietf-core-yang-cbor Normative.
> 
> I would encourage the WG to pick one mechanism. If it ends up being draft-
> ietf-core-yang-cbor, I am happy to progress it quick. (CORE WG is one of the
> WGs I am responsible for)
> 
> Best Regards,
> Alexey

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 2 May 2019 11:20:24 -0400

Hi Med,

> On May 2, 2019, at 3:18 AM, [email-masked] wrote:
> 
> Hi Alissa, 
> 
> Please see inline.
> 
> Cheers,
> Med
> 
>> De : Alissa Cooper via Datatracker [mailto:[email-masked] <mailto:[email-masked]>]
>> Cc : [email-masked] <mailto:[email-masked]>; Liang Xia; dots-
>> [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> [Med] It seems that you missed "By default, “. 

Even with “by default” this still is problematic. MUST indicates an absolute requirement.

> [Med] It refers to the information conveyed in cdid. 

I think it would be helpful to clarify that.

> [Med] I checked this wording with Ben.  

Ok, perhaps he can comment then.

> [Med] We used to have both as informative references, but unless I'm mistaken 7951 was moved to normative so that at least one method is supported.

This is being discussed in another thread, but if that is the case the normative requirement text needs to change too.

Thanks,
Alissa

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 3 May 2019 07:17:55 +0000

Hi Alissa,

Please see inline

From: Dots <[email-masked]> On Behalf Of Alissa Cooper
Sent: Thursday, May 2, 2019 8:50 PM
To: [email-masked]
Cc: [email-masked]; Liang Xia <[email-masked]>; [email-masked]; IESG <[email-masked]>; [email-masked]
Subject: Re: [Dots] Alissa Cooper's Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________
Hi Med,

On May 2, 2019, at 3:18 AM, [email-masked]<mailto:[email-masked]> wrote:

Hi Alissa,

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : Alissa Cooper via Datatracker [mailto:[email-masked]]
Envoyé : jeudi 2 mai 2019 03:56
À : The IESG
Cc : [email-masked]<mailto:[email-masked]>; Liang Xia; dots-
[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : Alissa Cooper's Discuss on draft-ietf-dots-signal-channel-31: (with
DISCUSS and COMMENT)

= Section 3 =

MUST implies an absolute requirement, so "MUST .... unless" is a problematic
construction.

[TR] “MUST (NOT)..unless” construction is used in several specifications, please see https://tools.ietf.org/html/rfc8094#section-3.1 and https://tools.ietf.org/html/rfc7232#section-2.2.1

-Tiru

alternatively," which indicates that port number discovery is an alternative
to
the fixed to-be-assigned port.

I didn't have time to get very far into draft-boucadair-dots-server-
discovery,

but it appears that it does not mandate support for any single discovery
mechanism for clients and servers to support. If so, that "alternatively"
seems
like more of a problem, since it allows for there to be no interoperable
mechanism for clients to discover server ports. I think maybe what was
intended
here was:

s/MUST/SHOULD/

= Section 4.4.1 =

(1)

= Section 13.1 =

Thanks,
Alissa

= Section 4.4.1 =

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 6 May 2019 11:02:14 -0500

> CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Alissa is correct that MUST is absolute within the realm that it applies
to, so we need to be clear about what domain the requirement applies to.
The text in the -31 here is particularly problematic because of the
following "MAY alternatively" which is in a different sentence and has a
confusing relationship to the previous text.  A (hopefully clearer)
proposal:

In some cases, a DOTS client and server may have mutual agreement to use a
specific port number, such as by explicit configuration or dynamic
discovery [I-D.boucadair-dots-server-discvory].  Absent such mutual
agreement, the DOTS signal channel MUST run over port number TBD as defined
in Section 9.1, for both UDP and TCP.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 6 May 2019 12:11:32 -0500

> Actually, there is no interoperability problem. 

The reference to both draft-ietf-core-yang-cbor and RFCs 7951+7049 presents
an attractive nuisance of an interoperability problem; to say that "both
approaches produce a valid encoding" without qualifier that an extra
consultation to tables 4 and 6 is grossly misleading.

> The implementers do only need to look at tables 4 and 6:

If that's what they have to do, you need to point them there, instead of
just the "normal" ways to go from YANG to CBOR.

-Ben

---

From: <[email-masked]>
Date: Tue, 7 May 2019 06:15:54 +0000

Hi Ben, 

I already went with the s/by default, .... MUST/SHOULD to address the comment from Alissa. I also implemented the other change proposals. 

FWIW, the updated version is available at: https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/master/draft-ietf-dots-signal-channel-31.txt.

Cheers,
Med

> De : Benjamin Kaduk [mailto:[email-masked]]
> Envoyé : lundi 6 mai 2019 18:02
> À : Konda, Tirumaleswar Reddy
> Cc : Alissa Cooper; BOUCADAIR Mohamed TGI/OLN; draft-ietf-dots-signal-
> [email-masked]; Liang Xia; [email-masked]; [email-masked]; IESG
> Objet : Re: [Dots] Alissa Cooper's Discuss on draft-ietf-dots-signal-channel-
> 31: (with DISCUSS and COMMENT)
> 
> > Cc: [email-masked]; Liang Xia
> <[email-masked]>; [email-masked]; IESG <[email-masked]>; dots-
> [email-masked]
> > CAUTION: External email. Do not click links or open attachments unless you
> recognize the sender and know the content is safe.
> >
> >
> > On May 2, 2019, at 3:18 AM,
> [email-masked]<mailto:[email-masked]> wrote:
> >
> > Hi Alissa,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >
> > [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>
> > [TR] “MUST (NOT)..unless” construction is used in several specifications,
> please see https://tools.ietf.org/html/rfc8094#section-3.1 and
> https://tools.ietf.org/html/rfc7232#section-2.2.1
>

---

From: <[email-masked]>
Date: Tue, 7 May 2019 06:30:44 +0000

Re-,

Please see inline.

Cheers,
Med

> Envoyé : lundi 6 mai 2019 19:12
> Cc : Alexey Melnikov; [email-masked]; Alissa Cooper;
> [email-masked]; Liang Xia; The IESG; [email-masked]

[Med] I made this change: 

OLD: 
   This document specifies a YANG module for representing DOTS
   mitigation scopes, DOTS signal channel session configuration data,
   and DOTS redirected signalling (Section 5).  Representing these data
   as CBOR data can either follow the rules in [I-D.ietf-core-yang-cbor]
   or those in [RFC7951] combined with JSON/CBOR conversion rules in
   [RFC7049]; both approaches produce a valid encoding.  All parameters
   in the payload of the DOTS signal channel are mapped to CBOR types as
   specified in Section 6.

NEW:
   This document specifies a YANG module for representing DOTS
   mitigation scopes, DOTS signal channel session configuration data,
   and DOTS redirected signaling (Section 5).  All parameters in the
   payload of the DOTS signal channel are mapped to CBOR types as
   specified in Table 4 (Section 6).

---

From: Barry Leiba <[email-masked]>
Date: Tue, 7 May 2019 10:17:40 -0400

> I already went with the s/by default, .... MUST/SHOULD to address the comment from Alissa.

But Ben's solution is much better: I think the "SHOULD ... unless"
construct is a bad one (though Alissa thinks the "MUST ... unless"
construct is bad, and we disagree on that).  Ben has avoided both and
made the situation quite clear.  I strongly suggest using that.

Barry

---

From: <[email-masked]>
Date: Thu, 9 May 2019 15:14:15 +0000

Hi Barry, 

Thank you for the feedback. 

I updated the text accordingly. 

Cheers,
Med

> De : Barry Leiba [mailto:[email-masked]]
> Envoyé : mardi 7 mai 2019 16:18
> Cc : Benjamin Kaduk; Konda, Tirumaleswar Reddy; draft-ietf-dots-signal-
> [email-masked]; Alissa Cooper; [email-masked]; Liang Xia; IESG; dots-
> [email-masked]
> Objet : Re: [Dots] Alissa Cooper's Discuss on draft-ietf-dots-signal-
> channel-31: (with DISCUSS and COMMENT)
>

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 9 May 2019 17:08:47 -0400

Thanks, the changes look good. However I still don’t understand why RFC 7951 is listed as a normative reference.

Alissa

> On May 1, 2019, at 9:55 PM, Alissa Cooper via Datatracker <[email-masked]> wrote:
>

---

From: <[email-masked]>
Date: Fri, 10 May 2019 05:35:07 +0000

Hi Alissa, 

The main reason is that the examples in the draft are using the JSON encoding of YANG modelled data.

Cheers,
Med

> De : Alissa Cooper [mailto:[email-masked]]
> Envoyé : jeudi 9 mai 2019 23:09
> À : Alissa Cooper
> Cc : IESG; [email-masked]; Liang Xia;
> [email-masked]; [email-masked]

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 10 May 2019 10:00:25 -0400

Hi Med,

> On May 10, 2019, at 1:35 AM, [email-masked] wrote:
> 
> Hi Alissa, 
> 

This does not necessitate a normative reference. See https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/

Alissa

---

From: <[email-masked]>
Date: Fri, 10 May 2019 15:12:40 +0000

Re-,

OK, thanks. 

This is now fixed in -33: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ 

Cheers,
Med

> Envoyé : vendredi 10 mai 2019 16:00
> This does not necessitate a normative reference. See
> https://www.ietf.org/blog/iesg-statement-normative-and-informative-
> references/
> 
> Alissa
> 
> >
> > Cheers,
> > Med
> >