Subject: [DNSOP] Call for Adoption: draft-dupont-dnsop-rfc2845bis

From: tjw ietf <[email-masked]>
Date: Tue, 10 Apr 2018 14:56:53 -0400

This draft was widely accepted in Singapore, and the chairs were waiting for
a revision before starting a call for adoption. That revision took a few
months
but it has been done and DNSOP is ready to start a call for adoption.

This draft addresess the bug found in the existing RFC.

This starts a Call for Adoption for draft-dupont-dnsop-rfc2845bis

The draft is available here:
https://datatracker.ietf.org/doc/draft-dupont-dnsop-rfc2845bis/

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.

This call for adoption ends: 23:59 24 April 2018

Thanks,
tim wicinski
DNSOP co-chair

---

From: 神明達哉 <[email-masked]>
Date: Tue, 10 Apr 2018 13:57:11 -0700

At Tue, 10 Apr 2018 14:56:53 -0400,

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

I support the adoption.  I've already reviewed the draft and provided
(minor) feedback:
https://www.ietf.org/mail-archive/web/dnsop/current/msg22063.html

--
JINMEI, Tatuya

---

From: Bob Harold <[email-masked]>
Date: Wed, 11 Apr 2018 08:50:04 -0400

On Tue, Apr 10, 2018 at 4:57 PM, 神明達哉 <[email-masked]> wrote:

> I support adoption.

In various places, like 4.3.  TSIG Record Format, "resolver and server" is
used which seems a little vague to me, since I use TSIG between master and
slave authoritative servers, neither of which is a resolver.  Would it make
sense to use "sender and receiver" ?  Or 6.5.4. uses "client" and "server"
and that would work, if used consistently everywhere.

6.5.1.  Key check and error handling
Why is this only for a "non-forwarding server" ? --- Answer is in 6.7, A
reference to there might be helpful.

-- 
Bob Harold

---

From: Joe Abley <[email-masked]>
Date: Wed, 11 Apr 2018 08:55:42 -0400

Hi Bob,

On Apr 11, 2018, at 08:50, Bob Harold <[email-masked]> wrote:

> In various places, like 4.3.  TSIG Record Format, "resolver and server" is used which seems a little vague to me, since I use TSIG between master and slave authoritative servers, neither of which is a resolver.  Would it make sense to use "sender and receiver" ?  Or 6.5.4. uses "client" and "server" and that would work, if used consistently everywhere.

Since you can send and receive both responses and queries, I prefer
"initiator" and "responder" to "sender" and "receiver". I think I
first saw those terms used in one of Vixie's drafts, and I liked them.

"Client" and "server" have semantic overtones (e.g. relating to end
users and services) and I find them less precise unless the context is
very clear.

Joe

---

From: Bob Harold <[email-masked]>
Date: Wed, 11 Apr 2018 09:05:56 -0400

On Wed, Apr 11, 2018 at 8:55 AM, Joe Abley <[email-masked]> wrote:

> > In various places, like 4.3.  TSIG Record Format, "resolver and server"
> is used which seems a little vague to me, since I use TSIG between master
> and slave authoritative servers, neither of which is a resolver.  Would it
> make sense to use "sender and receiver" ?  Or 6.5.4. uses "client" and
> "server" and that would work, if used consistently everywhere.
>

Agreed.   "initiator" and "responder" is better, I just could not think of
the right term.

-- 
Bob Harold