Subject: RE: Standard Track dependencies on Informational RFCs

From: Scott Bradner <[email-masked]>
Date: Wed, 30 Aug 2000 20:36:16 -0400 (EDT)

> An informational RFC certainly meets these requirements.

I don't think we want to say that any info RFC qualifies

so how do we say just what we want to say and no more?

Scott

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 31 Aug 2000 07:52:11 +0200

>so how do we say just what we want to say and no more?

we publish info RFCs containing external standards when:

- we don't have change control
- that is the easiest way to get free/stable publication

We could standardize MD5 until we were blue in the face, and we would still 
not have the power to redefine what MD5 does. That's as good a definition 
of "external standard" as any.

[For the record, I believe that not putting HMAC on the standards track was 
a mistake; before that RFC publication, HMAC did not exist as a 
referencable entity; if the IETF discovered an error in its description, 
the IETF could (and should!) repair that error by recycling the 
specification. But that's water under the bridge]

For reference purposes, things would be simpler if we created a REF series 
just like the FYI series: an additional property of info RFCs that says 
"normative references to these documents are permitted".

But that's solving the problem by creating more paperwork, something I'm 
generally not in favour of.

              Harald

--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]

---

From: Graham Klyne <[email-masked]>
Date: Thu, 31 Aug 2000 10:23:18 +0100

>so how do we say just what we want to say and no more?

Promote the info RFC to BCP?

#g

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 31 Aug 2000 11:17:53 +0100 (BST)

> Promote the info RFC to BCP?

BCPs get updated. The whole point of things like MD5 algorithms is
that they don't get updated.

Can we overload the meaning of 'historic'?

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 31 Aug 2000 08:52:52 -0500

That certainly wasn't what I intended to say or said, so
I was surprised that Scott disagreed with my interpretation.
My recollection (since I was present at IESG telechats ex
officio at the time) is that the IESG explicitly decided
to accept normative references to MD5 and HMAC precisely
because their nature was that of mathematical algorithms
or theorems. I believe that is the common sense interpretation
of 2026 - whether the reference is an RFC or a textbook or
whatever is irrelevant. 

I don't see any need to tweak the wording or the interpretation.

  Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org
Non-IBM email: [email-masked]

---

From: John Stracke <[email-masked]>
Date: Thu, 31 Aug 2000 10:07:33 -0400

> Can we overload the meaning of 'historic'?

Ah, but, when you overload meanings, you overload brains, too.  :-)

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"I think we'd get fewer bug reports if we    |
[email-masked]|stopped selling our software off planet."    |
\==============================================================/

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 31 Aug 2000 10:55:53 -0400

>I don't see any need to tweak the wording or the interpretation.

All,

        I agree with Brian and Harald and others.  There is no 
need to tweak things.  Nothing is broken.  There is no real 
process problem with having LDAP depend on MD5 even though MD5 
is described in an Informational RFC.

        We don't (and could not) have the power to change the
MD5 specification.  The IETF is not deep in the kinds of
crypto algorithm expertise that would be appropriate for
standardising a crypto algorithm (though for IETF to 
standardise the *application of a given crypto algorithm to 
some IETF protocol* seems emininently reasonable). 

        We have enough real technical issues to deal with in 
the IETF.  It isn't constructive to create new non-technical 
issues that we don't need to have, IMHO.

Ran
[email-masked]