[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Fwd: Re: ID Tracker State Update Notice: draft-ietf-opes-ocp-core]

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 ---