Subject: [DNSOP] Call for Adoption: draft-bellis-dnsop-session-signal

From: Tim Wicinski <[email-masked]>
Date: Fri, 22 Jul 2016 21:39:41 -0400

I know we've just started talking about this, and the authors are still 
sorting out a few things, but the sense of the room we received was to 
adopt it, work on it, etc.

It appears they have simplified it in the -01 version.

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.

Please also indicate if you are willing to contribute text, review, etc.

With this being the summer, we're going to run a 3 week call for adoption.

This call for adoption ends: Thursday, 12 August 2016

Thanks,
tim wicinski
DNSOP co-chair

---

From: Shane Kerr <[email-masked]>
Date: Tue, 26 Jul 2016 17:03:23 +0200

Tim,

At 2016-07-22 21:39:41 -0400

> This call for adoption ends: Thursday, 12 August 2016

I think the document itself needs some work (such as more detailed
motivation statement, some use cases, probably getting rid of "terminate
session", and so on).

At first I thought that this should stay in homenet, but it does use a
lot of DNS jargon which probably makes it best to sit in dnsop, so I
support its adoption.

Cheers,

--
Shane

---

From: Ray Bellis <[email-masked]>
Date: Tue, 26 Jul 2016 16:39:29 +0100

> lot of DNS jargon which probably makes it best to sit in dnsop, so I

It's actually motivated from DNS-SD and the "push" document there, and
not from Homenet at all.

The authors have a -02 that we've just been working on, albeit not
posted yet while we wait for instructions from the Chairs since the call
for adoption is ongoing.

That text is in my Github:

<https://github.com/raybellis/draft-bellis-dnsop-session-signal>

Ray

---

From: Matthew Pounsett <[email-masked]>
Date: Tue, 26 Jul 2016 11:46:44 -0400

> by DNSOP, and comments to the list, clearly stating your view.

I think this draft is suitable for adoption, and support adopting the
current version.  I've already supplied some review and comments to the
authors and intend to provide more.

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

---

From: william manning <[email-masked]>
Date: Wed, 27 Jul 2016 07:50:16 -0700

I'll be happy to work on/review/ suggest text for this draft.

/W

---

From: 神明達哉 <[email-masked]>
Date: Wed, 27 Jul 2016 11:02:48 -0700

On Fri, Jul 22, 2016 at 6:39 PM, Tim Wicinski <[email-masked]> wrote:

> 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