Subject: [DNSOP] Benoit Claise's No Objection on draft-ietf-dnsop-dns-terminology-04: (with COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Wed, 16 Sep 2015 01:55:53 -0700

Benoit Claise has entered the following ballot position for
draft-ietf-dnsop-dns-terminology-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-terminology/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this document.

- Reading first the write-up, I started to wonder about the rationale to
produce a terminology document as BCP?
I re-read RFC 2026, and concluded that BCPs should document standardize
practive.
Then I realized the diff between version 3 and 4 :-) 

- From the shepherd writeup: 
"One issue raised by the Working Group was that such a list of
definitions would be best served with some sort of Index. 
The authors and the Document Shepherd agree, but feel it would be better
served being handled during the editing process."
What/when is the editing process? AUTH48? Why wait?

- "Most of the definitions here are believed to be the consensus
definition of the DNS community - both protocol developers and
operators."
I hope we can write: "Most of the definitions here are the consensus
definition of the DNS community - both protocol developers and
operators.", leaving no doubts about the process.

- "Further, some terms that
   are defined in early DNS RFCs now have definitions that are generally
   agreed to, but that are different from the original definitions.
   Therefore, the authors intend to follow this document with a
   substantial revision in the not-distant future.  That revision will
   probably have more in-depth discussion of some terms as well as new
   terms; it will also update some of the RFCs with new definitions."

You lost me here. Do you want a new revision of this document, or
revisions of early DNS RFCs, or both?
And why do you say "That revision will probably have more in-depth
discussion of some terms".
Does it mean that THIS document is not final? This is the way I read it.

---

From: Tim WIcinski <[email-masked]>
Date: Fri, 18 Sep 2015 15:00:16 -0400

On 9/16/15 4:55 AM, Benoit Claise wrote:
>   From the shepherd writeup:

In going back over all the WGLC comments, and the email discussions with 
the authors, it is apparent that the Shepherd spoke out of turn here. 
There document would not be best served with an Index.

with apologies,

tim

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 18 Sep 2015 11:58:34 -0700

> What/when is the editing process? AUTH48? Why wait?

See mail from the shepherd on this topic.

> operators.", leaving no doubts about the process.

Good catch; will fix.

> Does it mean that THIS document is not final? This is the way I read 

You read it correctly. The WG came to agreement on the need for a 
document that repeated the definitions from the RFCs in one place, that 
we should point out where RFCs disagreed with each other, that this RFC 
should not update RFCs even if their definitions are wrong, and that a 
later revision of this document will update those RFCs. The reason for 
that last point is that there were a fair number of places where the WG 
could not come to consensus yet, but might later with significantly more 
work.

--Paul Hoffman

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 18 Sep 2015 15:44:31 -0500

Hi, Paul,

On Fri, Sep 18, 2015 at 1:58 PM, Paul Hoffman <[email-masked]> wrote:

> You read it correctly. The WG came to agreement on the need for a document
> that repeated the definitions from the RFCs in one place, that we should
> point out where RFCs disagreed with each other, that this RFC should not
> update RFCs even if their definitions are wrong, and that a later revision
> of this document will update those RFCs. The reason for that last point is
> that there were a fair number of places where the WG could not come to
> consensus yet, but might later with significantly more work.
>

I had the same question Benoit entered in his comment. Your explanation was
helpful for me.

Spencer

---

From: Benoit Claise <[email-masked]>
Date: Mon, 21 Sep 2015 10:16:51 +0200

On 18/09/2015 21:00, Tim WIcinski wrote:
> In going back over all the WGLC comments, and the email discussions 
> with the authors, it is apparent that the Shepherd spoke out of turn 
> here. There document would not be best served with an Index.
Thanks. No worries Tim.

Regards, Benoit
> .

---

From: Benoit Claise <[email-masked]>
Date: Mon, 21 Sep 2015 11:02:36 +0200

Paul,
> document that repeated the definitions from the RFCs in one place, 
> that we should point out where RFCs disagreed with each other, that 
> this RFC should not update RFCs even if their definitions are wrong, 
> and that a later revision of this document will update those RFCs. The 
> reason for that last point is that there were a fair number of places 
> where the WG could not come to consensus yet, but might later with 
> significantly more work.
Thanks for the background information. I guess this process makes sense.
However, the way the text is written lowers the relevance of this document.
Here is my reading/understanding:

    "Further, some terms that
      are defined in early DNS RFCs now have definitions that are generally
      agreed to, but that are different from the original definitions.

So far, I'm thinking. You guys did a terrific job, as you arrived to 
some to agreed definitions. Great.

      Therefore, the authors intend to follow this document with a
      substantial revision in the not-distant future.  That revision will
      probably have more in-depth discussion of some terms

Then, I don't understand "therefore, we need a new revision with more 
discussions"
So I start wondering: So this is a temp work (because the new revisions 
will obviously obsolete this document). And you want a "substantial" 
revision, with more discussions. So either the work is not complete, or 
there is no consensus...

    as well as new

Proposal (but remember it's a COMMENT, not a DISCUSS, so listen to your 
responsible AD)
Either you remove this paragraph (because expressing your intend 
shouldn't be part of the RFC), or you express it differently. Something 
such as:

    Now that a single document contains all DNS-related definitions, now
    that the different conflicting definitions in early DNS RFCs have
    been agreed
    upon, a later revision of this document will update all the RFCs,
    when required. The
    reason for the phase approach is that checking every DNS RFCs for
    consistency with this
    updated terms might result in some updates. Additionally, some new
    terms might be required.

I'm not in love with this paragraph, but I've been trying to introduce a 
more positive spin to it.

Regards, Benoit