On Thu, Feb 01, 2018 at 02:14:53PM -0500, tjw ietf <tjw.i...@gmail.com> wrote a message of 55 lines which said:
> This starts a Working Group Last Call for draft-ietf-dnsop-session-signal After reading -05 : My personal feeling is that it is complicated, with a lot of details. May be separating in two documents, one for the base DSO concept and one for the standards TLV (with their detailed behavior) would have been better. There is a discussion about a possible Privacy section <https://github.com/raybellis/draft-bellis-dnsop-session-signal/pull/36> for which I suggest the following text: The intention of this specification is to enable stateful information (connection parameters and DNS data) directly related to the DSO Session to be transmitted. This creates trackable state and prevents queries from coming from successive privacy addresses, as could be the case with regular DNS queries, for a privacy-conscious client. Before using DSO (or any kind of long-lived DNS sessions), this consequence should be taken into account. The risk is partially mitigated by using encryption (which protects against sniffing by a third-party, but not against logging by the server.) The design of new TLV must also avoid adding any information that could make this tracking easier. Now, other points: > There are a myriad of other potential use cases for DSO given the > versatility and extensibility of this specification. I don't really like this sort of sentence. Either we have ideas about these potential use cases and we should write them down, or we don't and we should avoid this sort of very general words (after all, human imagination being what it is, we can be sure surprising use cases will be found.) > If the RCODE is set to any value other than NOERROR (0) or DSONOTIMP > (tentatively 11), then the client should assume that the server does > not support DSO. (Why "should" in lower case?) RFC 1035 being very clear that the rcode from a non-DSO server must be NOTIMP (this is also said in section 4.2.1 of the draft), I suggest to change that to: If the server does not handle DSO at all, it MUST reply with RCODE NOTIMP (4) (this is from RFC 1035, section 4.1.1). Because not all servers will be correct, if the client receives an answer with the RCODE set to any value other than NOERROR (0) or DSONOTIMP (tentatively 11), then the client should assume that the server does not support DSO. > DNS Stateful Operations uses "DSO request messages" and "DSO > response messages". DSO request messages are further subdivided > into two variants, "acknowledged request messages" (which generate a > corresponding response message) and "unacknowledged request > messages" (which do not generate any corresponding response > message). It seems to me that the draft uses "response-requiring messages" as a synonym of "acknowledged request messages" (and "non-response-requiring messages" as a synonym of "unacknowledged request messages"). If I'm correct, it would be better to state it clearly in the terminology section. > 7.1. MESSAGE ID > The table below illustrates the legal combinations: Since there are only four combinations, I do not find this table useful. Last, RFC 5226 (IANA considerations section) is now replaced by RFC 8126 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
