[Sipping] Expert review of draft-andreasen-sipping-rfc3603bis

["Miguel A. Garcia" <[e-mail]>]

Draft:
http://tools.ietf.org/html/draft-andreasen-sipping-rfc3603bis-05
Reviewer: Miguel Garcia <[e-mail]>
Review Date: 2008-10-28
Review Deadline:
Status: Expert Review

Review Summary: This draft is basically ready for publication, but has 
nits that should be fixed before publication.


Expert Evaluation (per RFC 3427):
---------------------------------
     1.  A designated expert (as defined in RFC 2434 [4]) MUST review the
         proposal for applicability to SIP and conformance to these
         guidelines.  The Expert Reviewer will send email to the Transport
         Area Directors on this determination.  The expert reviewer can
         cite one or more of the guidelines that haven't been followed in
         his/her opinion.

I am the designated expert.

     2.  The proposed extension MUST NOT define SIP option tags, response
         codes, or methods.

The extension defines new header fields, but not option tags, response 
codes, or methods.

     3.  The function of the proposed header MUST NOT overlap with current
         or planned chartered extensions.

Note that this draft is a revision of RFC 3603 originally published in 
October 2003. There is a historical overlap: the P-DCS-Redirect header 
overlaps with the History-Info header specified in RFC 4244. It is 
understandable that this overlap has historical reasons: the original 
P-DCS-Redirect came to existence before History-Info. For backward 
compatibility reasons with existing implementations, the P-DCS-Redirect 
header has to exist. Perhaps the draft should include a note 
acknowledging this overlap and providing a motivation for its existence.

Other than that, there are no overlaps with current or planned chartered 
extensions.

     4.  The proposed header MUST be of a purely informational nature, and
         MUST NOT significantly change the behavior of SIP entities which
         support it.  Headers which merely provide additional information
         pertinent to a request or a response are acceptable.  If the
         headers redefine or contradict normative behavior defined in
         standards track SIP specifications, that is what is meant by
         significantly different behavior.

The defined headers are of a purely informational nature and do not 
significantly change the behavior of SIP entities which support it.

     5.  The proposed header MUST NOT undermine SIP security in any sense.
         The Internet Draft proposing the new header MUST address security
         issues in detail as if it were a Standards Track document.  Note
         that, if the intended application scenario makes certain
         assumptions regarding security, the security considerations only
         need to meet the intended application scenario rather than the
         general Internet case.  In any case, security issues need to be
         discussed for arbitrary usage scenarios (including the general
         Internet case).

Security of these new headers is appropriately addressed in each case and 
in the general Security Considerations section.

     6.  The proposed header MUST be clearly documented in an (Individual
         or Working Group) Informational RFC, and registered with IANA.

That is the main purpose of this document.

     7.  An applicability statement in the Informational RFC MUST clearly
         document the useful scope of the proposal, and explain its
         limitations and why it is not suitable for the general use of SIP
         in the Internet.

An applicability statement clearly indicates the scope of applicability 
of these header fields.


Comments:
---------

1) Section 5.1, extension to Table 2 of RFC 3261 for the 
P-DCS-Trace-Party-ID. The proxy column indicates "dr" (for "delete" and 
"read" actions). The text in Section 5.6.1 also indicates a modify 
action, so I am missing an "m" mnemonic in this column.

Reading Section 5.6.1, I haven't being able to determine if there is a 
case when an originating proxy can add ("a") this header if the incoming 
request does not contain it. Perhaps this is also something that Section 
5.6.1 should clarify.



2) Issues with the NTP format.
Towards the end of Section 5.1, the text reads:

    The timestamp-param is populated using format defined by
    the Simple Network Time Protocol in [RFC4330]

I think the text should say:

    The timestamp-param is populated using the Network Time Protocol
    timestamp format defined in RFC 1305 [RFC1305] and used by the Simple
    Network Time Protocol [RFC4330].

Additionally, the text does not say and should say how this value is 
encoded. RFC 1305 defines a 64-bit for the NTP timestamp format. 
Therefore, one can encoded in decimal, BCD, UTF-8, base64, or some other 
format. Presumably UTF-8 should be used. Please add normative text 
indicating how to encode this format.

Last thing: Since the NTP timestamp format is a 64-bit format, it can be 
encoded as decimal (value 1 - 2^64-1), UTF-8, BCD, etc. I think the 
example of the timestamp parameter in Section 5.1 is quite suspicious of 
being wrong:

    timestamp=123456789



3) Section 6.4 provides procedures for untrusted UASes. The first (and 
other) paragraph says:

    If the UAS receives an INVITE request with an OSPS-Tag of "BLV",
    dialog identification that matches an existing dialog, it MUST reject
    the request with a 403-Forbidden error code.

My comment: if the UAS is untrusted, why do you think it will implement 
the "MUST reject" action? I doubt this will happen. Furthermore, I hope 
the protocol is not compromised if untrusted UASes receive a P-DCS-OSPS 
header field in a SIP request and ignore it, as one would do if a header 
is not implemented.

So, if the network entities cannot trust that UASes will follow this 
procedures, and if UASes may safely ignored, then I don't understand the 
value of the MUST strength.

The same can be extrapolated to other normative text within the same section.



4) Last sentences in Section 7 reads:

    The P-DCS-Billing-
    Info header extension is used only on requests and responses between
    proxies and trusted User Agents.  It is never sent to, nor sent by,
    an untrusted UA.

Question: how can you guarantee that an untrusted UA will never sent this 
header? The UA is untrusted, so, you don't trust what it does. I guess 
the correct text should say: "It is never sent to an untrusted UA. It is 
expected that untrusted UAs do not send this header".

The same applies to Section 7.2.


5) Text in the wrong section. Section 7.2 is devoted to "Procedures at an 
Untrusted UAC". Therefor, I am expecting to find procedures that takes 
place at an untrusted UAC, not elsewhere. However, the sentence in there 
reads:

    "This header is never sent to an untrusted UAC ..."

Notice that the UAC is not the active subject (related to the title), but 
just the passive object which receives the header. Therefore, I conclude 
that this text, while correct, is misplaced. Please move it to the 
correct section.

The same applies to the text in Sections 7.4, 8.2, 8.4 and perhaps 
others. In Sections 8.2 and 8.4, the text is even written with normative 
strength (surprise).

6) Second paragraph in Section 8 reads:

    The header may also contain the associated BCID ...

I guess the "may" should be a normative "MAY"

In this same paragraph, it would be nice to have short description of 
what ccc-id and BCID are all about.


7) Inconsistent usage of normative text. Section 8.3 first paragraph 
contains two instances of "may". I thought it is fine to have then 
without normative strength, since they both are describing non-SIP 
procedures that go beyond the scope of the document. However, the second 
paragraph in the same Section 8.3 contains two instances of "MAY" for 
similar stuff. As a minimum, all these instances should have the same 
consistent treatment, either as normative or non-normative strength. I 
don't have a strong opinion of which one to use.

The same applies to Section 8.6.1 second and third paragraphs; and 
Section 8.6.2 second paragraph.


Nits:
-----
- Section 5.1: s/tel: URL/tel URL
- Although header fields in SIP are case-insensitive, I would suggest to 
respect the original way of writing them. For example: 
s/Refer-to/Refer-To across the document.
- Section 7.6.1: s/P-DCS-Billing- Info/P-DCS-Billing-Info
- Section 7.6.1: s/Contact: header/Contact header
- Section 7.6.2: s/Billing- Correlation-ID/Billing-Correlation-ID
- Title of Section 8:
   s/P-DCS-REDIRECT/P-DCS-Redirect
- Expand BCID at first usage.
- Section 8.5, first paragraph:
   s/of Service[PCDQOS].Otherwise/of Service[PCDQOS]. Otherwise
- Section 8.6, first paragraph:
   s/a proxy that received/a proxy that receives


/Miguel

-- 
Miguel A. Garcia
[phone]
Ericsson Spain
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP