Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt

From: Petr Špaček <[email-masked]>
Date: Thu, 27 Apr 2017 09:40:30 +0200

On 21.3.2017 20:34, Jan Komissar (jkomissa) wrote:
> Hi,
> 
> I have one comment for this draft. In Section 3.3 Message Format, I would prefer that if a Session Signaling message is received where any of the section count fields are not zero, the receiver MUST respond with an error code, e.g. FORMERR, but MUST NOT terminate the connection. My reason is that in order to ignore any non-zero count fields, the receiving software must have code to walk all the sections and this code would effectively be useless, but would still have to be properly maintained. The soft error response is required to make it possible for a future client to probe servers for support for a future Session Signaling based feature that uses the RR sections.

(Jan, thank you for reminding me to review this version!)

Other people already commented on semantics so I will focus on message
format:

My attempts to find reasoning for the new TLV format in archives did not
yield an elaborate explanation. Assuming I did not miss anything, it
seems to me that the current TLV format (placed outside of standard DNS
RR) is going to require brand new code and logic and makes imlementation
harder than necessary.

Every DNS server and resolver already has own code to parse DNS RRs do
various operations with them but this could cannot be reused for the
current TLV format.

It would be much easier to implement if we had new RRs like (e.g.)
"SSOP" and "SSMOD" and placed them inside additional section. We could
get the same semantics by creating a DNS message with all sections empty
except "SS*" RRs in additional section. Overhead on wire is negligible
and it makes implementation much easier and safer (because the normal RR
handling code is battle-tested already).

For these reasons I propose to move to standard RR format to enable code
re-use. Thank you for considering this.

Petr Špaček  @  CZ.NIC

> Jan.
> 
> 
> On 3/13/17, 7:44 PM, "DNSOP on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:
> 
>     
>     A New Internet-Draft is available from the on-line Internet-Drafts directories.
>     This draft is a work item of the Domain Name System Operations of the IETF.
>     
>             Title           : DNS Session Signaling
>             Authors         : Ray Bellis
>                               Stuart Cheshire
>                               John Dickinson
>                               Sara Dickinson
>                               Allison Mankin
>                               Tom Pusateri
>     	Filename        : draft-ietf-dnsop-session-signal-02.txt
>     	Pages           : 25
>     	Date            : 2017-03-13
>     
>     Abstract:
>        The EDNS(0) Extension Mechanism for DNS is explicitly defined to only
>        have "per-message" semantics.  This document defines a new Session
>        Signaling Opcode used to communicate persistent "per-session"
>        operations, expressed using type-length-value (TLV) syntax, and
>        defines an initial set of TLVs used to manage session timeouts and
>        termination.
>     
>     
>     The IETF datatracker status page for this draft is:
>     https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/
>     
>     There's also a htmlized version available at:
>     https://tools.ietf.org/html/draft-ietf-dnsop-session-signal-02
>     
>     A diff from the previous version is available at:
>     https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-session-signal-02
>     
>     
>     Please note that it may take a couple of minutes from the time of submission
>     until the htmlized version and diff are available at tools.ietf.org.
>     
>     Internet-Drafts are also available by anonymous FTP at:
>     ftp://ftp.ietf.org/internet-drafts/

---

From: Ray Bellis <[email-masked]>
Date: Thu, 27 Apr 2017 10:11:09 +0100

> re-use. Thank you for considering this.

The break from standard RR format is intentional, and in large part to
avoid the tendency to overload the existing meaning of RR fields as was
done with EDNS (i.e. the use of the CLASS field to carry buffer size,
and putting bit fields and extended RCODEs into the TTL field).

It also (intentionally) prevents *mixing* of SS* TLVs and normal RRs
within a session signalling message (or indeed vice versa, putting SS
TLVs into a standard QUERY message).

Yes, it'll need some new code, but it's not difficult code (indeed it'd
be very similar to the code for parsing the RDATA of an OPT RR).

I think the cost of that extra bit of code is outweighed by *not*
needing extra code in the standard packet handling path to cope with
rejecting mixed packets.

Ray