Subject: [SIP] draft-garcia-sip-visited-network-id-03

From: Tan Ya-Ching ICM N PG U ID A 1 <[email-masked]>
Date: Wed, 5 Jun 2002 11:14:10 +0200

Hi,

Some comments on the latest version of the draft:

- Throughout the draft, it is stated that the network 
  identification takes the form of a quoted text string. 
  But the ABNF in Section 4 shows that it can also be 
  a token.

- This is a repeated comment:
  Section 4, the paragraph after the example
  "a SIP proxy may insert a new P-Visited-Network-ID header
   if the request does not contain a P-Visited-Network-ID
   header with the same network identifier as its own network
   identifier".
  However, Table 2 of SIP shows that proxy cannot "r"ead
  the header. You explained in your email that the header may
  be encrypted and so cannot be read, but that is not clear to
  the readers of the draft.

- Section 4, 2nd paragraph after the example:
  "a proxy in a visited network that does not maintain
   registration state MAY insert a P-Visited-Network_ID
   header into any standalone request outside a dialog or
   a request that create a dialog".
  This is the only place where the requirement that the
  proxy 'does not maintain registration state' is mentioned.
  If this is a requirement, it should be mentioned and
  explained in Section 5.2

- The last sentence of the same paragraph:
  "At the time of writing this document, the only requests
  that create dialogs are INVITE and SUBSCRIBE". In fact,
  [9] states that "REFERs occurring outside an existing
  dialog effectively create a new dialog".

- The term 'a standalone request outside a dialog' should
  be avoided. Instead of repeating 'in a REGISTER request,
  a standalone request outside a dialog (e.g., MESSAGE), 
  or a request that initiates a dialog', can't we just refer to
  them as 'the requests indicated in Table 2' ?

- Why is the OPTIONS requested excluded ? Is it not a
  standalone request outside a dialog?

- As OPTIONS requests do not carry this header, it is
  possible that an OPTIONS request used to determine
  whether the UAS will accept an INVITE request gets
  positive response but an identical INVITE gets rejected
  due to failure in authorization of the INVITE based on
  the contents of the P-Visited-Network-ID. Is this not in
  violation of RFC 3261? 11.2 of RFC 3261 Processing 
  of OPTIONS request states that "The response code 
  chosen MUST be the same that would have been 
  chosen had the request been an INVITE".

- Section 5.2
  The closing bracket ")" after MESSAGE[8] is missing.

- The last paragraph of 5.2
  "A home proxy MUST delete this header when
  forwarding the message outside the home network
  domain...". Does this include forwarding the request
  to a user who is within the home network?

- In the References section, it is better to name just
  the authors and title of the drafts, not the file names
  including the version numbers. Otherwise, [9] would
  have to be updated to version 5.

Thanks,
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: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 05 Jun 2002 13:23:43 +0300

Ya-Ching:

Thanks for your comments. See my answer below.

>   But the ABNF in Section 4 shows that it can also be

Fixed throught the document.

>   the readers of the draft.

I am adding this new paragraph to explain thesituation:

Note also that, there is not requirement for the header to be readable in the proxies. Therefore, a first proxy may insert an encrypted header that only the registrar can decrypt. If the request traverses another proxy (e.g., a second proxy) located in the same administrative domain as the first proxy, the second proxy will not be able to read the contents of the P-Visited-Network-ID header. In this situation, the second proxy will consider that its visited network identifier is not already present in the value of the header, and therefore, it will insert a new P-Visited-Network-ID header value (hopefully with the same visited network identifier). When the request arrives at the registrar, it will notice that the header value is repeated (both the first and the second proxy inserted it). The decrypted values should be the same, because both proxies where part of the same administrative domain. While this situation is not desirable, it does not create any harm at the registra!
r.

>   If this is a requirement, it should be mentioned and

Well, this is not a requirement. You forgot to include the first
to words of the sentence: "For instance, ". This means that it
is only an example, where a proxy that does not keep any registration
state is inserting the header in an INVITE.

What I have done is to replace the MAY with a "may", as it is
just an example.

>   dialog effectively create a new dialog".

Good point. I'll fix it.

>   them as 'the requests indicated in Table 2' ?

But you will agree with me that I can't do this change until
the table is introduce. That leaves only one place to change,
in section 5.2.

>   standalone request outside a dialog?

I fixed it.

>   chosen had the request been an INVITE".

So, allowing the header in an OPTINS will solve the
problem. As I said, it was a typo and now it is fixed.

>   The closing bracket ")" after MESSAGE[8] is missing.

Now it is gone with a reference to the table.

>   to a user who is within the home network?

I added this text:

A home proxy SHOULD delete this header, even when the request is not forwarded outside the home network administrative domain, when the home proxy has used the contents of the header or the request is routed based on the called party.

>   have to be updated to version 5.

It is updated to version 5. I prefer, though, to name the
file names, in order to facilitate the search.

Thanks a lot for your comments. Keep tuned to -04 that will
include your comments.

/Miguel

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 7 Jun 2002 13:14:43 -0400

----- Original Message -----
From: "Miguel A. Garcia" <[email-masked]>
> Note also that, there is not requirement for the header to be readable in
the
> proxies. Therefore, a first proxy may insert an encrypted header that only
the
> registrar can decrypt. If the request traverses another proxy (e.g., a
second proxy)
> located in the same administrative domain as the first proxy, the second
proxy will
> not be able to read the contents of the P-Visited-Network-ID header. In
this
> situation, the second proxy will consider that its visited network
identifier is not
> already present in the value of the header, and therefore, it will insert
a new P-
> Visited-Network-ID header value (hopefully with the same visited network
identifier).
> When the request arrives at the registrar, it will notice that the header
value is
> repeated (both the first and the second proxy inserted it). The decrypted
values
> should be the same, because both proxies where part of the same
administrative
> domain. While this situation is not desirable, it does not create any harm
at the
> registrar.
You probably need to use the term "intermediary", as pure proxies would not
be allowed to modify the message body and thus could not add a body with the
excrypted header.

Are you suggesting that there will be intermediaries in the network that
will add an encrypted S/MIME "sip/message" body? If that is not the case,
only the UA would encrypt the header, but the UA is not allowed to insert
the header.

cheers,
(-:bob