Sorry, I forgot one additional comment.

While there seems not be a solid definition of what the “Updates” means in the 
RFC header, it always seems to me that “Updates” means you are changing 
something in those documents, rather than just extending them with new 
capabilities within the original documents framework.

I see nothing in the document that makes any changes (“updates”) RFC 1035 and 
RFC 7766.

RFC 5741 just has:


   [<RFC relation>: <RFC number[s]>]

      Some relations between RFCs in the series are explicitly noted in

      the RFC header.  For example, a new RFC may update one or more

      earlier RFCs.  Currently two relationships are defined: "Updates"

      and "Obsoletes" [RFC2223<https://tools.ietf.org/html/rfc2223>].  
Alternatives like "Obsoleted by" are

      also used (e.g., in [RFC5143<https://tools.ietf.org/html/rfc5143>]).  
Other types of relationships may

      be defined by the RFC Editor and may appear in future RFCs.

If you’ve already discussed this or believe the “Updates” to be in line with 
DNSOP / Ops Area practices, feel free to ignore this comment.


  *   Bernie

From: Bernie Volz <v...@cisco.com>
Date: Tuesday, February 13, 2018 at 9:18 PM
To: "draft-ietf-dnsop-session-sig...@ietf.org" 
<draft-ietf-dnsop-session-sig...@ietf.org>, "dnsop@ietf.org" <dnsop@ietf.org>
Subject: WGLC draft-ietf-dnsop-session-signal

Hi:

I have reviewed the document. In general, it is well written and ready to be 
advanced, though there are some nits that the authors should review and 
consider:

Section 1: Not sure why Stateful is capitalized in the following line:
transport protocol.  Each Stateful operation is communicated in its

Section 2: You probably should update this to the text in 
https://tools.ietf.org/html/rfc8174 and update the references accordingly.

Section 3: Do you want to add anything about Section 6 (and perhaps later 
sections)?

Section 4.2.2.3 (and perhaps other places similar text exists): When a 
connection is aborted because of an invalid message, is there any 
recommendation to be added about retrying? If the client terminates the 
connection, it would likely not be wise for it to immediately retry and repeat 
the operation as that can lead to an endless loop? Should some recommended 
backoff technique be provided? Or some other connection rate limiting warning?

Section 4.2.3, last paragraph: What should happen if a EDNS(0) TCP Keepalive 
option does appear? Should the connection be terminated? The message ignored?

Section 4.3: first paragraph: This text kind of conflicts with the text in 
4.2.1 which says that whether a message is acknowledge or unacknowledged is 
determined only by the specification for the Primary TLV. I understand this may 
not be worth addressing, but perhaps a reference to 4.2.1 is worth considering?

Section 6.1: INACTIVITY TIMEOUT and KEEPALIVE INTERVAL. Is mention 0xffffffff 
(infinite) worth adding to this text?

For:

The Keepalive TLV is not used as a request message Additional TLV.
Would “MUST NOT be used” be better?

For:

A Keepalive TLV MUST NOT be added as to other responses a Response
I think “as” should be removed.

Section 6.2: I would assume 0xfffffff would not mean infinite.

Section 6.2.1: If a client were to receive a new RCODE but does not understand 
it (older version), should there be a statement as to how the client should 
react? Should it treat the unknown error code as if NOERROR were sent?

Section 9: Seems a bit light, but OK if it ends up being acceptable. For 
example, while it probably means you have bigger problems, but large timer 
values (such as in the Retry Delay TLV) could be a denial of service vector. 
Though if the server does that, it probably isn’t who you wanted to be talking 
to anyway and you should have used TLS.

Perhaps also saying that if DNS over TLS isn’t used (just plan TCP), then it 
may be possible for a man-in-the-middle to inject messages (such as with a 
large Retry Delay TLV)?


Again, nothing that likely MUST be fixed.


  *   Bernie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to