Subject: [Curdle] Alexey Melnikov's No Objection on draft-ietf-curdle-ssh-modp-dh-sha2-07: (with COMMENT)

From: Alexey Melnikov <[email-masked]>
Date: Wed, 13 Sep 2017 04:46:10 -0700

Alexey Melnikov has entered the following ballot position for
draft-ietf-curdle-ssh-modp-dh-sha2-07: 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-curdle-ssh-modp-dh-sha2/

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

RFC 6234 must be normative, as it is required to implement this document.

---

From: "Mark D. Baushke" <[email-masked]>
Date: Wed, 13 Sep 2017 06:46:37 -0700

> RFC 6234 must be normative, as it is required to implement this document.

Agreed.

	-- Mark

---

From: "Mark D. Baushke" <[email-masked]>
Date: Thu, 14 Sep 2017 11:26:46 -0700

> RFC 6234 must be normative, as it is required to implement this document.

Please advise.

I ran https://tools.ietf.org/tools/idnits/idnits.pyht on the updated
draft (moving RFC 6234 to normative) and got this error:

|   Checking references for intended status: Proposed Standard
|   ----------------------------------------------------------------------------
| 
|      (See RFCs 3967 and 4897 for information about using normative references
|      to lower-maturity documents in RFCs)
| 
|   ** Downref: Normative reference to an Informational RFC: RFC 6234
| 
| 
|      Summary: 1 error (**), 0 flaws (~~), 0 warnings (==), 1 comment (--).
| 
| --------------------------------------------------------------------------------

Please advise if I am required to put RFC6234 as a normative reference,
or if I need to follow the idnits requirement.

	Thank you,
	-- Mark

---

From: Adam Roach <[email-masked]>
Date: Thu, 14 Sep 2017 14:51:46 -0500

> |   Checking references for intended status: Proposed Standard

Since I also made this comment, I'll try to clarify. The guiding process 
here is BCP97/RFC3967.

In this case, the IETF has published another organization's document as 
informational, which is a common reason to have a downref (cf BCP 97, 
section 2, bullet 1). I'll note that RFC6234 is already in the downref 
registry (https://datatracker.ietf.org/doc/downref/), which means that 
your area director is allowed to waive the requirement to call out the 
downref during IETF last call (BCP 97, section 3, 2nd paragraph).

It's EKR's call, of course, but I suspect this is the route to take.

/a

---

From: Mark Baushke <[email-masked]>
Date: Thu, 14 Sep 2017 20:36:23 +0000

Hi Adam,

> On Sep 14, 2017, at 12:51 PM, Adam Roach <[email-masked]> wrote:
> 
> Since I also made this comment, I'll try to clarify. The guiding process here is BCP97/RFC3967.
> 
> In this case, the IETF has published another organization's document as informational, which is a common reason to have a downref (cf BCP 97, section 2, bullet 1). I'll note that RFC6234 is already in the downref registry (https://datatracker.ietf.org/doc/downref/), which means that your area director is allowed to waive the requirement to call out the downref during IETF last call (BCP 97, section 3, 2nd paragraph).
> 

Okay. I will wait for EKR to make the call on this issue.

In the mean time, I have published revision -08 which I hope addresses all comments other than the RFC6234 issue.

I am open to any additional changes needed to progress this draft.

        Thank you,
        -- Mark
> 
> /a
> 
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 15 Sep 2017 10:41:29 +0100

Hi,

> >> |   Checking references for intended status: Proposed Standard

(From the department of pedantic IETF process :-))

You need to make it normative, as per IESG statement
<https://www.ietf.org/iesg/statement/normative-informative.html>. idnits
just tells you that there is a Downref, which means that the document
must be called out explicitly in IETF Last Call, unless it is already in
the Downref registry. Downrefs are generally not a problem, they just
require special process.

> > It's EKR's call, of course, but I suspect this is the route to take.

Documents describing hash algorithms were/are published as
Informational. Which means that they are always Downrefs from Proposed
Standards. Once a document is added to the Downref registry, there is no
need to call it explicitly in IETF Last Call for other documents that
reference it normatively and the warning from ID-nits can be ignored.

> In the mean time, I have published revision -08 which I hope addresses
> all comments other than the RFC6234 issue.
>

---

From: "Mark D. Baushke" <[email-masked]>
Date: Fri, 15 Sep 2017 13:04:35 -0700

Hi,

I have uploaded -09 of this draft.

https://tools.ietf.org/html/draft-ietf-curdle-ssh-modp-dh-sha2-09

It has two changes:

  1) RFC6234 is now a normative reference.
  2) ipr="trust200902"

I believe this has addressed all of the public and private review
comments I have received to date.

	-- Mark