Re: [Fwd: Re: ID Tracker State Update Notice: draft-ietf-opes-ocp-core]
Alex Rousskov <[email protected]>
| Newsgroups | gmane.ietf.opes |
|---|---|
| Message-ID | <[email protected]> |
On Wed, 5 May 2004, The Purple Streak, Hilarie Orman wrote: > OCP extensions are allowed to change normative OCP Core requirements > for OPES processors and callout servers. However, OCP extensions > SHOULD NOT make such changes and MUST require on a "MUST"-level that > such changes are negotiated prior to taking effect. Informally, this > specification defines compliant OCP agent behavior until changes to > this specifications (if any) are successfully negotiated. > > Is "negotiated" used to mean a protocol operation in the second > sentence, and as a action within a standards body in the third > sentence. The meaning of negotiation does not change from the second sentence to the third. If something implies that it does, please be specific what that something is or suggest a different wording. Note that the third sentence is not normative. Basic OCP negotiations mechanisms are defined in Section 6 "Negotiation". > I think that the IESG concern about negotiation is that if the state > machine for the core negotiaion changes as a result of negotiation > (in the protocol sense), The state always changes as a result of a successful negotiation. Otherwise, we did not negotiated anything! > you can easily get a resulting state machine that is unmanageable. > Infinite loops, deadlocks, etc. Can you add verbiage that indicates > why those bad things are not possibilities? I cannot prove protocol correctness; it is possible that OCP Core negotiation is flawed. Unknown bugs notwithstanding, Section 6 "Negotiation", Section 11.18 "Negotiation Offer (NO)", and Section 11.19 "Negotiation Response (NR)" contain specific rules/requirements that are meant to avoid wrong state as a result of a negotiation. Note that specific feature definitions (OCP Core does not define any features) may contain additional requirements. The section you quoted from above is about OCP extensions that may use OCP Core negotiation mechanisms to adjust some OCP Core rules to better fit their needs. The section has one example to illustrate the need. Thanks, Alex.