Re: [dnssd] Working Group Last Call - draft-ietf-dnsop-session-signal

[Stephane Bortzmeyer <[e-mail]>]

On Thu, Feb 01, 2018 at 02:14:53PM -0500,
 tjw ietf <[e-mail]> 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