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

[神明達哉 <[e-mail]>]

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

> 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.

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