A couple of additional things I spotted on a cursory scan: The DCS-Billing-Info header field defines parameters. Since the original version was published we now have an IANA table registering header field parameters. The ones in the original version of this document were included by RFC 3968. The new version appears to add a jip= parameter.The IANA considerations section therefore needs to address this. Ditto for P-DCS-LAES header field. Except here it seems to have removed one of the original registered parameters (key=) and added some more. Throughout the document. "header field" rather than "header" unless the entire header of the message is meant. regards Keith > -----Original Message----- > From: sipping-bounces@xxxxxxxx > [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Miguel A. Garcia > Sent: Tuesday, October 28, 2008 4:01 PM > To: Flemming Andreasen; B.McKibben@xxxxxxxxxxxxx; wtm@xxxxxxxxxxxxxxxx > Cc: sipping-ads@xxxxxxxxxxxxxx; Sipping; sipping-chairs@xxxxxxxxxxxxxx > Subject: Expert review of draft-andreasen-sipping-rfc3603bis > > 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 > _______________________________________________ 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
