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

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 15 Oct 2007 10:31:35 +0200

(As WG chair)

This is to announce a working group last call of 

http://www.ietf.org/internet-drafts/draft-ietf-sip-hitchhikers-guide-03.
txt

I would request comments on this document be made (to list and to author
mentioned in the document) by Monday October 29th 2007.

Please clearly identify the text of the document that is being commented
on, the nature of the comment (NIT, minor technical, major technical,
etc), and any suggested resolution, even if it is only some
alternatives.

Regards

Keith

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 18 Oct 2007 08:34:05 -0500

Hi, Keith,

I reviewed 00/01 of this draft pretty seriously, and have reviewed the 02 
and 03 diffs.

It's ready for publication as an Informational RFC.

I have one question, mostly involving future-proofing, and it may not 
require any changes to the current draft.

This text was added in 03:

   Essential Corrections to SIP:  A collection of fixes to SIP that
      address important bugs and vulnerabilities.  These include a fix
      requiring loop detection in any proxy that forks [82] and a
      clarification on how record-routing works [110].

This points to two references, but it's likely there will be others in the 
future, (my impression from 
http://www3.ietf.org/proceedings/07mar/minutes/sip.html and 
http://www3.ietf.org/proceedings/07jul/minutes/sip.html is that we have not 
identified the last essential correction to SIP).

Is there any convention that the SIP working group can adopt so that 
implementers can know that some future "fix to some random thing we all 
thought worked, but it doesn't" is ALSO an essential correction?

Thanks,

Spencer

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 24 Oct 2007 08:58:01 +0100

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"

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"

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.

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."

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.

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."

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."

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."

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."

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".

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."

12. Because RFC 4916, a core specification, mandates use of UPDATE, RFC
3311 should be considered a core specification.

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.

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?

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."

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.

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".

18. RFC 4458 is missing - any reason?

19. There is mention of several SDP extensions, yet in the section
"Security Mechanisms", there is no mention of RFCs 4567 and 4568.

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.

Editorial nits:
21. "and implementations
   interested in a particular topic often implement"
Change to:
"and implementers
              ^^^
   interested in a particular topic often implement"

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."

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."

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."

25. "RFC 4168 [36] defines how
      to carry SIP messages over the Stream Control Transmission
      Protocol (SCTP)."
Add reference to SCTP itself.

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"?

27. "defines a mechanism for learning about changes in conference
      state, including group membership."
Change "group membership" to "conference membership". 
This occurs twice.

28. "when there are a multiplicity of
      security mechanisms"
Change "are" to "is".

29-42 - padding

John

> -----Original Message-----
> From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
> Sent: 15 October 2007 09:32
> To: IETF SIP List
> Subject: [Sip] WGLC of draft-ietf-sip-hitchhikers-guide-03
> 
> (As WG chair)
>