IDPR as a Proposed Standard

yakov@watson.ibm.com Tue, 28 April 1992 17:21 UTC

Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa01865; 28 Apr 92 13:21 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa29194; 28 Apr 92 13:25 EDT
Received: from PARK-STREET.BBN.COM by NRI.Reston.VA.US id aa29182; 28 Apr 92 13:25 EDT
Received: from park-street by PARK-STREET.bbn.COM id aa22292; 28 Apr 92 13:04 EDT
Received: from BBN.COM by PARK-STREET.BBN.COM id aa22288; 28 Apr 92 13:02 EDT
Received: from watson.ibm.com by BBN.COM id aa16653; 28 Apr 92 13:02 EDT
Received: from yktvmz.watson.ibm.com by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 0659; Tue, 28 Apr 92 13:01:53 EDT
Date: Tue, 28 Apr 92 12:55:58 EDT
From: yakov@watson.ibm.com
To: iesg@isi.edu, iab@isi.edu
Cc: idpr-wg@bbn.com, hinden@sun.com
Subject: IDPR as a Proposed Standard
Message-ID: <9204281325.aa29182@NRI.Reston.VA.US>

> The IESG has received a request from the Inter-Domain Policy
> Routing Working Group to approve the publication of the
> Internet Drafts .... jointly as a Proposed Standard.

	I am really surprised that such a request was received.
	It seems that the process that governs the progress of IDPR
	clearly violates the procedures outlined in RFC1310.

	As stated in Section 2.4 of RFC1310 "After completion
	to the satisfaction of its author and the cognizant Working
	Group, a document that is expected to enter or advance
	in the Internet standardization process shall be made
	available as an Internet Draft. It shall remain as an
	Internet Draft for a period of time that permits useful
	community review, at least two weeks, before submission
	to the IESG".

	Now let's look at the facts about how IDPR was progressed :

	1) At the beginning of March Martha Steenstrup (chair of the IDPR WG)
		sent to the WG document "IDPR as a Proposed
		Standard". In this document she referenced two other
		documents, "An architecture for inter-domain policy routing"
		and "Inter-domain policy routing protocol specification: version 1".
		Both of these documents were referenced as Internet Drafts dated
		March 1992.

	2) The first document, "An architecture for inter-domain policy
		routing" was posted as an Internet Draft on April 16.
		It was posted WITHOUT previous review by the WG. It was
		submitted to the IESG before the the two weeks period required
		by RFC1310. As a matter of fact, I already sent to the IDPR
     WG fair number of comments on this document that are intended
		to correct technical errors, and I expect these comments
		to be discussed and resolved BEFORE submitting documents to the IESG.

	3) The second document, "Inter-domain policy routing protocol
		specification: version 1", dated March 1992 was NEVER
		posted as an Internet Draft at all. As a matter of fact,
		the only version of the protocol spec available as
		an Internet Draft is dated March 6, 1991 (not 1992).
		That again violates requirements imposed by RFC1310.

	4) Discussion within the IDPR WG, generated by the "IDPR
		as a Proposed Standard" document  shows that several major
		design choices were resolved by the IDPR architecture and
		protocols WITHOUT sufficient technical justification.
		On that ground several WG members openly expressed
		disagreement with submitting existing IDPR documents as
		a Proposed Standard. The discussion within IDPR WG clearly
		demonstrated that the IDPR documents were NOT completed
		"to the satisfaction of ... the cognizant Working Group".
		Given these facts, submitting documents to the IESG without
		satisfaction of the WG directly contradicts requirements
		imposed by RFC1310.

	All these facts make me wonder whether we have a single
	standardization process that applies to all the documents, or
	whether we have multiple tracks, and the one that is defined in
	RFC1310 is just one of them. If the former is the case (we have
	one track), then I would like to understand why IDPR was
	submitted to the IESG in clear violation of the procedures
	defined in RFC1310.  If the former is the case (we have multiple
	tracks), then I would appreciate if the IESG just state this in
	public.
	
 Yakov Rekhter.

 P.S. I was not sure whether I also have to post this message to the
 ietf mailing list, so I did not post it. However, if I have
 to post it to the IETF mailing list please let
 me know and I'll do it.