Forward, since Alex original email seems to not have gone through...
-Markus
--- Begin Message ---
On Thu, 29 Apr 2004, Alex Rousskov wrote:
'State Changes to IESG Evaluation::Revised ID Needed from IESG
Evaluation by Amy Vezza'
ID Tracker URL:
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=10380&rfc_flag=0
There are two "discuss" items:
1) It isn't clear how encryption is turned on.
I will need to polish the text to make it clear. I think the draft
lost some of the text that explicitly covered that when
security negotiation was put out of Core scope.
Done. I have polished/added the following paragraphs and changed the
negotiation example:
6. Negotiation
...
Two core negotiation primitives are supported: negotiation offer and
negotiation response. A Negotiation Offer (NO) message allows an
agent to specify a set of features from which the responder has to
select at most one feature it prefers. The selection is sent using a
Negotiation Response (NR) message. If the response is positive, both
sides assume that the selected feature is in effect immediately (see
Section 11.19 for details). If the response is negative, no
behavioral changes are assumed. In either case, further offers may
follow.
...
The following example shows a dialog with a callout server that
insists on two imaginary features to be used: strong transport
encryption and use of volatile storage for responses. The server is
designed to exchange no sensitive messages until both features are
enabled. Naturally, the volatile storage feature has to be negotiated
securely. The OPES processor supports one of the strong encryption
mechanisms but prefers not to offer (volunteer support for) strong
encryption, perhaps for performance reasons. The server has to send a
true "Offer-Pending" parameter to get a chance to offer strong
encryption (which is successfully negotiated in this case). Any
messages sent by either agent after the (only) successful NR response
are encrypted with "strongB" encryption scheme. The OPES processor
does not understand the volatile storage feature, and the last
negotiation fails (over an strongly encrypted transport connection).
P: NO ({"29:ocp://example/encryption/weak"})
;
S: NR
Offer-Pending: true
;
S: NO ({"32:ocp://example/encryption/strongA"},\
{"32:ocp://example/encryption/strongB"})
Offer-Pending: true
;
P: NR {"32:ocp://example/encryption/strongB"}
;
... all traffic below is encrypted using strongB ...
S: NO ({"31:ocp://example/storage/volatile"})
Offer-Pending: false
;
P: NR
Unknowns: ({"31:ocp://example/storage/volatile"})
;
S: CSE { 400 "33:lack of VolStore protocol support" }
;
...
11.19 Negotiation Response (NR)
...
The successfully negotiated feature becomes effective immediately:
The sender of a positive response MUST consider the corresponding
feature enabled immediately after the response is sent; the recipient
of a positive response MUST consider the corresponding feature
enabled immediately after the response is received. Note that the
scope of the negotiated feature application may be limited to a
specified service group. The negotiation phase state does not affect
enabling of the feature.
2) Opening for future feature extension is too big.
The comment that follows this vague statement seems to be
misinterpreting how the extension mechanism works. I will
polish the text and supply a specific example to make the
intent clear. I hope that will remove the "too big"
objection.
Done. Here is the polished text:
15.1 Adapting OCP Core
OCP extensions MAY change any normative requirement documented in
this specification, including OCP message syntax, except for the
following rule: OCP extensions MUST require that changes to normative
parts of OCP Core are negotiated prior to taking effect. In other
words, this specification defines compliant agent behavior until
changes to this specifications (if any) are successfully negotiated.
For example, if an RTSP profile for OCP requires support for sizes
exceeding 2147483647 octets, the profile specification can document
appropriate OCP message syntax and semantics changes while requiring
that RTSP adaptation agents negotiate "large size" support before
using large sizes. Such negotiation can be bundled with negotiating
another feature (e.g., negotiating an RTSP profile may imply support
for large sizes).
As implied by the above rule, OCP extensions may dynamically alter
the negotiation mechanism itself. Such an alternation would have to
be negotiated first, using the negotiation mechanism defined by this
specification. For example, successfully negotiating a feature might
change the default "Offer-Pending" value from false to true.
There was also a comment regarding lack of IANA registrations. I am
guessing that the IANA-related text we discussed on this list (and
with AD) after the draft was published did not make it to IESG. I will
include that text into the next version of the draft.
Done.
The entire updated draft is available at
http://www.measurement-factory.com/tmp/opes/
I would like to publish it in hope to close IESG discussion items.
Please let me know if you have any other suggestions/ideas.
Thanks,
Alex.
--- End Message ---