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

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

Hi Alissa,

Please see inline

From: Dots <[e-mail]> On Behalf Of Alissa Cooper
Sent: Thursday, May 2, 2019 8:50 PM
To: [e-mail]
Cc: [e-mail]; Liang Xia <[e-mail]>; [e-mail]; IESG <[e-mail]>; [e-mail]
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, [e-mail]<mailto:[e-mail]> wrote:

Hi Alissa,

Please see inline.

Cheers,
Med


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

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.

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

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

[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

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,

[Med] I updated that reference to I-D.ietf-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/

[Med] I implemented the second change.



= 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?

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

I think it would be helpful to clarify that.





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

[Med] I checked this wording with Ben.

Ok, perhaps he can comment then.




= Section 13.1 =

I don't understand why RFC 7951 is a normative reference but
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.

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

Thanks,
Alissa






----------------------------------------------------------------------
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?

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