Re: [sipcore] Updated 4244bis and new call flow document

[Mary Barnes <[e-mail]>]

Marianne and Shida,

Responses inline below [MB].

Thanks,
Mary.

On Sun, Jul 25, 2010 at 10:22 AM, Shida Schubert <[e-mail]> wrote:

>
> Hi Marianne;
>
> Thanks for the review, comments inline..
>
> On Jul 25, 2010, at 3:09 AM, <[e-mail]> <
> [e-mail]> wrote:
>
> > Hi Mary and all,
> >
> > I have some comments on draft-ietf-sipcore-rfc4244bis-01:
> >
> > 1- Regarding the "hit" and "target" parameters, is it really necessary to
> create both?
> >  I mean the "hit" parameter seems almost useless as it has to be removed
> from the R-URI just
> >  after its creation (kept only in the Contact header after a 3xx).
> >  Why the hi-target couldn't be a single parameter to tag URIs?
>
> I can't clearly recall why we added this "hit" parameter but
> we had some problems delivering the "to-be hi-entry" that
> caused the 3xx. We talked about escaping the history-info header
> in the contact header in 3xx so entity receiving the 3xx can construct
> the hi-entry but decided to go with using the "hit" parameter.
>

[MB] Yes, both are necessary. If you look at the last individual version of
the doc, the handling for the 3xx had been changed from RFC4244 and had the
redirect server adding hi-entries. However, that was broken since the
redirect server cannot know whether the URIs it puts in the Contact header
are actually used to retarget the request. But, the redirect server is the
only entity that knows the mechanisms by which the URIs it adds to the
contact were determined.  So, we added the "hit" as a URI parameter for the
URIs in the Contact header. Then, the proxy/entity that is actually building
the hi-entries can use this information to include the right "hi-target".
 This really ended up making the processing far less different than RFC 4244
and far less complex - both good things.  [/MB]

>
> >
> > 2- §4.1 it is said that
> >  "The entries SHOULD be evaluated to determine gaps in indices,
> >  which could indicate that an entry has been maliciously removed.
> >  Either way, an application SHOULD be aware of potentially missing
> information."
> > If the removed hi-entry is the last destination (leaf) of an unsuccessful
> route (branch),
> > how is it possible, at the end, to know that there is a missing entry?
>
> It's true that if a leaf at an unsuccessful forked branch isn't
> captured there is no way to find out if there is a leaf is missing, but you
> will still get an hi-entry showing the unsuccessful branch with
> a reason that triggered the request received(e.g.
> branch that failed due to 487 for example will show up in the H-I
> but contact address(leaf) at the end of the failed branch won't)..
>
[MB] The text you are referencing has to do with how you can know that
entries are missing if there are gaps in the values of the index - e.g., an
entry with an index of 1.1 and then the next having a value of 1.3, etc.
This actually should not occur with 4244bis since the privacy was changed to
anonymize rather than remove.  The only time that might happen is if you
have a rogue proxy or a proxy that has not properly implemented 4244(-bis).
This document relies on the fundamental SIP model that the proxies are
trusted. That text is not referring to the case where the request for that
branch does not result in a successful termination. However, the proxy
should include all the information associated with that branch IF it is
received before the request is successfully targeted. Note, that this gets
to the point that Paul raised wrt to the need to clarify the processing for
forking. For sequential forking, there is no issue, however, parallel
forking introduces the possibility that the entity to which a request is
successfully targeted not receiving the complete information. However, the
information is complete in terms of what is available at that point in time.
As Paul highlighted, we do need to add additional normative text to describe
the handling of the header in the case of forking.

As far as the case of a 487, if a proxy supports HI then the Request-URI for
that branch should be included. But, since it wasn't successful that entry
will not be the contact address as Shida notes. However, that is NOT
considered a missing entry since the request was not sent to the contact.
 [/MB]


>
> >
> > 3- §5.1.1 At the end of the second sentence, there are 2 right
> parenthesis.
> >  §6.3.1 after reference to [RFC3261], there are 2 right square brackets.
>
[MB] Will fix both of those - thanks. [/MB]

>
> >
> > 4- §6.1 In the rules after the header syntax, the sentence
> >  "There MUST be no more than one hi-target parameter."
> >  should be completed with "per hi-entry" to be more precise (as it is the
> case in the previous item).
>
[MB] Good point - I'll clarify. [/MB]


> >
> > 5- §6.3.2 In the sentence
> >       "This is accomplished by adding a new priv-value,
> >       history, to the Privacy header [RFC3323] indicating that a specific
> >       History-Info header entry can not be forwarded outside the domain."
> >  It should be better to complete with : To do this, the Privacy header
> with the priv-value history is
> >  escaped in the hi-entry corresponding to the concerned URI.
>
[MB] Okay, I'll clarify that.  [/MB]

> >
> > 6- §7:
> >       "For example, an Automatic Call Distribution (ACD)/Call center
> application
> >       that utilizes the entry prior to the first History-Info entry with
> an
> >       hi-target value of "mp", ..."
> >  Do you mean the entry with the index that matches the first History-Info
> entry with an hi-target value of "mp"? (instead of the prior)
>
> I will let Mary answer this one..
>
[MB]   Yes - that needs to be fixed. [/MB]

>
> Regards
>  Shida
>
> >
> > 7- Appendix B.2 and B.3: what is the "p=x" in the URI?
>
[MB] That was intended to represent a privacy header of "x", with x being
any value for the privacy header with "history". However, there is no
compact form for the privacy header, so really we should just show it inline
as we did in an earlier version. The gist of that call flow was to show that
rather than remove the entries they are now anonymized when they go outside
the domain responsible for the Request-URI. [/MB].


> >
> > Cheers,
> > Marianne
> >
> > -----Message d'origine-----
> > De : [e-mail] [mailto:[e-mail]] De la
> part de Mary Barnes
> > Envoyé : jeudi 1 juillet 2010 21:31
> > À : SIPCORE
> > Objet : Re: [sipcore] Updated 4244bis and new call flow document
> >
> > Hi folks,
> >
> > I have not seen any responses to this email. So, either folks don't see
> any issues with the documents and 4244bis is ready for WGLC or folks have
> not reviewed the documents.  I'm happy to assume the former, however, it
> would be good for folks that have read the docs to post a note on the
> mailing list as to whether they think  4244bis is ready for WGLC.  And, if
> not, please detail your concerns, so that we can determine whether they
> warrant discussion in Maastricht.
> >
> > Also, opinions on how/where to progress the call flow document would be
> welcome.  I personally do not think it's worthwhile to pursue this in
> DISPATCH, but it's not clear to me whether informational docs like this are
> under the purview of the SIPCORE charter.  Since BLISS is trying to close
> down, it is also not appropriate to pursue the work there.
> >
> > Thanks,
> > Mary.
> >
> > On Thu, Jun 24, 2010 at 3:11 PM, Mary Barnes <[e-mail]>
> wrote:
> >> Hi folks,
> >>
> >> The 4244bis draft has been updated and a separate call flow document
> >> created per the earlier summary of proposed changes:
> >> http://www.ietf.org/mail-archive/web/sipcore/current/msg02647.html
> >>
> >> http://www.ietf.org/id/draft-ietf-sipcore-rfc4244bis-01.txt
> >> http://www.ietf.org/id/draft-barnes-sipcore-rfc4244bis-callflows-00.tx
> >> t
> >>
> >> There are  two voicemail examples in the new call flow document.  The
> >> 4244bis has 3 call flows - the basic sequential forking and two
> >> privacy examples. All the rest are now in the call flow document.
> >>
> >> The other changes we made were updates to the UAC, UAS and application
> >> considerations section - adding additional text as to how the UAC and
> >> UAS process hi-entries (including related to responses).  The
> >> application considerations section now describes how the tags can be
> >> used to derive specific information and the past guidelines were
> >> removed since 4244bis has much definitive guidance on the normative
> >> aspects of the header (i.e., SHOULDs replaced with MUSTs, privacy via
> >> anonymization rather than removing entries, etc.) as summarized in
> >> Section 11.
> >>
> >> Please review and provide any additional comments. We believe that
> >> 4244bis is pretty much ready to go. We can fine tune the details in
> >> the call flows and should be able to get that ready very soon, as
> >> well.  Let us know if you see additional use cases you would like to
> >> add.
> >>
> >> Thanks,
> >> Mary et al
> >>
> > _______________________________________________
> > sipcore mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sipcore
> > _______________________________________________
> > sipcore mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sipcore
>
>