Subject: [dnsext] Robert Sparks' Discuss on draft-ietf-dnsext-dnssec-registry-fixes-08: (with DISCUSS)

From: Robert Sparks <[email-masked]>
Date: Tue, 07 Jun 2011 14:28:59 -0700

Robert Sparks has entered the following ballot position for
draft-ietf-dnsext-dnssec-registry-fixes-08: Discuss

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 http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Would the following approach achieve the goals the working group desires with this document?

Instead of keeping the Compliance information in the IANA registry as a new column, keep it entirely within this RFC. Add a sentence to the registry that says "See RFCXXXX for the IETF Consensus on which subset of these algorithms are required or recommended to implement or avoid." 

The RFC could then say that any changes to the RFC affecting that column should be done through obsoleting the RFC, replacing it with a new one.  That way, you would have a single document to refer to for conformance purposes, and a clear history of what changes were made. This would avoid Pete's concerns with the potential unintended consequences of the new proposed mechanics for maintaining the registry. It would also avoid an issue I have with the sentence that tries to constrain any updates to this RFC to _only_ use the obsoletes mechanism. It allows the working group to maintain any changes by only using a series of obsoletes, and guides future maintainers should the working group go away.  As long as the consensus was to only use obsoletes, that's exactly what will happen. If IETF consensus changes in the future, it would override any attempt to constrain the document maintenance anyway.

If a path like this was considered and rejected, documenting what it wouldn't achieve would help motivate the current proposal.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 7 Jun 2011 19:33:00 -0400

At 14:28 -0700 6/7/11, Robert Sparks wrote:

>Instead of keeping the Compliance information in the IANA registry as a
>new column, keep it entirely within this RFC. Add a sentence to the
>registry that says "See RFCXXXX for the IETF Consensus on which subset
>of these algorithms are required or recommended to implement or avoid."

FWIW, this is exactly what I had in mind.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Now, don't say I'm always complaining.
Wait, that's a complaint, isn't it?

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 07 Jun 2011 19:49:25 -0400

On Tue, 2011-06-07 at 14:28 -0700, Robert Sparks wrote:
> Add a sentence to the registry that says "See RFCXXXX for the IETF
> Consensus on which subset of these algorithms are required or
> recommended to implement or avoid."

I would expect a registry to do what the name says, no more.  We have
another system whose express purpose is to track the latest RFC on a
subject: STD numbers.  The registry could just mention the STD number.

-- 
Matt

---

From: Ralph Droms <[email-masked]>
Date: Tue, 21 Jun 2011 14:01:25 -0400

Robert - following up on your suggestion, for which there seems to be some consensus of support in the IESG, I have a couple of questions in line.

I'd like to get additional dnsext feedback on the proposed updates to the document.

- Ralph

On Jun 7, 2011, at 5:28 PM 6/7/11, Robert Sparks wrote:

> The RFC could then say that any changes to the RFC affecting that column should be done through obsoleting the RFC, replacing it with a new one.

Do you intend an RFC 2119 SHOULD in this sentence?

The separation you suggest would, if I understand RFC 6014 and the first paragraph of section 2.3 of dnsext-dnssec-registry-fixes correctly, avoid the problem of the IANA registry and the most recent RFC registry getting out of sync because of additions to the IANA registry through RFC 6014 that did not require obsoleting dnsext-dnssec-registry-fixes.

>  That way, you would have a single document to refer to for conformance purposes, and a clear history of what changes were made. This would avoid Pete's concerns with the potential unintended consequences of the new proposed mechanics for maintaining the registry.

I don't see how this process does any more to capture the history of changes than the process currently in the doc. In either case, I think there needs to be some explicit requirement in the RFC that the reasons for any changes in the implementation requirements MUST be documented in the RFC (although this requirement still requires chasing a chain of RFCs for the entire history of the implementation requirements).

> It would also avoid an issue I have with the sentence that tries to constrain any updates to this RFC to _only_ use the obsoletes mechanism. It allows the working group to maintain any changes by only using a series of obsoletes, and guides future maintainers should the working group go away.  As long as the consensus was to only use obsoletes, that's exactly what will happen. If IETF consensus changes in the future, it would override any attempt to constrain the document maintenance anyway.

Hence the SHOULD above?

> If a path like this was considered and rejected, documenting what it wouldn't achieve would help motivate the current proposal.

Agreed.

---

From: Robert Sparks <[email-masked]>
Date: Tue, 21 Jun 2011 13:27:16 -0500

> Do you intend an RFC 2119 SHOULD in this sentence?

I didn't. I can see how you might want to use 2119, but I don't think it actually helps. 
>> It would also avoid an issue I have with the sentence that tries to constrain any updates to this RFC to _only_ use the obsoletes mechanism. It allows the working group to maintain any changes by…

Again, I don't see how it helps, but if you really feel the need to invoke 2119 here, SHOULD is closer in spirit than MUST.
I think this would be healthier (more likely to produce the long term results the group wants) expressed as guidance to future maintainers rather than restrictions on process.
That said, I won't object if you choose to use 2119.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 21 Jun 2011 15:18:35 -0400

> I didn't. I can see how you might want to use 2119, but I don't think it actually helps.

OK, agreed...

> That said, I won't object if you choose to use 2119.

Right, we can work out some text that gives guidance and motivates that guidance.

- Ralph

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