Draft:
http://tools.ietf.org/html/draft-andreasen-sipping-rfc3603bis-05
Reviewer: Miguel Garcia <miguel.a.garcia@xxxxxxxxxxxx>
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
+34-91-339-3608
Ericsson Spain
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
