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

From: [email-masked]
Date: Mon, 13 Mar 2017 16:44:49 -0700

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: "Jan Komissar (jkomissa)" <[email-masked]>
Date: Tue, 21 Mar 2017 19:34:35 +0000

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.

On 3/13/17, 7:44 PM, "DNSOP on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:

    
    Abstract:

    

    
    _______________________________________________
    DNSOP mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/dnsop