Re: [DNSOP] Working Group Last Call - draft-ietf-dnsop-session-signal
The WGLC last call for session-signal has ended. I was on a conference call with the Authors yesterday, and they were addressing all open items, with the plan of releasing an updated version in the next day or so. Once this version is published, we'll ask all who submitted comments to confirm they have been addressed adequately, before moving on. thanks Tim On Thu, Feb 1, 2018 at 2:14 PM, tjw ietfwrote: > > This starts a Working Group Last Call for draft-ietf-dnsop-session-signal > > Current versions of the draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/ > > Please review the draft and offer relevant comments. Also, if someone > feels the document is *not* ready for publication, please speak out with > your reasons. > > We are doing a three week Working Group Last Call process, and we're cross > posting to a few groups where we hope to receive some strong reviews. > > This WGLC ends at midnight, 22 February 2018. > > thanks > Tim/suzanne > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call - draft-ietf-dnsop-session-signal
Two items related to this: 1: I think that it would be better to require TLS for all DSO connections. This document (DSO) specifies that it should use TCP or TLS for connections, but the DNS Push Notification (DPN) draft requires TLS. This would complicate matters if a standard TCP connection was opened for one purpose and later a DPN operation over the same connection was attempted. Also, it improves security for all DSO operations. 2: I also believe this document should only support DSO over TLS, not session based protocols in general. If there is a need/desire for doing DSO over other protocols, a new RFC allowing each protocol would be required. This requirement will ensure that all implementations of this draft would interoperate. (If DSO-over-X and DSO-over-Y both are compliant with this document, they are not likely to interoperate even if both X and Y are session based, which would defeat the purpose of a standard.) Regards, Jan. On 2/2/18, 4:58 PM, "DNSOP on behalf of Paul Hoffman"wrote: The current draft is hand-wavy when it comes to which transports DSO can run on. Section 2 says "such as": The term "connection" means a bidirectional byte stream of reliable, in-order messages, such as provided by using DNS over TCP [RFC1035][RFC7766] or DNS over TLS [RFC7858]. Section 4.1 says "are suitable": Standard DNS over TCP [RFC1035][RFC7766], and DNS over TLS [RFC7858] are suitable protocols. The document should explicitly list which protocols are currently acceptable, and say that the list can change in the future based on standards-track documents. Proposed wording for both of these above are: Section 2: The term "connection" means a bidirectional byte stream of reliable, in-order messages. Section 4.1 says "are suitable": DSO MUST be run as standard DNS over TCP [RFC1035][RFC7766] or DNS over TLS [RFC7858]. This list might expand in the future, such an expansion MUST be in standards-track RFCs. Having developers know exactly which protocols can be used is important so that they do not use protocols that they accidentally think are reliable and in-order. For example, the DOH WG is working on a protocol that might initially seem attractive, but it does *not* qualify for DSO. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call - draft-ietf-dnsop-session-signal
The current draft is hand-wavy when it comes to which transports DSO can run on. Section 2 says "such as": The term "connection" means a bidirectional byte stream of reliable, in-order messages, such as provided by using DNS over TCP [RFC1035][RFC7766] or DNS over TLS [RFC7858]. Section 4.1 says "are suitable": Standard DNS over TCP [RFC1035][RFC7766], and DNS over TLS [RFC7858] are suitable protocols. The document should explicitly list which protocols are currently acceptable, and say that the list can change in the future based on standards-track documents. Proposed wording for both of these above are: Section 2: The term "connection" means a bidirectional byte stream of reliable, in-order messages. Section 4.1 says "are suitable": DSO MUST be run as standard DNS over TCP [RFC1035][RFC7766] or DNS over TLS [RFC7858]. This list might expand in the future, such an expansion MUST be in standards-track RFCs. Having developers know exactly which protocols can be used is important so that they do not use protocols that they accidentally think are reliable and in-order. For example, the DOH WG is working on a protocol that might initially seem attractive, but it does *not* qualify for DSO. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop