Thanks for the comments, John. Responses below:
Elwell, John wrote:
Draft: draft-ietf-sip-hitchhikers-guide-03
Reviewer: John Elwell
Review Date: 2007-10-24
Review Deadline: 2007-10-29
Status: WGLC
Summary: This draft is basically ready for publication, but has nits
that should be fixed before publication.
My 42 comments below.
Minor comments:
1. "Any specification that defines an extension to SIP itself, where"
Change to:
"The basic SIP specification, RFC 3261 [ref], and any specification that
defines an extension to SIP itself, where"
fixed by other similar comments, now reads:
<t>Any specification that defines an extension to RFC 3261,
where an extension is a mechanism that changes or updates in
some way a behavior specified there.
</t>
2. "Any specification that defines an extension to SDP"
Change to
"The basic SDP specification, RFC 4566 [ref], and any specification that
defines an extension to SDP"
OK, but I need to add, "whose primary purpose is to support SIP" to the end.
3. RFC 3840 has been classified as a core spec. I am not sure that it
meets the criterion of applying to most calls. Some implementations only
do isfocus, which hardly arises on every call. You may wish to
reconsider this classification.
The intention of the spec is that a client is supposed to include all of
its capabilities, including things like supported media types, etc. in
each REGISTER. Quoting RFC 3840:
When a UA registers, it can choose to indicate a feature set
associated with a registered contact. Whether or not a UA does so
depends on what the registered URI represents. If the registered URI
represents a UA instance (the common case in registrations), a UA
compliant to this specification SHOULD indicate a feature set using
the mechanisms described here.
Based on this, each and every register ought to be utilizing this spec.
I agree this is not very widely implemented, but the intention of the
spec is that it is meant to be used with every REGISTER. SO it meets the
criteria.
4. Concerning RFC 4474: "It has seen little deployment so far,
but its importance as a key construct for anti-spam techniques
makes it a core part of the SIP specifications."
It would be worth mentioning its use for future security mechanisms
(e.g., DTLS-SRTP) too:
"It has seen little deployment so far,
but its importance as a key construct for anti-spam techniques and
new security mechanisms
makes it a core part of the SIP specifications."
ok
5. Concerning ICE: "A SIP option tag and
media feature tag RFC XXXX [108] have been defined for use with
ICE."
It is not clear whether [108] is also a core specification.
yes. I clarified.
6. "RFC 4916 [81] defines an extension to SIP that allows a UAC to
determine the identity of the UAS. Due to forwarding and
retargeting services, this may not be the same as the user that
the UAC was originally trying to reach. The mechanism works in
tandem with the SIP identity specification [19] to provide
signatures over the connected party identity."
It is confusing to talk about UAC and UAS here, because even with RFC
4916 it is always the UAC (for that transaction) whose identity is
given. It might also be worth mentioning mid-call usage. Change to:
"RFC 4916 [81] defines an extension to SIP that allows a calling UA to
determine the identity of the final called user (connected user).
Due to forwarding and
retargeting services, this may not be the same as the user that
the caller was originally trying to reach. The mechanism works in
tandem with the SIP identity specification [19] to provide
a signature over the connected party identity. It can also be used
if a party identity changes mid call due to third party call control
actions or PSTN behavior."
fixed
7. "RFC 3960
[27] defines some guidelines for handling early media - the
practice of sending media from the called party towards the caller
- prior to acceptance of the call. Early media is generated only
from the PSTN."
This is not true - application servers can generate early media. Suggest
deleting the last sentence and changing the previous sentence as
follows:
"RFC 3960
[27] defines some guidelines for handling early media - the
practice of sending media from the called party or an application
server towards the caller
- prior to acceptance of the call."
changed, though I think mentioning that PSTN is a major source is a
useful piece of guidance. Changed the second sentence to, "early media
is often generated from the PSTN"
8. "RFC 3204, MIME Media Types for ISUP and QSIG Objects (S): RFC 3204
[84] defines MIME objects for representing SS7 signaling messages.
These are carried in the body of SIP messages when SIP-T is used."
Change to:
"RFC 3204, MIME Media Types for ISUP and QSIG Objects (S): RFC 3204
[84] defines MIME objects for representing SS7 and QSIG signaling
messages.
SS7 signaling messages are carried in the body of SIP messages
when SIP-T is used. QSIG signaling messages can be carried in a similar
way."
fixed
9. In the PSTN section you may wish to consider adding
"RFC 4497, Interworking between SIP and QSIG (B): RFC 4497 [ref] defines
how to do protocol mapping from QSIG signaling to SIP."
this are out of scope based on the current definitions for included specs.
10. Concerning RFC 3323: "Though it
defines numerous privacy services, the only one broadly used is
the one that supports privacy of the P-Asserted-ID header field
[15]."
Suggest changing "numerous" to "several".
ok
11. Concerning RFC 3311: "This method is meant as a means for
updating session information prior to the completion of the
initial INVITE transaction. It was developed primarily to support
RFC 3312 [59]."
It is not limited to use before completion of INVITE, and one use is for
session timer refresh, another is with connected-ID. Change to:
"This method is meant as a means for
updating session information prior to the completion of the
initial INVITE transaction. It can also be used for updating call
information mid-call. It was developed primarily to support
RFC 3312 [59], but has found other uses, including use with RFC
4028 [ref] for session timer refresh and with RFC 4916 [ref] for
connected identity."
similar change already made based on other comments.
12. Because RFC 4916, a core specification, mandates use of UPDATE, RFC
3311 should be considered a core specification.
Hmm, good point.
13. Concerning RFC 4028: "Session
timers introduces a fair bit of complexity for relatively little
gain, and has thus seen little deployment."
I am a little surprised by this statement, but if it is based on
feedback from SIPit then I guess it is OK.
Well, sipit20 results showed a fair number of implementations. I dont
thinka lot are used but I'm OK to temper this statement. I'll changed to
'moderate' deployment.
14. Section "Minor Extensions".
Several of these are extensions to mechanisms listed later in the
document, e.g., REFER, pre-conditions. Should the section be moved
further back, e.g., to the end?
moved back, before security mechanisms
15. Concerning RFC 4508: "It is useful for informing the target of the
REFER
about the characteristics of the REFER target."
Terminology is rather confusing: "target of the REFER" and "REFER
target" are supposed to mean different things. Change to:
"It is useful for informing the target of the REFER request
about the characteristics of the intended target of the referred
request."
ok
16. "RFC 3265 defines a basic framework for event notification in SIP.
It
introduces the notion of an event package, which is a collection of
related state and event information. Much of the state and events in
SIP systems have event packages, allowing other entities to learn
about changes in that state."
Although several RFCs are repeated in different sections
(intentionally), in this particular case the text is completely
different from that in the core specs section. Suggest alignment one way
or the other.
aligned this with the definition of rfc3265 from core. Indeed, rfc3265
itself doesnt appear here, which is wrong. FIxed that too.
17. "RFC XXXX [96] defines a SIP
event package that allows a proxy to notify a user agent about its
desire for the UA to use certain codecs or generally obey certain
media session policies."
Change "proxy" to "policy server".
ok
18. RFC 4458 is missing - any reason?
error. been added.
19. There is mention of several SDP extensions, yet in the section
"Security Mechanisms", there is no mention of RFCs 4567 and 4568.
wow - frankly I am not sure why I didnt put them in. Maybe its because
they are not necessarily SIP specific (MIKEY in particular talks about
rtsp). But that said I do think they belong. And to complete the
triumvirate, recently added draft-ietf-sip-dtls-srtp-framework-00.txt
probably belongs too.
I added the following to the security section:
<t hangText="RFC 4567, Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP) (S):"> <xref target="RFC4567"/> defines
extensions to SDP that allow tunneling of an key
management protocol, namely MIKEY
<xref target="RFC3830"/>, through offer/answer
exchanges. This mechanism is one of three SRTP keying
techniques specified for SIP, with DTLS-SRTP
<xref target="I-D.ietf-sip-dtls-srtp-framework"/> having
been selected as the final solution.
</t>
<t hangText="RFC 4568, Session Description Protocol (SDP)
Security Descriptions for Media Streams (S):">
<xref target="RFC 4568"/> defines extensions to SDP that allow for
the negotiation of keying material directly through offer/answer,
without a separate key management protocol. This mechanism,
sometimes called sdescriptions, has the drawback that the media keys
are available to any entity that has visibility to the SDP. It is
one of three SRTP keying techniques specified for SIP, with
DTLS-SRTP <xref target="I-D.ietf-sip-dtls-srtp-framework"/> having
been selected as the final solution.
</t>
<t hangText="draft-ietf-sip-dtls-srtp-framework, Framework for
Establishing an SRTP Security Context using DTLS (S):">
<xref target="I-D.ietf-sip-dtls-srtp-framework"/> defines
the overall framework and SDP and SIP processing required
to perform key management for RTP using Datagram TLS
(DTLS) <xref target="RFC4347"/> directly between
endpoints, over the media path. It is
one of three SRTP keying techniques specified for SIP, with
DTLS-SRTP <xref target="I-D.ietf-sip-dtls-srtp-framework"/> having
been selected as the final solution.
</t>
20. "17. Emergency Services
Emergency services here covers both emergency calling (for example,
911 in the United States), and pre-emption services, which allow
authorized individuals to gain access to network resources in time of
emergency."
In fact the only two RFCs listed relate to pre-emption, not emergency
calling.
OK, changed to just pre-emption.
Editorial nits:
21. "and implementations
interested in a particular topic often implement"
Change to:
"and implementers
^^^
interested in a particular topic often implement"
ok
22. "The SIP change process [8] defines two types of extensions to SIP.
These are normal extensions and the so-called P-headers (where P
stands for "preliminary", "private", or "proprietary", and the "P-"
prefix is included in the header field name) are meant to be used in
areas of limited applicability."
Change to:
"The SIP change process [8] defines two types of extensions to SIP.
These are normal extensions and the so-called P-headers (where P
stands for "preliminary", "private", or "proprietary", and the "P-"
prefix is included in the header field name), which are meant to be
used in
^^^^^^^
areas of limited applicability."
ok
23. "RFC 3325 [15], which defines the
P-Asserted-ID header field has been widely deployed."
Add comma as follows:
"RFC 3325 [15], which defines the
P-Asserted-ID header field, has been widely deployed."
ok
24. "RFC 4320 [18] formally updates RFC 3261, and
modifies some of the behaviors associated with non-INVITE
transactions. These address some problems found in timeout and
failure cases."
It is not clear what "these" refers to. Suggest change to:
"RFC 4320 [18] formally updates RFC 3261, and
modifies some of the behaviors associated with non-INVITE
transactions. Modifications address some problems found in
timeout and
^^^^^^^^^^^^^^
failure cases."
changed to, "this addresses"
25. "RFC 4168 [36] defines how
to carry SIP messages over the Stream Control Transmission
Protocol (SCTP)."
Add reference to SCTP itself.
ok
26. "Its primary application was in support of
voicemail services."
What is the reason for the past tense? Can we just change "was" to "is"?
text already adjusted basedon other comments
27. "defines a mechanism for learning about changes in conference
state, including group membership."
Change "group membership" to "conference membership".
This occurs twice.
done
28. "when there are a multiplicity of
security mechanisms"
Change "are" to "is".
ok
-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. 499 Thornall St.
Cisco Fellow Edison, NJ 08837
Cisco, Voice Technology Group
[EMAIL PROTECTED]
http://www.jdrosen.net PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
