Subject: [dispatch] PROTO Review: draft-drage-sipping-rfc3455bis-09.txt

From: Mary Barnes <[email-masked]>
Date: Tue, 29 Oct 2013 11:26:33 -0500

In preparation for the PROTO write-up, I have reviewed the document in
detail.  My detailed review was originally based on the -08, but I also
reviewed the 09 diff.  There are a few errors that have been introduced in
the -09 and many of my -08 comments remain - I've separated comments from
nits below.  A number of these comments are with regards to text that was
not changed from RFC 3455, but I think some of the text requires updating
and we need to keep in mind that this an entirely new IESG that will be
reviewing this document, so they won't have the same context of the IESG
that approved RFC 3455.  I will note that I also have not validated the
content of section 9 against a diff of this document and RFC 3455.  I will
need to do that before I progress the document unless the authors can point
me to another review that has done that.

Regards,
Mary.

Summary:  This document needs some work prior to being progressed.

Comments:
----------------
- Section 1.  I think you should be explicit that these extensions apply
only to a private network - saying they are "generally not applicable" is
too soft, so I would suggest some minor rewording something like:
OLD:

   The SIP extensions specified in this document make certain
   assumptions regarding network topology, linkage between SIP and lower
   layers, and the availability of transitive trust.  These assumptions
   are generally NOT APPLICABLE in the Internet as a whole.

NEW:

   The SIP extensions specified in this document make certain
   assumptions regarding network topology, linkage between SIP and lower
   layers, and the availability of transitive trust.  These assumptions
   apply only to private networks and are not appropriate for use in
an Internet environment.

- Section 3.  This section needs to be updated.  I don't think that 10
year old background is relevant in the current context.   You should
be able to model this after the text in more recent 3GPP P-header
documents, referring to the SIP change process.

- Section 4.1. "registered address-of-record" -> "registered SIP
address-of-record"

- Section 4.1, 3rd paragraph.  "Note that, generally speaking," ->
"Note that in standard SIP usage [RFC3261]"

- Section 4.1.2.3.  I don't think this is stated properly.  I think
the intent is that this header is not applicable to proxies, therefore
the proxy MUST relay the header field unchanged.  I would suggest
rewording something like:

OLD:

   This memo does not define any procedure at the proxy.  The proxy does
   not add, read, modify or delete the header field, and therefore any
   proxy will relay this header field unchanged.

NEW:

   This header is not intended to be used by proxies - a proxy does
   not add, read, modify or delete the header field, and therefore any
   proxy MUST relay this header field unchanged.

Section 4.2, 1st paragraph.  The behavior in this sentence is not
normative from a SIP protocol perspective, thus MAY is not
appropriate.  I suggest the MAY be changed to "can".

   The UAS MAY use the information to render different distinctive
audiovisual alerting
   tones, depending on the URI used to receive the invitation to the
   session.

Section 4.2.2.2, 2nd paragraph.  The behavior in this sentence is not
normative from a SIP protocol perspective, thus  I suggest the MAY be
changed to "can".

- Section 4.3.3, last paragraph.  I think this ought to be a MUST:
"The identifier should be globally unique.."

- Section 4.3.2.1.  This text has changed from the -08.   I don't know
what a "normal User Equipment" is and the term "User Equipment" is not
defined in this specification.  I think it would be better to say
something like. However, even with this proposed change, I think you
also need text for user agent server behavior - i.e., what would a UAS
do if it received this header.

OLD:

   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.

NEW:

   In the context of the network to which the header fields defined in
this document apply, a User Agent has no knowledge of the
P-Visited-Network-ID when sending the REGISTER request.  Therefore
user agent clients MUST NOT insert a P-Visited-Network-ID header field
in any SIP message.

- Section 4.3.2.2:, 2nd paragraph:  "home network MAY use" -> "home
network can use"

- Section 4.3.2.2, last paragraph:

OLD: Note that a received P-Visited-Network-ID from a UA is a failure
case and must be deleted.

NEW:  Note that a received P-Visited-Network-ID from a UA is a failure
case and MUST be deleted when the request is forwarded.

Section 4.4.2.1, 2nd paragraph:  "MUST trust the proxy" -> "MUST have
a trust relationship with the proxy"

Section 4.4.2.1, 3rd paragraph:  "there must also be a transitive
trust" ->  "there MUST also be a transitive trust"

Section 4.4.2.2, 2nd paragraph: "MAY act upon any information present"
-> "can act upon any information present",  "MAY use the call id" ->
"can use the call id"

Section 4.5.2: 2nd paragraph: "MAY use the hostnames" -> "can use the
hostnames"

Section 4.5.2.1 2nd paragraph: "MAY use the contents" -> "can use the contents"

- Section 4.6.2, 3rd paragraph: "MAY use the values" -> "can use the values"

- Section 4.6.3, 3rd paragraph: needs some editorial work.  Maybe the
following change would work:

OLD:

   Depending on the call scenario it is needed to add for each transit
   network either a transit network name or a void value.  Nevertheless
   it can not be guaranteed that all values will appear within the
P-Charging-Vector header field.

NEW:

   Depending on the call scenario, each transit network can add either
a transit network name or a void    value.  However, it can not be
guaranteed that all the values that are added will appear within the
P-Charging-Vector header field.

- Section 4.6.3, next to last paragraph: "which needs to be
incremented" -> "which MUST be incremented"

- Section 4.6.3, last paragraph.  I have no idea what that is trying
to say other than void values have no index.  What does "taken into
consideration" mean. Are you talking about limits on the number of
entries or are you suggesting that the number of void values must be
considered when setting the index for the transit network names?

- Section 4.6.4.2: I don't know what this means:  "A deletion of the
elements could appear depending on the network policy and trust
rules".  Is it just trying to say that along with the adding and
modifying in the previous sentence that the elements can also be
deleted by the proxy?

- Section 5.7. Delete this text and table.   We aren't these tables
anymore as they really don't provide any useful information.  You just
need to verbally state what messages these headers can appear in.

- Section 6.1: this needs some tighter wording.  What is meant by
"potentially annoying"  for example?

- Section 6.2: I think you need to be more specific about the "nature"
that makes this header not of particular concern with regards to
security. Does it reveal additional, unique information about an
individual that isn't available in other headers.  Also, the 2nd
paragraph needs some work - maybe something like:

OLD:

An eavesdropper may collect the list of identities a user is
registered.  This may have privacy implications.  To mitigate this
problem, this extension SHOULD only be used in a secured environment,
where encryption of SIP messages is provided either end-to-end or
hop-by-hop.

NEW:

 An eavesdropper could possibly collect the list of identities a user
is registered.  This can have privacy implications.  To mitigate this
problem, this extension MUST only be used in a secured environment,
where encryption of SIP messages is provided either end-to-end or
hop-by-hop.

- Section 6.4,

--3rd paragraph: "should not" -> "MUST NOT"

-- 7th paragraph:  "SHOULD NOT be sent" -> "MUST NOT be sent"

-- 8th paragraph: "SHOULD NOT send sensitive information" -> "MUST NOT
send sensitive information"

-- 9th paragraph: "is required to delete" -> "is REQUIRED to delete"

-- 10th paragraph:  How does a network ensure the information is not
of a sensitive nature?   I would think that the information just
should not be sent outside of the trust domain.  I believe that's
consistent with the scope of these headers, is it not?

-- 11th paragraph: So, what does a proxy do with that information.
What are the implications if the information is used and it's not
valid?

- Section 9, item 2.  I think you need to add this text with regards
to the recommendation to use RFC 4244 (bis) to the body of this
document and include a real reference.

*Nits:*

- Section 4.1, 2nd paragraph.  "has associated to an
address-of-record" -> "has associated with an address-of-record"

- Section 4.1.2.2, 2nd paragraph, "In case" -> "If",  "shall not" -> SHALL NOT

- Section 4.3.2.2, last sentence.  The -09 introduced a typo: "T
means" -> "This means"

- Section 4.3.2.3, 1st paragraph after 1st example.  The -09
introduced another typo: "the REGISTRAR" -> "at the REGISTRAR"

Section 4.2.2.1, 3rd paragraph:  "there must also be a transitive
trust" ->  "there MUST also be a transitive trust"

Section 4.6, 2nd paragraph: "includes, includes but is not limited to"
-> "includes, but is not limited to,"

Section 4.6.2.2, 1st paragraph: "one ore more" -> "one or more"

On Tue, Oct 8, 2013 at 11:58 AM, <[email-masked]> wrote:

> Dear all,
> I would like to inform you that I have implemented all comments coming
> from the expert review done by Dean Willis. Also an editorial cleanup was
> made.
>
> If there are still some comments that needs to be implemented please
> inform me.
>
> From my side I would be happy to proceed the draft further towards
> publication.
>
> Thank you and Best Regards
>
> Roland
>
>
> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]
> Gesendet: Dienstag, 8. Oktober 2013 13:40
> An: Christer Holmberg; Keith Drage; Jesske, Roland
> Betreff: New Version Notification for draft-drage-sipping-rfc3455bis-09.txt
>
>
> A new version of I-D, draft-drage-sipping-rfc3455bis-09.txt
> has been successfully submitted by Keith Drage and posted to the IETF
> repository.
>
> Filename:        draft-drage-sipping-rfc3455bis
> Revision:        09
> Title:           Private Header (P-Header) Extensions to the Session
> Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)
> Creation date:   2013-10-08
> Group:           Individual Submission
> Number of pages: 47
> URL:
> http://www.ietf.org/internet-drafts/draft-drage-sipping-rfc3455bis-09.txt
> Status:
> http://datatracker.ietf.org/doc/draft-drage-sipping-rfc3455bis
> Htmlized:
> http://tools.ietf.org/html/draft-drage-sipping-rfc3455bis-09
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-drage-sipping-rfc3455bis-09
>
> Abstract:
>    This document describes a set of private Session Initiation Protocol
>    (SIP) header fields (P-headers) used by the 3rd-Generation
>    Partnership Project (3GPP), along with their applicability, which is
>    limited to particular environments.  The P-header fields are for a
>    variety of purposes within the networks that the partners use,
>    including charging and information about the networks a call
>    traverses.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> The IETF Secretariat
>
>   -