Subject: Re: [Ieprep] terminology

From: [email-masked]
Date: Sat, 16 Nov 2002 12:30:07 EST

In a message dated 11/15/2002 8:48:39 PM Eastern Standard Time, 
[email-masked] writes:

> In IETF, "requirement" means something that an implementer MUST implement
> and/or something that an operator MUST deploy.
> 

[MAP] If you believe this, exactly as you've stated, then we all have a very 
serious problem, and I can see why all the fuss. Henning pointed out very 
well, I think, that it is not that simple.

If it isn't clearly understood up front that no IETF "requirement" (as 
indicated by "MUST" in an RFC) actually places a requirement on an 
implementor or operator, then there is a major issue that must be addressed 
by the IAB before any progress can be made on anything important. As I 
believe you have been arguing, the only "requirements" are contractual: for 
an implementor, what the buyer of the equipment says they "must" have in 
order to be able to buy it. And for an operator, what their contract with the 
customer says that they "must" provide. (And, oh yes, in some environments, 
there may actually be government laws to mandate some things - like safety.)

I really can' t understand this continued argument that, just because 
something is written in an RFC, that every implementor and operator is 
required to support it. We must adopt a clear policy that all Proposed 
Standards are voluntary. (I presume it is already assumed.)

Scott, please clarify this. If I am wrong, then I guess that "MUST" can't be 
used anywhere in any document again

MIke Pierce
Artel

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 16 Nov 2002 13:28:52 -0500

On Saturday, Nov 16, 2002, at 12:30 America/Montreal, [email-masked] 
wrote:
> implementor or operator, then there is a major issue that must be 
> addressed by the IAB before any progress can be made on anything 
> important.

Two points:
	- IAB has virtually no role in the IETF standards process.  See 
RFC-2026.
	- You likely mean the IETF community when you talk about changing 
things,
		since our processes are pretty much all bottom-up.

And that is definitely NOT "clearly understood up front".  It is 
particularly
NOT understood when USG officials visit ISPs and tell them that the USG 
plans
to mandate deployment of the forthcoming IEprep standards from IETF (and
that HAS happened to more than one US ISP according to what the ISPs 
tell me).

> As I believe you have been arguing, the only "requirements" are 
> contractual: for an implementor, what the buyer of the equipment says 
> they "must" have in order to be able to buy it. And for an operator, 
> what their contract with the customer says that they "must" provide. 
> (And, oh yes, in some environments, there may actually be government 
> laws to mandate some things - like safety.)

I've been trying to say that what you all keep erroneously calling 
"requirements"
are in fact contractual objectives of you all.  If you all could switch 
to other
words than "requirement" it would lower the temperature of this 
conversation
VERY considerably.

> Standards are voluntary. (I presume it is already assumed.)

Actually, we still have mandatory specs and elective specs on the IETF 
standards-track.
This won't be changing anytime soon.  Further, IETF standards need to 
apply to
*all* places on the globe.  So even an optional spec ought only talk in 
terms of
global requirements (e.g. Japan's IEprep does not include voice), not 
those belonging
to a subset of countries.

In the draft-carlberg-ets-* documents, a lot of effort was made to very 
clearly state
the very limited applicability of each draft.  That kind of effort 
needs to be
undertaken with all the documents -- and the conversations also need to 
use words
(such as "requirement", "MUST", "SHOULD", or "MAY") very thoughtfully.

Ran

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