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

[Mary Barnes <[e-mail]>]

Hi Roland,

Thanks for your response.  Additional comments below [MB].

Thanks,
Mary.


On Thu, Nov 21, 2013 at 7:21 AM, <[e-mail]> wrote:

> Hi Mary,
>
> Thank you for your review.
>
> I have added now your proposals to the draft.
>
> Other comments please see below.
>
>
>
> I hope now everything is OK.
>
>
>
> Thank you and Best Regards
>
>
>
> Roland
>
>
>
> *Von:* Mary Barnes [mailto:[e-mail]]
> *Gesendet:* Dienstag, 29. Oktober 2013 17:27
> *An:* Jesske, Roland
> *Cc:* DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis
> *Betreff:* PROTO Review: draft-drage-sipping-rfc3455bis-09.txt
>
>
>
> 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.
>
>
>
> [RJ] OK, I have changed the text:
>
> The Third Generation Partnership Project (3GPP) has selected SIP as
>
>      the protocol used to establish and tear down multimedia sessions in
> the
>
>      context of its IP Multimedia Subsystem (IMS). For more information on
>
>      the IMS, a detailed description can be found in 3GPP TS 23.228 . This
> document is an update of RFC3455   which covers the requirements in RFC4083
> and describes updates and adds private extensions to address those
> requirements which are needed in for 3GPP Release 11. Each extension, or
> set of related extensions is described in its own section below
>
[MB] I suggest just a bit more rewording.  Note that I didn't see that this
document is adding any new headers

    The Third Generation Partnership Project (3GPP) uses SIP as

     the protocol  to establish and tear down multimedia sessions in the

     context of its IP Multimedia Subsystem (IMS), as described in

     the 3GPP TS 23.228 specification.

     RFC 3455 defines SIP private header extensions (referred to as
P-headers) which are

     required by the 3GPP specification. Note that the requirements for
these extensions

     are documented in RFC 4083.   This document is an update to RFC3455.

     This document updates existing P-header descriptions

     to address additional requirements which are needed for 3GPP Release
11.

     Each of the P-headers is described in the sections below.

[/MB]


> - 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?
>
>
>
> [RJ] Yes! Changed the text to:
>
>
>
> A void value has no index. By adding the next value the index has to be incremented by the number of void entries +1.
>
>
>
> - 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?
>
>
>
> [RJ] Yes, I have changed the text:
>
> Procedures described within 4.6.2.2 apply. A transit-ioi MAY be
>
>            added or modified by a proxy. A deletion of the transit-ioi or
> a entry within the tranist-ioi could
>
>            appear depending on the network policy and trust rules. This is
>
>            also valid by replacing the transit-ioi with a void value.
>
>
>
>
>
> - 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.
>
>
>
> [RJ] OK
>
>
>
> So I changed 5.7 to “New header”
>
> The P-Associated-URI can appear in SIP REGISTER method and 2xx resonses,
> P-Called-Party-ID can appear in SIP INVITE, OPTIONS, PUBLISH,SUBSCRIBE,
> MESSAGE methods and all responses, P-Visited-Network-ID can appear in all
> SIP methods except ACK, BYE and CANCEL and all responses,
> P-Access-Network-Info can appear in all SIP methods exept ACK and CANCEL,
> P-Charging-Vector  can appear in all SIP methods exept CANCEL and the
> P-Charging-Function-Addresses can appear in all SIP methods exept ACK and
> CANCEL.
>
[MB] I suggest you put each of these in separate sentences - i.e., rather
than use comma separators, use a period.  You should also spell out that
these are header fields - i.e., "The P-Associated-URI header field can
appear....2xx responses.   The P-Called-Party-ID header field....

>
>
>
>
> - Section 6.1: this needs some tighter wording.  What is meant by "potentially annoying"  for example?
>
>
>
> [RJ] I do not know. This is original text. So I deleted the words.
>
>
>
> - 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.
>
>
[MB]  So, I think the first sentence is trying to say: "An eavesdropper
could possibly collect the list of identities a user has registered."
or  "An eavesdropper could possibly collect the list of identities
registered by a user."
[/MB]

> - 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?
>
>
>
> [RJ] Yes that is also my understanding so I deleted that paragraph. I think the rest is sufficient and described well how to behave.
>
>
>
> -- 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?
>
> [RJ] Yes I did some changes as follows.
>
>
>
>         <t>A proxy receiving a message containing the P-Access-Network-Info
>
>        header field from a non-trusted entity is not able to guarantee the
>
>        validity of the contents. Thus this content SHOULD be deleted based on local policy.</t>
>
>
>
> - 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.
>
>
>
> [RJ] OK done. I let the reference RFC4244 since 3GPP uses currently only RFC4244.
>
> Replaced following text:
>
> With section 9.2
>
>        <t>Requirements for a more general solution are proposed in <xref
>
>          target="RFC4244"></xref>. 3GPP will continue to use the
>
>          P-Called-Party-ID header field even though RFC 4244 <xref
>
>          target="RFC4244"></xref> has now been published.</t>
>
>
>
> I think the text in Section 9.2 is better.
>
> *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, <[e-mail]> 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: [e-mail] [mailto:[e-mail]]
> 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
>
>   -
>