=A0=A0 The SIP exten=
sions specified in this document make certain
<=
span style=3D'color:black'>=A0=A0 assumptions regarding network topology, l=
inkage between SIP and lower
=A0=A0 layers, and the availability of transitive trust.=A0 These=
 assumptions
=A0=A0=
 are generally NOT APPLICABLE in the Internet as a whole. 

=A0=A0 assumptions regarding network topology, linkage between SIP and =
lower
=A0=A0 layers=
, and the availability of transitive trust.=A0 These assumptions=

=A0=A0 apply only to private =
networks and are not appropriate for use in an Internet environment.

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

[RJ] OK, I ha=
ve changed the text:
- Section 4.1. "regi=
stered address-of-record" -> "registered SIP address-of-record=
"
- Section 4.1, 3rd paragraph.  =
;"Note that, generally speaking," -> "Note that in standa=
rd 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 somethin=
g like:
OLD: 
=A0=A0 This=
 memo does not define any procedure at the proxy.=A0 The proxy does
=A0=A0 not add, read, modi=
fy or delete the header field, and therefore any
NEW:
 =

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

Section 4.2, 1st paragr=
aph.  The behavior in this sentence is not normative from a SIP protoc=
ol perspective, thus MAY is not appropriate.  I suggest the MAY be cha=
nged to "can".   
=A0=A0 The UAS MAY use the information to re=
nder different distinctive audiovisual alerting
=A0=A0 session.
Sect=
ion 4.2.2.2, 2nd paragraph.  The behavior in this sentence is not norm=
ative from a SIP protocol perspective, thus  I suggest the MAY be chan=
ged to "can". =

- Section 4.3.3, last pa=
ragraph.  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 t=
he term "User Equipment" is not defined in this specification. &n=
bsp;I think it would be better to say something like. However, even with th=
is proposed change, I think you also need text for user agent server behavi=
or - i.e., what would a UAS do if it received this header. 

OLD:=A0=A0 A normal User Equipment has normally no knowledge of t=
he P-Visited-
=A0=
=A0 Network-ID when sending the REGISTER.=A0 Therefore user agent clients
=A0=A0 do not insert=
 a P-Visited-Network-ID header field in any SIP message.<=
/pre>NEW: 
=A0=A0 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 re=
quest.  Therefore user agent clients MUST NOT insert a P-Visited-Netwo=
rk-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 r=
eceived P-Visited-Network-ID from a UA is a failure case and MUST be delete=
d when the request is forwarded. 
&nb=
sp;
Section 4.4.2.1, 2nd paragraph:  "MUST trust the p=
roxy" -> "MUST have a trust relationship with the proxy"&=
nbsp;
=

Section 4.4.2.1, 3rd paragraph:  "there mu=
st also be a transitive trust" ->  "there MUST also be a =
transitive trust" <=
/span>
Section 4.4.2.2, 2nd paragraph: "M=
AY act upon any information present" -> "can act upon any info=
rmation present",  "MAY use the call id" -> "ca=
n use the call=
 id" 
=
Section 4.5.2: 2nd paragra=
ph: "MAY use the hostnames" -> "can use the hostnames&quo=
t; 
&n=
bsp;
Secti=
on 4.5.2.1 2nd paragraph: "MAY use the contents" -> "can =
use the contents" 
- Sectio=
n 4.6.2, 3rd paragraph: "MAY use the values" -> "can use =
the values" 
- Section 4.6.3, 3r=
d paragraph: needs some editorial work.  Maybe the following change wo=
uld work: 
=

OLD:
=A0=A0 Depending on the call scenar=
io it is needed to add for each transit
=A0=A0 network either a transit network name or a void=
 value. =A0Nevertheless
=A0=A0 it can not be guaranteed that all values will appear within the=
 P-Charging-Vector header field. 
NEW=
: 
&nb=
sp;
=A0=A0 Depending on the call scenario, each transi=
t network can add either a transit network name or a void=A0=A0=A0 val=
ue.=A0 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, ne=
xt to last paragraph: "which needs to be incremented" -> =
"which MUST be incremented"<=
o:p>

- 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 limi=
ts on the number of entries or are you suggesting that the number of void v=
alues must be considered when setting the index for the transit network nam=
es?  
 [RJ] Yes! Changed the text to:<=
/pre> 
A void =
value has no index. By adding the next value the index has to be incremente=
d by the number of void entries +1.
 <=
/span>
- Section 4.6.4.2: I don't know what thi=
s means:  "A deletion of the elements could appear depending on th=
e network policy and trust rules".  Is it just trying to say that along with the add=
ing and modifying in the previous sentence that the elements can also be de=
leted by the proxy? 

[RJ] Yes, I have changed the text:=
=
Procedures described within 4.6.2.2 apply. A transit-io=
i MAY be
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 added or modified =
by a proxy. A deletion of the transit-ioi or a entry within the tranist-ioi=
 could
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 appear depending on =
the network policy and trust rules. This is
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 also valid by replacing the t=
ransit-ioi with a void value.

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

[RJ] OK
 <=
/o:p>
So I changed 5.7 to “New h=
eader”
The P-Associated-URI can appear in SIP REGISTER method and 2=
xx resonses, P-Called-Party-ID can appear in SIP INVITE, OPTIONS, PUBLISH,S=
UBSCRIBE, MESSAGE methods and all responses, P-Visited-Network-ID can appea=
r 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-Chargin=
g-Vector=A0 can appear in all SIP methods exept CANCEL and the P-Charging-F=
unction-Addresses can appear in all SIP methods exept ACK and CANCEL.<=
/o:p>

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

[RJ] I do not know. =
This is original text. So I deleted the words.
 <=
/pre>- 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 re=
veal additional, unique information about an individual that isn't availabl=
e in other headers.  Also, the 2nd paragraph needs some work - maybe s=
omething like:

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

hop-=
by-hop. 
=A0  
NEW:&=
nbsp;

 An eavesdropper could possibly collect the=
 list of identities a user is registered.=A0 This can have privacy implicat=
ions.=A0 To mitigate this problem, this extension MUST only be used in a se=
cured environment, where encryption of SIP messages is provided either end-=
to-end or hop-by-hop. 
 - Section 6.4, 
--3rd p=
aragraph: "should not" -> "MUST NOT" 

-- 7th paragraph:  =
;"SHOULD NOT be sent" -> "MUST NOT be sent" 
 <=
/pre>-- 8th paragraph=
: "SHOULD NOT send sensitive information" -> "MUST NOT se=
nd sensitive information"

-- 9th paragraph: "is required to delete" -> =
"is REQUIRED to delete" 
=
-- 10th paragraph:  How does a network ensure the information is not o=
f 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 i=
s also my understanding so I deleted that paragraph. I think the rest is su=
fficient and described well how to behave.

-- 11t=
h paragraph: So, what does a proxy do with that information.  <=
span style=3D'font-family:"Arial","sans-serif"'>What are the implications i=
f the information is used and it's not valid?  [RJ] Yes I did some changes as follows.

=A0=A0=A0=
=A0=A0=A0=A0 <t>A proxy receiving a message containing the P-Access-N=
etwork-Info
=A0=A0=A0=A0=A0=A0 header field from a non-tru=
sted entity is not able to guarantee the
=A0=A0=A0=A0=A0=A0 validity of the contents. Thus this content =
SHOULD be deleted based on local policy.</t><=
pre> 
- Section 9,=
 item 2.  I think you need to add this text with regards to the recomm=
endation to use RFC 4244 (bis) to the body of this document and include a r=
eal reference.

[RJ] OK done. I let th=
e reference RFC4244 since 3GPP uses currently only RFC4244. 
Replaced following text:
With section 9.2
=A0=A0=A0=A0=A0=A0 <t>Requirements for a more g=
eneral solution are proposed in <xref
=A0=A0=A0=A0=A0=A0=A0=A0 target=3D"RFC4244"><=
/xref>. 3GPP will continue to use the
=A0=A0=A0=A0=A0=A0=A0=A0 P-Called-Party-ID header field even =
though RFC 4244 <xref
=
=A0=A0=A0=A0=A0=A0=A0=A0 target=3D"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" -&g=
t; "has associated with an address-of-record"
- Section 4.1.2.2, 2nd paragraph, "In case" -> &quo=
t;If",  "shall not" -> SHALL NOT
- Section 4.3.2.2, last sentence.  The -09 introduced a typo:=
 "T means" -> "This means" 
<=
o:p> 
- S=
ection 4.3.2.3, 1st paragraph after 1st example.  The -09 introduced a=
nother typo: "the REGISTRAR" -> "at the REGISTRAR"

Section 4.2.2.1, 3rd paragraph:  "there must als=
o be a transitive trust" ->  "there MUST also be a transi=
tive trust" =

Section 4.6, 2nd paragraph: "in=
cludes, includes but is not limited to" -> "includes, but is n=
ot limited to," 

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

=A0=A0 The SIP=
 extensions specified in this document make certain=A0=A0 assumptions regarding network topology, linkage between =
SIP and lower
=A0=A0 layers, and=
 the availability of transitive trust.=A0 These assumptions
=A0=A0 are generally NOT APPLICABLE in the Internet as a w=
hole. 
=A0
=A0
=A0=A0 assumptions regarding network topology, linkage bet=
ween SIP and lower
=A0=A0 layers=
, and the availability of transitive trust.=A0 These assumptions<=
/u>
=A0=A0 apply only to private networks and are not appropri=
ate for use in an=A0Internet environment.
=A0=

- Section 3. =A0This section needs to be updated. =A0I don't thin=
k that 10 year old background is relevant in the current context. =A0 You s=
hould be able to model this after the text in more recent 3GPP P-header doc=
uments, referring to the SIP change process.=A0
=A0
[RJ] OK, I have changed the text:
- Section 4.1. "registered address-of-rec=
ord" -> "registered SIP address-of-record"<=
u>
- Section 4.1, 3rd paragraph. =A0"Note that, generally speaking,=
" -> "Note that in standard SIP usage [RFC3261]"
- Section 4.1.2.3. =A0I don't think this is stated properly. =A0I=
 think the intent is that this header is not applicable to proxies, therefo=
re the proxy MUST relay the header field unchanged. =A0I would suggest rewo=
rding something like:
OLD:=A0
=A0=A0 This memo does not define any procedure at the proxy.=
=A0 The proxy does
=A0=A0 not add, read, modify or delete the header field, a=
nd therefore any
=A0=A0 proxy wi=
ll relay this header field unchanged.
NEW:=A0=A0=A0 This header is not intended to be used by proxi=
es - a proxy does
=A0=A0 not add, read, modify or delete the header field, a=
nd therefore any
=A0=A0 proxy MU=
ST relay this header field unchanged.
Section 4.=
2, 1st paragraph. =A0The behavior in this sentence is not normative from a =
SIP protocol perspective, thus MAY is not appropriate. =A0I suggest the MAY=
 be changed to "can". =A0=A0
=A0=A0=
 The UAS MAY use the information to render different distinctive audiovisua=
l alerting
=A0=A0 tones, dependi=
ng on the URI used to receive the invitation to the
=A0=A0 session.
Section 4.2.2.2, 2nd paragraph. =A0The behavior in this sentence =
is not normative from a SIP protocol perspective, thus =A0I suggest the MAY=
 be changed to "can".=A0<=
/pre>
=A0
- Section 4.3.3, last paragraph. =A0I thi=
nk this ought to be a MUST: "The identifier should be globally unique.=
."=A0
=A0
- Section 4.3.2.1. =A0This text has chang=
ed from the -08. =A0 I don't know what a "normal User Equipment&qu=
ot; is and the term "User Equipment" is not defined in this speci=
fication. =A0I think it would be better to say something like. However, eve=
n with this proposed change, I think you also need text for user agent serv=
er behavior - i.e., what would a UAS do if it received this header.=A0
=A0
OLD:
=A0=A0 A normal =
User Equipment has normally no knowledge of the P-Visited-
=A0=A0 Network-ID when sending the REGISTER.=A0 Therefore =
user agent clients
=A0=A0 do not=
 insert a P-Visited-Network-ID header field in any SIP message.

NEW:=A0
=A0=A0 In the context of the network to which the header field=
s defined in this document apply, a User Agent has=A0no knowledge of the P-=
Visited-Network-ID when sending the REGISTER request. =A0Therefore user age=
nt clients MUST NOT insert a P-Visited-Network-ID=A0header field=A0in any S=
IP message.
=A0
- Section 4.3.2.2:, 2nd paragraph: =A0"home network MAY use&qu=
ot; -> "home network can use"

- Section 4.3.2.2=
, last paragraph: =A0
=A0
OLD: Note that a received P-Visited-Net=
work-ID from a UA is a failure case and must be deleted.
=A0
N=
EW: =A0Note that a received P-Visited-Network-ID from a =
UA is a failure case and MUST be deleted when the request is forwarded. =

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

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

Section 4.4.2.2, 2nd paragraph: "MAY act upo=
n any information present" -> "can act upon any information pr=
esent", =A0"MAY use the call id" -> "can use the=A0<=
/span>call id"=A0<=
u>
Section 4.5.2: 2nd paragraph: "MAY use the hostnames" ->=
 "can use the hostnames"=A0
=A0
Se=
ction 4.5.2.1 2nd paragraph: "MAY use the contents" -> "c=
an use the=A0contents"=A0
- Section 4.6.2, 3rd paragraph=
: "MAY use the values" -> "can use the values"=A0
- Section 4.6.3, 3rd paragr=
aph: needs some editorial work. =A0Maybe the following change would work:=
=A0
=A0
OLD:
=A0=A0 Depending=
 on the call scenario it is needed to add for each transit
=A0=A0 network either a transit network name or a void val=
ue. =A0Nevertheless
=A0=A0 it ca=
n not be guaranteed that all values will appear within the P-Charging-Vecto=
r header field.=A0
NEW:=A0
=A0
=A0=A0 Depending on the call scenario, each transit netwo=
rk can add either a transit network name=A0or a void=A0=A0=A0 value.=A0 How=
ever, it can not be guaranteed that all the values that are added will appe=
ar within the P-Charging-Vector header field.
=A0
- Section 4.6.3, next=
 to last paragraph:=A0"which needs to be incremented" -> "=
;which MUST be incremented"=

=A0
=
- Section 4.6.3, last paragraph. =A0I have no idea what that is trying to s=
ay other than void values have no index. =A0What does "taken into cons=
ideration" mean. Are you talking about limits on the number of entries=
 or are you suggesting that the number of void values must be considered wh=
en setting the index for the transit network names? =A0
=A0
[RJ] Yes! Changed the text to:
=A0
A void value has no index. By a=
dding the next value the index has to be incremented by the number of void =
entries +1.
=A0- Section 4.6.4.2: I d=
on't know what this means:=A0=A0"A deletion of the elements could appear d=
epending on the network policy and trust rules". =A0Is it just trying to say that along with =
the adding and modifying in the previous sentence that the elements can als=
o be deleted by the proxy?=A0
=A0
[RJ] Yes, I have changed the text:
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 also valid by re=
placing the transit-ioi with a void value.
=A0
=A0
- Section 5.7=
. Delete this text and table. =A0 We aren't these tables anymore as the=
y really don't provide any useful information. =A0You just need to verb=
ally state what messages these headers can appear in.=A0
=A0
[RJ] OK
=A0
So =
I changed 5.7 to =93New header=94
=A0
=A0
- Section 6.1=
: this needs some tighter wording. =A0What is meant by "potentially an=
noying" =A0for example? =A0
=A0
[RJ] I do not know. This is original text. So I deleted the words.=

=
=A0
- Section 6.2: I think you need to be more specific about the "na=
ture" that makes this header not of particular concern with regards to=
 security. Does it reveal additional, unique information about an individua=
l that isn't available in other headers. =A0Also, the 2nd paragraph nee=
ds some work - maybe something like:
=A0
OLD:
An eavesdropper =
may collect the list of identities a user is registered.=A0 This may have p=
rivacy implications.=A0 To mitigate this problem, this extension SHOULD onl=
y be used in a secured environment, where encryption of SIP messages is pro=
vided either end-to-end or

hop-by-hop.=A0
=A0 =A0
NEW:=A0
=A0
=A0An eavesdropper cou=
ld possibly collect the list of identities a user is registered.=A0 This ca=
n have privacy implications.=A0 To mitigate this problem, this extension MU=
ST only be used in a secured environment, where encryption of SIP messages =
is provided either end-to-end or hop-by-hop.=A0

- Section 6.4,=A0
-=
-3rd paragraph: "should not" -> "MUST NOT"=A0=

=A0
-- 7th paragraph: =A0"SHOULD NOT be =
sent" -> "MUST NOT be sent"=A0
=A0
--=
 8th paragraph: "SHOULD NOT send sensitive information" -> &qu=
ot;MUST NOT send sensitive information"
--=
 9th paragraph: "is required to delete" -> "is REQUIRED t=
o delete"=A0
-- 10th paragraph: =A0How does=
 a network ensure the information is not of a sensitive nature? =A0 I would=
 think that the information just should not be sent outside of the trust do=
main. =A0I believe that's consistent with the scope of these headers, i=
s it not?
=A0
[RJ] Yes that is also my understanding so I deleted that paragraph. I thi=
nk the rest is sufficient and described well how to behave.
=A0-- 11th paragraph: So, what does a proxy do with that=
 information. =A0What a=
re the implications if the information is used and it's not valid? =A0<=
u>

[RJ] Yes I did some changes as follows.
=A0
=A0=A0=A0=A0=A0=A0 validity of the contents. Th=
us this content SHOULD be deleted based on local policy.</t>
=A0
=A0
[RJ] OK done. I let the reference RFC4244 si=
nce 3GPP uses currently only RFC4244. 
Replaced following text:With section 9.2
=A0=A0=A0=A0=A0=A0 <t>Requirements for a =
more general solution are proposed in <xref
=A0=A0=A0=A0=A0=A0=A0=A0 target=3D"RFC4244&q=
uot;></xref>. 3GPP will continue to use the
=A0=A0=A0=A0=A0=A0=A0=A0 P-Called-Party-ID head=
er field even though RFC 4244 <xref
=A0=A0=A0=A0=A0=A0=A0=A0 target=3D"RFC4244">=
</xref> has now been published.</t>
=A0
I think the text in Section 9.2 is better.
Ni=
ts:
- Section =
4.1, 2nd paragraph. =A0"has associated to an address-of-record" -=
> "has associated with an address-of-record"
- Section 4.1.2.2, 2nd parag=
raph, "In case" -> "If", =A0"shall not" -&=
gt; SHALL NOT
- Section 4.3.2.2, last sentence. =A0The -09 int=
roduced a typo: "T means" -> "This means"=A0<=
span style>
=A0
-=
 Section 4.3.2.3, 1st paragraph after 1st example. =A0The -09 introduced an=
other typo: "the REGISTRAR" -> "at the REGISTRAR"
=A0
Section 4.2.2.1, 3rd paragraph: =A0"there must also=
 be a transitive trust" -> =A0"there MUST also be a transitive=
 trust"=A0
=A0
Section 4.6, 2nd paragraph: "includes, includes but=
 is not limited to" -> "includes, but is not limited to,"=
=A0
=A0
Section 4.6.2.2, 1st paragraph: "one ore more"=
 -> "one or more"=A0
=A0
=A0
=A0=