DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 :cc:content-type:content-transfer-encoding;
 b=SpIepLPLKSo4+x3Fi8coXOALhkfeccl2IXOKLpxwSXwk+kRo+N5DGD12zRPEf5mKpU
 cNqCisTslWp/IkDiHOZRdtGdwZIKTUv7RyG6NR6twYRAFQ0Z+Kdqh/LLGhJsQ+hGAAXd
 gdIbhYmylS+1BIQhAtzDZPDg+BLR7KUrbjGgA=
MIME-Version: 1.0
In-Reply-To: <A444A0F8084434499206E78C106220CA023554628B@MCHP058A.global-ad.net>
References: <A444A0F8084434499206E78C106220CA023554628B@MCHP058A.global-ad.net>
Date: Tue, 2 Nov 2010 14:25:05 -0500
Message-ID: <AANLkTi=B1qL2D-U85mMp3Dft2kvmuB9Sv5EAQ9vQBtot@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: "Elwell, John" <john.elwell@siemens-enterprise.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-02
Precedence: list

Hi John,

Responses inline below [MB].  I will skip the ones that I replied to
in the other response [MB].

Thanks,
Mary.

On Mon, Nov 1, 2010 at 5:13 PM, Elwell, John
<john.elwell@siemens-enterprise.com> wrote:
> Despite the effort that has gone into addressing comments raised by peopl=
e on -01, I still find -02 hard to understand in places. I have not had tim=
e to review the whole document, but here are some comments up to section 7.=
 Just as I finished writing this I saw Mary's response to my comments on -0=
1, which I will respond to tomorrow. Apologies for any overlap between the =
two.
>
>
> 1. As a general comment that I have made before, the document still talks=
 about 'header' in many places where it is not referring to the entire head=
er for a SIP message, but only to a particular header field such as History=
-Info. History-Info is only one field within the entire SIP header. See RFC=
 3261 section 6 - definitions of header and header field. Although RFC 3261=
 is not 100% consistent, in general things like Contact, To, From etc. are =
referred to as header fields, and hence History-Info should be too. Section=
 4.3 of RFC 4485 also calls for attention to be given to the correct use of=
 terms header, header field and header field parameter, although it fails t=
o say what the correct use is and one has to rely on RFC 3261.
[MB] I replied to this in the other email. But, yes, this doc does use
Header to mean Header field, but that's done in many other documents.
However, I can change all of those to say "header field" if it makes a
difference in understanding the document. [This might be something to
put on the RFC editor list if folks are insisting that we always use
"Header field"]  The term header field parameter AFAIK is only used to
refer to the two new header field parameters defined in this document.
[/MB].
>
> Also there are some instances of "header parameter field", which is not a=
 normal term - it should be "header field parameter".
[MB] That's a typo. [/MB]
>
> 2. There is some confusion concerning Reason - sometimes it is referred t=
o as a parameter (e.g., 7.1 3rd bullet, 7.1 last paragraph), sometimes as r=
eason header, sometimes as reason, sometimes as Reason header, sometimes as=
 Reason...
[MB] Logically, Reason is a "parameter" for the hi-entries. However,
rather than redefine the "parameter", we reuse the Reason header by
escaping it in the URI - the term Reason header was used for brevity.
I did add text in the -02 to clarify that in cases where it is
confusing. I can change all instances to refer to "escape a Reason
header in the hi-targeted-uri" rather than just "add a Reason header".
[/MB]
>
> 3. The word "entry" is used inconsistently. Mostly it occurs in "hi-entry=
", which is fine. But we also have "targeted-to-URI entry", "entry" (alone)=
, History-Info entry (which is probably fine, as long as we say what it is)=
, "header entry". Also "hi-entries".
[MB] Which term do you prefer?  I will change all the entry(s) to
hi-entry. The targeted-to-URI entry possibly should be
hi-targeted-to-uri. [/MB]

>
> 4. As another general comment, there are too many normative statements us=
ing the passive voice, and therefore hard to understand. To quote one examp=
le of the sort of ambiguity that can arise from using passive, in 7.3.2:
> "For retargets that are the result of an explicit SIP response, a
> =A0 Reason MUST be associated with the hi-targeted-to-uri."
> Is this saying that an entity that inserts History-Info MUST include in h=
i-targeted-uri an escaped Reason header field? Or is this saying that a rec=
ipient of Reason MUST associate it with an hi-targeted-to-uri. I guess the =
first interpretation is more plausible, but why not say what is meant, rath=
er than fudging it?
[MB] The Reason header is added to the hi-entry whose
hi-targeted-to-URI is being retargeted due to the response.  It is
added by the entity receiving the response.  Note that it is added to
the entry prior to the entry that is being added as a result of the
retargeting due to the response - i.e., it's not added to the
"current" hi-entry.  It's added to the previous.  The sentences
following the one that you highlight are intended to say just that.
That's why the term "associated" is loosely used because the next
sentences are the normative part. So, really, that first sentence
shouldn't be "MUST be" and would be more accurate to say "is". [/MB]
>
> 5. Section 1:
> "there is a need for a standard mechanism within
> =A0 SIP for communicating the retargeting history of such a request"
> What is meant by "such a request"? We have not previously mentioned "requ=
est". The preceding text has talked about calls, not requests, but perhaps =
it should talk about requests.
[MB] I will change "such a request" to "call requests". [/MB]
>
> 6. Section 3:
> "Current network applications provide the ability for elements
> =A0 involved with the call to exchange =A0additional information relating=
 to
> =A0 how and why the call was routed to a particular destination"
> Change "exchange" to "obtain". I think that would fit better with the exa=
mples that follow.
[MB] Okay. [/MB]
>
> 7. Section 3:
> "Capturing aliases and Globally Routable User Agent URIs (GRUUs)
> =A0 =A0 =A0[RFC5627], which can be overwritten by a home proxy =A0upon re=
ceipt"
> The term "home proxy" is not used in RFC 3261.
[MB] I will change to "proxy in the home domain" which is a term used
in RFC 5627 (earlier versions of GRUU did use the term "home
proxy")[/MB]
>
> 8. Section 4:
> "The =A0following information is carried in the History-Info header as
> =A0 detailed in Section 7.1:"
> I think it would be better to say "For each target used for forwarding a =
request, the =A0following information is carried in the History-Info header=
 as detailed in Section 7.1:"
> This would make it clear that there can be more than one instance of this=
 information.
[MB] Okay. [/MB]
>
> 9. Section 4;
> "Target : A parameter indicating ..."
> This overloads the word target. Perhaps a better generic term for these p=
arameters would be "Derivation".
[MB] I will just change to "Indicates.." which matches the form of the
other bullets in that list. [/MB]
>
> 10. Section 4:
> "A SIP entity changing the target of a
> =A0 request in response to a redirect or REFER"
> A REFER does not cause an entity to change the target of a request - it c=
auses an entity to generate a new request. H-I will indeed be added, but th=
at is covered by the statement above about creating a new request.
[MB] Yep. [/MB]
>
> 11. "propagates any
> =A0 History-Info header from the initial Request in the new request":
> Contrary to what it says in the first half of the sentence, this does ind=
eed acknowledge that we have a new request as a result of REFER. However, t=
he statement is incorrect because there is no normative statement (e.g., in=
 section 5) concerning this special behaviour for REFER. There is merely a =
requirement in Appendix A.
[MB] I'll add text. [/MB]
>
> 12. Section 4:
> "Note that an hi-entry is not included for the fork to
> =A0 sip:bob@192.0.2.7 "
> This is misleading, because there is indeed H-I sent to 192.0.2.7. I thin=
k what it should say is that the H-I sent to 192.0.2.3 and subsequently sen=
t back to Alice does not contain an entry for target 192.0.2.7.
[MB] yep. [/MB]
>
> 12bis. Section 5.1:
> "In addition, the UAC
> =A0 SHOULD add =A0a History-Info header"
> Why is this only a SHOULD, not a MUST? What would be the exceptions?
[MB] This was issue  #28  where Dale suggested it be change from a
"MAY" to a "SHOULD" (with which you agreed in the email thread).  But,
I don't have a problem to change this to a MUST. [/MB]
>
> 13. Section 5.1:
> "As a result, intermediaries and
> =A0 the UAS at least know the original Request-URI, and if the Request-
> =A0 URI was modified by a previous hop. "
> This is inaccurate, since intermediaries may have removed H-I for privacy=
 or other reasons. Best to delete the sentence.
[MB] Okay. HOwever, entries should not be removed for privacy - that
was a change from RFC 4244 - they MUST be anonymized.  [/MB]
>
> 14. Section 5.1:
> "A UAC that wants to ensure =A0that privacy not
> =A0 be applied to its identity MUST include a Privacy header with a priv-
> =A0 value of "none"."
> I am not sure that 'none' ensures anything - it is only a request accordi=
ng to RFC 3323.
[MB] Then I'll change it from "ensure" to "request". [/MB]
>
> 15. Section 5.1:
> "A new hi-entry =A0MUST then be added for the URI from
> =A0 the Contact header (which becomes the new Request-URI) "
> The Contact header field could contain >1 URIs. I think what we want to s=
ay is that the UAC MUST populate the new-hi-entry with the URI chosen as th=
e Request-URI for the new request.
[MB] Yes. [/MB]
>
> 16. Section 5.1:
> "If the Contact header contained any of
> =A0 the header parameter fields defined in this specification"
> Don't understand. The parameters defined in this specification are parame=
ters of the History-Info header field, so would not appear in a Contact hea=
der field. Admittedly there is some mention in 7.3.4 of using the parameter=
s in a Contact header field, but there is nothing that specifies the extend=
ed syntax of the Contact header field.
[MB] The header field parameters are defined for the Contact header
(and History-Info) in the IANA section.  It is introduced in 7.1 and
the usage thereof described in 7.3.4.  [/MB]
>
> 17. Section 5.1:
> "MUST include the header parameter field =A0as a header parameter field
> =A0 associated with the current hi-entry as described in Section 7.3.4."
> Is "current hi-entry" the "new hi-entry" from a couple of sentences earli=
er?
[MB] Yes. Do you have a terminology preference? [/MB]
>
> 18. Section 5.2.1:
> "The last hi-entry reflects the most recent
> =A0 target and MUST contain the Request-URI for the received request,"
> If I interpret this correctly, this is talking about what the UAS receive=
s. What the UAS receives is outside the control of the UAS, so we can't use=
 RFC 2119 language. Should be "will".
[MB] Yep. [/MB]
>
> 19. Section 5.2.1:
> "e.g., the last proxy does
> =A0 not support History-Info"
> In the previous sentence we used the term "previous entity", so it would =
be better to stick to that term rather than "last proxy".
[MB] Okay. [/MB]
>
> 20. Section 5.2.1:
> "hi-index attribute"
> and
> "hi-target attribute"
> Up till now we have called these parameters rather than attributes
[MB] I'll change to parameter [/MB].
>
> 21. Section 5.2.1:
> "The
> =A0 addition of the missing hi-entry ensures that the most complete
> =A0 information can be provided in the response ..."
> Not sure that it is "most complete" - "more complete" would be better, si=
nce there could still be some missing entries from upstream.
[MB] Most complete as "possible" - but I can change to "more". [/MB]
>
> 22. Section 5.2.1:
> "Prior to any application usage of the information, the validity MUST
> =A0 be ascertained"
> What MUST ascertain the validity - the UAS or the application? Use active=
 voice. How does it do this? Is this testable? I don't believe we can use R=
FC2119 language here.
[MB] That is saying that the UAS MUST check that the entries that it
is aware of contain the information that might be needed by an
application (i.e., the last entry, target header field parameters,
etc.). It's testable from a software implementation perspective - not
a protocol perspective.  I can change the MUST to a lower case
recommended .. ie., it is recommended that the UAS...Note, that this
was one of the SHOULDS (from RFC 4244) that folks wanted to change to
MUST.  [/MB]
>
> 23. Section 5.2.2:
> "If the "histinfo" option tag is received in a request, the UAS MUST
> =A0 include any History-Info received in the request in the subsequent
> =A0 response"
> This is incorrect for a B2BUA - a B2BUA should be allowed to use informat=
ion received from its other interface. Also it is not necessarily correct f=
or a regular UAS, since I would have thought a UAS should be required to in=
clude the hi-entry inserted in accordance with 5.2.1, rather than using jus=
t the H-I received.
[MB] We can reword something like the following to capture your concern:

   If the "histinfo" option tag is received in a request, the UAS MUST
   include any History-Info received in the request and any hi-entries
   added by the UAS in the subsequent response.  In addition, in
   the case of a B2BUA, the UAS MAY include any hi-entries
   received by the UAC in a response in the subsequent response
   sent by the UAS.

[/MB]

>
> 24. Section 5.2.2:
> "The processing of History-Info in responses follows the methodology
> =A0 described in Section 16.7 of [RFC3261], "
> We can't refer to 16.7 of RFC 3261, because that is for proxies, not UASs=
.
[MB] See reply in other email response [/MB]
>
> 25. Section 5.3:
> "the redirect server MUST add the appropriate target header
> =A0 field parameter to each Contact header as described in Section 7.3.4.=
"
> I don't think 7.3.4 tells me how to do this. Section 7.3.4 does mention t=
he Contact header field, but only in the context of adding these parameters=
 to the History-Info header field (if I understand correctly).
[MB] 7.3.4 tells you which one to add based upon the mechanism by
which the targets are determined.  The header field parameter is added
based upon the same criteria. [/MB]
>
> 26. Section 6:
> "A Reason MAY be associated with the hi-targeted-to-uri that has been
> =A0 retargeted as shown in the example in Appendix B.1."
> It would be good to be more precise, since B.1 is long - refer to A6, per=
haps.
[MB] Okay. [/MB]
>
> 27. Section 6.1.1:
> "The proxy MUST include an hi-index attribute
> =A0 =A0 =A0with a value of "1""
> It says we are inserting an entry, not replacing any existing entries. Va=
lue "1" will not apply if there is an existing entry.
[MB] Correct. If the prior hop did not include an hi-entry, then one
is added. Even if there are already other hi-entries, there is no way
to know how many hops might have been missed and thus, the indexing
needs to be reset to 1 to reflect such. [/MB]
>
> 28. Section 6.1.1:
> "The proxy MUST add a separate hi-entry in each
> =A0 =A0 =A0separate outgoing request for each of the current (outgoing)
> =A0 =A0 =A0targets in the target set."
> Ambiguous - there should be only one entry per request - not one per targ=
et in each request.
> Perhaps it should say "For each outgoing request relating to a target in =
the target set, the proxy MUST add a single hi-entry identifying that targe=
t. For this new hi-entry, the proxy MUST..."
[MB] Yes - your suggestion is more clear. [/MB]
>
> 29. Section 6.1.2:
> "When re-sending a request as "
> I don't think this is really resending - we are retargeting, and therefor=
e changing some aspects of the original request.
[MB] I'll change to "sending the retargeted request" [/MB]
>
> 30. Section 6.1.2:
> "in the order indicated by the indexing (see
> =A0 =A0 =A0Section 7.3.3)"
> We really need a more precise reference - where in 7.3.3 does it tell me =
how to use the aggregated information?
[MB] 7.3.3. refers to RFC 3261 Step 7
       "Aggregate Authentication Header Field Values", which states:
         "the proxy MUST collect any WWW-
         Authenticate and Proxy-Authenticate header field values from
         all other 401 (Unauthorized) and 407 (Proxy Authentication
         Required) responses received so far in this response context
         and add them to this response without modification before
         forwarding.  "

It's actually easier to just reword that to match what is done for
History-Info header field something like the following:
         The SIP entity MUST collect any History-Info header
         field values from
         all other responses received so far in this response context
         and add them to this response without modification before
         forwarding.
[/MB]


>
> 31. Section 6.1.2:
> "If the received error response did not include
> =A0 =A0 =A0any History-Info header fields, the proxy MUST use the same
> =A0 =A0 =A0History-Info header fields that were sent in the outgoing requ=
est
> =A0 =A0 =A0that failed to build the outgoing request."
> First, the two instances of "outgoing request" are confusing - I think th=
e second should be "new outgoing request" or "retargeted request".
[MB] I'll change to "new outgoing request" since the other request
could also have been retargeted.
> Second, what if some responses include aggregated information and others =
don't?
[MB]  That shouldn't matter.  The receiving entity will use what it
can. If the normative procedures are followed, it's fairly
deterministic as to when the aggregated information should be used.
[/MB]
>
> 32. Section 6.1.2:
> "Same as per Step 2 above for the normal forwarding case
> =A0 =A0 =A0Section 6.1.1."
> This is confusing, because 6.1.1 is not on "normal forwarding case" but o=
n "initial requests".
[MB]  Section 6.1.2. use of "initial" is referring to both the case of
the "initial" hi-entry to be added (bullet 1) AND the case whereby a
Proxy received a request and it is adding the "initial" hi-entry for
the first ("initial") retargeting.  The "normal" forwarding is
specifically bullet #3.  I think it would be clearer if we just
removed the word "initial" from the title and first paragraph and add
an explicit reference to bullet 3. [/MB]
>
> 33. Section 6.1.3:
> "When re-sending a request as "
> Again I don't think "re-sending" is the correct term.
[MB] I'll change to the "generating new requests"  [/MB]
>
> 34. Section 6.1.3:
> " =A0 Step 1: =A0Including Previous Entries
> =A0 =A0 =A0The proxy MUST include the History-Info header fields that wer=
e
> =A0 =A0 =A0sent in the outgoing request that is being redirected."
> This seems to be a significant difference from the 4xx/5xx/6xx case. In t=
hat case we include any hi-entries from downstream entities that have sent =
back the 4xx/5xx/6xx - why not in the 3xx case too?
[MB] See response to issue 25 in your previous set of comments. [/MB]
>
> 35. Section 6.1.3:
> "add a Reason header this
> =A0 =A0 =A0entry"
> Change "this" to "to this".
>
> 36. "MUST forward captured History-Info in subsequent,
> =A0 provisional, and final responses to the request sent by the ultimate
> =A0 UAS (see Section 5.2)"
> If a response does not contain any captured H-I (because the UAS doesn't =
support it), is there any requirement on the proxy to generate it from its =
own information?
[MB] A proxy would have added an hi-entry for the UAS if it follows
the normative procedures in this document. But, there is no way for
the proxy to generate any additional hi-entries (in cases where the
UAS internally retargets or B2BUA case).   [/MB]
>
> 37. Section 7.1:
> "Reason: An optional parameter for History-Info,"
> It is not in the ABNF as a parameter of History-Info - in fact it is an e=
scaped header field.
[MB] Correct - this is a summary of information associated with each
hi-entry and it is described in   as being escaped. Logically, the
information is there. Certainly, it's clear that it's not defined
specifically in the ABNF for the header. [/MB]
>
> 38. Section 7.1:
> "he hi-target is added for a hi-entry when it is
> =A0 =A0 =A0first added in a History-Info header field, and only one value=
 is
> =A0 =A0 =A0permitted"
> I believe it should say "only one parameter is permitted". True that para=
meter ('rc' or 'mp') can have only one value, but I don't think that is the=
 point we are trying to make.
[MB] Correct. [/MB]
>
> 39. Section 7.3.2:
> "If the response contains a Reason header for a protocol
> =A0 that is not SIP (e.g., Q.850), it MUST be captured as an additional
> =A0 Reason associated with the hi-targeted-to-uri that has been
> =A0 retargeted, along with the SIP Response Code"
> I think this is saying that the entity MUST include two Reason parameters=
 in the hi-entry. Perhaps we should state that more explicitly. Also, does =
order matter?
[MB] I can add (i.e., there will be two reason headers), but I figured
when you add "an additional" to one, that it's obvious that there are
two headers. Per RFC  , order does not matter. [/MB]
>
> 40. Section 7.3.3 item 6:
> "When a response is built and it represents the aggregate of
> =A0 =A0 =A0 responses to multiple forks "
> Suddenly we are talking about forks when previously we were talking about=
 branches.
[MB] A branch reflects a fork.  I'll clarify the text  in item 6, such
that it reads:
"the index MUST be captured
       for each forked request, creating a new branch,  per the rules above=
..."
and change the use of forks to branch in the body of item 6.
[/MB]
>
> 41. Section 7.1.3, item 6:
> "For example, if
> =A0 =A0 =A0 a procesing entity received failure responses for forks 1.1.1=
 and
> =A0 =A0 =A0 1.1.2, it would return both the 1.1.1 and 1.1.2 entries to th=
e
> =A0 =A0 =A0 entity that generated the hi-entry with index of 1."
> I can't figure this out - shouldn't "index of 1" be "index of 1.1"?
[MB] No.  The processing entity in that sentence has the index of 1.1.
The processing entity is the subject of that sentence and "it" returns
the response to the entity that would have added the hi-entry with
index of 1.[/MB]
>
> 42. Section 7.1.3, item 6:
> "See
> =A0 =A0 =A0 Appendix B.1 for an example"
> It is unclear where exactly in B.1 I am supposed to look - searching for =
'1.1.1' or '1.1.2' produces no results. Please cite the specific messages.
[MB] Okay. [/MB]
>
> Although I didn't review beyond section 7, I happened to notice the follo=
wing in Appendix B:
> "B. =A0An entity (UA or proxy) retargeting in response to a redirect
> =A0 =A0 =A0 =A0 =A0 or REFER MUST include any Request History information=
 from
> =A0 =A0 =A0 =A0 =A0 the redirect/REFER in the new request."
> It is unclear how you can retarget in response to a REFER. A REFER reques=
ts leads to the generation of a new request - there is no retargeting.
[MB] I'll reword that to reflect that the REFER includes the
History-Information from previous retargets. [/MB]
>
> John
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>