Subject: PKINIT-ECC downref to RFC 3278

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 16 Mar 2007 16:14:38 -0400

Larry recently submitted draft-zhu-pkinit-ecc-03.txt, which resovles the 
issue of a dependency on the PKIX ECC algorithms document by referring to 
another source.  At this point, I believe the document is ready to move 
forward except for one issue.

In the process of updating references, a normative reference was introduced 
to RFC 3278, which defines use of ECC in CMS.  Unfortunately, RFC 3278 is 
informational, while the intended status of draft-zhu-pkinit-ecc is 
Standards Track.  That means we have a normative downreference, and we need 
to determine how to proceed.  Available options include:

(1) Determine that the reference is not needed, and remove it.
(2) Change the intended status of draft-zhu-pkinit-ecc to Informational.
(3) Ask the IESG to permit the downreference.

I'd like to hear comments from the WG on how we should proceed.
I would _not_ like to see a new document version at this time.

-- Jeff

---

From: Brian Tung <[email-masked]>
Date: Fri, 16 Mar 2007 15:03:57 -0800

> I would _not_ like to see a new document version at this time.

I'm confused.  RFC 3278 indicates that it does not define a standard of
any sort, but it references RFC 2119 and uses MUST, etc., as though it
were defining a standard.  In other words, for what purpose MUST an
implementation do such and such, as described in RFC 3278?

RFC 3278 reads as though it defined building blocks that implementors
supporting ECC had to use, but since no actual protocol was defined, it
had to be published as informational.  Have I erred in my interpretation?
If I haven't, then I suggest asking permission for the downreference.

-- 
Brian Tung <[email-masked]>, formerly of
USC Information Sciences Institute

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 20 Mar 2007 04:29:23 -0500

> implementation do such and such, as described in RFC 3278?

Me too.  I think that making a document Informational solely on account
of IPR issues is silly.  Instead what we need is to either accept the
document into the Stnadards Track IPR issues and all, reject the
document altogether, or find some other way to label the status of the
document other than the categories we have now (Historical, Experimental,
Informational, Proposed Standard, Draft Standard and Standard).

> If I haven't, then I suggest asking permission for the downreference.

There are many examples of RFCs on the Standards Track that don't
specify protocols (e.g., RFC2744).  Any RFC that defines building blocks
that will be normatively referenced from other RFCs that define actual
protocols should be on the Standards Track.  Perhaps we need additional
categories as I suggested (Proposed Non-Protocol Standard, Proposed
Encumbered Standard, ...).

In any case, I'm of the opinion that resolving this problem requires
IESG input.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 21 Mar 2007 07:37:49 -0400 (EDT)

> Informational, Proposed Standard, Draft Standard and Standard).

Discussions on issues like whether we have the right set of document
categories, or any other issues related to real or perceived problems with
the IETF process, are off topic for this working group and mailing list.
Please take them to [email-masked].

At present, "Informational" is the correct designation for a protocol
specification which is produced by an IETF working group but not destined
to become an Internet Standard.  The decision as to handle IPR issues, and
in particular on whether to standardize a protocol which has IPR issues,
is primarily up to the working group; in the case of RFC3278, that was
SMIME, and they decided not to target standards track.

We can choose to make the same decision for PKINIT-ECC, or we can choose
to pursue publication on the standards track despite the IPR issues.  If
we choose the latter, we can ask Sam and the IESG for help in doing so;
for example, they could upgrade RFC 3278(*) or choose to allow the
normative downreference (modulu IETF consensus).

I would like to see discussion on this topic, as the document cannot
proceed until we decide what we want to do.

(*) Note that while it is the IESG's prerogative to determine the category
    under which a document is published, it is very unlikely that the IESG
    will upgrade RFC 3278 to Proposed Standard unless the request to do so
    comes from the SMIME working group.  However, I'm tole that SMIME is
    planning to rev that document, so they may decide to upgrade it.

-- Jeff