Subject: [dispatch] Fwd: Review of draft-drage-sipping-rfc3455bis-08

From: Mary Barnes <[email-masked]>
Date: Wed, 11 Sep 2013 15:12:57 -0500

Hi all,

The authors of draft-drage-sipping-rfc3455bis-08 have requested the ADs to
sponsor this document. It is a 3GPP dependency and is an update of RFC
3455.  In order to progress the document, the ADs asked for an expert
review.  Dean Willis performed the review detailed below.  The authors will
need to update the document to address the changes.  In addition, we need
to ensure that no one in the DISPATCH WG has concerns with regards to
progressing this document as AD sponsored.  If you do have concerns, please
raise them no later than Wednesday, Oct. 2nd, 2013 5pm Pacific.

Regards,
Mary
DISPATCH WG co-chair

---------- Forwarded message ----------
From: Dean Willis <[email-masked]>
Date: Wed, Sep 11, 2013 at 2:38 PM
Subject: Fwd: Review of draft-drage-sipping-rfc3455bis-08
To: Mary Barnes <[email-masked]>

I've completed a cursory review of draft-drage-sipping-rfc3455bis-08. I
have not validated the ABNF; such validation is needed before submission to
the RFC Editor.

General: This draft is a revision to an existing limited-scope RFC. The
revisions are not controversial, but are primarily small clarifications. I
found nothing major to complain about, but noticed a few nits that can be
readily addressed.

In last sentence of 4.2:

     A SIP proxy MUST NOT insert a P-Called-Party-ID header
     field in the REGISTER requests.

Please remove the "the" before "REGISTER". Explain the MUST. What happens
if they do? Will the registrar reject the request?

Guidance in 4.3.2.1 on SHOULD is lacking. Why? When would this SHOULD
reasonably be violated?

In 4.3.2.3.  Examples of Usage

   Finally, in flow F3, proxy P2 decides to insert his own identifier,
   derived from its own domain name to the P-Visited-Network-ID header
   field.

Note the "his own identifier". How did we determine the masculinity of the
proxy?

4.4.2.2 Proxy behavior

   An outbound proxy MUST remove any P-Access-Network-Info
   header field containing a "network-provided" value.

How does a proxy know it's an outbound proxy? Draft-ietf-sip-outbound? I
think perhaps a clarifying sentence that refers to the edge of the
protection zone referenced in 4.4.1 would help. Alternatively, a
proxy-requires is needed. Note that the whole 4th paragraph here is a bit
fudgy, and doesn't really address the "outbound" question.

Sentence: "A proxy that provides services to the user, is typically located
in the home network, and therefore trusted." This has an extra comma in it
after "user".

referenced in 4.4.1 would help. Alternatively, a proxy-requires is needed.
Note that the whole 4th paragraph here is a bit fudgy, and doesn't reall
yaddress the "outbound" question.

 Sentence: "A proxy that provides services to the user, is typically
located in the home network, and therefore trusted." This has an extra
comma in it after "user".

4.5 The P-Charging Function-Addresses header field

The third paragraph "We define ..." is a bit complex and probably not
consistent in header and header field uses. Of course, this is a global
problem in SIP literature, but is it a header or a header field?

---

From: <[email-masked]>
Date: Fri, 13 Sep 2013 10:25:10 +0200

Hi Mary,
now I have updated the draft with regard to the comments from Dean. More detail please see below.
When I get positive feedback on my proposed changes I will upload the new version on Monday.
I went through a further time and made an additional editorial wrap-up.
There was also identified that the ABNF for the time-zone was not correct. (Correction of ABNF change UE-time-zone to local-time-zone)

Best Regards

Roland

Here are the comments:

In last sentence of 4.2:

Please remove the "the" before "REGISTER". Explain the MUST. What happens if they do? Will the registrar reject the request?
[RJ] OK

Guidance in 4.3.2.1 on SHOULD is lacking. Why? When would this SHOULD reasonably be violated?

[RJ] Comment on 4.3.2.1: A  normal User Equipment has no knowledge of the P-Visited-Network-ID when sending the REGISTER.   This is the task of the first proxy within the visited network. I do not know why Should not instead of must not was taken.

Note the "his own identifier". How did we determine the masculinity of the proxy?
[RJ] OK replaced it by its

4.4.2.2 Proxy behavior

[RJ] changed to:  An proxy sending towards an untrusted entity MUST remove any
           P-Access-Network-Info header field containing a "network-provided"
           value. --> I hope that is OK for all.

How does a proxy know it's an outbound proxy? Draft-ietf-sip-outbound? I think perhaps a clarifying sentence that refers to the edge of the protection zone referenced in 4.4.1 would help. Alternatively, a proxy-requires is needed. Note that the whole 4th paragraph here is a bit fudgy, and doesn't really address the "outbound" question.

[RJ] I hope that this is solved with the proposal above.

Sentence: "A proxy that provides services to the user, is typically located in the home network, and therefore trusted." This has an extra comma in it after "user".

[RJ] OK done

The third paragraph "We define ..." is a bit complex and probably not consistent in header and header field uses. Of course, this is a global problem in SIP literature, but is it a header or a header field?

[RJ] OK fixed. header --> header field

---

From: Dean Willis <[email-masked]>
Date: Fri, 13 Sep 2013 11:07:14 -0500

On Sep 11, 2013, at 3:12 PM, Mary Barnes <[email-masked]> wrote:

> Hi all,
> 
> The authors of draft-drage-sipping-rfc3455bis-08 have requested the ADs to sponsor this document. It is a 3GPP dependency and is an update of RFC 3455.  In order to progress the document, the ADs asked for an expert review.  Dean Willis performed the review detailed below.  The authors will need to update the document to address the changes.  In addition, we need to ensure that no one in the DISPATCH WG has concerns with regards to progressing this document as AD sponsored.  If you do have concerns, please raise them no later than Wednesday, Oct. 2nd, 2013 5pm Pacific.  

I'm terribly sorry, but seem to have had a major cut-and-paste error in the text I sent Mary (actually, I've apparently found a new bug in Chrome OS text editor, which is a new "desktop app").

The full text of my review, with less gibberish, is hopefully here:

Review: draft-drage-sipping-rfc3455bis-08

in last sentence of 4.2

   A SIP proxy MUST NOT insert a P-Called-Party-ID header field in the
   REGISTER requests.

elimnate "the" before "REGISTER". Explain the MUST. What happens if they do? WIll the registrar reject the request?

4.3 Question: What is threat model on spoofing P-Visited-Network-ID?

IN 4.3.2.3.  Examples of Usage

4.4.2.2 Proxy behavior

How does a proxy know it's an outbound proxy? Draft-ietf-sip-outbound? I think perhaps a clarifying sentence that refers to the edge of the protection zone referenced in 4.4.1 would help. Alternatively, a proxy-requires is needed. Note that the whole 4th paragraph here is a bit fudgy, and doesn't reall yaddress the "outbound" question.

4.5 The P-ChargingFunction-Addresses header field

The third paragraph "We define ..." is a bit complex and probably not consistent in header and header field uses. Of course, this is a global problem in SIP literatue, but ...

4.6 The P-Charging-Vector header

In the 9th parapgraph: "When presen only one instance of the header MUST be present in a particular request or response." Probably missing a "t" on "presen".

---

From: Dean Willis <[email-masked]>
Date: Fri, 13 Sep 2013 11:16:44 -0500

> [RJ] Comment on 4.3.2.1: A  normal User Equipment has no knowledge of the P-Visited-Network-ID when sending the REGISTER.   This is the task of the first proxy within the visited network. I do not…

[DW] This is what happens when we try to use requirements language to explain "how things work", instead of using them to describe the LIMITATIONS on how things can be used. RFC 2119 is no substitute for descriptive prose.

I suggest inserting your above explanation, or some close variant thereof, instead of the SHOULD in question.

> [RJ] OK replaced it by its

[DW] That was mostly a tongue-in-cheek comment. I'm struggling to learn Spanish, which has apparently arcane logic for determining the gender of inanimate objects. Proxies might well be masculine in some languages. So I'm actually curious about whether there was a real reason to use "his" here.

>            value. à I hope that is OK for all.
>  

[DW] I think this is supported by the discussion of the sensitivity of network-provided values, so that's probably adequate.

> [RJ] OK fixed. header à header field

[DW] I believe my cut-and-paste error dropped off a small comment on 4.6 

In the 9th parapgraph: "When presen only one instance of the header MUST be present in a particular request or response." Probably missing a "t" on the first "presen".

---

From: <[email-masked]>
Date: Wed, 18 Sep 2013 08:22:21 +0200

Hi Dean,
Thank you for your comments.
I have incorporated everything.
The text in 4.3.2.1 is now.
A normal User Equipment has normally no knowledge of the P-Visited-Network-ID when sending the REGISTER. Therefore user agent clients do not insert a P-Visited-Network-ID header field in any SIP message.

I hope everybody is now happy.
When I receive the last comments I will update the draft and upload it.

Best regards

Roland