Subject: RE: Last Call: 'Extensible Provisioning Protocol (EPP)' to DraftStandard (draft-hollenbeck-epp-rfc3730bis)

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 17 Oct 2006 08:42:28 -0400

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]] 
> Sent: Friday, October 13, 2006 1:33 PM
> To: [email-masked]
> Subject: Re: Last Call: 'Extensible Provisioning Protocol 
> (EPP)' to DraftStandard (draft-hollenbeck-epp-rfc3730bis)
> 
> Hi.  RFC 3967 is not applicable in cases where the appropriate
> solution is to advance the normative downreference on the standards
> track.  In each case where you have a normative down reference, to a
> PS, please explain why advancing that document is not the appropriate
> solution.
> 
> It is my opinion that "it would be hard to do so" is not a reasonable
> answer to this question.

Your note wasn't addressed to me, Sam, but I will assume that you're
asking me the question.  Since some of the reference RFCs are cited in
multiple documents it'll be more efficient to address them individually.
In all cases but one it's not the protocol that's being cited
normatively, but a portion of the referenced specification.

Advancing the referenced documents probably *is* the theoretically
appropriate solution.  The apparent lack of interest or inability to do
so is the practical problem.  Rather than being stalled indefinitely, I
think I can remove or revise the normative references as follows:

RFC 3023 (XML Media Types)
Referenced by: draft-hollenbeck-epp-rfc3730bis-03
3023 is referenced only in the media registration template provided in
appendix B.  A case could be made that this reference is thus
informative.

RFC 3339 (Date and Time on the Internet: Timestamps)
Referenced by: draft-hollenbeck-epp-rfc3730bis-03,
draft-hollenbeck-epp-rfc3731bis-04, draft-hollenbeck-epp-rfc3732bis-03,
draft-hollenbeck-epp-rfc3733bis-04
This reference is sited to capture a format that is also available in
the W3C's XML Schema specifications.  It can be replaced with an
existing normative reference to the W3C specification.

RFC 3513 (Internet Protocol Version 6 (IPv6) Addressing Architecture)
Referenced by: draft-hollenbeck-epp-rfc3732bis-03
This reference is cited only to capture IPv6 address syntax.  3513 has
been obsoleted by 4291, which is a draft standard.  The reference to
3513 could be replaced with a reference to 4291.

RFC 2822 (Internet Message Format)
Referenced by: draft-hollenbeck-epp-rfc3733bis-04
This reference is cited only to capture SMTP email address syntax.  It
can be replaced with RFC 822, which is a full standard.

RFC 2246 (The TLS Protocol Version 1.0)
Referenced by: draft-hollenbeck-epp-rfc3734bis-03
This is probably a problem because rfc3734bis does indeed require an
implementation of TLS.  2246 has been obsoleted by 4346 (TLS 1.1), which
is itself a Proposed Standard.  The TLS working group is currently
working on 4346bis (TLS 1.2); the intent is to produce another Proposed
Standard.  Perhaps rfc3734bis could be recycled at Proposed until
4346bis or a successor progresses or our standards track processes
change to deal with the situation some other way.  The other possibility
is to consider this text from 3967:

"There are exceptional procedural or legal reasons that force the target
of the normative reference to be an informational or historical RFC or
to be at a lower standards level than the referring document."

with a specific focus on the "exceptional procedural" words.  The TLS
working group (established in 1996) charter doesn't currently include a
plan to advance any version of the specification to Draft Standard
status.  I've been following the TLS work and I understand the need for
revisions to deal with vulnerabilities, but the lack of a Draft Standard
version of TLS puts all work that depends on TLS in standards track
purgatory.  Is that an "exceptional procedural" reason?

-Scott-

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Sam Hartman <[email-masked]>
Date: Tue, 17 Oct 2006 10:46:53 -0400

>>>>> "Hollenbeck," == Hollenbeck, Scott <[email-masked]> writes:

    >> -----Original Message----- From: Sam Hartman
    >> [mailto:[email-masked]] Sent: Friday, October 13, 2006
    >> 1:33 PM To: [email-masked] Subject: Re: Last Call: 'Extensible
    >> Provisioning Protocol (EPP)' to DraftStandard
    >> (draft-hollenbeck-epp-rfc3730bis)
    Hollenbeck,> RFC 2246 (The TLS Protocol Version 1.0) Referenced
    Hollenbeck,> by: draft-hollenbeck-epp-rfc3734bis-03 This is
    Hollenbeck,> probably a problem because rfc3734bis does indeed
    Hollenbeck,> require an implementation of TLS.  2246 has been
    Hollenbeck,> obsoleted by 4346 (TLS 1.1), which is itself a
    Hollenbeck,> Proposed Standard.  The TLS working group is
    Hollenbeck,> currently working on 4346bis (TLS 1.2); the intent is
    Hollenbeck,> to produce another Proposed Standard.  Perhaps
    Hollenbeck,> rfc3734bis could be recycled at Proposed until
    Hollenbeck,> 4346bis or a successor progresses or our standards
    Hollenbeck,> track processes change to deal with the situation
    Hollenbeck,> some other way.  The other possibility is to consider
    Hollenbeck,> this text from 3967:

    Hollenbeck,> "There are exceptional procedural or legal reasons
    Hollenbeck,> that force the target of the normative reference to
    Hollenbeck,> be an informational or historical RFC or to be at a
    Hollenbeck,> lower standards level than the referring document."

    Hollenbeck,> with a specific focus on the "exceptional procedural"
    Hollenbeck,> words.  

If we have IETf consensus that we consider this sort of procedural
reason sufficient, then I support the exception.  I also support such
an IETf consensus.

I think that would be a significant change in how we approach draft
standards.  While I don't mind using your document as a test case,I do
think it important that your document not be unusual in this regard.
If we approve this sort of exception we should plan to approve
exceptions whenever similar situations arise.

If we're going to do that we should update RFC 3967 to be more clear.

So, let's see if we have consensus on your document set .  If so,
let's go publish your documents.  Then I can try to recruit someone to
make minor updates to 3967.

--Sam

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 18 Oct 2006 02:42:14 +0200

> existing normative reference to the W3C specification.

That's odd, why should you be forced to replace a normative reference to
the perfectly fine RFC 3339 by some spec. published elsewhere ?  AFAIK
nothing is wrong with RFC 3339, let's just promote it if that's what it
takes to reference it. 

Frank