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

From: <[email-masked]>
Date: Thu, 2 Jan 2014 10:29:59 +0100

Hi Mary,
I wish you a happy new year 2014. And the best for the next year.

I was looking again on my changes I made due to your proposal in December.
I realized that if I change the SHOULD to MUST we have now a backward compatibility problem.
We are using the P-Associated-URI also over the IMS user interface which is not encrypted.
So I propose to add some more words.
...
Section 6.1
...
         <t>An eavesdropper could possibly collect the list of identities a user is registered.
       This can 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.  </t>

      <t> Since the P-Associated-URI header field value allows to implicitly register
      a bundle of URIs with one REGISTER Message the impact of security using the P-Associated-URI header field is not higher than
      using single REGISTER messages when registering all identities explicit.</t>

For the P-Called-Party-Id the change should be also done like as follows:

        <t>An eavesdropper could possibly collect the list of identities a user is registered.
       This can 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.  </t>

        <t>Normally within a 3GPP environment the P-Called-Party-ID is not sent towards end users but may be exchanged between carriers where other security mechanisms than SIP encryption are used.  </t>

Sorry coming so late.
If this is OK for you I will include it to a new version.

Thank you and Best Regards

Roland

Von: Mary Barnes [mailto:[email-masked]]
Gesendet: Freitag, 27. Dezember 2013 19:45
An: Jesske, Roland
Cc: DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis
Betreff: Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt

Hi Roland,

Thanks for making these changes. I finally had a chance to review this updated version.   I still have a couple comments on the security section as I think you will get questions during SEC review around this unless some more detail is provided on security threats and impacts.   I've extracted these few points from previous review comment threads.

Thanks,
Mary.

----Previous point  --------------------------------->

- 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.

-

[MB] So, you removed that part of the sentence and are left with:

"This attack should not have any significant impacts."

I don't think that adds any value and just begs the question "what are the insignificant impacts and are there any privacy concerns"?  Really, it's the next paragraph that provides details of the impacts.  I think you could probably remove that sentence altogether and not lose anything.

[/MB]

----Previous point --------------------------------->

-  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.

----End previous point ------------------------------<

[MB]  The suggested change for the first sentence didn't get into the revision.  And, I believe you still need to identify privacy/security implications by addressing whether or not this header reveals any unique information about an individual that isn't available in other headers.   [/MB]

On Tue, Dec 3, 2013 at 7:00 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Mary,
Thank you for your comments and proposals.
I have now included all comments and uploaded a new version.
So we can now proceed.

Thank you and Best Regards

Roland

A new version of I-D, draft-drage-sipping-rfc3455bis-10.txt

has been successfully submitted by Roland Jesske and posted to the IETF repository.

Filename:   draft-drage-sipping-rfc3455bis

Revision:   10

Title:            Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)

Creation date:    2013-12-03

Group:            Individual Submission

Number of pages: 46

URL:             http://www.ietf.org/internet-drafts/draft-drage-sipping-rfc3455bis-10.txt

Status:          http://datatracker.ietf.org/doc/draft-drage-sipping-rfc3455bis

Htmlized:        http://tools.ietf.org/html/draft-drage-sipping-rfc3455bis-10

Diff:            http://www.ietf.org/rfcdiff?url2=draft-drage-sipping-rfc3455bis-10

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.

Von: Mary Barnes [mailto:[email-masked]<mailto:[email-masked]>]
Gesendet: Montag, 25. November 2013 23:01

An: Jesske, Roland
Cc: DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis
Betreff: Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt

Hi Roland,

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

Thanks,
Mary.

On Thu, Nov 21, 2013 at 7:21 AM, <[email-masked]<mailto:[email-masked]>> 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:[email-masked]<mailto:[email-masked]>]
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<http://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<http://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, <[email-masked]<mailto:[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]> [mailto:[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<http://tools.ietf.org>.

The IETF Secretariat
  -

---

From: Atle Monrad <[email-masked]>
Date: Mon, 6 Jan 2014 08:19:05 +0000

Mary

I hope that you are OK with Rolands clarifications for a new version of the draft.

Hopefully this version can then be progressed. It contains all 3GPP-additions since RFC 3455 upto & including 3GPP-Rel-11

Thanks
/atle

________________________________

Atle Monrad
3GPP CT Chairman

Group Function Technology - Standardization and Technical Regulation
Ericsson

From: [email-masked] [mailto:[email-masked]]
Sent: 2. januar 2014 10:30
To: [email-masked]
Cc: [email-masked]; Gonzalo Camarillo; Atle Monrad; [email-masked]
Subject: AW: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt

Hi Mary,

Sorry coming so late.

Roland

Hi Roland,

Thanks,
Mary.

-

[/MB]

OLD:

hop-by-hop.

NEW:

Roland

Revision:   10

Number of pages: 46

Abstract:

   traverses.

An: Jesske, Roland

Hi Roland,

Thanks,
Mary.

Roland

Regards,
Mary.

Comments:
----------------

NEW:

[/MB]

OLD:

NEW:

   session.

OLD:

NEW:

OLD:

NEW:

[RJ] OK

OLD:

hop-by-hop.

NEW:

- Section 6.4,

Replaced following text:

With section 9.2

Nits:

Roland

-----Ursprüngliche Nachricht-----
Von: [email-masked]<mailto:[email-masked]> [mailto:[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

Abstract:

The IETF Secretariat
  -

---

From: Mary Barnes <[email-masked]>
Date: Mon, 6 Jan 2014 13:00:09 -0600

Hi Roland,

One final editorial nit below.  If you can spin a revision, then I'll send
the PROTO write-up to the AD.

Thanks,
Mary.

On Thu, Jan 2, 2014 at 3:29 AM, <[email-masked]> wrote:

> …
> …
>       a bundle of URIs with one REGISTER Message the impact of security
> using the P-Associated-URI header field is not higher than
>
[MB] I just have some editorial suggestions for the above:
NEW:

<t> While the P-Associated-URI header field value allows the implicit
registration of

      a bundle of URIs with one REGISTER Message the impact of security
using the P-Associated-URI header field is no higher than

      using separate REGISTER messages for each of the URIs. </t>

[/MB]

>         <t>Normally within a 3GPP environment the P-Called-Party-ID is
> not sent towards end users but may be exchanged between carriers where
> other security mechanisms than SIP encryption are used.  </t>
>
>
>
> Sorry coming so late.
>
> *Von:* Mary Barnes [mailto:[email-masked]]
> *Gesendet:* Freitag, 27. Dezember 2013 19:45
>
> *An:* Jesske, Roland
> *Cc:* DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis
> *Betreff:* Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt
>
>
>
> Hi Roland,
>
>
>
> Thanks for making these changes. I finally had a chance to review this
> updated version.   I still have a couple comments on the security section
> as I think you will get questions during SEC review around this unless some
> more detail is provided on security threats and impacts.   I've extracted
> these few points from previous review comment threads.
>
>
>
> Thanks,
>
> Mary.
>
>
>
>  *[*RJ] I do not know. This is original text. So I deleted the words.
>
> -
>
> On Tue, Dec 3, 2013 at 7:00 AM, <[email-masked]> wrote:
>
> Hi Mary,
>
> Title:            Private Header (P-Header) Extensions to the Session
> Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)
>
> URL:
> http://www.ietf.org/internet-drafts/draft-drage-sipping-rfc3455bis-10.txt
>
> Status:
> http://datatracker.ietf.org/doc/draft-drage-sipping-rfc3455bis
>
> Htmlized:
> http://tools.ietf.org/html/draft-drage-sipping-rfc3455bis-10
>
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-drage-sipping-rfc3455bis-10
>
>
>
> Abstract:
>
> *Von:* Mary Barnes [mailto:[email-masked]]
> *Gesendet:* Montag, 25. November 2013 23:01
>
>
> *An:* Jesske, Roland
> *Cc:* DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis
>
> *Betreff:* Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt
>
>
>
> Hi Roland,
>
>
>
> On Thu, Nov 21, 2013 at 7:21 AM, <[email-masked]> wrote:
>
> Hi Mary,
>
> *Von:* Mary Barnes [mailto:[email-masked]]
> *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.
>
>
>
> - 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 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
>
> - Section 4.3.2.2:, 2nd paragraph:  "home network MAY use" -> "home network can use"
>
>
>
>
>
> - 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?
>
>
>
> 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....
>
>
>
>
>
> [MB]  So, I think the first sentence is trying to say: "An eavesdropper
> could possibly collect the list of identities a user has registered."
>
> *Nits:*
> 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.
>
> Von: [email-masked] [mailto:[email-masked]]
> Title:           Private Header (P-Header) Extensions to the Session
> Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)
> 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:
> 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
>
>   -
>
>
>
>
>

---

From: <[email-masked]>
Date: Tue, 7 Jan 2014 07:35:30 +0100

Hi Mary,
Now a new revision is available.

Roland

Von: Mary Barnes [mailto:[email-masked]]
Gesendet: Montag, 6. Januar 2014 20:00
An: Jesske, Roland
Cc: DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis
Betreff: Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt

Hi Roland,

One final editorial nit below.  If you can spin a revision, then I'll send the PROTO write-up to the AD.

Thanks,
Mary.

On Thu, Jan 2, 2014 at 3:29 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Mary,
I wish you a happy new year 2014. And the best for the next year.

      <t> Since the P-Associated-URI header field value allows to implicitly register
      a bundle of URIs with one REGISTER Message the impact of security using the P-Associated-URI header field is not higher than
      using single REGISTER messages when registering all identities explicit.</t>
[MB] I just have some editorial suggestions for the above:
NEW:
<t> While the P-Associated-URI header field value allows the implicit registration of
      a bundle of URIs with one REGISTER Message the impact of security using the P-Associated-URI header field is no higher than
      using separate REGISTER messages for each of the URIs. </t>
[/MB]

Sorry coming so late.

Roland

An: Jesske, Roland

Hi Roland,

Thanks,
Mary.

-

[/MB]

OLD:

hop-by-hop.

NEW:

Roland

Revision:   10

Number of pages: 46

Abstract:

   traverses.

An: Jesske, Roland

Hi Roland,

Thanks,
Mary.

Roland

Regards,
Mary.

Comments:
----------------

NEW:

[/MB]

OLD:

NEW:

   session.

OLD:

NEW:

OLD:

NEW:

[RJ] OK

OLD:

hop-by-hop.

NEW:

- Section 6.4,

Replaced following text:

With section 9.2

Nits:

Roland

-----Ursprüngliche Nachricht-----
Von: [email-masked]<mailto:[email-masked]> [mailto:[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

Abstract:

The IETF Secretariat
  -

---

From: Mary Barnes <[email-masked]>
Date: Tue, 7 Jan 2014 11:54:33 -0600

Thanks Roland.  I have reviewed that version and all the changes I
suggested have been made.  However, in doing the PROTO write-up I realized
that I wasn't certain anyone had reviewed the ABNF. So, I ran the ABNF
through Bill Fenner's tool:
http://tools.ietf.org/tools/bap/abnf.cgi

And, there are a couple things that need to be fixed:
1)  DOT needs to change to "." (we had this same bug in RFC 4244):
transit-ioi-indexed-value = transit-ioi-name DOT transit-ioi-index

2)  There's an extra space here (between * and parenthesis):
transit-ioi-name = ALPHA * (ALPHA / DIGIT)
NEw: transit-ioi-name = ALPHA *(ALPHA / DIGIT)

There are also a number of long lines in the ABNF that should be fixed.

In addition, IDNITS identifies other errors and warnings per the following.
 Those should also be addressed including considering whether obsolete
references need changing:

idnits 2.13.01

tmp/draft-drage-sipping-rfc3455bis-11.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** There are 9 instances of too long lines in the document, the longest one
     being 20 characters in excess of 72.

  == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the
     document.

  == There are 4 instances of lines with non-RFC5735-compliant IPv4 addresses
     in the document.  If these are example addresses, they should be changed.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The document seems to contain a disclaimer for pre-RFC5378 work, but was
     first submitted on or after 10 November 2008.  The disclaimer is usually
     necessary only for documents that revise or obsolete older RFCs, and that
     take significant amounts of text from those RFCs.  If you can contact all
     authors of the source material and they are willing to grant the BCP78
     rights to the IETF Trust, you can and should remove the disclaimer.
     Otherwise, the disclaimer is needed and you can ignore this comment.
     (See the Legal Provisions document at
     http://trustee.ietf.org/license-info for more information.)

  Checking references for intended status: Informational
  ----------------------------------------------------------------------------

  == Missing Reference: 'RFC XXXX' is mentioned on line 1667, but not defined

  -- Looks like a reference, but probably isn't: '3' on line 1948

  == Unused Reference: 'RFC2976' is defined on line 2065, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC3262' is defined on line 2068, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC3311' is defined on line 2075, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC3428' is defined on line 2081, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC3903' is defined on line 2093, but no explicit
     reference was found in the text

  ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234)

  -- Obsolete informational reference (is this intentional?): RFC 2976
     (Obsoleted by RFC 6086)

  -- Obsolete informational reference (is this intentional?): RFC 3265
     (Obsoleted by RFC 6665)

     Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

While I apologize for not catching these issues earlier, it really is the
responsibility of authors to check idnits (beyond what the submission tool
requires) for their documents.  I routinely run idnits before I submit a
document as it can also save time when fixing the  nits that the submission
tool catches:   https://tools.ietf.org/tools/idnits/

Regards,
Mary.

On Tue, Jan 7, 2014 at 12:35 AM, <[email-masked]> wrote:

> *Gesendet:* Montag, 6. Januar 2014 20:00
>
> *An:* Jesske, Roland

---

From: <[email-masked]>
Date: Wed, 8 Jan 2014 09:46:29 +0100

Thank you Marry,
for doing all this review.
So I have now put out the errors.
There are still some unused references which are in our informal reference section. But useful for the reader to know they exist.
There are also some warnings with regard to IP addresses and wrong FQDNs which I think is some interpretation of strings in the text which are not meant to be a IP address or FQDN at all.

Detail see below.

So now hopefully everything is ready for the next step.

Best Regards

Roland

tmp/draft-drage-sipping-rfc3455bis-12.txt:

     No issues found here.

     No issues found here.

  Miscellaneous warnings:

     No issues found here.

  == Missing Reference: 'RFC XXXX' is mentioned on line 1662, but not defined

  -- Looks like a reference, but probably isn't: '3' on line 1943

  == Unused Reference: 'RFC3311' is defined on line 2072, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC3428' is defined on line 2078, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC3903' is defined on line 2090, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC6086' is defined on line 2101, but no explicit
     reference was found in the text

     Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.
--------------------------------------------------------------------------------

Von: Mary Barnes [mailto:[email-masked]]
Gesendet: Dienstag, 7. Januar 2014 18:55
An: Jesske, Roland
Cc: DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis
Betreff: Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt

Thanks Roland.  I have reviewed that version and all the changes I suggested have been made.  However, in doing the PROTO write-up I realized that I wasn't certain anyone had reviewed the ABNF. So, I ran the ABNF through Bill Fenner's tool:
http://tools.ietf.org/tools/bap/abnf.cgi

In addition, IDNITS identifies other errors and warnings per the following.  Those should also be addressed including considering whether obsolete references need changing:

idnits 2.13.01

     No issues found here.

     No issues found here.

     document.

  Miscellaneous warnings:

     (Obsoleted by RFC 6086)

     (Obsoleted by RFC 6665)

     the items above.
While I apologize for not catching these issues earlier, it really is the responsibility of authors to check idnits (beyond what the submission tool requires) for their documents.  I routinely run idnits before I submit a document as it can also save time when fixing the  nits that the submission tool catches:   https://tools.ietf.org/tools/idnits/

Regards,
Mary.

On Tue, Jan 7, 2014 at 12:35 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Mary,
Now a new revision is available.

Roland

An: Jesske, Roland

Hi Roland,

Thanks,
Mary.

Sorry coming so late.

Roland

An: Jesske, Roland

Hi Roland,

Thanks,
Mary.

-

[/MB]

OLD:

hop-by-hop.

NEW:

Roland

Revision:   10

Number of pages: 46

Abstract:

   traverses.

An: Jesske, Roland

Hi Roland,

Thanks,
Mary.

Roland

Regards,
Mary.

Comments:
----------------

NEW:

[/MB]

OLD:

NEW:

   session.

OLD:

NEW:

OLD:

NEW:

[RJ] OK

OLD:

hop-by-hop.

NEW:

- Section 6.4,

Replaced following text:

With section 9.2

Nits:

Roland

-----Ursprüngliche Nachricht-----
Von: [email-masked]<mailto:[email-masked]> [mailto:[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

Abstract:

The IETF Secretariat
  -

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 08 Jan 2014 10:45:44 -0500

On 1/8/14 3:46 AM, [email-masked] wrote:
> There are still some unused references which are in our informal
> reference section. But useful for the reader to know they exist.

You could avoid the error by adding a bit of text that simply notes that 
these might provide useful context for the reader. Then the references 
will be referenced.

	Thanks,
	Paul

> There are also some warnings with regard to IP addresses and wrong FQDNs
> which I think is some interpretation of strings in the text which are
> not meant to be a IP address or FQDN at all.
>
> Detail see below.
>
>    Checking nits according to
> http://www.ietf.org/id-info/1id-guidelines.txt:
>
>
> *Von:*Mary Barnes [mailto:[email-masked]]
> *Gesendet:* Dienstag, 7. Januar 2014 18:55
> *An:* Jesske, Roland
> suggested have been made.  However, in doing the PROTO write-up I
> realized that I wasn't certain anyone had reviewed the ABNF. So, I ran
> the ABNF through Bill Fenner's tool:
>
> In addition, IDNITS identifies other errors and warnings per the
> following.  Those should also be addressed including considering whether
> obsolete references need changing:
>
>
>
> idnits 2.13.01
>
>
>
>    Checking nits according tohttp://www.ietf.org/id-info/1id-guidelines.txt:
>
>    Checking nits according tohttp://www.ietf.org/id-info/checklist  :
>
> While I apologize for not catching these issues earlier, it really is
> the responsibility of authors to check idnits (beyond what the
> submission tool requires) for their documents.  I routinely run idnits
> before I submit a document as it can also save time when fixing the
>   nits that the submission tool catches:
> https://tools.ietf.org/tools/idnits/
>
> Regards,
>
> Mary.
>
> *Von:*Mary Barnes [mailto:[email-masked]
> <mailto:[email-masked]>]
>     <t>Normally within a 3GPP environment the P-Called-Party-ID is not
>     sent towards end users but may be exchanged between carriers where
>     *Von:*Mary Barnes [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     Thanks for making these changes. I finally had a chance to review
>     this updated version.   I still have a couple comments on the
>     security section as I think you will get questions during SEC review
>     around this unless some more detail is provided on security threats
>     and impacts.   I've extracted these few points from previous review
>     comment threads.
>
>     Thanks,
>
>     Mary.
>
>       _[_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:
>
>
>
>
>
>     Title:            Private Header (P-Header) Extensions to the
>     Session Initiation Protocol (SIP) for the 3rd-Generation Partnership
>     Project (3GPP)
>
>     *Von:*Mary Barnes [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *Von:*Mary Barnes [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     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.
>
>     - 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 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
>
>         - Section4.3.2.2  <http://4.3.2.2>:, 2nd paragraph:  "home network MAY use" -> "home network can use"
>
>
>
>
>
>
>
>
>
>         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.2, 2nd paragraph: "MAY act upon any information present" -> "can act upon any information present",  "MAY use the call id" -> "can use thecall id"
>
>         - Section4.6.4.2  <http://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?
>
>
>
>                     added or modified by a proxy. A deletion of the
>         transit-ioi or a entry within the tranist-ioi could
>
>         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....
>
>
>
>
>
>     [MB]  So, I think the first sentence is trying to say: "An
>     eavesdropper could possibly collect the list of identities a user
>     has registered."
>
>         -- 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?
>
>         _Nits:_
>         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.
>
>         Von: [email-masked] <mailto:[email-masked]>
>         [mailto:[email-masked] <mailto:[email-masked]>]
>         Title:           Private Header (P-Header) Extensions to the
>         Session Initiation Protocol (SIP) for the 3rd-Generation
>         Partnership Project (3GPP)
>         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 <http://tools.ietf.org>.
>
>         The IETF Secretariat
>
>            -
>
>
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Mary Barnes <[email-masked]>
Date: Wed, 8 Jan 2014 10:06:38 -0600

On Wed, Jan 8, 2014 at 9:45 AM, Paul Kyzivat <[email-masked]> wrote:

> these might provide useful context for the reader. Then the references will
> be referenced.
>
>         Thanks,
>         Paul
>

[MB] I agree. Otherwise, you will still be dealing with this when the RFC
Editor gets the document as one of the things they will do is to remove
unused references. [/MB]

>>     I don't think that adds any value and just begs the question "what
>> are the insignificant impacts and are there any privacy concerns"?  Really,
>> it's the next paragraph that provides details of the impacts.  I think you
>> could probably remove that sentence altogether and not lose anything.
>>
>>
>>
>>
>>
>>     [/MB]
>>
>>
>>
>>     -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]  The suggested change for the first sentence didn't get into the
>> revision.  And, I believe you still need to identify privacy/security
>> implications by addressing whether or not this header reveals any unique
>> information about an individual that isn't available in other headers.
>> [/MB]
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>     - 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, 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:
>>
>>         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".
>>
>>         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:
>>
>>             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.
>>
>>
>>
>>         - Section4.3.2.2  <http://4.3.2.2>:, 2nd paragraph:  "home
>> network MAY use" -> "home network can use"
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>         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 thecall id"
>>
>>
>>             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?
>>
>>
>>
>>         A void value has no index. By adding the next value the index has
>> to be incremented by the number of void entries +1.
>>
>>
>>
>>         - Section4.6.4.2  <http://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.
>>
>>
>>
>>         [RJ] OK
>>
>>
>>
>>         - 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.
>>
>>         -- 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?
>>
>>
>>         - 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.
>>
>>
>>
>>         - Section 4.1, 2nd paragraph.  "has associated to an
>> address-of-record" -> "has associated with an address-of-record"
>>
>>         - 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,"
>>
>>
>>
>>         [mailto:[email-masked] <mailto:[email-masked]
>> >]
>>

---

From: Mary Barnes <[email-masked]>
Date: Fri, 10 Jan 2014 13:34:45 -0600

IN addition to removing the unused references in the next update, there are
still 4 domain names that are not using an appropriate documentation domain
(e.g., home.net).  Please add that change to the list for the next
revision.  I'm going to ahead and forward the PROTO write-up to Gonzalo,
noting the changes that are needed and suggesting those changes can be made
along with other IETF LC changes.

Thanks,
Mary

On Wed, Jan 8, 2014 at 2:46 AM, <[email-masked]> wrote:

> There are still some unused references which are in our informal reference
> section. But useful for the reader to know they exist.
>
> which I think is some interpretation of strings in the text which are not
> meant to be a IP address or FQDN at all.
>
>
>
> Detail see below.
>
>
>

---

From: Mary Barnes <[email-masked]>
Date: Fri, 10 Jan 2014 13:37:48 -0600

There is yet one more change needed.  This document is an Updates to
3455bis (AFAIK, unless Obseletes works better for 3GPP usage).  That
categorization needs to be included in the document header (3rd line).

Thanks,
Mary.

On Fri, Jan 10, 2014 at 1:34 PM, Mary Barnes <[email-masked]>wrote:

> IN addition to removing the unused references in the next update, there
> are still 4 domain names that are not using an appropriate documentation
> domain (e.g., home.net).  Please add that change to the list for the next
>>      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

---

From: Andrew Allen <[email-masked]>
Date: Fri, 10 Jan 2014 19:45:04 +0000

I think it obsoletes RFC 3455. It is a complete replacement for the original.

Andrew

From: Mary Barnes [mailto:[email-masked]]
Sent: Friday, January 10, 2014 02:37 PM Eastern Standard Time
To: [email-masked] <[email-masked]>
Cc: DISPATCH <[email-masked]>; Dean Willis <[email-masked]>
Subject: Re: [dispatch] PROTO Review: draft-drage-sipping-rfc3455bis-09.txt

There is yet one more change needed.  This document is an Updates to 3455bis (AFAIK, unless Obseletes works better for 3GPP usage).  That categorization needs to be included in the document header (3rd line).

Thanks,
Mary.

On Fri, Jan 10, 2014 at 1:34 PM, Mary Barnes <[email-masked]<mailto:[email-masked]>> wrote:
IN addition to removing the unused references in the next update, there are still 4 domain names that are not using an appropriate documentation domain (e.g., home.net<http://home.net>).  Please add that change to the list for the next revision.  I'm going to ahead and forward the PROTO write-up to Gonzalo, noting the changes that are needed and suggesting those changes can be made along with other IETF LC changes.

Thanks,
Mary

On Wed, Jan 8, 2014 at 2:46 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Thank you Marry,

Detail see below.

Best Regards

Roland

     No issues found here.

     No issues found here.

  Miscellaneous warnings:

     No issues found here.

An: Jesske, Roland

idnits 2.13.01

     No issues found here.

     No issues found here.

     document.

  Miscellaneous warnings:

     (Obsoleted by RFC 6086)

     (Obsoleted by RFC 6665)

     the items above.

Regards,
Mary.

Roland

An: Jesske, Roland

Hi Roland,

Thanks,
Mary.

Sorry coming so late.

Roland

An: Jesske, Roland

Hi Roland,

Thanks,
Mary.

-

[/MB]

OLD:

hop-by-hop.

NEW:

Roland

Revision:   10

Number of pages: 46

Abstract:

   traverses.

An: Jesske, Roland

Hi Roland,

Thanks,
Mary.

Roland

Regards,
Mary.

Comments:
----------------

NEW:

[/MB]

OLD:

NEW:

   session.

OLD:

NEW:

OLD:

NEW:

[RJ] OK

OLD:

hop-by-hop.

NEW:

- Section 6.4,

Replaced following text:

With section 9.2

Nits:

Roland

-----Ursprüngliche Nachricht-----
Von: [email-masked]<mailto:[email-masked]> [mailto:[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

Abstract:

The IETF Secretariat
  -

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Mary Barnes <[email-masked]>
Date: Fri, 10 Jan 2014 13:48:26 -0600

Thanks Andrew.  So, that needs to be clearly stated in the abstract as
well.  In addition, the Overview section states:
"This document is an update to RFC3455".  So that also needs to be fixed.
Given the number of changes at this point, I would now prefer Roland make
those changes before we ask Gonzalo to progress it to IETF LC.

Mary.

On Fri, Jan 10, 2014 at 1:45 PM, Andrew Allen <[email-masked]> wrote:

>  *From*: Mary Barnes [mailto:[email-masked]]
> *Sent*: Friday, January 10, 2014 02:37 PM Eastern Standard Time
> *To*: [email-masked] <[email-masked]>
> *Cc*: DISPATCH <[email-masked]>; Dean Willis <[email-masked]>
>
> *Subject*: Re: [dispatch] PROTO Review:
> draft-drage-sipping-rfc3455bis-09.txt
>
>> domain (e.g., home.net).  Please add that change to the list for the
>> next revision.  I'm going to ahead and forward the PROTO write-up to
>> Gonzalo, noting the changes that are needed and suggesting those changes
>> can be made along with other IETF LC changes.
>>
>>  Thanks,
>> Mary
>>
>>
>>> the responsibility of authors to check idnits (beyond what the submission
>>> tool requires) for their documents.  I routinely run idnits before I submit
>>> a document as it can also save time when fixing the  nits that the
>>> submission tool catches:   https://tools.ietf.org/tools/idnits/
>>>
>>>
>>>
>>> Regards,
>>>
>>> Mary.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 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
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
>

---

From: <[email-masked]>
Date: Wed, 15 Jan 2014 08:54:18 +0100

Hi Mary,
Version -13 is uploaded. (http://www.ietf.org/internet-drafts/draft-drage-sipping-rfc3455bis-13.txt )
I hope I have covered everything now.
-RFC references not used deleted.
-FQDN corrected
-statement that RFC3455 is obsolete included in Head and Abstract

Best Regards

Roland

Von: Mary Barnes [mailto:[email-masked]]
Gesendet: Freitag, 10. Januar 2014 20:48
An: Andrew Allen
Cc: Jesske, Roland; [email-masked]; [email-masked]
Betreff: Re: [dispatch] PROTO Review: draft-drage-sipping-rfc3455bis-09.txt

Thanks Andrew.  So, that needs to be clearly stated in the abstract as well.  In addition, the Overview section states:
"This document is an update to RFC3455".  So that also needs to be fixed.   Given the number of changes at this point, I would now prefer Roland make those changes before we ask Gonzalo to progress it to IETF LC.

Mary.

On Fri, Jan 10, 2014 at 1:45 PM, Andrew Allen <[email-masked]<mailto:[email-masked]>> wrote:

Andrew

From: Mary Barnes [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, January 10, 2014 02:37 PM Eastern Standard Time
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: DISPATCH <[email-masked]<mailto:[email-masked]>>; Dean Willis <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dispatch] PROTO Review: draft-drage-sipping-rfc3455bis-09.txt

Thanks,
Mary.

Thanks,
Mary

Detail see below.

Best Regards

Roland

     No issues found here.

     No issues found here.

  Miscellaneous warnings:

     No issues found here.

An: Jesske, Roland

idnits 2.13.01

     No issues found here.

     No issues found here.

     document.

  Miscellaneous warnings:

     (Obsoleted by RFC 6086)

     (Obsoleted by RFC 6665)

     the items above.

Regards,
Mary.

Roland

An: Jesske, Roland

Hi Roland,

Thanks,
Mary.

Sorry coming so late.

Roland

An: Jesske, Roland

Hi Roland,

Thanks,
Mary.

-

[/MB]

OLD:

hop-by-hop.

NEW:

Roland

Revision:   10

Number of pages: 46

Abstract:

   traverses.

An: Jesske, Roland

Hi Roland,

Thanks,
Mary.

Roland

Regards,
Mary.

Comments:
----------------

NEW:

[/MB]

OLD:

NEW:

   session.

OLD:

NEW:

OLD:

NEW:

[RJ] OK

OLD:

hop-by-hop.

NEW:

- Section 6.4,

Replaced following text:

With section 9.2

Nits:

Roland

-----Ursprüngliche Nachricht-----
Von: [email-masked]<mailto:[email-masked]> [mailto:[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

Abstract:

The IETF Secretariat
  -

---

From: Mary Barnes <[email-masked]>
Date: Thu, 16 Jan 2014 09:27:28 -0600

Roland,

Thank you for making these changes and fixing additional nits.  There are
still a couple of things, but I'll go ahead and note those in the PROTO
write-up and I believe these can be changed with any other LC comments.
 Note, that some of these comments relate to things that idnits has
identified:
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-drage-sipping-rfc3455bis-13.txt

It really does save you grief to run a doc through idnits before you submit
- the nits checked
by the submission tool are the bare minimum and the submission tool does
not block submission for a number of other nits.   Please keep this in mind
when you make changes based on IETF LC comments.

Thanks,
Mary.

1) Abstract:   This document is an update to RFC3455. ->  This
document obsoletes RFC 3455.

2) There are still quite a few domain names in the examples in this
document that are not using the domain names that are specified to be
used in examples in RFCs per RFC 2606 - e.g. home1.net -> example.net,
visited.net, etc.  It think the tool did not catch all of these as
some are embedded in SIP URIs, etc.

3) As idnits points out, there are still some IP addresses that don't
follow the rules in terms of those to be used in examples in
documentation per RFC 5735.

On Wed, Jan 15, 2014 at 1:54 AM, <[email-masked]> wrote:

> Hi Mary,
>
> Version -13 is uploaded. (
> http://www.ietf.org/internet-drafts/draft-drage-sipping-rfc3455bis-13.txt
> )
>
> *Gesendet:* Freitag, 10. Januar 2014 20:48
> *An:* Andrew Allen
> *Cc:* Jesske, Roland; [email-masked]; [email-masked]
> *Betreff:* Re: [dispatch] PROTO Review: