Re: [Sip] WGLC of draft-ietf-sip-hitchhikers-guide-03

[Jonathan Rosenberg <[e-mail]>]

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
[e-mail]
http://www.jdrosen.net                         PHONE: [phone]
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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip