IDPR as a Proposed Standard

[[e-mail]]

Noel,

>I hope you realize that should you force other standards to jump
>these hoops, opponents might be in the future deploy them against
>ones you are interested in.

	I would be more than happy if opponents (as well as proponents)
	of the standards I am interested in would require these standards
	to be non-ambiguous, not self-contradictory, and technically correct
	(as well as not promising to deliver undeliverables, and not being
	biased). If they are "excellent goals" (as you describe them yourself),
	then you should not view them as "hoops".

	I also like to point out, that I am not "forcing" anything.

>... you are unhappy with some of the basic design choices in IDPR,
>and that has been suggested to you (by me among others) that the
>time to do that was some time ago, and that it's too late to really
>expect to do so now.

	The design choices that you are referring to are some of the key design
	choices of the IDPR architecture. As Mike Little pointed out in
	his mail (4/16) to the IAB/IESG/IDPR-WG these design decisions were
	made at the time the group was called Open Routing Working
	Group (ORWG), but the group, itself, was closed. So, your suggestion
	that "the time to do that was some time ago" does not strike
	me as feasible.

	By the way, it is not only me who is unhappy. Other members
	of the IDPR WG expressed similar opinion as well. Just read
	the IDPR WG mailing list.

>I propose to discuss some of these on the IDPR WG mailing list.

	I fully support your proposal. In fact, the comments on the
	Architecture document I posted to the IDPR WG mailing list are
	specifically posted with the intention of discussing these
	issues on the mailing list.  So far I received only comments from
	you. Should I expect Martha to comment as well ?

Yakov Rekhter.