[Sip] RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide
"Brian Stucker" <bstucker@nortel.com> Thu, 08 November 2007 21:09 UTC
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqEd7-0006zv-05; Thu, 08 Nov 2007 16:09:37 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IqEd4-0006xh-N2 for sip-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 16:09:34 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqEd4-0006vV-5c; Thu, 08 Nov 2007 16:09:34 -0500
Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqEd3-0005PD-4X; Thu, 08 Nov 2007 16:09:33 -0500
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lA8L9Si07406; Thu, 8 Nov 2007 21:09:28 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 08 Nov 2007 15:09:18 -0600
Message-ID: <1ECE0EB50388174790F9694F77522CCF13132B06@zrc2hxm0.corp.nortel.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide
Thread-Index: AcgiS6A1W9zkQlycR82+duJ9ODvL9g==
From: Brian Stucker <bstucker@nortel.com>
To: Jonathan Rosenberg <jdrosen@cisco.com>, rai@ietf.org, sip <sip@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90
Cc:
Subject: [Sip] RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org
Jonathan, Thanks for putting the document together. It took quite awhile to just review it! Here are the comments that I have as part of the RAI-ART review of the document. Apologies for the probable repeats in here from list comments, I was not able to try to correlate my comments with others on the various reflectors. I tried to break my comments up by section and document so hopefully it's coherent in plain-text. Regards, Brian ---- Section 1: This document itself is not an update to RFC 3261 <http://tools.ietf.org/html/rfc3261> or an extension to SIP. It is an informational document, meant to guide newcomers, implementors and deployers to the SIP suite of specifications. May want to change "meant to guide newcomers, implementors and deployers to the SIP suite of specifications" since many of the documents are not predicated upon SIP itself. For example, RFC-4566, 3388, 3264. Also, I don't think we want to imply that this document is exhaustive. Perhaps "It is an information document, meant to introduce newcomers, implementors and deployers to many of the important IETF specifications associated with SIP. Specifications referenced by this document were chosen based on working group consensus and the list presented here is not intended to be exhaustive or confer any special status over documents not included." Might also want to include some pointers to the relevant WG webpages to give newcomers a place to go for further information. As well as include some boilerplate about the dangers of implementing I-D's before they become RFCs (I think this was already discussed somewhat on the RAI mailing list). Section 2: Although I agree that documents defining relevant registries should be excluded, what about pointers to the registries themselves? Seems like some of the interop problems we wind up with are due to disregard or lack of visibility of the IANA registration process to implementors. Section 3: RFC3261: I think it would be useful to provide a reverse-lookup list of RFCs that formally update 3261 under the 3261 entry: RFC-3583, RFC-4320 and RFC-4916. There is a statement under 4320 that it formally updates 3261, but there is no mention under 4916 that it formally updates 3261, it just looks like any other extension. Putting a pointer to the SIPS work as a TBD formal update to 3261 would also be good as well as collapsing the "essential corrections to SIP" under the 3261 entry so that people don't skip over that material would be good as well. RFC3264: Should we perhaps put a pointer here to the offer/answer draft for further clarification of 3264 since it seems pretty clear that the baseline specification did not entirely capture all of the interactions that arise in implementations? RFC3325: May want to remove the word "secure" from the description of the P-Asserted-ID header description. P-Asserted-ID does not confer any security of the caller ID information. It's the trust domain that provides the security in contrast to a mechanism like RFC-4474. RFC3581: Rport is necessary to routing a response through a NAT, but does not solve NAT traversal for SIP signaling. Perhaps a pointer to outbound under this RFC would be useful to highlight what you don't get with rport that you need to fully address NAT traversal issues, or simply remove it entirely and rely on folks to go to the NAT traversal section to discover it there as it's not necessary at all if you have no NATs to traverse (ALGs and SBCs aside). RFC4474: I don't think it's necessary that we should highlight the deployment size of the various RFCs in this way, especially given that the RFC is much newer (and has more complicated requirements) than RFC3325. SIPS: Should note that this will formally update RFC3261 when approved to highlight that newcomers should ignore what's in RFC3261. Section 4: RFC2848/3910: If this has seen little deployment and is very narrowly scoped, then why are we including it in the guide? RFC3372: Widespread implementation in a limited deployment model. It should be noted that it's usage is intended to be temporary as ISUP endpoints are obviated from the network. RFC3960: Early media is not just generated by the PSTN. We should be fair here and acknowledge that 3960 does not solve all of the various issues associated with early media (without enumerating them). We all know this to be the case, so just a sentence or two should suffice to warn the reader. RFC3959: We should highlight that this specification has not seen widespread deployment. As of a few IETFs ago nobody indicated that they had developed anything with regards to this specification when asked at a working group meeting. This is only important in that 3960 does not solve all of the early media issues. Shouldn't we have an entry in this section for RFC3966 to cover tel URIs? Section 5: RFC3262: PRACK is complicated, for sure, but it's used for more than just PSTN interworking and is more than mildly deployed depending upon the environment. RFC3311: ..but can be used to initiate a reliable request during session establishment when a re-INVITE is not possible. This is key for conveying information to an originator that cannot be conveyed in a response either due to offer/answer complications or because a header is not allowed in a response message type. We should also point out here that when UPDATE is used to convey SDP, support for RFC3262 is required in some scenarios. I don't think this is widely recognized. Should also call out that it can be used to convey mid-call information as well. RFC3608: You've captured the client perspective of the usage of service-route, but from a server perspective, it's used by proxies to capture the route set of a registration to know how to route future requests on behalf of the client. In this role it has seen greater deployment and applicability. RFC 3841: Should probably call out the relationship between this RFC and 3840. Need to remove duplicate entry for SDP negotiation under PSTN interworking. RFC4244: Should remove reference to voicemail here. It has broader scope. RFC4758 is intended for this purpose now (later comment). Shouldn't we have an entry in this section for RFC3880, CPL? Section 6: RFC3605: Should this be here and under the core specifications section? I don't see this attribute show up in SDP very often (pre-ICE), but it is necessary for some NAT traversal solutions. Perhaps only have a reference to it here? Outside of NAT traversal, is there a primary reason to have this RFC or ICE in the core specifications section? OUTBOUND: Doesn't outbound satisfy the requirements of a broadly applicable extension to SIP? Seems like if ICE is a core specification, that OUTBOUND should be considered one as well? RFC3890: It's used extensively in other SDOs, paricularly wireless. RFC4730: Should probably explain here briefly, that 2833/4733 is most commonly used to convey DTMF for SIP deployments, but the difference is that KPML does it on the signaling path as opposed to the media path. This is somewhat important given the low current deployment of KPML. Section 13: Perhaps we should add an entry here for RFC4896 or make a note under the entry for RFC3486 that RFC4896 updates both RFC3486 and RFC3485 which is the static dictionary for SIP (which provides the explicit coupling between SIGCOMP and SIP eluded to in the draft text). The important bit for an entry to RFC3485 is that there are a few bugs in the dictionary such that you'd need to refer to section 12 of RFC4896 to come up with a BCP implementation. Section 14: I think we should add an entry for RFC4758 to capture the voicemail service URI as another important service URI RFC. Section 15: RFC3853: May want to state that RFC3853 'formally' updates RFC3261, and put a pointer to this from the core specifications section as a result since it's a correction to 3261. RFC3893: Should RFC3893 entry simply say something to the effect of 'use RFC4474', or be dropped altogether? RFC3329: There are now three possible security models now in 3GPP: HTTP DIGEST, AKA, and early-IMS. As early-IMS doesn't really involve much in the way of security mechanisms within the SIP protocol, the coexistance of it with digest or AKA seems to be very probable. Perhaps we should just remove the last sentence and leave it up to the reader to decide if it's needed for their purpose. Section 16: Shouldn't we perhaps move RFC4796 from section 7 to this section? Section 17: Providing a pointer off to ECRIT seems useful here. That's it! _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
- [Sip] RAI-ART Review Comments for draft-ietf-sip-… Brian Stucker
- Re: [Sip] RAI-ART Review Comments for draft-ietf-… Peter Saint-Andre
- RE: [Sip] RAI-ART Review Comments for draft-ietf-… DOLLY, MARTIN C, ATTLABS
- RE: [Sip] RAI-ART Review Comments for draft-ietf-… Brian Stucker
- RE: [Sip] RAI-ART Review Comments for draft-ietf-… DOLLY, MARTIN C, ATTLABS
- RE: [RAI] RE: [Sip] RAI-ART Review Comments fordr… Elwell, John
- [Sip] Re: RAI-ART Review Comments for draft-ietf-… Jonathan Rosenberg
- Re: [Sip] RAI-ART Review Comments for draft-ietf-… Jonathan Rosenberg
- RE: [Sip] RAI-ART Review Comments for draft-ietf-… Mary Barnes
- RE: [RAI] RE: [Sip] RAI-ART Review Comments fordr… Henry Sinnreich
- Re: [Sip] RAI-ART Review Comments for draft-ietf-… Jonathan Rosenberg
- [Sip] RE: RAI-ART Review Comments for draft-ietf-… Brian Stucker