[sipcore] Fwd: Updates to draft-ietf-sipcore-rfc4244bis-11, version 1.

[Mary Barnes <[e-mail]>]

Hi all,

This is a set of suggested changes from Dale based upon the comments
he sent to the list previously:
http://www.ietf.org/mail-archive/web/sipcore/current/msg05489.html

Responses are inline below [MB].   Based upon my responses, I do not
believe any of the changes impact normative behavior (as intended)
thus another WG and/or IETF LC should not be necessary, but I will
leave that decision to the chairs/AD.

Mary.


---------- Forwarded message ----------
From: Dale R. Worley <[e-mail]>
Date: Wed, Feb 6, 2013 at 9:09 AM
Subject: Updates to draft-ietf-sipcore-rfc4244bis-11, version 1.
To: [e-mail], [e-mail]


Here are my proposed fixes to the -11 version.  I believe that all of
these changes are non-controverisial, in that they adjust the document
to express what we all agree it ought to mean.  But in a number of
places, the prescribed procedures are actually different from the
current text.  Please review this and get back to us with your
thoughts.

Thanks,

Dale

======================================================================

Updates to draft-ietf-sipcore-rfc4244bis-11, version 1.

This document is organized as a series of responses to the points in
my e-mail of 18 Jan
(http://www.ietf.org/mail-archive/web/sipcore/current/msg05489.html).

==========

> From: [e-mail] (Dale R. Worley)
> To: SIPCORE <[e-mail]>
> Subject: [sipcore] Questions about draft-ietf-sipcore-rfc4244bis-11.txt
> Date: Fri, 18 Jan 2013 12:10:40 -0500 (EST)
>
> I've got a few questions about 4244bis.  I think that there are
> understood answers to most of them, but we might have to update the
> wording to remove ambiguity.

==========

> 1. When an entity receives a (non-100) provisional response to a
> request, should it modify the hi-entry by adding a Reason value
> carrying the status of the response?  The current text (section 10.2)
> clearly requires it.  If the request eventually receives a failure
> response, the 1xx Reason will (probably) later be replaced by the
> failure code.  (But not necessarily:  see section 10.2 paragraph 3.)
>
> The only example in draft-ietf-sipcore-rfc4244bis-callflows-01 of this
> situation is section 3.1 message F8, and the 180 status is not
> reported in a Reason header-value for <sip:[e-mail]> (which
> thus contradicts section 10.2).
>
> The alternative is that 1xx responses do not set the Reason value
> (although they do add to the cache any new hi-entries they carry).
> This would require changing the text in section 9.3 step 2 and section
> 10.2.

NOTE:  I am assuming that non-100 provisional responses are intended
to carry hi-entries upstream, and that proxies that see those
responses are intended to cache the hi-entries carried in them.
(Those cached hi-entries can later be updated by a final response
which adds a Reason header value to them.)  If this is not so, these
changes need to be revised.

As far as I can tell, we have never intended for receipt of a
provisional (1xx) response to an INVITE to set a Reason header on the
corresponding cached hi-entry.  The only example in 4244bis-callflows
of this situation is message F6 of section 3.1, in which there would
be a Reason header on hi-entries 1.2 and 1.2.1 -- and there is not.
And RFC 4244, which also has the Reason header value mechanism, does
not specify that 1xx responses set Reason header values.

So I propose that we all agree that 1xx responses should not generate
Reason headers and we edit the text accordingly.
[MB] Correct.  That's been the intent for both 4244 and 4244bis.
It's mentioned in 9.4 that the HI is not sent in 100 responses (since
those do not result in retargeting), thus there would be no reason to
add a Reason header to anything.  [/MB]

 The changes are:

   section 9.3 step 2

   Step 2:  Add Reason header field

      The SIP entity adds one or more Reason header fields to the hi-
------^
change "The" to "If the response code is not 1xx, the"
      targeted-to-uri in the (newly) cached hi-entry reflecting the SIP
      response code in the non-100 response, per the procedures of
---------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^
delete(?)
      Section 10.2.

This change results in:

      If the response code is not 1xx, the SIP entity adds one or more
      Reason header fields to the hi-targeted-to-uri in the (newly)
      cached hi-entry reflecting the SIP response, per the procedures
      of Section 10.2.

[MB] Note that the section is specific to non-100 responses, which is
why it is written as it currently is.
I don't see that your suggested text adds any more information - i.e.,
the IF isn't necessary.  We are stating specific behavior for that
specific step and an "IF" isn't necessary.  I do not think this change
is necessary. [/MB]

   10.2.  Reason in the History-Info Header Field

   A Reason header field is added to the "headers" component in an hi-
   targeted-to-uri when the hi-entry is added to the cache based upon
   the receipt of a non-100 or non-2xx SIP response, as described in
   Section 9.3.  If the Reason header field is being added due to
   receipt of an explicit SIP response and the response contains any
   Reason header fields (see [RFC3326]), then the SIP entity MUST
   include the Reason header fields in the "headers" component of the
   hi-targeted-to-uri in the last hi-entry added to the cache, unless
   the hi-targeted-to-uri is a Tel-URI.  If the SIP response does not
   contain a Reason header field, the SIP entity MUST include a Reason
   header field, containing the SIP Response Code, in the "headers"
   component of the hi-targeted-to-uri in the last hi-entry added to the
   cache, unless the hi-targeted-to-uri is a Tel-URI.

The changes to this paragraph are extensive enough that I am not
showing the individual differences.  Note I have changed "the last
hi-entry added to the cache" to "the corresponding hi-entry".  The
latter makes more sense to me, and specifies the same hi-entry.  But
others may prefer the current description, in which case we can retain
it.

The new version of this paragraph is:

   A Reason header field is added to the "headers" component in an hi-
   targeted-to-uri when a non-100, non-2xx SIP response is received to
   the corresponding INVITE, or when a response is received containing
   the hi-entry with a Reason header value, as described in Section
   9.3.
[MB] You have dropped the reference to the cache here and that very
important.  I think it's obvious that we
are dealing with the corresponding INVITE.  When we talk about SIP
responses, we do not qualify it as "the SIP response received to the
corresponding INVITE".  But, it certainly causes no harm.  I would
suggest that sentence read:
   A Reason header field is added to the "headers" component in an hi-
   targeted-to-uri when the hi-entry is added to the cache based upon
   the receipt of a non-100 or non-2xx SIP response to the
corresponding INVITE, as described in
   Section 9.3.

[/MB]

   If the Reason header value is being added to an hi-targeted-to-uri
   due to receipt of an explicit SIP response to the corresponding
   INVITE and the response contains any Reason header fields (see
   [RFC3326]), then the SIP entity MUST also include the Reason header
   fields in the "headers" component of the hi-targeted-to-uri in the
   corresponding cached hi-entry, unless the hi-targeted-to-uri is a
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   Tel-URI.  If the SIP response does not contain a Reason header
   field with a protocol of "SIP", the SIP entity MUST include a
   Reason header field, containing the SIP Response Code, in the
   "headers" component of the hi-targeted-to-uri in the corresponding
   cached hi-entry, unless the hi-targeted-to-uri is a Tel-URI.

[MB]  Note, you dropped "field" from the "Reason header value above,
which is not correct. So the real changes I see above are with regards
to highlighting that it's the corresponding cached hi-entry (rather
than the last.  I have annotated above that that is the only change
(AFAICT).  I can make that change as follows:
OLD:
    If the Reason header field is being added due to receipt of an explicit
    SIP response and the response contains any
    Reason header fields (see [RFC3326]), then the SIP entity MUST
    include the Reason header fields in the "headers" component of the
    hi-targeted-to-uri in the last hi-entry added to the cache, unless
    the hi-targeted-to-uri is a Tel-URI.

NEW:
   If the Reason header field is being added due to receipt of an explicit
   SIP response to the corresponding INVITE
                                    ^^^^^^^^^^^^^^^^^^^^^^
   and the response contains any
   Reason header fields (see [RFC3326]), then the SIP entity MUST
   include the Reason header fields in the "headers" component of the
   hi-targeted-to-uri in the corresponding cached hi-entry,  unless
                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   the hi-targeted-to-uri is a Tel-URI.
[/MB]

There is a slight change here in that if the response contains
"Reason: Q.850;cause=14", then both the Q.850 response code and the
SIP response code will be recorded in the cached hi-entry.  The
previous text caused only the Q.850 response code to be recorded.
[MB] I don't see that the previous text said that only the Q.850
response code was recorded.
The text says that "Reason header fields" as in plural fields are added. [/MB]

If a Reason header includes a reason-value with protocol "SIP", that
reason-value is recorded instead of the response code in the response.
(This is the same as the previous text.)

==========

> 2. During the life of the document, there was confusion about how
> hi-entries were to be organized.  The intention of the original writer
> and the current draft is that hi-entries are accumulated in a cache in
> the order the entity receives them (in requests and responses),
> allowing hi-entries that have the *same* index but *different* URIs,
> and (implicitly) eliminating duplicates.
[MB] It wasn't just the original author and the current author, this
has been the intent of
the document and the approach was agreed by the WG. Certainly, there were some
errors that might have lead one to believe otherwise, but that was
never the intent. [/MB]
>
> But some people who have worked on the draft (including myself) were
> for a while mistaken in believing that the hi-entries were to be
> organized into a tree, and hence the index values needed to be unique,
> and the History-Info header would list the hi-entries in tree-walking
> order (technically, "preorder").  The confusion was abetted by there
> being no examples that distinguish the two techniques.
[MB] I think the confusion is that if everyone supported HI, you would
get a tree.
You can still get a somewhat pruned tree using the indices.  I think
the confusion is that the RFC never
had any intention of defining application behavior.  It is merely
recording what happens at the SIP protocol level. That's it.  How an
application uses the information (whether to build a tree or whatever)
is out of scope. [/MB]
> Unfortunately, the -11 draft doesn't eliminate all the remnants of the
> mistake.  I haven't gone through -11 in detail, but "preorder" appears
> in section 9.2 and section 10.3, so at least those sections describe
> the accumulation of hi-entries incorrectly.

The fix to this issue overlaps the fix for issue #4:

> 4. If a downstream entity that does not support History-Info forks a
> request to entities that do support History-Info, an entity can
> receive two hi-entries with the same index that were not generated for
> the same fork of the request.  Conversely, an entity will receive
> responses that contain hi-entries that are duplicates of entries that
> are already in the cache.
>
> These facts imply that there is a process by which an entity
> determines whether a received hi-entry is "the same" as an hi-entry
> already in the cache (and so doesn't need to be added again).  Since
> index values cannot be depended upon to be unique, we really ought to
> state what the comparison rule is.
>
> I think it is sufficient to use the rule "the same index value and the
> URIs are equivalent (per RFC 3261 section 19.1.4, but ignoring the
> Reason header fields)".  This won't always give the result one would
> want (if a non-supporting downstream element forks the request to two
> target URIs that ultimately arrive at the same element, two hi-entries
> could be generated with the same index and URI), but this rule is
> simple, well-defined, and should work well in almost all situations.

In addition, when a response is received, it may contain hi-entries
that are duplicates of hi-entries already in the cache, except they
contain Reason header values that are not in the cached hi-entries.  I
believe we intend that the cached hi-entries be updated to include the
received Reason header values.

The edits to fix these three issues are:

   9.2.  Sending a Request with History-Info

   When sending a request, a SIP entity MUST include all the hi-entries
   from the cache that was created per Section 9.1.  In addition, the
   SIP entity MUST add a new hi-entry to the outgoing request, but the
   SIP entity MUST NOT add the hi-entry to the cache at this time.  The
--------------------------------------------------------------------^
Change this sentence to:  "The hi-entries in the outgoing request's
History-Info header are in the order of the hi-entries in the cache,
which is the order in which they were added to the cache."

[MB] That's fine. And, just for clarification, the statement below is
the OLD and the one above is the NEW [/MB]

   hi-entries in the outgoing request's History-Info header field is the
   preorder of the tree of hi-entries, that is, by the lexicographic
   ordering of the hi-indexes.  The new hi-entry is populated as
   follows:

   9.3.  Receiving a Response with History-Info or Request Timeouts

   Step 1:  Add hi-entry to cache

      The SIP entity MUST add the hi-entry that was added to the request
-----------------------------^
For clarity insert "to the cache" here, and...
      that received the non-100 response or timed out to the cache, if
------------------------------------------------------^^^^^^^^^^^^
... remove "to the cache" here.
      it was not already cached.  The hi-entry MUST be added to the
----------------------------------^
Change this sentence to "If so, the hi-entry MUST be added to the end
of the cache."

      cache in ascending order as indicated by the values in the hi-
      index parameters of the hi-entries (e.g., 1.2.1 comes after 1.2
      but before 1.2.2 or 1.3).

[MB] I can't decipher the changes you are suggesting above.  I think I
see your point.  However,
there is something very subtle here.  This is dealing with responses
and we add the hi-entries once we
get the response.  However, the value of the hi-index actually does
reflect a chronological order in terms of generating requests.  As
discussed previously, you lose that chronological ordering across
entities, but for a specific
SIP entity they do reflect the chronological processing at that
entity.  So, I don't think this is broken.  With the cache
model, we aren't adding them to the cache until we get the response
even though they were added to the request (in both chronological and
lexicographical order).
[/MB]


   9.3.  Receiving a Response with History-Info or Request Timeouts

   Step 3:  Add additional hi-entries

      The SIP entity MUST also add to the cache any hi-entries received
      in the response that are not already in the cache.  This situation
      can occur when the entity that generated the non-100 response
      retargeted the request before generating the response.  As per
      Step 1, the hi-entries MUST be added to the cache in ascending
      order as indicated by the values in the hi-index parameters of the
      hi-entries

This paragraph needs more extensive changes:
[MB] It's not clear to me why you think it needs to be done this way.
This is still mapping back to the original request sent by a specific
entity (e.g., Proxy A).   I think you are confused by the scenario
being described.  The retargeting was not done by Proxy A that is
caching the hi-entries.  It was done by Proxy B that received the
request and it retargeted before returning the 1xx response thus there
is an additional hi-entry that Proxy A should add to its cache. [/MB]

   Step 3:  Add and update additional hi-entries

      The SIP entity MUST also add to the cache any hi-entries received
      in the response that are not already in the cache.  This
      can occur when the entity that generated the non-100 response
      retargeted the request before generating the response.  Such
      hi-entries MUST be added to the end of the cache in the order
      they appear in the History-Info header field of the response.

      If an hi-entry in the response contains Reason header value(s)
      and the matching hi-entry in the cache does not, the Reason
      header value(s) MUST be added to the cached hi-entry.  This can
      occur when the hi-entry was added to the cache by a provisional
      response to an INVITE that was further retargeted, and later a
      final response to that INVITE is received.

      In these cases, an hi-entry in a response's History-Info header
      field and an hi-entry in the cache are considered matching when
      they have the same index value and the hi-targeted-to-uris are
      equivalent (per RFC 3261 section 19.1.4, but ignoring the Reason
      header fields).

   10.2.  Reason in the History-Info Header Field

   A Reason header field is added to the "headers" component in an hi-
   targeted-to-uri when the hi-entry is added to the cache based upon
----------------------------------------^^^^^^^^
change to "added to, or updated within,"

   the receipt of a non-100 or non-2xx SIP response, as described in
   Section 9.3.  [...]
[MB] Why "updated within"?  [/MB]

   10.3.  Indexing in the History-Info Header Field

   In order to maintain ordering and accurately reflect the retargeting
   of the request, the SIP entity MUST add a hi-index to each hi-entry.
   Per the syntax in Section 5, the hi-index consists of a series of
   nonnegative integer separated by dots (e.g., 1.1.2).  Each dot
   reflects a SIP forwarding hop.  The nonnegative integer following
   each dot reflects the order in which a request was retargeted at the
   hop.  The highest nonnegative integer at each hop reflects the number
   of entities to which the request has been retargeted at the specific
   hop (i.e., the number of branches) at the time that the request
   represented by this hi-entry was generated.  Thus, the indexing
   results in a logical tree representation for the history of the
   request and the hi-entries are given in the preorder of the tree.
-----------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
delete this clause
[MB] Okay. [/MB]

==========

> 3. Due to the confusion discussed in #2, we have to consider whether
> consensus was actually found in the WGLC.
[MB] We had consensus in WGLC.  Your comments came well after WG last call
and after IETF LC.

>We thought we had
> consensus, but people did not have the same understanding of this
> aspect of the draft.  (Ugh.)

This is a procedural issue, not a technical one.  I don't see any
objection to correcting the normative text if everyone who cares
agrees that the changes express what we intended.  (We should check
this point with the AD.)

[MB] I do not see that we are changing any of the intended normative
behavior but rather fixing things that didn't quite reflect the
normative behavior as stated elsewhere (i.e., inconsistencies). [/MB]

==========

> 5. In draft-ietf-sipcore-rfc4244bis-callflows-01, examples 3.6 and 3.7
> do not show the History-Info value in the final 200 response to the
> UAC.  This final value would be useful, in particular, because they
> give further examples of how proxies process History-Info.

I was mistaken here:  The final 200 response from the example.com
proxy to the UAC in these examples has the same History-Info as the
200 response arriving at the example.com proxy, because there is no
History-Info information that the proxy knows that is not known to the
UAS that generated the 200 response.  Thus there is nothing
interesting to document.

==========

> 6. Interestingly, despite the fact that there can be duplicate index
> values, when a request is received by a UAS, there is no ambiguity in
> the history when tracing *back* from the last hi-entry (the one that
> denotes the UAS).  This is because even if this UAS is "down one fork"
> from a forking non-supporting proxy, none of the hi-entries generated
> "down the other fork" will be present in the request the UAS sees.
>
> This is in contrast to the situation at the UAC, which may see
> hi-entries with duplicate indexes, and the interpretation of "rc",
> "mp", and "np" parameters can be ambiguous.

This is an interesting observation, but it does not require
documentation in the RFCs.

==========

> 7. In example 3.6 message F6 in
> draft-ietf-sipcore-rfc4244bis-callflows-01, the History-Info is:
>
>    History-Info: <sip:[e-mail]>;index=1
>    History-Info: <sip:bob@192.0.2.5?Reason=SIP%3Bcause%3D302>;\
>                       index=1.1;rc=1
>    History-Info: <sip:[e-mail]>;index=1.2;mp=1
>    History-Info: <sip:carol@192.0.2.4?Reason=SIP%3Bcause%3D408>;\
>                       index=1.2.1;rc=1.2
>    History-Info: <sip:[e-mail];\
>                       target=sip:bob%40example.com;cause=408>;\
>                       index=1.3;mp=1.2
>    History-Info: <sip:vm@192.0.2.6;\
>                       target=sip:bob%40example.com;cause=408>;\
>                       index=1.3.1;rc=1.3
>
> This is what we intend, as it shows both where the index=1.3 URI came
> from (sip:[e-mail]) as well as why the index=1.3 fork was
> generated (because sip:[e-mail] failed).  But it points out
> that we need to improve the description in rfc4244bis section 5 of
> what the values of the "rc" (etc.) parameters are.  A naive reader
> might think "rc=1.2" in the 1.3 entry means that
> <sip:[e-mail];target=sip:bob%40example.com;cause=408> was
> generated as a contact for <sip:carol@192.0.2.4>.  Instead, it means
> that the 1.3 fork was generated *because* the 1.2 fork returned a
> response; it was generated *from* the index=1 URI.
>
> Actually, the real rules for interpreting "rc" (etc.) are not simple:
[MB] The above is an example, thus the description is not complete. [/MB]
>
> 1) If the index-val in the param points to an entry with a Reason
> header-param whose value is "SIP;cause=3xx" (after removing
> escaping!), then:
> - the URI was one of the Contact values in the 3xx response
> - that response was why the new fork was generated.
>
> 2) If the index-val in the param points to the parent of this
> hi-entry, then:
> - the URI was generated from the URI of the parent hi-entry
> - the fork was not generated due to the response from any other fork.
>
> 3) If the index-val in the param points to an hi-entry that is not the
> parent, and that hi-entry does not contain a Reason header-param
> containing a 3xx status, then:
> - the URI was generated from the URI of the parent hi-entry
> - the fork was generated due to the response from the hi-entry with
> the specified index-val.
>
> And this doesn't match the section 5 definition of the value of "rc"
> (etc.), which is:
>
>          The "rc" header field parameter contains the value of the
>          hi-index in the hi-entry with an hi-targeted-to-uri that
>          reflects the Request-URI that was retargeted

In section 5, these paragraphs need to be revised:

   o  hi-target-param: An optional parameter reflecting the mechanism by
      which the Request URI captured in the hi-targeted-to-uri in the
      History-Info header field value (hi-entry) was determined.  This
      parameter is either an "rc", "mp" or "np" header field parameter,
      which is interpreted as follows:

         "rc": The hi-targeted-to-URI represents a change in Request-URI
         while the target user remains the same.  This occurs for
         example when user has multiple AoRs as an alias.  The "rc"
         header field parameter contains the value of the hi-index in
         the hi-entry with an hi-targeted-to-uri that reflects the
         Request-URI that was retargeted

         "mp": The hi-targeted-to-URI represents a user other than the
         target user associated with the Request-URI in the incoming
         request that was retargeted.  This occurs when a request is
         statically or dynamically retargeted to another user
         represented by an AoR unassociated with the AoR of the original
         target user.  The "mp" header field parameter contains the
         value of the hi-index in the hi-entry with an hi-targeted-to-
         uri that reflects the Request-URI that was retargeted, thus
         identifying the "mapped from" target.

         "np": The hi-targeted-to-URI represents that there was no
         change in Request-URI.  This would apply for example when a
         proxy merely forwards a request to a next hop proxy and loose
         routing is used.  The "np" header field parameter contains the
         value of the hi-index in the hi-entry with an hi-targeted-to-
         uri that reflects the Request-URI that was copied unchanged
         into the request represented by this hi-entry.  That value will
         usually be the hi-index of the parent hi-entry of this hi-
         entry.

The revised paragraphs are:

[MB] I don't agree with this proposal - that's way too much detail for
this section.  I believe that the normative
sections describe how/when you add the "rc" tag which should match
what you are describing in your new bullets.    I will note that this
section has been updated several times both adding more text and
reducing the text in this section.  What you have proposed for the
bullets below (i.e., the "rc", "mp" etc.) is some of the level of
detail we had previously (in the -02).   I believe the text you
suggest is application logic - note that items 2 & 4 describe the "rc"
scenarios and this wasn't intended to be comprehensive.  If you can
highlight what's missing in those 2 bullets, we can perhaps make some
changes there.   I will note if these suggestions had been made much
earlier in the process, it would have been much more helpful - much of
the text you mention has been in the document since around the -02.
We did several rounds of major edits while developing this document
both while it was an individual and as a WG document.  Note that this
document became a WG document literally 3 years ago.  It's quite
disruptive to be raising this issues at this stage. [/MB]

   [This first paragraph is unchanged:]
   o  hi-target-param: An optional parameter reflecting the mechanism by
      which the Request URI captured in the hi-targeted-to-uri in the
      History-Info header field value (hi-entry) was determined.  This
      parameter is either an "rc", "mp" or "np" header field parameter,
      which is interpreted as follows:

         "rc": The hi-targeted-to-URI represents a change in Request-URI
         while the target user remains the same.  This occurs for
         example when user has multiple AoRs as an alias or when
         forwarding the request to a registered contact of an AoR.

         "mp": The hi-targeted-to-URI represents a user other than the
         target user associated with the Request-URI in the incoming
         request that was retargeted.  This occurs when a request is
         statically or dynamically retargeted to another user
         represented by an AoR unassociated with the AoR of the original
         target user.

         "np": The hi-targeted-to-URI represents that there was no
         change in Request-URI.  This would apply for example when a
         proxy merely forwards a request to a next hop proxy and loose
         routing is used.  The "np" header field parameter contains the
         value of the hi-index in the parent hi-entry of this hi-entry.

      If the index-val in the parameter points to the parent hi-entry of this
      hi-entry, then:
      - the URI was generated from the URI of the parent hi-entry
      - the fork was not generated due to the response from any other fork.

      If the index-val in the parameter points to an hi-entry with a Reason
      header value whose protocol is "SIP" and whose cause begins with "3",
      then:
      - the URI was one of the Contact values in the 3xx response
      - the fork was generated due to the 3xx response from the hi-entry with
      the specified index-val.

      If the index-val in the param points to an hi-entry that is not the
      parent, and that hi-entry does not contain a Reason header value
      containing a SIP 3xx cause, then:
      - the URI was generated from the URI of the parent hi-entry
      - the fork was generated due to the response from the hi-entry with
      the specified index-val.

======================================================================

I believe that is everything to be done.

Dale