Document: draft-sinnreich-sipdev-req-05.txt Review: Mary Barnes Date: 16 februari 2005 Assignment: ------------ SIP Telephony Device Requirements and Configuration (Informational) - 1 of 4 draft-sinnreich-sipdev-req-05.txt Note: RFC-Editor note forthcoming to respond to a few last-minute comments. Token: Jon Peterson Reviewer: Mary Barnes Summary: -------- Draft is ready for publication as an individual, Informational, pending some updates, per the comments below. General Comment: ---------------- - Given that this is an Informational, individual document, I would think that all references are Informational. I understand the current division of references in terms of only having the mature work be Normative, otherwise, this document would never get published. However, there's a real inconsistency in that some of the documents in the Informational section (eg. MWI - Req 16) are defined as MUST in terms of the requirements of this document, thus from the perspective of this document, they would have to be Normative (if one were following the "normal" standard's guidance). So, I think it would be much easier all around (and less confusing) to just have all the references as Informative, since there is nothing at all Normative about this document, thus none of the references should be Normative. In that way, you avoid also the problem of this document sitting forever in the RFC Editor's Q waiting for the entirety of SIP specs to get completed. Detailed Comments: ------------------ - Abstract: rather than referring to this as an "Informational I-D", just refer to it as a "document". - Abstract: Given the volume of specs that MUST be implemented to meet these requirements, I think that the statement may need some altering : "The objectives of the requirements are a minimum set of interoperability and multi-vendor supported core features..." I would suggest changing to: "The objectives of the requirements are a well-defined set of interoperability and multi-vendor supported core features..." - Introduction, page 3: ditto. Also, there is some funky formatting of paragraphs in this section (i.e. missing blank lines between paragraphs?) - Introduction, general: I think the objectives of this document are admirable, however, I think it needs to be clear that since some of the recommendations go beyond what is defined within the SIP/SIPPING WGs in IETF and that it's also a "snapshot" of what's currently available in terms of SIP based specs, a statement something like the following in the Introduction would be useful: "While the recommendations of this document go beyond what is currently mandated for SIP implementations within IETF, this is believed necessary to support the specified operational objectives. However, it is also important to keep in mind that the SIP specifications are constantly being evolved, thus these recommendations need to be considered in the context of that change and evolution." - Introduction, page 4, last paragraph: Same comment as for the abstract above, given the volume of specs that MUST be implemented to meet these requirements (i.e. same change proposed to the paragraph beginning "The objectives..." ) - Req-14: Why is this not a MUST, given that 3264 hold behavior is normative SIP behavior? (Since this is just an informational, individual document, it might be useful to just include a note as to why this is a SHOULD rather than a MUST; if this were a standard's track document or WG document, I don't think the SHOULD would be acceptable). - Req-18: Should be updated to reference the newly published RFC 3966, which obsoletes 2806. - SIP-23 through SIP-26: Why the different tagging for these requirements (i.e. what's different about these "SIP-" requirements versus all the other "Req-" requirements or is this just a typo)? - Section 2.6: I think it would be useful for this section to mention the new ECRIT WG at this time leave an overall analysis of Emergency support "For Future Study" at this time. - Req-42: per the above comment, I think it's too pre-mature to reference [53] and [54]. I think, though, that a reference to the SIPPING location requirements draft would be appropriate (I don't see that listed at all - I know it's a requirements, but it does currently contain a solution proposal and it would not be unreasonable to suggest that the solution developed by SIP based on this requirements should be supported). - Req-43: Along the lines of the section 2.6 comment, I think MUST is too strong in the context of emergency calls. I think a SHOULD would be appropriate. - Req-73: I think either "mobile" needs to be inserted prior to "telephony clients" in this requirement or the SHOULD needs to be changed to a "MAY" in terms of GSM codec support. - Section 2.19: I was surprised to not see the SIPPING WG NAT scenarios document referenced here. I would think at a minimum this would be a SHOULD, although, in the context of the objectives of this document, I would consider it a MUST. That document has been updated to include usage of ICE, STUN, etc. and will likely be updated further going forward. So, I think it would be much more sensible for this document to reference that and then minimize the discussion in Req-87, for example. Perhaps, removing that Note about ICE and adding a Req-87.5 recommending that the SIPPING NAT scenarios document be used as an implementation guideline. - Section 3.5: Purely editorial comment - This section doesn't make sense in that I would expect the subsequent sections to be sub-sections of 3.5 (i.e. should 3.6 be 3.5.1). - Section 3.23: Editorial: there's the phrase "AOR Identification" just sitting between the 1st and 2nd sentences of this section. Formatting problem or stray text? - Section 4.2: I would have expected a reference to the TCP Connection reuse work in SIP WG given the last statement and perhaps even a reference to the Connection oriented Guidelines draft (draft-gurbani-sipping-connection-guidelines-01.txt) in SIPPING. - Section 4.4: see my comment on section 2.19 above. Why isn't SIPPING WG NAT scenarios document recommended here? References: - [9] Should be updated to RFC 3966. - [11] Is there a reason the 2833bis draft(s) aren't referenced? - [19] Is there a reason SDP new isn't referenced (other than RFC 3261 doesn't reference it, as much of the ongoing work in the WGs is now referencing SDP-new)? - [26] This is now RFC 3951 - [27] This is now RFC 3952 - [43] and [59] are duplicates - [71] This is now RFC 3959 Per comments above propose that references are added for: - draft-ietf-sipping-location-requirements-02 - draft-ietf-sipping-nat-scenarios-01 - draft-ietf-sip-connect-reuse-03.txt - draft-gurbani-sipping-connection-guidelines-01.txt