Subject: [DNSOP] Review of draft-ietf-dnsop-attrleaf-fix

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 18 Jul 2018 11:37:05 -0400

I've reviewed this document and it also looks like it's pretty much ready.
My suggestions here are also pretty minor:

As the other document, this one uses MUST without the RFC2119 boilerplate.

Section 3.2 replaces text in Section 4.1 of something, but I don't know
what; the prior paragraph refers to multiple other documents.  I suggest:
(a) clarify which document's 4.1 is being replaced, and (b) don't bother
including the original (replaced) text.

I believe Section 4 can include a note to the RFC Editor to remove it prior
to publication.

Section 5, as in the other document, is too terse.  I suggest summarizing
the fact that the only thing going on here is creating of IANA requirements
on future work, and updating old documents to reference those requirements.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Wed, 18 Jul 2018 09:33:39 -0700

On 7/18/2018 8:37 AM, Murray S. Kucherawy wrote:
> what; the prior paragraph refers to multiple other documents.  I 
> suggest:  (a) clarify which document's 4.1 is being replaced, and (b) 
> don't bother including the original (replaced) text.

I'll add reference to the RFC being modified, closer to the modification 
text, but I'd rather keep the old language in there, to reduce the 
likelihood that someone will replace too-much/not-enough of the existing 
text.

> 
> I believe Section 4 can include a note to the RFC Editor to remove it 
> prior to publication.

oh?

> 
> Section 5, as in the other document, is too terse.  I suggest 
> summarizing the fact that the only thing going on here is creating of 
> IANA requirements on future work, and updating old documents to 
> reference those requirements.

Same reaction as for the other document.  I think it the change creates 
a 'form' of greater substance but not the substance of substance.

It doesn't allow a security reviewer to do a better (or worse) job and 
it doesn't demonstrate meaningfully greater security knowledge of the 
writer...

Side note: FWIW I am certainly concerned that this section be 
meaningful.  When it was first required by the IAB, we were given no 
guidance about what to include and had no skill at knowing/guessing.  So 
pro forma language, similar to what I've put in, was the norm.  In most 
cases, it represented conformance to form but had no substance.  However 
in the current case, I believe it exactly summarizes the issue for these 
documents.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 18 Jul 2018 12:38:19 -0400

> likelihood that someone will replace too-much/not-enough of the existing

My concern here is based on past ART efforts where direct citation was said
to risk inaccurate copying, and thus semantic drift.  Naturally in each
instance it's easy to argue "This is a correct copy of the text being
replaced" but it's still a generally discouraged practice.

Over in DCRUP, we faced the same problem and instead produced Section 3 of
RFC8301 with this in mind, for example.

-MSK