On Fri, Jul 22, 2016 at 6:39 PM, Tim Wicinski <tjw.i...@gmail.com> wrote:
> This starts a Call for Adoption for draft-bellis-dnsop-session-signal > > The draft is available here: > https://datatracker.ietf.org/doc/draft-bellis-dnsop-session-signal/ > > Please review this draft to see if you think it is suitable for adoption by > DNSOP, and comments to the list, clearly stating your view. I've read the 01 version of the draft. I don't have a strong opinion on whether it's suitable for adoption, mainly because its motivation is vague to me. If it becomes clearer in a subsequent version I'll probably be more supportive for the adoption. Specific comments on 01: - Section 1: perhaps its first 2 paragraphs intend to describe the motivation, but these are quite vague to me. Since it's vague I can't propose any specific suggestion, but hopefully these will be revised to be more specific about what are the problems today and specifically how this proposal tries to address them. - Overall: I think it's better to describe what the recipient should do if a MUST is violated. In some cases it might be very minor and doesn't affect interoperability in practice, but implementors will still wonder what they should do in those cases. Such cases include (if this is not a comprehensive list): Section 3.1: Each message MUST contain only a single TLV. Section 4.2.1: [..]It MUST NOT be initiated by a server. Section 4.2.2: [...] It MUST NOT be initiated by a client. - Section 3.1 The Z bits are currently unused, and SHOULD be set to zero (0) in requests and responses unless re-defined in a later specification. Not a strong opinion, but in my experiences with other protocols on cases like this, I guess this would normally be a MUST for the sender and the recipient MUST ignore an unexpected value. - Section 4.2.2 The Terminate Session TLV (2) MAY be sent by a server to request that the client terminate the session. Specifically what does "terminate" mean? It probably depends on the underlying protocol (TCP or DNSoTLS, etc), but it would be nicer if this document explicitly defines this term in Section 2 (maybe with an example for a specific protocol like TCP). - Section 4.2.3: s/for. a client/for a client/ it may leave the current session idle for. a client. The definition -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
