RE: Protocol: control specifications.

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

I can see no point in discussions of how a server should handle incorrect criticality. Presumably, if the server knows the criticality is wrong then it knows enough to inplement it. Then, according to the rules, the criticality from the server's perspective is TRUE - controls that are implemented have to be performed. So, you would be asking a server to tell the client either
1) I did it this time, but don't send it to another server as you may get an incorrect result, or
2) I didn't do it. I could have but, na-na-na, you got the criticality wrong. Let that teach you a lesson!

I don't see either as acceptable server behaviour. I thought this had been settled. I thought I would see no more text on this.

Ron

-----Original Message-----
From: owner-ietf-ldapbis@OpenLDAP.org
[mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Kurt D. Zeilenga
Sent: Wednesday, 10 March 2004 09:43
To: Hallvard B Furuseth
Cc: ietf-ldapbis@OpenLDAP.org
Subject: RE: Protocol: control specifications.


At 12:30 PM 3/9/2004, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>> Well, I think the question was more about what use scenarios
>> server-side enforcement of a particular criticality value would be
>> useful.  In the past, the use scenario discussed was so that client
>> developers would, if they tested against a server which implemented
>> such checks, receive a diagnostic (a protocolError) that would tell
>> them that they didn't provide the particular criticality value called
>> for.  The question was whether this wether or not there were other
>> (non-diagnostic) use cases.
>
>I cannot think of any.

noted.


>>At 01:11 PM 3/8/2004, Hallvard B Furuseth wrote:
>>>Kurt D. Zeilenga writes:
>
>>>- While I think control specs should be able to mandate the
>>>  criticality protocol field, they should not mandate that servers check
>>>  it.  That is a [Protocol] issue.  It would just add to the mess if one
>>>  could trust a server to catch wrong criticality for some controls, but
>>>  not for others.
>>
>
>> Problem here is that any mandated value is control-specific.  The
>> [protocol] discusses criticality handling which is not
>> control-specific.
>
>So if a server wishes to verify the criticality of controls in general,
>it must do it in the implementation of each control.

Well, I rather not get into implementation detail.  It is possible
that a server could implement their general control processing
in a manner which allowed them to verify criticality values
mandated by the control specification.  My point is that there
is a logic separation of control-neutral and control-specific
processing and any criticality verification is logically part of
the control-specific processing (as its specification is
control specific).

>I don't see a
>problem with that, as long as the server does it consistently.

Consistent with the control's specification!  The behavior
is control-specific...  one specification could say "incorrect
criticality is to be treated as a protocolError" while another
specification could say "incorrect criticality should be viewed
as constraintViolation" while another could say "if a incorrect
criticality is detected, it should be logged but otherwise
ignored".

I would hope most specifications would opt for the last (with
ability to disable logging) as a) it provides a useful diagnostic
and b) encourages servers to be liberal in what they accept.

I, for one, would likely ignore mandates to return errors where
I could instead process the operation unambigiously.

>Which is
>a quality of implementation issue, not a [protocol] or control spec
>issue.
>
>> While a control specification can certainly say
>> "servers implementing this control are to verify its critical field is
>> TRUE", (...), this is a control
>> specific semantic and not part of the control-neutral criticality
>> processing discussed in [Protocol].
>
>Yes.  Which is why I don't want control specs to say that.
>Because...
>
>> Whether or not such statements
>> are or aren't appropriate can be left to discussions regarding
>> particular control specifications which attempt to make them (as any
>> such verification is part of the control-specific processing).
>
>No.  If the control spec says that, it is altering the semantics of the
>criticality field.  Which [Protocol] says should not be done.

While [Protocol] says future specifications should not overload
criticality field, [Protocol] does not restrict the scope of
extension which a control might express.

>> Instead of saying the control specifications may require such a
>> verification (or verification of any number of other things), it would
>> like be better to clarify that the scope of any LDAP extension is only
>> limited by what can be supported in a truly optional manner.
>
>It's not clear to me what this suggestion means in practice.

Well, I would agree that some extension authors don't understand
that extensions should be truly optional.

>I _think_ it at least means to remove the text
>     (note: the semantics of the criticality field 
>     are defined above should not be altered by the control's 
>     specification)

This text is intended to highlight an important change in practice,
a change that resulted from significant discussion (namely in LDAPEXT)
of technical issues with existing extension specifications (some
"in progress", some published).  As the consensus was, and appears to
still be, that the overloading criticality is generally not appropriate,
it is appropriative for us to say so in this revision.  Otherwise
it is likely the practice would continue (especially given that not
all control specifications are subject to IETF review).

I note as well that this practice, aside from causing issues with
each overloading specification, also caused and continues to cause
confusion as to precise what are the criticality semantics.  Hence,
aside from clarifying what future specifications should avoid doing,
the note also reenforces that criticality semantics are just those
which were specified in RFC 2251.

>>>- I thought (and still suspect) rfc2251 said wrong criticality was an
>>>  error,
>> 
>> I do not believe your view is supported by the consensus of the WG
>
>It's been a while since the discussion, but at the moment I don't
>remember anyone but you and me saying what we think rfc2251 was meant to
>say.  Though I assume Jim agrees with you, since he adopted your changes
>so easily.

Consensus, especially when limited to just list posts, can be a
hard thing to judge.  I've tried to take all inputs (from list,
from personal conversations, from face-to-face meetings, etc..)
and weight them to come up with a belief of what the consensus
(or lack thereof) is.  I then generally try to state this belief
(as I have done here) as well as what actions I am considering
taking based upon this belief.  This is intended to allow
additional input (regarding either my view of consensus or the
proposed actions).

>> nor by existing implementations (many of which implement controls
>> whose specifications mandate clients provide particular criticality
>> values).
>
>Well, the question would be what most servers do;

Actually, the question is whether there are multiple independently
developed implementations.  2 servers would be enough... but I
not aware of any.

>> At present, I am inclined to either treat your request as a new feature
>> (and hence out-of-scope) or as a clarification to an un-implemented
>> interpretation (which we should avoid), or simply as a change which
>> is not supported by WG consensus.  However, to ensure the WG fully
>> considers all issues, it seemed appropriate to see if there were
>> other use scenarios.
>
>-- 
>Hallvard