Subject: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-07 - sections 10.1 and 11-end

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 19 Apr 2012 22:33:16 -0400

Correction of my comments on 10.3:  I proposed removing all of item 6:

   6.  Missing entity: If the request clearly has a gap in the hi-entry
       (e.g. by evaluating via header to the existing request history to
       see if it traversed a domain which doesn't exist in History-Info
       header field.), the entity adding an hi-entry MUST add an index a
       digit of "0" to the current index prior to adding appropriate
       index for the action to be taken.  If the index of the last hi-
       entry in the request received was 1.1.2 and there was a missing
       hi-entry and the request was being forwarded to the next hop, the
       resulting index will be 1.1.2.0.1.

But I should have restricted it to removing the "condition", namely
"(e.g. by evaluating via header to the existing request history to see
if it traversed a domain which doesn't exist in History-Info header
field.)"

10.1.1.  Indicating Privacy

   In this case, the
   intermediary MUST set a Privacy header field to a priv-value of
   "history" and include the Privacy header field in the hi-targeted-to-
   uri, for each new hi-entry added by the intermediary, as the request
   is retargeted within the domain for which the SIP entity is
   responsible.  Note, that the hi-entries that are added to a request
   from the cache are excluded in this case since the appropriate
   privacy was set for those hi-entries when they were originally added
   to a request.  The intermediary MUST NOT include any other priv-
   values in this Privacy header field.

The phrasing here is awkward.  I think this would be better:

   In this case, the intermediary MUST construct a Privacy header
   field with the single priv-value of "history" and include the
   Privacy header field in the hi-targeted-to-uri, for each new
   hi-entry created by the intermediary, as the request is retargeted
   within the domain for which the SIP entity is responsible.
   (Note that hi-entries that are added to a request
   from the cache are not modified by this process.)

However, I'm uncertain of the phrase "is retargeted within the
domain".  Does that mean retargeting outside the domain of interest
cannot have this process applied?  Perhaps we want to leave the
determination to the intermediary, since it is doing the modification
on its own behalf.  In that case, we would change the end of the
sentence to:

   ... for each new hi-entry created by the intermediary whose
   hi-targeted-to-uri it wishes to privacy protect.

   Finally, the terminator of the request may not want to reveal the

I think it would be more standard to say

   A UAS may not want to reveal the

and replace "terminator" with "UAS" in the rest of the paragraph.

10.1.2.  Applying Privacy

   When a request is retargeted to a URI associated with a domain for
   which the SIP intermediary is not responsible or a response is
   forwarded to a domain for which the SIP intermediary is not
   responsible, a Privacy Service at the boundary of the domain applies

It would be shorter to say

   When a SIP message is forwarded to a domain for which the SIP
   intermediary is not responsible ...

I think that has the same effect.

   which a SIP intermediary is responsible, are anonymized by the

probably should be "which >>>the<<< SIP intermediary is responsible",
referring to the intermediary discussed in the first paragraph.

   URIs containing a domain of anonymous.invalid (e.g.,
   [email-masked]).  If there is a Privacy header field in

Strictly, that should be "sip:[email-masked]" and/or
"sips:[email-masked]".  Perhaps it would be better to not
describe the URI at all but just refer to RFC 3323.  However, the
algorithm requires that H-I processing can *recognize* entries that
have already been anonymized, so we have to add a condition:

   The Privacy Service MUST change any hi-targeted-to-uris in
   >>>these<<< hi-entries that have not been anonymized (evidenced by
   their domain not being "anonymous.invalid") to anonymous URIs
   containing a domain of "anonymous.invalid" as described in RFC 3323
   section 4.1.

also:

   If there is a Privacy header field in the "headers" component of
   the hi-targeted-to-uri in >>>these<<< hi-entries(?), then the
   Privacy header field value MUST be removed from the hi-entry.

Similarly in the next paragraph:

   If there is not a Privacy header field in the message header of the
   request or response that is being forwarded, but there is a Privacy
   header field with a priv-value of "history" in the "headers"
   component in any of the hi-targeted-uris in the hi-entries
   associated with the domain for which a SIP intermediary is
   responsible, then the Privacy Service MUST update those
   hi-targeted-to-uris >>>as described above.<<<  Any other priv-values
   in the Privacy header field in the "headers" component of the
   hi-targeted-to-uris in the hi-entries MUST be ignored.
   >>>[Last sentence deleted, as it is included in the "as above"
   prescription.]<<<

Maybe there is a better way to factor out the "anonymize and remove
Privacy" operation.

11.  Application Considerations

   The SIP entity MUST determine if there are gaps in the indices.

This is strictly true, but I don't think it's the sense we want.
There is also the problem that the two types of "gap" are distinctly
different in what they reveal.  Maybe something fuzzier like:

   The SIP entity MUST be prepared to process effectively messages
   whose hi-entries show evidence of "gaps", that is, situations that
   reveal that not all of the forks of the request have been recorded
   in the hi-entries.

   Gaps are possible if the request is forwarded through
   intermediaries that do not support the History-info header field and
   are reflected by the existence of multiple hi-entries with an digit
   of "0" e.g. "1.1.0.1".

Replace "digit" with "integer" as discussed before, and change "an",
or rather leave it as "an" because we're changing "digit" to integer.

But "multiple" should be deleted.  In particular, when a UAS receives
a request whose request-URI does not match the last hi-entry, it adds
a "gap" hi-entry, but since the UAS does not forward the request
onward, it does not add any further hi-entries with "0"s.  But in this
case, the request *has* had a gap in H-I processing.

   Gaps are also possible in the case of
   parallel forking if there is an outstanding request at the time the
   SIP entity sends a response as described in Section 9.4, in which
   case the gap will not be visible as the branch responsible for the
   gap wasn't on the path of the request received.

I think this sentence needs to be modified strongly:

   Gaps are also possible in the case of
   parallel forking if there is an outstanding request at the time the
   SIP entity sends a >>>message<<<.

A gap (missing branch) due to an outstanding request can be revealed
in both requests and responses.  The final part of the sentence I
can't understand.  I wonder if there was a further sentence which was
damaged and joined to this previous sentence.

12.  Application Specific Usage

It would be wise to mark this section as non-normative:

   Following are possible application-specific usages of History-Info.

and we could add:

   See also the example call flows in Appendix B.

Dale

---

From: Shida Schubert <[email-masked]>
Date: Fri, 20 Apr 2012 20:05:52 +0900

Hi Dale;

 Thanks again for your comments. 

 My comments inline..

> if it traversed a domain which doesn't exist in History-Info header

 Okay, that is more clear but I still see no harm in leaving it in 10.3.

 The text could reside in 9.2 but I personally think it provides more uses 
by having it in 10.3.  

>   from the cache are not modified by this process.)

 Looks good. 

> on its own behalf.  In that case, we would change the end of the

 Well, for requests that are retargeted outside the domain, if the 
intermediary want privacy, it should anonymize the hi-entries 
before retargeting outside the domain of interest but following 
modification does leave room for intermediary to make a choice, 
so I will use your suggestion with the following modification. 

> and replace "terminator" with "UAS" in the rest of the paragraph.

 DONE.

> I think that has the same effect.

FIXED.

> referring to the intermediary discussed in the first paragraph.

FIXED.

>   containing a domain of "anonymous.invalid" as described in RFC 3323

 FIXED.

>   Privacy header field value MUST be removed from the hi-entry.

 I think it is fine as is. 

> or rather leave it as "an" because we're changing "digit" to integer.

FIXED.

>   SIP entity sends a >>>message<<<.

FIXED.

> damaged and joined to this previous sentence.

 We were just trying to describe how there could be an index missing 
not a "0" but  a branch can start from 2 instead of 1 due to parallel forking. 

 Many Thanks indeed for all of your suggestions and comments.

 Regards
  Shida

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 24 Apr 2012 13:57:16 -0400

> From: Shida Schubert [[email-masked]]
> 

Let me reconstitute what I should have said, and then let's see if we
still disagree:

In 9.1, "Receiving a Request" (not 9.2 as I said above), is:

   If the Request-URI of the incoming request does not match the hi-
   targeted-to-uri in the last hi-entry (i.e., the previous SIP entity
   that sent the request did not include a History-Info header field),
   the SIP entity MUST add a hi-entry to end of the cache, on behalf of
   the previous SIP entity, as follows:

The condition in section 10.3 item 6 (as shown above) is:

       If the request clearly has a gap in the hi-entry
       (e.g. by evaluating via header to the existing request history to
       see if it traversed a domain which doesn't exist in History-Info
       header field.), 

I think this condition should be added to the condition in 9.1 as an
alternative situation in which the procedures of 9.1 should be
performed.  I think we agree that we *intend* the procedures of 9.1 to
be applied in the conditions described in item 6, but I am emphasizing
that 9.1 is the "procedural" text that specifies when in processing
these procedures are done, and 9.1 should list *all* the conditions
that trigger it.

Now that I read 10.3 again, I see that 10.3 is not procedural, but
rather gives in one place all the rules for constructing hi-indexes of
new hi-entries.  And from that point of view, item 6 is proper as
written.  I might suggest that item 6 should refer to 9.1 as 9.1 is
the the implementation of the rules in item 6, but I see that no other
item in 10.3 refers to "procedural" sections; all the references are
in the reverse direction.

So I stand by my recommended change to section 9.1, but 10.3 does not
need to be changed.  Let me try to update 9.1 in a less messy way than
my last attempt:

   The SIP entity MUST detect whether the request clearly has a gap in
   the hi-entries, mandatorily by testing if the Request-URI of the
   incoming request does not match the hi-targeted-to-uri in the last
   hi-entry, and optionally by other tests, e.g. by comparing the Via
   header to the existing request history to see if it traversed a
   domain which doesn't exist in History-Info header field.  If a gap
   is detected, the SIP entity MUST add a hi-entry to end of the
   cache, on behalf of the previous SIP entity, as follows:

The original text referred to by the following remarks is:
|   Gaps are also possible in the case of
|   parallel forking if there is an outstanding request at the time the
|   SIP entity sends a response as described in Section 9.4, in which
|   case the gap will not be visible as the branch responsible for the
|   gap wasn't on the path of the request received.

> not a "0" but a branch can start from 2 instead of 1 due to parallel forking.

One problem is that "gap" is being used in two senses throughout this
draft.  One sense is "a branch of parallel forking that is not
recorded in this History-Info header, but is revealed by
non-sequential numbering of the children of an entry".  Another sense
is "an ancester of this request did not add an hi-entry".

Another is the phrase "gap will not be visible" -- the *gap* is
visible, I think you mean "the hi-entries whose absence constitute the
gap are not present".

I've tried to revise that sentence but I don't grasp exactly what
situation you are describing.  It seems to be some case of the general
rule that branches of the overall hi-entry tree can be missing at any
point, due to the timings of requests and responses in the propagation
of the request.

Dale

---

From: Shida Schubert <[email-masked]>
Date: Wed, 25 Apr 2012 14:48:54 +0900

Hi Dale;

 Many thanks for your feedbacks.

 My comments inline.

> these procedures are done, and 9.1 should list *all* the conditions

 I agree. 

>   cache, on behalf of the previous SIP entity, as follows:

 This looks good. 

 Although may be simply removing the condition in 10.3 
(evaluating via etc.) alone may be sufficient. 

 Comparing via header is probably unnecessary as receiving a 
request with hi-entry which doesn't match the R-URI is enough 
to detect a gap.  

> is "an ancester of this request did not add an hi-entry".

 The referenced text refers to the gap in the sense that "a branch of 
parallel forking that is not recorded" 

> visible, I think you mean "the hi-entries whose absence constitute the

 The gap in this sense (parallel forking) may not be visible if you 
are received a request from the first branch. 

 Let's say it forked at the third hop and you were the fourth hop the 
hi-indexes would look like. 1.1.1.1
 
 Now if you were on the second fork it would look like: 1.1.2.1 without 
the 1.1.1 entry, so then you know that forking likely happened and 
gap is visible. 

> point, due to the timings of requests and responses in the propagation

 I hope above comments clarify this. 

 Regards
  Shida