I've attached section 9.1 that Keith refers to. So we have to write an I-D
explaining why we want to have the normative reference to the Experimental
RFCs 2565 and 2566. Carl-Uno and I will draft such an I-D.
Tom
-----Original Message-----
From: Keith Moore [mailto:moore at cs.utk.edu]
Sent: Monday, May 17, 1999 11:14
To: Hastings, Tom N
Cc: moore at cs.utk.edu; IETF-IPP
Subject: Re: IPP> FW: FW: ADM - Questions on Backwards Compatibility
betwe en IPP/1. 0 an d IPP/1.1
> Is this a "normative" reference or not?
SHOULD is a normative reference.
Requesting a variance is the easiest way to fix this.
The variance procedure is documented in RFC 2026, section 9.1.
Keith
Here is section 9.1:
9.1 The Variance Procedure
Upon the recommendation of the responsible IETF Working Group (or, if
no Working Group is constituted, upon the recommendation of an ad hoc
committee), the IESG may enter a particular specification into, or
advance it within, the standards track even though some of the
requirements of this document have not or will not be met. The IESG
may approve such a variance, however, only if it first determines
that the likely benefits to the Internet community are likely to
outweigh any costs to the Internet community that result from
noncompliance with the requirements in this document. In exercising
this discretion, the IESG shall at least consider (a) the technical
merit of the specification, (b) the possibility of achieving the
goals of the Internet Standards Process without granting a variance,
(c) alternatives to the granting of a variance, (d) the collateral
and precedential effects of granting a variance, and (e) the IESG's
ability to craft a variance that is as narrow as possible. In
determining whether to approve a variance, the IESG has discretion to
limit the scope of the variance to particular parts of this document
and to impose such additional restrictions or limitations as it
Bradner Best Current Practice [Page 27]
RFC 2026 Internet Standards Process October 1996
determines appropriate to protect the interests of the Internet
community.
The proposed variance must detail the problem perceived, explain the
precise provision of this document which is causing the need for a
variance, and the results of the IESG's considerations including
consideration of points (a) through (d) in the previous paragraph.
The proposed variance shall be issued as an Internet Draft. The IESG
shall then issue an extended Last-Call, of no less than 4 weeks, to
allow for community comment upon the proposal.
In a timely fashion after the expiration of the Last-Call period, the
IESG shall make its final determination of whether or not to approve
the proposed variance, and shall notify the IETF of its decision via
electronic mail to the IETF Announce mailing list. If the variance
is approved it shall be forwarded to the RFC Editor with a request
that it be published as a BCP.
This variance procedure is for use when a one-time waving of some
provision of this document is felt to be required. Permanent changes
to this document shall be accomplished through the normal BCP
process.
The appeals process in section 6.5 applies to this process.