Subject: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis

From: Adam Roach - SIPCORE Chair <[email-masked]>
Date: Mon, 16 Aug 2010 16:29:12 -0500

[as chair]

A major author of draft-ietf-sipcore-rfc4244bis-01 believes that the 
document has no remaining open issues, and is ready for evaluation. 
Today, we are starting a two-week working group last call period. This 
last call period ends on Tuesday, August 31st.

The latest version of the document can be retrieved here:

http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis

Any comments on the document should be sent to the SIPCORE mailing list.

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 25 Aug 2010 10:45:46 -0500

[as chair]

As a reminder, we're just over halfway through this WGLC, and have not 
yet seen any comments. Please take some time to review this draft.

/a

On 8/16/10 4:29 PM, Adam Roach - SIPCORE Chair wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Aug 2010 12:45:07 -0400

[as individual]

There was some discussion on the -00 version back in July that was not, 
AFAICT, addressed in the -01 version. There is a thread emanating from 
mary's announcement of the -00 version. The following is a hook into 
that thread:

http://www.ietf.org/mail-archive/web/sipcore/current/msg03056.html

It has to do with when privacy should be applied.

	Thanks,
	Paul

---

From: Mary Barnes <[email-masked]>
Date: Wed, 25 Aug 2010 11:51:27 -0500

Sorry, I should have replied to that thread, but I didn't think there was a
change necessary.  I'll reply now.

Mary.

On Wed, Aug 25, 2010 at 11:45 AM, Paul Kyzivat <[email-masked]> wrote:

> mary's announcement of the -00 version. The following is a hook into that
> thread:
>
>> As a reminder, we're just over halfway through this WGLC, and have not yet
>> seen any comments. Please take some time to review this draft.
>>
>> /a
>>
>>> document has no remaining open issues, and is ready for evaluation. Today,
>>> we are starting a two-week working group last call period. This last call
>>> period ends on Tuesday, August 31st.
>>>

---

From: Mary Barnes <[email-masked]>
Date: Wed, 25 Aug 2010 12:01:15 -0500

Actually, I did respond to that message, per the following:
http://www.ietf.org/mail-archive/web/sipcore/current/msg03088.html

(threading in the email archives is no better than my archiving method for
emails).

Thanks,
Mary.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Aug 2010 14:01:58 -0400

Mary Barnes wrote:
> (threading in the email archives is no better than my archiving method 
> for emails). 

Hmm. I cannot find that one anywhere in my own archives, and I don't 
recall seeing it. Don't know why. :-(

> That sentence is written within the context of core RFC 3261.  We really didn't get into the RFC 3325 trust domain concept in RFC 4244 - in particular because RFC 3325 is informational.  However, there is an UNLESS later in that section:
> 
> "...,unless the processing entity knows a priori that it can rely on a downstream processing entity within its domain to apply the requested privacy or local policy allows the forwarding."
> 
> So, I will include that same clause in the sentence you are concerned about.

That doesn't do it for me. I think one way or another you need to 
address whether "domain" means "DNS domain" or "trust domain". And if it 
means "trust domain" then of course we need a ref to 3325.

You seem to mean DNS domain, but the kinds of actions you are discussing 
seem more related to 3323 and 3325. ISTM that if you mean DNS domain 
then you mean it based on an assumption that "DNS domain" = "trust domain".

	Thanks,
	Paul

> Thanks,
> Mary. 
> 
> On Wed, Aug 25, 2010 at 11:51 AM, Mary Barnes 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Sorry, I should have replied to that thread, but I didn't think
>     there was a change necessary.  I'll reply now.
> 
>     Mary. 
> 
> 
>     On Wed, Aug 25, 2010 at 11:45 AM, Paul Kyzivat <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         [as individual]
> 
>         There was some discussion on the -00 version back in July that
>         was not, AFAICT, addressed in the -01 version. There is a thread
>         emanating from mary's announcement of the -00 version. The
>         following is a hook into that thread:
> 
>             As a reminder, we're just over halfway through this WGLC,
>             and have not yet seen any comments. Please take some time to
>             review this draft.
> 
>             /a
> 
>                 A major author of draft-ietf-sipcore-rfc4244bis-01
>                 believes that the document has no remaining open issues,
>                 and is ready for evaluation. Today, we are starting a
>                 two-week working group last call period. This last call
>                 [email-masked] <mailto:[email-masked]>
>             [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>

---

From: Mary Barnes <[email-masked]>
Date: Wed, 25 Aug 2010 13:18:13 -0500

Paul,

In the context of 4244/-bis, the term domain is a DNS domain (per RFC 3261)
and not a SPEC-T Trust Domain per RFC 3325.  However, the specific
terminology we are referring to is also in RFC 3261 in that a SIP entity can
be responsible for multiple domains, which is not a Trust domain, but is
something that can be configured.  That's the context meant in RFC
4244/-bis.  It is outside the scope of RFC 3261 (and thus RFC 4244/-bis) as
to how those relationships are configured. It could certainly be done using
the Trust domain model, but again, that's out of scope.

If it helps, I can add in the terminology section that domain (and the
terminology around the domains for which an entity is responsible, etc. ) is
used in the same context as RFC 3261, but I personally don't think that
should be necessary.

Mary.
On Wed, Aug 25, 2010 at 1:01 PM, Paul Kyzivat <[email-masked]> wrote:

> Hmm. I cannot find that one anywhere in my own archives, and I don't recall
> seeing it. Don't know why. :-(
>
> That sentence is written within the context of core RFC 3261.  We really
>> didn't get into the RFC 3325 trust domain concept in RFC 4244 - in
>> particular because RFC 3325 is informational.  However, there is an UNLESS
>> later in that section:
>>
>> "...,unless the processing entity knows a priori that it can rely on a
>> downstream processing entity within its domain to apply the requested
>> privacy or local policy allows the forwarding."
>>
> That doesn't do it for me. I think one way or another you need to address
> whether "domain" means "DNS domain" or "trust domain". And if it means
> "trust domain" then of course we need a ref to 3325.
>
> seem more related to 3323 and 3325. ISTM that if you mean DNS domain then
> you mean it based on an assumption that "DNS domain" = "trust domain".
>
>        Thanks,
>        Paul
>
> Thanks,
>> Mary.
>> On Wed, Aug 25, 2010 at 11:51 AM, Mary Barnes <[email-masked]<mailto:
>> [email-masked]>> wrote:
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Aug 2010 20:46:23 -0400

Mary,

I don't think that does it either. Let me try to explain another way:

The privacy feature you describe extends the behavior of priv-values 
"session" and "header" that are specified in 3323. (And also adds a new 
value "history".) In 3323 there is a lot of text describing the privacy 
service, and what it does based on priv-values when it is processing a 
request or response. There is also a bunch of text discussing what the 
UA should do to ensure that the request or response reaches a suitable 
privacy service that will act according to its wishes.

RFC 3325 extends this, with the introduction of trust domains. And 
importantly, it says (not in so many words, but effectively) that 
proxies on the edge of a trust domain are to act as privacy services 
with respect to the priv-val of "id". (It doesn't say they act as a 
privacy service for anything else.)

4244bis section 6.3.2 says:

    If the requestor has indicated a priv-
    value of "session" or "header" in the request, all History-Info
    entries MUST be anonymized when the request leaves a domain for which
    the intermediary is responsible.

It does *not* say what is responsible for doing that. Since this is a 
modification to 3323, I would presume that it is a privacy service as 
specified in 3323 that would be carrying this out. If so, it can only do 
so for the values that are present when it gets the request, and then 
only if its passing the request on to a node that is not in its domain.
If users were to follow the guidelines of 3323, the privacy service 
would be the first server the request reaches after leaving the UAC, and 
thus would have little value.

The is what led me to think you meant trust domains. Because I think the 
behavior you are looking for is more like what 3325 does for "id" 
privacy. But of course that only works in an environment that has trust 
domains and entities charged with carrying out some privacy service 
functions at the edge of the domain. But as it stands those aren't 
charged with implementing "session" or "header" privacy.

So, I don't understand what entitiy you expect to carry out this 
particular new privacy service act. One way or another I think this 
document will have to find a way to say that.

	Thanks,
	Paul

Mary Barnes wrote:
> Paul,
>  
> In the context of 4244/-bis, the term domain is a DNS domain (per RFC 
> 3261) and not a SPEC-T Trust Domain per RFC 3325.  However, the specific 
> terminology we are referring to is also in RFC 3261 in that a SIP entity 
> can be responsible for multiple domains, which is not a Trust domain, 
> but is something that can be configured.  That's the context meant in 
> RFC 4244/-bis.  It is outside the scope of RFC 3261 (and thus RFC 
> 4244/-bis) as to how those relationships are configured. It could 
> certainly be done using the Trust domain model, but again, that's out of 
> scope.
>  
> terminology around the domains for which an entity is responsible, etc. 
> ) is used in the same context as RFC 3261, but I personally don't think 
> that should be necessary.
>  
> Mary.
> On Wed, Aug 25, 2010 at 1:01 PM, Paul Kyzivat <[email-masked] 
>         (threading in the email archives is no better than my archiving
>         method for emails).
> 
> 
>         That sentence is written within the context of core RFC 3261.
>          We really didn't get into the RFC 3325 trust domain concept in
>         RFC 4244 - in particular because RFC 3325 is informational.
>          However, there is an UNLESS later in that section:
> 
>         "...,unless the processing entity knows a priori that it can
>         rely on a downstream processing entity within its domain to
>         apply the requested privacy or local policy allows the forwarding."
> 
>     address whether "domain" means "DNS domain" or "trust domain". And
>     if it means "trust domain" then of course we need a ref to 3325.
> 
>     You seem to mean DNS domain, but the kinds of actions you are
>     discussing seem more related to 3323 and 3325. ISTM that if you mean
>     DNS domain then you mean it based on an assumption that "DNS domain"
>     = "trust domain".
> 
>            Thanks,
>            Paul
> 
>         Thanks,
>         Mary.
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
> 
>            On Wed, Aug 25, 2010 at 11:45 AM, Paul Kyzivat
>         <[email-masked] <mailto:[email-masked]>
>            <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> 
>                [as individual]
> 
>         <mailto:[email-masked] <mailto:[email-masked]>>
> 
>         <mailto:[email-masked] <mailto:[email-masked]>>
> 
>         <mailto:[email-masked] <mailto:[email-masked]>>
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 31 Aug 2010 18:32:02 +0200

I have reviewed the document as far as section 8, before running out of time. Although the technical content of the document is reasonably stable, there are far too many minor problems that need fixing before it is ready to go. Specific comments:

1. In general, there are too many normative statements (MUST/SHOULD) written in the passive voice, or in the active voice with an inappropriate subject. I have pointed out a few of these in later comments, but all should be checked.

2. It nearly always uses the term "header" rather than "header field", although never, as far as I know, meaning the entire SIP header.

3. Section 2:
"The term "retarget" is used in this document to refer both to the
   process of a Proxy Server/User Agent Client (UAC) changing a Uniform
   Resource Identifier (URI) in a request based on the rules for
   determining request targets as described in Section 16.5  of [RFC3261]
   and the subsequent forwarding of that request as described in section
   16.6 of [RFC3261]."
Sections 16.5 and 16.6 of RFC 3261 are concerned only with proxies, so for the UAC case it is inappropriate to say the term applies as described in those sections.

4. Section 2:
"Noting that  [RFC3261] uses the term ... "
This sentence lacks a main clause.

5. Section 2:
"for which is  not"
Should be "for which it is not"

6. Section 3:
"by locating the first  entry just prior to the last hi-entry marked "
The word "first" is confusing. It seems to be redundant - unless it has some special meaning that I have failed to grasp.

7. Section 4.1:
"and if the Request-URI was modified by a previous hop"
What is a hop? I tend to think of a hop as being the "wire" between two SIP entities, but here it seems to be used to mean a SIP entity such as a proxy. If we really want to use this term, we should define it. Check for other instances too.

8. Section 4.1:
"A UAC that wants to ensure that privacy not
   be applied to its identity  MUST include a Privacy header with a priv-
   value of "none.""
Privacy associated with a UAC's identity is outside the scope of History-Info, which in general does not reveal a UAC's identity.

9. Section 4.1:
"reason  header"
Capitalize - should be "Reason".

10. "the reason  header  MUST be associated with the hi-
   targeted-to-uri in the previous (last) hi-entry, as described in
   Section 6.3.3"
I don't think 6.3.3 really tells me how to achieve this association - it tells me when I must associate. But see also comments on 6.3.3.

11. Section 4.1:
"A new hi-entry MUST then be added for the URI from
   the Contact header (which becomes the new Request-URI)."
This seems to be a rather convoluted way of saying that you use the new URI from the new Request URI to populate the new hi-entry. Mentioning Contact header (field) is confusing, since the recursed request also contains a Contact header field.

12. Section 4.1:
"If the URI in the
   Contact header  contains a "hit" URI parameter"
Make it clear this is the Contact header field from the 3xx response.

13. Section 4.1:
"Prior to any application usage of the information  by the UAC"
It is not clear what information this is talking about. Presumably H-I in responses (and not just 3xx responses mentioned in the previous paragraph).

14. Section 4.2.1:
"The last hi-entry reflects the most recent
   target and SHOULD contain  the Request-URI for the received request."
We cannot place a normative requirement on hi-entry. There is no normative requirement on the UAS concerning receipt - the UAS is not in control of what it receives. Should rephrase, e.g., "will normally contain".

15. Section 4.2.1:
"the
   UAS MUST insert an hi-entry ."
How is this testable, other than by the fact that H-I will get reflected in the response? But that should be covered in 4.2.2, shouldn't it?

16. Section 4.2.1:
"If privacy is required, the procedures of
   Section 6.3.2 MUST be used."
As far as I can see, 6.3.2 talks only about requests, whereas here we are talking about responses. I am not convinced considerations are quite the same.

17. Section 4.2.2:
"The information can also be useful for
   implementations with B2BUAs that include the History-Info, received
   in the incoming request, in the subsequent outgoing request."
The words "implementations with B2BUAs" seem strange - why not just "B2BUAs"?

18. Section 4.2.2:
"the UAS MUST
   include any History-Info received in the request  in the subsequent
   response"
Does this include 100 responses?

19. Section 4.2.2:
"The processing of History-Info in responses follows the methodology
   described in Section 16.7 of [RFC3261 ]"
Section 16.7 is concerned only with proxies, not UASs.

20. Section 5.1.1:
"Upon receipt of an initial request for a dialog, or a standalone
   request"
This is a different formulation from that in 4.1: "in any request not associated with an established dialog".

21. Section 5.1.1:
"The proxy MUST add a "hit" SIP/SIPS URI parameter
      for the target URI that are determined"
Singular/plural error.

22. Section 5.1.1:
"If
      privacy is required, the procedures of Section 6.3.2 MUST be used."
In fact I think one needs to go to 6.3.2 to find out how to determine whether privacy is required, as well as for the procedures when it is found to be required.

23. Section 5.1.2:
"When re-sending a request as a result of retargeting because of
   failure"
Should we make it clear that this doesn't apply in case of 3xx, i.e., which errors it does apply to.

24. Section 5.1.2:
"If the received error response did not include
      any History-Info header fields, the proxy MUST use the same
      History-Info header fields that were sent in the outgoing request
      that failed to build the outgoing request."
Hard to understand, because of the two instances of "outgoing request". Perhaps:
"... MUST use the same History-Info header fields in the new outgoing request as those sent in the request that failed."

25. Sections 5.1.2 and 5.1.3. These are different, in that 5.1.2 allows for multiple branches failing, but 5.1.3 allows for only a single request encountering 3xx. Firstly, it is possible >1 request can return 3xx (the proxy is not forced to recurse immediately the first 3xx arrives). Secondly it is possible that some failure responses might arrive before the 3xx on which the proxy recurses. I think the new request should reflect H-I from all previous branches, not just the one leading to recursion. Also the tagging of the recursed request should take account of all previous branches.

26. Section 5.2:
"A proxy that receives a request with the "histinfo" option tag in the
   Supported header, SHOULD forward captured History-Info in subsequent,
   provisional , and final responses "
Does this include 100 responses?

27. Section 5.2:
"A proxy MAY anonymize any hi-entry whose domain corresponds to a
   domain for which it is responsible (as per [RFC3323 ])."
I don't think RFC 3323 tells me how to anonymize an hi-entry.

28. Section 5.2:
"The processing of History-Info in responses follows the methodology
   described in Section 16.7 of [RFC3261], with the processing of
   History-Info headers  adding an additional step, just before Step 9,
   "Forwarding the Response"."
What is meant by "processing of History-Info headers"? Does this refer to the procedures of the first two paragraphs?

29. Section 6.1:
"The format for
      this parameter is a string of digits, separated by dots to
      indicate the number of forward hops and retargets"
It is not clear from this whether the dots indicate the number of forward hops or the number of retargets. I know it is explained in detail later, but for somebody reading from front to back, this isn't very clear. Again, use of the word "hop" without definition is a concern.

30. Section 6.1:
"By adding the
      new entries in order (i.e., following existing entries per the
      details in Section 5.1 ), "
Section 5.1 doesn't really give details - in fact it refers forward to 6.3.4.

31. Section 6.1:
"The latter case indicates that the
      History-Info entries for the domain MUST  be anonymized prior to
      forwarding, whereas the use of the Privacy header escaped in the
      hi-targeted-to-uri means that a specific hi-entry MUST be
      anonymized."
Two instances of bad use of normative language. The active voice should be used, with the subject indicating to what the requirement applies (presumably to an entity forwarding a request or response in certain circumstances, but that surely is covered by the relevant procedures sections). I suspect we shouldn't be using normative language here.

32. Section 6.1:
"The following summarizes the  syntax of the History-Info header"
It looks to me like a formal definition, rather than a summary.

33. Section 6.1:
"hi-index = "index" EQUAL 1*DIGIT *("." 1*DIGIT) "
Would it be better to have a new definition index-value, which could then be reused by mp-param?

34. Section 6.1:
"There MUST be no more than one hi-target parameter."
Presumably this is per hi-entry.

35. Section 6.3.1:
"SIP/SIPS URI target parameter for History-Info Header"
A confusing title, because the parameter seems to used in the URI when the URI is NOT in a History-Info header field.

36. Section 6.3.1:
"This
   parameter is used to populate the hi-target parameter Section 6.3.5
   when a Request-URI is first added in a hi-entry in the History-Info
   header field ."
I would say the parameter is used when an hi-entry is added containing the Request-URI value.

37. Section 6.3.1:
""mp": The Request-URI is a URI that represents another user.  This
      occurs when a request is to be statically or dynamically
      retargeted to another user. "
So what if a request is retargeted to something that is neither a contact nor the AOR of another user, e.g., retargeting a dial string to a service URN?

38. Section 6.3.2:
This whole section talks about requests. What about responses? For example, a request from domain A arrives at a proxy in domain B, which inserts an hi-entry requiring privacy before forwarding to the UAS. The UAS returns it in a response. I believe that hi-entry should be anonymized or removed before passing back to domain A, but I can't find anything requiring this.

39. Section 6.3.2:
"If the requestor has indicated a priv-
   value of "session" or "header" in the request, all History-Info
   entries MUST be anonymized  when the request leaves a domain for which
   the intermediary is responsible."
Another bad formulation of a normative statement. It should use the active voice, with a subject indicating the entity to which the requirement applies. Or is that better handled in section 5 (perhaps it is already covered - I haven't checked)?

40. Related to the above, I think the split of procedures between sections 4 and 5 on the one hand and section 6 on the other hand is rather confusing, and leads to a lot of forward and backward referencing and, in one or two places, duplication I think. Perhaps it is too late to do much about this, except to ensure consistency and avoid repetition.

41. Section 6.3.3:
"For retargets that are the result of an explicit SIP response, a
   Reason MUST be associated with the hi-targeted-to-uri ."
Again this is passive voice. Also, what is meant by "associated with". I assume it means include a Reason in the hi-entry - why not say so?

42. Section 6.3.2:
"MUST be included  as the
   Reason associated with the hi-targeted-to-uri that has been
   retargeted."
Again, the passive voice, and again I don't like the vague expression "associated with". Similarly in subsequent sentences in this paragraph.

43. Section 6.3.4:
"an index MUST be  included along with the
   Targeted-to-URI being captured"
Passive. Who or what does this requirement apply to? Presumably to any entity inserting an hi-entry, but not to an entity merely passing one on, or a UAS reflecting an hi-entry back towards the UAC.

44. Section 6.3.4:
"Within each level, the
   integer reflects the number of peer entities to which the request has
   been routed ."
I don't think this is necessarily correct. For example, I could have two branches, each with a different target, but both resolving to the same next hop peer entity. Shouldn't it reflect the number of branches?

45. Section 6.3.4:
"With the index for each new
       branch calculated by incrementing the last/lowest  digit at the
       current level"
What does last/lowest mean? I can understand "last", but not "lowest". I spotted at least one other instance of this formulation.

46. Section 6.3.4:
"For example, if the index in the History-Info header of
       the received request was 1.2, then the index in the History-Info
       header field for the new hi-targeted- to-URI would be 1.3. "
This doesn't make sense. If the received request had index 1.2, surely the index of the new hi-entry would be 1.2.x? Or should "received request" be "received 3xx response"? Even then I am not convinced that the index of the new hi-entry would necessarily be 1.3 - there may already have been a 1.3, in which case it would have to be 1.4, and so on.

47. Section 6.3.4:
"Each index are  sequentially
       assigned."
Change "are" to "is".

48. Section 6.3.4:
"Note that for each individual fork, only the entry corresponding
       that  that fork is included "
Repeated "that".

49. Section 6.3.5:
"The hi-target attribute MUST  be added to the History-Info header if
   the target to which the request is being forwarded contains a "hit"
   URI parameter as defined in Section 6.3.1."
Again passive voice - what is the subject? Assuming it is a UAC or a proxy, isn't such a requirement already covered by sections 4.1 and 5? We should not repeat normative statements in different sections.

50. Section 6.3.5:
"If the value of the "hit" parameter is "mp", then the index of the
   entry corresponding to the original target (i.e., the "mapped-from"
   target) MUST  be added as a parameter to "mp"."
Similar comment to above.

51. Section 6.3.5:
"2.  Entry prior to last entry with hi-target of "rc" in the Request
       received by a UAS - i.e., the Request URI associated with the
       destination of the request was determined based on a Registered
       Contact."
I don't understand the i.e. part. The entry prior to the last entry with "rc" was not determined based on a registered contact - it is the next entry (the one containing rc) that was so determined.

52. Section 6.3.5:
"4.  Entry prior to first entry with hi-target of "rc" in the Request
       received by a UAS - i.e., the first Registered Contact to which
       the request was targeted."
Similar comment.

John

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Adam Roach
> Sent: 25 August 2010 16:46
> To: SIPCORE Chairs
> Cc: SIPCORE (Session Initiation Protocol Core) WG
> Subject: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipcore-rfc4244bis
>
>   [as chair]
>