Subject: [Sip] Comments on draft-garcia-sip-visited-network-id-01

From: Tan Ya-Ching ICM N PG U ID A 1 <[email-masked]>
Date: Fri, 24 May 2002 19:00:48 +0200

Hi,

 - General
   The term 'standalone request'  or 'standalone transaction
   request' is used throughout the document. Please define
   what it means.

 - 3rd paragraph of Section 1
   "... it seems sensitive..." should be "... it seems sensible..."

 - Section 2, point 3 "There is not requirement that..." should
   be "There is no requirement that ...", and at the end of the
   sentence, "in this memo" should be "in this document".

- Section 4
  Please delete the 1st sentence "The P-Visited-Network-ID
  is an extension of a SIP header", or replace it with "This
  specification defines a new header field.

- 1st paragraph on page 4
  "..., a SIP node may insert a new P-Visited-Network-ID header,
  if there was already one present with different contents" is
  misleading. I think you meant :
  "..., a proxy MAY insert a new P-Visited-Network-ID header
  if the request does not contain any P-Visited-Network-ID header
  with the same network identifier as its own network identifier".

  Delete the "a vairous" in "...a various different administrative 
  domains"

- The addition to Table 2 in Section 4
  A "r" should be added to the "ad" under proxy. Proxies must
  be able to read this header.

- Section 5.1
  "The UA SHOULD NOT insert" should be "MUST NOT insert".
  I think the result can be disastrous if a UA inserts one.

- Section 5.2
  Replace "the contents of a provisioned string" with just "a text
  string" and delete the "at the user's home domain" at the end.
  Otherwise it reads like "identifies ...the proxy is operating
  at the user's home network", where it is not.

- 10.2
  draft-sipping-garcia-3gpp-req-03 should be
  draft-garcia-sipping-3gpp-req-03 instead. This same error
  is also in the called party id draft.

Regards,
Ya-Ching

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Tan Ya-Ching ICM N PG U ID A 1 <[email-masked]>
Date: Mon, 27 May 2002 10:42:42 +0200

Hi Miguel,

| > - The addition to Table 2 in Section 4
| >   A "r" should be added to the "ad" under proxy. Proxies must
| >   be able to read this header.
| > 
| 
| <miguel> Ummm... not sure. If a proxy decides to encrypt this 
| header, so that only the registrar or proxy at home is able to
| read it, it will not make any negative effect to other proxies
| in the path. The only negative effect is that these proxies in
| the middle will not be able to read the contents, so they will
| not know if the same visited network ID was already present or
| not. But it does not introduce any problem. 
| </miguel>

If P-Visited-Network_ID header cannot be read by proxy, I fail to see the
point of this header.

If the draft states that "... a SIP node (I think you mean proxy here) may
insert a new P-Visited-Network-ID header, if there was already one present
with different contents...", then you have to state what happens if the
content is encrypted and the proxy cannot see the contents. You can't just
say 'But it does not introduce any problem'.

| 
| <miguel>
| What I wanted to express, is a scenario where a proxy in a visited
| network is using different strings to identify his own network
| at different home networks. So, for example, proxy P1 receives
| a request addressed to network N1; P1 inserts VNID1. The same proxy
| P1 receives a request addressed to network N2; it may decide to
| insert VNID2. This VNID is known between both networks, so from
| the point of view of the protocol I don't see why we should limit
| it here.
| </miguel>

OK. Now I get it.

Regards,
Ya-Ching