From rai-bounces@ietf.org Thu Nov 01 06:15:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InX49-0007rr-R6; Thu, 01 Nov 2007 06:14:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InX46-0007mn-OT; Thu, 01 Nov 2007 06:14:18 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InX3q-0001sn-Q3; Thu, 01 Nov 2007 06:14:08 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id lA1ADvcA018261; Thu, 1 Nov 2007 05:13:57 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 05:13:56 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.26]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 11:13:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 Date: Thu, 1 Nov 2007 11:13:53 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180018867C7@DEEXC1U01.de.lucent.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF12DC4A04@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 Thread-Index: AcgaGKH+zp3EvtG8TLeDyez69R12VQAQbavAAD12KJAAQbDz8A== References: <5D1A7985295922448D5550C94DE291800188609F@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF12DC4A04@zrc2hxm0.corp.nortel.com> From: "DRAGE, Keith \(Keith\)" To: "Francois Audet" , "Avshalom Houri" , , , X-OriginalArrivalTime: 01 Nov 2007 10:13:54.0333 (UTC) FILETIME=[E83D2CD0:01C81C6F] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f44ec47f6ebd2aaf0f97ba9529b3ca5 Cc: X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0992682465==" Errors-To: rai-bounces@ietf.org This is a multi-part message in MIME format. --===============0992682465== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81C6F.E7E3EF9F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81C6F.E7E3EF9F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At the risk of committing myself - definitely in. =20 Apart from one issue that I need to respond to Francois on which is about documentation of Warning headers (i.e. adequately documenting the changes as far as RFC 3261 and IANA are concerned, and anything the PROTO shepherd (Dean) finds during his writeup, this document is finished by the WG. =20 The outbound reference is not going to prevent the submission to IESG, or the IESG approving it, merely delay the publication until outbound gets an RFC number assigned.=20 =20 regards =20 Keith ________________________________ From: Francois Audet [mailto:audet@nortel.com]=20 Sent: Tuesday, October 30, 2007 11:56 PM To: DRAGE, Keith (Keith); Avshalom Houri; rai@ietf.org; sip@ietf.org; jdrosen@cisco.com Subject: RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 =09 =09 What about SIPS, which is already in hitchiker's guide, and which is waiting on outbound because of a normative reference? ________________________________ From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 Sent: Tuesday, October 30, 2007 01:01 To: Avshalom Houri; rai@ietf.org; sip@ietf.org; jdrosen@cisco.com Subject: RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 =09 =09 (As WG chair) =20 Just a note that I should have included with the WGLC. =20 The intention with this document is to republish on a recurring basis, and therefore to keep it up to date (say once a year or so). =20 The 1st versions is intended to include gruu, outbound and ice, but apart from that, anything that is not published in that timeframe will probably be removed unless there is exceptional justification for keeping it, with the idea that it will appear in the next version. =20 regards =20 Keith ________________________________ From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com]=20 Sent: Monday, October 29, 2007 10:40 AM To: rai@ietf.org; sip@ietf.org; jdrosen@cisco.com Subject: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 =09 =09 I have been assigned to review of draft-ietf-sip-hitchhikers-guide-03=20 from the perspective of presence and the SIMPLE group but ended up in=20 commenting on the whole document at the end.=20 =09 For background on RAI-ART, please see the FAQ at =09 http://www.softarmor.com/rai/art/rai-art-FAQ.html =20 =09 Please resolve these comments along with any other Last Call comments=20 you may receive.=20 =09 In my opinion this draft is basically ready for publication, but has=20 nits that should be fixed before publication.=20 =09 Citations from the draft are marked by <<< text from draft >>>=20 =09 General comments=20 ----------------=20 =09 By its nature there are a lot of reference to drafts in the document.=20 It will take a lot of time for these documents to become and RFC.=20 So how we are going to publish this as an RFC? Since when the=20 referenced drafts will become an RFC, this draft would have to be=20 updated with new drafts, will it be held in the=20 RFC ED queue for ever?=20 =09 How do we gauge the usage of an RFC or a draft? There are many places=20 here that it is said that this or that RFC/draft got widely implemented=20 or not.=20 How it is measured? The wide implementation test is used to decide=20 whether an RFC or draft are core or not and therefore there should be=20 some text explaining how the wide implementation was determined.=20 =09 Better change RFC XXXX (before the reference number in []) to the name=20 of the draft (with no version number), it will make the ride smoother.=20 =09 An introduction that details the various grouping should be added. It=20 should include additional text on the group and what was the criteria=20 for putting an RFC/draft in the group.=20 =09 2. Scope of this Document=20 --------------------------=20 =09 <<<=20 o Any specification that defines an extension to SIP itself, where=20 an extension is a mechanism that changes or updates in some way a=20 behavior specified in RFC 3261=20 >>>=20 =09 "to SIP itself" sounds vague. It will be better to say:"to RFC 3261"=20 instead.=20 Maybe there should be an earlier definition of RFC 3261 as the SIP nucleus=20 (or the president of the galaxy) and that RFCs/drafts mentioned in this=20 document are based on their relation to it.=20 =09 <<<=20 Excluded from this list are requirements, architectures, registry=20 definitions, non-normative frameworks, and processes. Best Current=20 Practices are included when they normatively define mechanisms for=20 accomplishing a task.=20 >>>=20 =20 "normatively define" not sure what is meant by normative with=20 respect to BCP. Seems like a contradiction in terms.=20 =09 3. Core SIP Specifications=20 ---------------------------=20 =09 If we think on presence as eventually replacing registration, since it=20 carries much more information about the availability of the user,=20 should we consider also presence as a towel?=20 =09 <<<=20 RFC 3261, The Session Initiation Protocol (S): RFC 3261 [1] is the=20 core SIP protocol itself. RFC 3261 is an update to RFC 2543 [9].=20 It is the president of the galaxy [42] as far as the suite of SIP=20 specifications is concerned.=20 >>>=20 =09 RFC 3261 is a very big document. Should it be treated as one or it can=20 be divided into parts in this document e.g. proxy, client etc.? I am not=20 sure what would be better.=20 =09 4. Public Switched Telephone Network (PSTN) Interworking=20 =09 ---------------------------------------------------------=20 =09 Regarding RFC 3578=20 Ugly in one corner of the galaxy may be beautiful on the other of it :-)=20 =09 7. Minor Extensions=20 --------------------=20 =09 <<<=20 RFC XXXX, Referring to Multiple Resources in SIP (S): RFC XXXX [44]=20 allows a UA sending a REFER to ask the recipient of the REFER to=20 generate multiple SIP requests, not just one. This is useful for=20 conferencing, where a client would like to ask a conference server=20 to eject multiple users.=20 >>>=20 =09 Should not this be referred to in the conferencing section also?=20 =09 <<<=20 RFC 4483, A Mechanism for Content Indirection in Session Initiation=20 Protocol (SIP) Messages (S): RFC 4483 [89] defines a mechanism for=20 content indirection. Instead of carrying an object within a SIP=20 body, a URL reference is carried instead, and the recipient=20 dereferences the URL to obtain the object. The specification has=20 potential applicability for sending large instant messages, but=20 has yet to find much actual use.=20 >>>=20 =09 The specification has also potential for sending large presence=20 documents via a URL.=20 =09 <<<=20 RFC 4583, Session Description Protocol (SDP) Format for Binary Floor=20 Control Protocol (BFCP) Streams (S): RFC 4583 [91] defines a=20 mechanism in SDP to signal floor control streams that use BFCP.=20 It is used for Push-To-Talk and conference floor control.=20 >>>=20 =09 Should not this be referred to in the conferencing section also?=20 =09 <<<=20 RFC XXXX, Connectivity Preconditions for Session Description Protocol=20 Media Streams (S): RFC XXXX [93] defines a usage of the precondition=20 framework [59]. The connectivity precondition makes sure that the=20 session doesn't get established until actual packet connectivity=20 is checked.=20 >>>=20 =09 Should not this be referred to in the QoS section also?=20 =09 8. Conferencing=20 ----------------=20 =09 The Conferencing section should be before or after "Instant Messaging,=20 Presence and Multimedia" as it is also an application. See the comment=20 on whether presence is an application or not later.=20 =09 10. Event Framework and Packages=20 ----------------------------------=20 =09 Suggest to divide this section to event framework section and to=20 packages section. The event framework should include 3265, 3903, 4662=20 and subnot-etags which define the event framework itself.=20 The other section will the packages sections that will list the=20 packages.=20 =09 Alternatively, many of the packages are mentioned in their proper=20 section so it may be that all the event packages can be fit into=20 their relevant section and there is not a need for packages section.=20 =09 11. Quality of Service=20 -----------------------=20 =09 <<<=20 RFC 3313, Private SIP Extensions for Media Authorization (I): RFC=20 3313 [61] defines a P-header that provides a mechanism for passing=20 an authorization token between SIP and a network QoS reservation=20 protocol like RSVP. Its purpose is to make sure network QoS is=20 only granted if a client has made a SIP call through the same=20 providers network. This specification is sometimes referred to as=20 the SIP walled garden specification by the truly paranoid androids=20 in the SIP community. This is because it requires coupling of=20 signaling and the underlying IP network.=20 >>> =20 =09 Understand that being a "truly paranoid" is a virtue? :-)=20 =09 15. Security Mechanisms=20 ------------------------=20 =09 Should not RFC 3323 (Privacy), RFC 3325 (Asserted-ID) and RFC 4474=20 (Identity) be mentioned here also? =20 =09 16. Instant Messaging, Presence and Multimedia=20 -----------------------------------------------=20 =09 Maybe create an applications section and put also conferencing as a type=20 of an application.=20 =09 Including presence here with IM and multimedia seems that presence is=20 regarded as an additional type of media. I am not sure that I agree with=20 this. Presence is an enabler for many other applications and it deserves=20 a section of its own.=20 =09 It is very tempting to include the simple-simple content here=20 (as an appendix?). If simple-simple is not to be included here, there=20 should be at least a reference to simple-simple as for presence=20 there are so many documents that are essential for doing presence and=20 are not mentioned here (e.g. watcher format, RPID, presence rules,=20 partial notify and publish and many many more). Roughly counting, there=20 are about 20-25 RFCs/drafts that are very relevant to presence that are=20 mentioned in simple-simple in addition to the ones that are mentioned here.=20 =09 The MSRP drafts seem to be forgotten?=20 =09 Thanks=20 --Avshalom =09 ------_=_NextPart_001_01C81C6F.E7E3EF9F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
At the risk of committing myself - definitely=20 in.
 
Apart from one issue that I need to respond to = Francois on=20 which is about documentation of Warning headers (i.e. adequately = documenting the=20 changes as far as RFC 3261 and IANA are concerned, and anything the = PROTO=20 shepherd (Dean) finds during his writeup, this document is finished by = the=20 WG.
 
The outbound reference is not going to prevent = the=20 submission to IESG, or the IESG approving it, merely delay the = publication until=20 outbound gets an RFC number assigned.
 
regards
 
Keith

From: Francois Audet = [mailto:audet@nortel.com]=20
Sent: Tuesday, October 30, 2007 11:56 PM
To: = DRAGE, Keith=20 (Keith); Avshalom Houri; rai@ietf.org; sip@ietf.org;=20 jdrosen@cisco.com
Subject: RE: [RAI] RAI review of=20 draft-ietf-sip-hitchhikers-guide-03

What=20 about SIPS, which is already in hitchiker's guide, and which is = waiting on=20 outbound because of a normative reference?

From: DRAGE, Keith (Keith)=20 [mailto:drage@alcatel-lucent.com]
Sent: Tuesday, October = 30, 2007=20 01:01
To: Avshalom Houri; rai@ietf.org; sip@ietf.org;=20 jdrosen@cisco.com
Subject: RE: [RAI] RAI review of=20 draft-ietf-sip-hitchhikers-guide-03

(As WG chair)
 
Just a note that I should have included = with the=20 WGLC.
 
The intention with this document is to = republish on a=20 recurring basis, and therefore to keep it up to date (say once a = year or=20 so).
 
The 1st versions is intended to include = gruu, outbound=20 and ice, but apart from that, anything that is not published in that = timeframe will probably be removed unless there is exceptional = justification=20 for keeping it, with the idea that it will appear in the next=20 version.
 
regards
 
Keith

From: Avshalom Houri=20 [mailto:AVSHALOM@il.ibm.com]
Sent: Monday, October 29, = 2007=20 10:40 AM
To: rai@ietf.org; sip@ietf.org;=20 jdrosen@cisco.com
Subject: [RAI] RAI review of=20 draft-ietf-sip-hitchhikers-guide-03


I have been = assigned to=20 review of draft-ietf-sip-hitchhikers-guide-03
from the perspective of presence and = the SIMPLE=20 group but ended up in
commenting on the whole document at the end. =

For background on RAI-ART, please = see the FAQ=20 at
http://www.softarmor.com/rai/art/rai-art-FAQ.html<= /A>=20

Please resolve these = comments=20 along with any other Last Call comments
you may receive. =

In my opinion this draft is = basically ready for=20 publication, but has
nits that=20 should be fixed before publication.

Citations from the draft are marked = by=20 <<< text from draft >>>

General comments
---------------- =

By its nature there are a lot of = reference to=20 drafts in the document.
It will=20 take a lot of time for these documents to become and RFC. =
So how we are going to publish this = as an RFC?=20 Since when the
referenced=20 drafts will become an RFC, this draft would have to be =
updated with new drafts, will it be = held in=20 the
RFC ED queue = for=20 ever?

How do we = gauge the=20 usage of an RFC or a draft? There are many places
here that it is said that this or = that RFC/draft=20 got widely implemented
or=20 not.
How it is = measured? The=20 wide implementation test is used to decide
whether an RFC or draft are core or = not and=20 therefore there should be
some=20 text explaining how the wide implementation was determined. =

Better change RFC XXXX = (before the=20 reference number in []) to the name
of the draft (with no version number), it will make the = ride=20 smoother.

An = introduction=20 that details the various grouping should be added. It =
should include additional text on = the group and=20 what was the criteria
for=20 putting an RFC/draft in the group.

2.  Scope of this Document
--------------------------

<<<
 =20  o  Any specification that defines an extension to SIP = itself,=20 where
    =   an=20 extension is a mechanism that changes or updates in some way = a=20
      = behavior=20 specified in RFC 3261
>>>

"to SIP=20 itself" sounds vague. It will be better to say:"to RFC = 3261"=20
instead.
Maybe there should be an earlier = definition of=20 RFC 3261 as the SIP nucleus
(or=20 the president of the galaxy) and that RFCs/drafts mentioned in = this=20
document are based on = their relation=20 to it.

<<<=20
   Excluded from = this list=20 are requirements, architectures, registry
   definitions, = non-normative=20 frameworks, and processes.  Best Current
   Practices are included = when they=20 normatively define mechanisms for
   accomplishing a task.
>>>
   
"normatively define" not sure what is meant by normative=20 with
respect to = BCP. Seems like=20 a contradiction in terms.

3.  Core SIP Specifications
--------------------------- =

If we think on presence as = eventually replacing=20 registration, since it
carries=20 much more information about the availability of the user, =
should we consider also presence as = a=20 towel?

<<<=20
   RFC 3261, The = Session=20 Initiation Protocol (S):  RFC 3261 [1] is the =
      core SIP = protocol itself.=20  RFC 3261 is an update to RFC 2543 [9].
      It is the = president of the=20 galaxy [42] as far as the suite of SIP
      specifications is concerned. =
>>>

RFC 3261 is a very big document. = Should it be=20 treated as one or it can
be=20 divided into parts in this document e.g. proxy, client etc.? I am=20 not
sure what would = be=20 better.

4. =  Public=20 Switched Telephone Network (PSTN) Interworking
---------------------------------------------------------= =20

Regarding RFC = 3578=20
Ugly in one corner of the = galaxy may=20 be beautiful on the other of it :-)

7.  Minor Extensions =
-------------------- =

<<<
   RFC XXXX, Referring to Multiple Resources in = SIP (S):=20  RFC XXXX [44]
 =20     allows a UA sending a REFER to ask the recipient of = the=20 REFER to
  =    =20 generate multiple SIP requests, not just one.  This is useful = for
    =  =20 conferencing, where a client would like to ask a conference = server=20
      to = eject multiple=20 users.
>>>=20

Should not this be = referred to in=20 the conferencing section also?

<<<
 =20  RFC 4483, A Mechanism for Content Indirection in Session=20 Initiation
 =20  Protocol (SIP) Messages (S):  RFC 4483 [89] defines a = mechanism=20 for
    =  =20 content indirection.  Instead of carrying an object within a=20 SIP
    =   body,=20 a URL reference is carried instead, and the recipient =
      dereferences = the URL to=20 obtain the object.  The specification has
      potential = applicability for=20 sending large instant messages, but
      has yet to find much actual = use.=20
>>> =

The specification has also potential = for sending=20 large presence
documents via a=20 URL.

<<<=20
   RFC 4583, = Session=20 Description Protocol (SDP) Format for Binary Floor =
   Control Protocol (BFCP) = Streams=20 (S):  RFC 4583 [91] defines a
      mechanism in SDP to signal floor = control=20 streams that use BFCP.
 =20     It is used for Push-To-Talk and conference floor=20 control.
>>>=20

Should not this be = referred to in=20 the conferencing section also?

<<<
 =20  RFC XXXX, Connectivity Preconditions for Session Description = Protocol
  =  Media=20 Streams (S):  RFC XXXX [93] defines a usage of the=20 precondition
  =  =20   framework [59].  The connectivity precondition makes = sure that=20 the
    =  =20 session doesn't get established until actual packet = connectivity=20
      is=20 checked.
>>>=20

Should not this be = referred to in=20 the QoS section also?

8.=20  Conferencing
----------------

The=20 Conferencing section should be before or after "Instant = Messaging,=20
Presence and Multimedia" = as it is also=20 an application. See the comment
on whether presence is an application or not = later.=20

10.  Event = Framework and=20 Packages
----------------------------------

Suggest to divide this section to = event=20 framework section and to
packages section. The event framework should include = 3265, 3903,=20 4662
and = subnot-etags which=20 define the event framework itself.
The other section will the packages sections that will = list=20 the
packages.=20

Alternatively, many of = the=20 packages are mentioned in their proper
section so it may be that all the event packages can be = fit=20 into
their relevant = section and=20 there is not a need for packages section.

11.  Quality of Service =
----------------------- =

<<<
   RFC 3313, Private SIP Extensions for Media=20 Authorization (I):  RFC
      3313 [61] defines a P-header that = provides a=20 mechanism for passing
 =20     an authorization token between SIP and a network QoS = reservation
  =  =20   protocol like RSVP.  Its purpose is to make sure = network QoS=20 is
    =   only=20 granted if a client has made a SIP call through the same =
      providers = network.=20  This specification is sometimes referred to as =
      the SIP walled = garden=20 specification by the truly paranoid androids
      in the SIP = community.=20  This is because it requires coupling of
      signaling and = the=20 underlying IP network.
>>>      

Understand that being a "truly = paranoid" is a=20 virtue? :-)

15. =  Security Mechanisms
------------------------

Should not RFC 3323 (Privacy), RFC 3325 (Asserted-ID) and = RFC=20 4474
(Identity) be = mentioned=20 here also?    

16.  Instant Messaging, Presence and = Multimedia=20
-----------------------------------------------=20

Maybe create an = applications=20 section and put also conferencing as a type
of an application. =

Including presence here with IM and = multimedia=20 seems that presence is
regarded=20 as an additional type of media. I am not sure that I agree = with=20
this. Presence is an = enabler for many=20 other applications and it deserves
a section of its own.

It is very tempting to include the simple-simple content=20 here
(as an = appendix?). If=20 simple-simple is not to be included here, there
should be at least a reference to = simple-simple=20 as for presence
there are so=20 many documents that are essential for doing presence and =
are not mentioned here (e.g. watcher = format,=20 RPID, presence rules,
partial=20 notify and publish and many many more). Roughly counting, = there=20
are about 20-25 = RFCs/drafts that are=20 very relevant to presence that are
mentioned in simple-simple in addition to the ones that = are=20 mentioned here.

The MSRP=20 drafts seem to be forgotten?

Thanks
--Avshalom
------_=_NextPart_001_01C81C6F.E7E3EF9F-- --===============0992682465== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAI mailing list RAI@ietf.org https://www1.ietf.org/mailman/listinfo/rai --===============0992682465==-- From rai-bounces@ietf.org Thu Nov 01 10:37:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inb9e-000680-GL; Thu, 01 Nov 2007 10:36:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inb9c-00066F-J8; Thu, 01 Nov 2007 10:36:16 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Inb9W-0003nR-Cg; Thu, 01 Nov 2007 10:36:16 -0400 X-IronPort-AV: E=Sophos;i="4.21,358,1188802800"; d="scan'208";a="29234125" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 01 Nov 2007 07:36:04 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lA1Ea2Qx002058; Thu, 1 Nov 2007 07:36:02 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA1Ea2ZU013825; Thu, 1 Nov 2007 14:36:02 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 07:35:40 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 07:35:40 -0700 Message-ID: <4729E458.6030703@cisco.com> Date: Thu, 01 Nov 2007 10:36:08 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Francois Audet Subject: Re: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 References: <5D1A7985295922448D5550C94DE291800188609F@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF12DC4A04@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF12DC4A04@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2007 14:35:40.0251 (UTC) FILETIME=[79B212B0:01C81C94] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2436; t=1193927762; x=1194791762; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[RAI]=20RAI=20review=20of=20draft-ietf-sip-hitchhiker s-guide-03 |Sender:=20; bh=xIm0hf0iugRdtr70SuT9jDa0YUHxN1uiuVEaCPTuF78=; b=dEcgZ+IaO/+QNOpxEBY+EN/EGE8AvFvz/wKbCRfaHgdtBqjPLZ0j8Ql7WdiCBV4VxGCV8Duh /BUXvYrFHU+npw58J7m8VDXsmOlGgIAd+2+ZNEnqPKUQSvJ2GHTTflH6; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: sip@ietf.org, Avshalom Houri , rai@ietf.org X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rai-bounces@ietf.org inline: Francois Audet wrote: > What about SIPS, which is already in hitchiker's guide, and which is > waiting on outbound because of a normative reference? > > ------------------------------------------------------------------------ > *From:* DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > *Sent:* Tuesday, October 30, 2007 01:01 > *To:* Avshalom Houri; rai@ietf.org; sip@ietf.org; jdrosen@cisco.com > *Subject:* RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 > > (As WG chair) > > Just a note that I should have included with the WGLC. > > The intention with this document is to republish on a recurring > basis, and therefore to keep it up to date (say once a year or so). > > The 1st versions is intended to include gruu, outbound and ice, but > apart from that, anything that is not published in that timeframe > will probably be removed unless there is exceptional justification > for keeping it, with the idea that it will appear in the next version. This is news to me... What I thought would happen is that we have references to everything in the guide, and when the guide appears as an RFC, whatever references are at RFC status at that time, get RFC numbers. Everything else is referenced as an I-D. I think you are suggesting that, instead, when we send this to IESG, we remove any content and references associated with documents which are not on track to publication around the same timeframe as hitchhikers guide itself. Indeed it will require us to change those references to normative in order to get rfc-editor to do a REF hold on hitchhikers till its dependencies clear. If my interpretation is correct, my next question is whether this applies to just the core specs or all of the specs. I personally would rather leave the document as is - include everything, and recognize that some references will be drafts rather than RFCs when hitchhikers is published. Next round of hitchhikers will have more of them as RFCs. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ RAI mailing list RAI@ietf.org https://www1.ietf.org/mailman/listinfo/rai From rai-bounces@ietf.org Thu Nov 01 10:58:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InbUf-0005Ku-Dg; Thu, 01 Nov 2007 10:58:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InbUc-0005HH-NN; Thu, 01 Nov 2007 10:57:58 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InbUc-000378-4z; Thu, 01 Nov 2007 10:57:58 -0400 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 lA1Evkk18529; Thu, 1 Nov 2007 14:57:46 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 Subject: RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 Date: Thu, 1 Nov 2007 09:57:40 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF12E572BD@zrc2hxm0.corp.nortel.com> In-Reply-To: <4729E458.6030703@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 Thread-Index: AcgclWSXcUNjORGwTPG/Q8fZUb7hqQAATCig References: <5D1A7985295922448D5550C94DE291800188609F@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF12DC4A04@zrc2hxm0.corp.nortel.com> <4729E458.6030703@cisco.com> From: "Brian Stucker" To: "Jonathan Rosenberg" , "Francois Audet" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: sip@ietf.org, rai@ietf.org, Avshalom Houri X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rai-bounces@ietf.org I would also prefer that I-D references be left in the document. It's very helpful to the community to not only know where SIP is at when you read the guide, but to know where it's headed. If for no other reason than it prevents someone from thinking they've discovered a novel problem and go off implementing a solution parallel to what will soon (hopefully) be an RFC. Likewise, if they find that the I-D is incomplete, it gives them a reference to make comments against that they may not have otherwise discovered. It's an informative document. What if we just copy paragraphs two and three of from the boilerplate "status of this memo" into the introduction as a warning to those who read the document later as an RFC that I-D's referenced by the guide can change.=20 Is there any harm in doing this? Regards, Brian=20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Thursday, November 01, 2007 9:36 AM > To: Audet, Francois (SC100:3055) > Cc: sip@ietf.org; Avshalom Houri; rai@ietf.org > Subject: Re: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 >=20 > inline: >=20 > Francois Audet wrote: > > What about SIPS, which is already in hitchiker's guide, and=20 > which is=20 > > waiting on outbound because of a normative reference? > >=20 > > =20 > -------------------------------------------------------------- > ---------- > > *From:* DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > *Sent:* Tuesday, October 30, 2007 01:01 > > *To:* Avshalom Houri; rai@ietf.org; sip@ietf.org;=20 > jdrosen@cisco.com > > *Subject:* RE: [RAI] RAI review of=20 > > draft-ietf-sip-hitchhikers-guide-03 > >=20 > > (As WG chair) > > =20 > > Just a note that I should have included with the WGLC. > > =20 > > The intention with this document is to republish on a recurring > > basis, and therefore to keep it up to date (say once a=20 > year or so). > > =20 > > The 1st versions is intended to include gruu, outbound=20 > and ice, but > > apart from that, anything that is not published in that=20 > timeframe > > will probably be removed unless there is exceptional=20 > justification > > for keeping it, with the idea that it will appear in=20 > the next version. >=20 > This is news to me... >=20 > What I thought would happen is that we have references to=20 > everything in the guide, and when the guide appears as an=20 > RFC, whatever references are at RFC status at that time, get=20 > RFC numbers. Everything else is referenced as an I-D. >=20 > I think you are suggesting that, instead, when we send this=20 > to IESG, we remove any content and references associated with=20 > documents which are not on track to publication around the=20 > same timeframe as hitchhikers guide itself. Indeed it will=20 > require us to change those references to normative in order=20 > to get rfc-editor to do a REF hold on hitchhikers till its=20 > dependencies clear. >=20 > If my interpretation is correct, my next question is whether=20 > this applies to just the core specs or all of the specs. >=20 > I personally would rather leave the document as is - include=20 > everything, and recognize that some references will be drafts=20 > rather than RFCs when hitchhikers is published. Next round of=20 > hitchhikers will have more of them as RFCs. >=20 > -Jonathan R. >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www1.ietf.org/mailman/listinfo/rai >=20 _______________________________________________ RAI mailing list RAI@ietf.org https://www1.ietf.org/mailman/listinfo/rai From rai-bounces@ietf.org Thu Nov 01 11:11:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inbgy-0005KC-5A; Thu, 01 Nov 2007 11:10:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inbgt-0005Hb-OW; Thu, 01 Nov 2007 11:10:39 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Inbgt-0003Tl-7m; Thu, 01 Nov 2007 11:10:39 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQU00LRQ25Q20@usaga01-in.huawei.com>; Thu, 01 Nov 2007 08:10:38 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JQU00MZB25OV3@usaga01-in.huawei.com>; Thu, 01 Nov 2007 08:10:38 -0700 (PDT) Date: Thu, 01 Nov 2007 10:09:58 -0500 From: Spencer Dawkins Subject: Re: [Sip] Re: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 To: rai@ietf.org, sip@ietf.org Message-id: <0b5a01c81c99$447b1470$6401a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <5D1A7985295922448D5550C94DE291800188609F@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF12DC4A04@zrc2hxm0.corp.nortel.com> <4729E458.6030703@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rai-bounces@ietf.org I was going to respond offlist, but Brian's already onlist with followups, so... I would like to support Jonathan's understanding here. I thought the Hitchhiker's Guide was very useful when it appeared, and have reviewed multiple versions of the draft since then. I would like for it to be "out there", and I would like for each revision to be as helpful as we can make it. (1) delaying publication due to REF-HOLD for completed-and-approved specifications to pass through RFC Editor processing doesn't seem helpful, while (2) removing references to completed-and-approved specifications that don't have RFC numbers assigned seems even LESS helpful. I see no problem with references to completed-and-approved IDs in an Informational RFC that we expect to update anyway. My understanding is that these IDs really ARE stable references - they no longer expire, and are replaced with "was published as RFC XXXX" boilerplate when an RFC IS available. One recent redirection looks like this (appears as http://www.ietf.org/internet-drafts/draft-ietf-mip6-dsmip-problem-04.txt) "This Internet-Draft, draft-ietf-mip6-dsmip-problem-03.txt, was published as an Informational RFC, RFC 4977 (http://www.ietf.org/rfc/rfc4977.txt), on 2007-8-29." As long as we publish specifications the way we publish them, there's going to be a delay, measured in months, for significant specifications in RFC Editor processing/Auth48/etc. REF-HOLD for the Hitchhiker's Guide makes no sense. Thanks, Spencer From: "Jonathan Rosenberg" > inline: > > Francois Audet wrote: >> What about SIPS, which is already in hitchiker's guide, and which is >> waiting on outbound because of a normative reference? >> >> ------------------------------------------------------------------------ >> *From:* DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] >> *Sent:* Tuesday, October 30, 2007 01:01 >> *To:* Avshalom Houri; rai@ietf.org; sip@ietf.org; jdrosen@cisco.com >> *Subject:* RE: [RAI] RAI review of >> draft-ietf-sip-hitchhikers-guide-03 >> >> (As WG chair) >> Just a note that I should have included with the WGLC. >> The intention with this document is to republish on a recurring >> basis, and therefore to keep it up to date (say once a year or so). >> The 1st versions is intended to include gruu, outbound and ice, but >> apart from that, anything that is not published in that timeframe >> will probably be removed unless there is exceptional justification >> for keeping it, with the idea that it will appear in the next >> version. > > This is news to me... > > What I thought would happen is that we have references to everything in > the guide, and when the guide appears as an RFC, whatever references are > at RFC status at that time, get RFC numbers. Everything else is referenced > as an I-D. > > I think you are suggesting that, instead, when we send this to IESG, we > remove any content and references associated with documents which are not > on track to publication around the same timeframe as hitchhikers guide > itself. Indeed it will require us to change those references to normative > in order to get rfc-editor to do a REF hold on hitchhikers till its > dependencies clear. > > If my interpretation is correct, my next question is whether this applies > to just the core specs or all of the specs. > > I personally would rather leave the document as is - include everything, > and recognize that some references will be drafts rather than RFCs when > hitchhikers is published. Next round of hitchhikers will have more of them > as RFCs. _______________________________________________ RAI mailing list RAI@ietf.org https://www1.ietf.org/mailman/listinfo/rai From rai-bounces@ietf.org Thu Nov 01 11:12:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inbik-0007Q7-2K; Thu, 01 Nov 2007 11:12:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inbih-0007NN-By; Thu, 01 Nov 2007 11:12:31 -0400 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InbiZ-00050P-W5; Thu, 01 Nov 2007 11:12:31 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.8/8.13.8) with ESMTP id lA1FCNrC105466; Thu, 1 Nov 2007 15:12:23 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id lA1FCNsS2166952; Thu, 1 Nov 2007 16:12:23 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id lA1FCM33005124; Thu, 1 Nov 2007 16:12:23 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id lA1FCMbS005121; Thu, 1 Nov 2007 16:12:22 +0100 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF12E572BD@zrc2hxm0.corp.nortel.com> References: <5D1A7985295922448D5550C94DE291800188609F@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF12DC4A04@zrc2hxm0.corp.nortel.com> <4729E458.6030703@cisco.com> <1ECE0EB50388174790F9694F77522CCF12E572BD@zrc2hxm0.corp.nortel.com> To: "Brian Stucker" MIME-Version: 1.0 Subject: RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 X-Mailer: Lotus Notes Release 8.0NP August 02, 2007 From: Avshalom Houri Message-ID: Date: Thu, 1 Nov 2007 17:12:19 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 01/11/2007 17:12:22, Serialize complete at 01/11/2007 17:12:22 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8 Cc: sip@ietf.org, rai@ietf.org X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0432910785==" Errors-To: rai-bounces@ietf.org This is a multipart message in MIME format. --===============0432910785== Content-Type: multipart/alternative; boundary="=_alternative 005387EDC2257386_=" This is a multipart message in MIME format. --=_alternative 005387EDC2257386_= Content-Type: text/plain; charset="US-ASCII" I also think that leaving the references to the drafts is important. I do not know what should be the actual mechanism but it will be like hitchhiking a space ship that has many of its windows covered, it will be hard to see where we are flying to. --Avshalom "Brian Stucker" 01/11/2007 16:57 To "Jonathan Rosenberg" , "Francois Audet" cc , Avshalom Houri/Haifa/IBM@IBMIL, Subject RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 I would also prefer that I-D references be left in the document. It's very helpful to the community to not only know where SIP is at when you read the guide, but to know where it's headed. If for no other reason than it prevents someone from thinking they've discovered a novel problem and go off implementing a solution parallel to what will soon (hopefully) be an RFC. Likewise, if they find that the I-D is incomplete, it gives them a reference to make comments against that they may not have otherwise discovered. It's an informative document. What if we just copy paragraphs two and three of from the boilerplate "status of this memo" into the introduction as a warning to those who read the document later as an RFC that I-D's referenced by the guide can change. Is there any harm in doing this? Regards, Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Thursday, November 01, 2007 9:36 AM > To: Audet, Francois (SC100:3055) > Cc: sip@ietf.org; Avshalom Houri; rai@ietf.org > Subject: Re: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 > > inline: > > Francois Audet wrote: > > What about SIPS, which is already in hitchiker's guide, and > which is > > waiting on outbound because of a normative reference? > > > > > -------------------------------------------------------------- > ---------- > > *From:* DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > *Sent:* Tuesday, October 30, 2007 01:01 > > *To:* Avshalom Houri; rai@ietf.org; sip@ietf.org; > jdrosen@cisco.com > > *Subject:* RE: [RAI] RAI review of > > draft-ietf-sip-hitchhikers-guide-03 > > > > (As WG chair) > > > > Just a note that I should have included with the WGLC. > > > > The intention with this document is to republish on a recurring > > basis, and therefore to keep it up to date (say once a > year or so). > > > > The 1st versions is intended to include gruu, outbound > and ice, but > > apart from that, anything that is not published in that > timeframe > > will probably be removed unless there is exceptional > justification > > for keeping it, with the idea that it will appear in > the next version. > > This is news to me... > > What I thought would happen is that we have references to > everything in the guide, and when the guide appears as an > RFC, whatever references are at RFC status at that time, get > RFC numbers. Everything else is referenced as an I-D. > > I think you are suggesting that, instead, when we send this > to IESG, we remove any content and references associated with > documents which are not on track to publication around the > same timeframe as hitchhikers guide itself. Indeed it will > require us to change those references to normative in order > to get rfc-editor to do a REF hold on hitchhikers till its > dependencies clear. > > If my interpretation is correct, my next question is whether > this applies to just the core specs or all of the specs. > > I personally would rather leave the document as is - include > everything, and recognize that some references will be drafts > rather than RFCs when hitchhikers is published. Next round of > hitchhikers will have more of them as RFCs. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www1.ietf.org/mailman/listinfo/rai > --=_alternative 005387EDC2257386_= Content-Type: text/html; charset="US-ASCII"
I also think that leaving the references to the drafts is important.
I do not know what should be the actual mechanism but it will be like
hitchhiking a space ship that has many of its windows covered,
it will be hard to see where we are flying to.

--Avshalom


"Brian Stucker" <bstucker@nortel.com>

01/11/2007 16:57

To
"Jonathan Rosenberg" <jdrosen@cisco.com>, "Francois Audet" <audet@nortel.com>
cc
<sip@ietf.org>, Avshalom Houri/Haifa/IBM@IBMIL, <rai@ietf.org>
Subject
RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03





I would also prefer that I-D references be left in the document. It's
very helpful to the community to not only know where SIP is at when you
read the guide, but to know where it's headed. If for no other reason
than it prevents someone from thinking they've discovered a novel
problem and go off implementing a solution parallel to what will soon
(hopefully) be an RFC. Likewise, if they find that the I-D is
incomplete, it gives them a reference to make comments against that they
may not have otherwise discovered.

It's an informative document. What if we just copy paragraphs two and
three of from the boilerplate "status of this memo" into the
introduction as a warning to those who read the document later as an RFC
that I-D's referenced by the guide can change.

Is there any harm in doing this?

Regards,
Brian

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]
> Sent: Thursday, November 01, 2007 9:36 AM
> To: Audet, Francois (SC100:3055)
> Cc: sip@ietf.org; Avshalom Houri; rai@ietf.org
> Subject: Re: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03
>
> inline:
>
> Francois Audet wrote:
> > What about SIPS, which is already in hitchiker's guide, and
> which is
> > waiting on outbound because of a normative reference?
> >
> >    
> --------------------------------------------------------------
> ----------
> >     *From:* DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]
> >     *Sent:* Tuesday, October 30, 2007 01:01
> >     *To:* Avshalom Houri; rai@ietf.org; sip@ietf.org;
> jdrosen@cisco.com
> >     *Subject:* RE: [RAI] RAI review of
> > draft-ietf-sip-hitchhikers-guide-03
> >
> >     (As WG chair)
> >      
> >     Just a note that I should have included with the WGLC.
> >      
> >     The intention with this document is to republish on a recurring
> >     basis, and therefore to keep it up to date (say once a
> year or so).
> >      
> >     The 1st versions is intended to include gruu, outbound
> and ice, but
> >     apart from that, anything that is not published in that
> timeframe
> >     will probably be removed unless there is exceptional
> justification
> >     for keeping it, with the idea that it will appear in
> the next version.
>
> This is news to me...
>
> What I thought would happen is that we have references to
> everything in the guide, and when the guide appears as an
> RFC, whatever references are at RFC status at that time, get
> RFC numbers. Everything else is referenced as an I-D.
>
> I think you are suggesting that, instead, when we send this
> to IESG, we remove any content and references associated with
> documents which are not on track to publication around the
> same timeframe as hitchhikers guide itself. Indeed it will
> require us to change those references to normative in order
> to get rfc-editor to do a REF hold on hitchhikers till its
> dependencies clear.
>
> If my interpretation is correct, my next question is whether
> this applies to just the core specs or all of the specs.
>
> I personally would rather leave the document as is - include
> everything, and recognize that some references will be drafts
> rather than RFCs when hitchhikers is published. Next round of
> hitchhikers will have more of them as RFCs.
>
> -Jonathan R.
>
> --
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Cisco Fellow                                   Parsippany, NJ
> 07054-2711
> Cisco Systems
> jdrosen@cisco.com                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com
>
> _______________________________________________
> RAI mailing list
> RAI@ietf.org
> https://www1.ietf.org/mailman/listinfo/rai
>

--=_alternative 005387EDC2257386_=-- --===============0432910785== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAI mailing list RAI@ietf.org https://www1.ietf.org/mailman/listinfo/rai --===============0432910785==-- From rai-bounces@ietf.org Thu Nov 01 12:10:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IncbY-0000Os-54; Thu, 01 Nov 2007 12:09:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IncbU-0000NG-2h; Thu, 01 Nov 2007 12:09:08 -0400 Received: from ottgw.pt.com ([209.217.107.194] helo=grandpa.ottawa.pt.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IncbQ-0007SL-SS; Thu, 01 Nov 2007 12:09:08 -0400 Received: from [10.81.15.111] (unknown [10.81.15.111]) by grandpa.ottawa.pt.com (Postfix) with ESMTP id 5258DD71A3; Thu, 1 Nov 2007 11:45:07 -0400 (EDT) Message-ID: <4729FA13.1060409@pt.com> Date: Thu, 01 Nov 2007 12:08:51 -0400 From: Andrew Booth User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Avshalom Houri Subject: Re: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 References: <5D1A7985295922448D5550C94DE291800188609F@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF12DC4A04@zrc2hxm0.corp.nortel.com> <4729E458.6030703@cisco.com> <1ECE0EB50388174790F9694F77522CCF12E572BD@zrc2hxm0.corp.nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: sip@ietf.org, rai@ietf.org X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rai-bounces@ietf.org I appologise in advance if this comment is not helpful. In the SIGTRAN mailing list there was a similar issue for some RFC, and if I recall correctly the compromize was that I-D's could be listed as Informational References but not Normative References. Is this an option here? Andrew Avshalom Houri wrote: > > I also think that leaving the references to the drafts is important. > I do not know what should be the actual mechanism but it will be like > hitchhiking a space ship that has many of its windows covered, > it will be hard to see where we are flying to. > > --Avshalom > > > > > > > > *"Brian Stucker" * > > 01/11/2007 16:57 > > > To > "Jonathan Rosenberg" , "Francois Audet" > > cc > , Avshalom Houri/Haifa/IBM@IBMIL, > Subject > RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 > > > > > > > > > > I would also prefer that I-D references be left in the document. It's > very helpful to the community to not only know where SIP is at when you > read the guide, but to know where it's headed. If for no other reason > than it prevents someone from thinking they've discovered a novel > problem and go off implementing a solution parallel to what will soon > (hopefully) be an RFC. Likewise, if they find that the I-D is > incomplete, it gives them a reference to make comments against that they > may not have otherwise discovered. > > It's an informative document. What if we just copy paragraphs two and > three of from the boilerplate "status of this memo" into the > introduction as a warning to those who read the document later as an RFC > that I-D's referenced by the guide can change. > > Is there any harm in doing this? > > Regards, > Brian > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > Sent: Thursday, November 01, 2007 9:36 AM > > To: Audet, Francois (SC100:3055) > > Cc: sip@ietf.org; Avshalom Houri; rai@ietf.org > > Subject: Re: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 > > > > inline: > > > > Francois Audet wrote: > > > What about SIPS, which is already in hitchiker's guide, and > > which is > > > waiting on outbound because of a normative reference? > > > > > > > > -------------------------------------------------------------- > > ---------- > > > *From:* DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > > *Sent:* Tuesday, October 30, 2007 01:01 > > > *To:* Avshalom Houri; rai@ietf.org; sip@ietf.org; > > jdrosen@cisco.com > > > *Subject:* RE: [RAI] RAI review of > > > draft-ietf-sip-hitchhikers-guide-03 > > > > > > (As WG chair) > > > > > > Just a note that I should have included with the WGLC. > > > > > > The intention with this document is to republish on a recurring > > > basis, and therefore to keep it up to date (say once a > > year or so). > > > > > > The 1st versions is intended to include gruu, outbound > > and ice, but > > > apart from that, anything that is not published in that > > timeframe > > > will probably be removed unless there is exceptional > > justification > > > for keeping it, with the idea that it will appear in > > the next version. > > > > This is news to me... > > > > What I thought would happen is that we have references to > > everything in the guide, and when the guide appears as an > > RFC, whatever references are at RFC status at that time, get > > RFC numbers. Everything else is referenced as an I-D. > > > > I think you are suggesting that, instead, when we send this > > to IESG, we remove any content and references associated with > > documents which are not on track to publication around the > > same timeframe as hitchhikers guide itself. Indeed it will > > require us to change those references to normative in order > > to get rfc-editor to do a REF hold on hitchhikers till its > > dependencies clear. > > > > If my interpretation is correct, my next question is whether > > this applies to just the core specs or all of the specs. > > > > I personally would rather leave the document as is - include > > everything, and recognize that some references will be drafts > > rather than RFCs when hitchhikers is published. Next round of > > hitchhikers will have more of them as RFCs. > > > > -Jonathan R. > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ > > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com FAX: (973) 952-5050 > > http://www.jdrosen.net > PHONE: (973) 952-5000 > > http://www.cisco.com > > > > _______________________________________________ > > RAI mailing list > > RAI@ietf.org > > https://www1.ietf.org/mailman/listinfo/rai > > > > ------------------------------------------------------------------------ > > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www1.ietf.org/mailman/listinfo/rai > _______________________________________________ RAI mailing list RAI@ietf.org https://www1.ietf.org/mailman/listinfo/rai From rai-bounces@ietf.org Thu Nov 01 12:26:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Incrg-0005ct-MW; Thu, 01 Nov 2007 12:25:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Incre-0005c5-UH; Thu, 01 Nov 2007 12:25:50 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IncrX-00080a-Rf; Thu, 01 Nov 2007 12:25:50 -0400 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 lA1GPJk13657; Thu, 1 Nov 2007 16:25:19 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 Subject: RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 Date: Thu, 1 Nov 2007 11:25:10 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF12EADA8C@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF12E572BD@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 Thread-Index: AcgclWSXcUNjORGwTPG/Q8fZUb7hqQAATCigAAM/CvA= References: <5D1A7985295922448D5550C94DE291800188609F@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF12DC4A04@zrc2hxm0.corp.nortel.com> <4729E458.6030703@cisco.com> <1ECE0EB50388174790F9694F77522CCF12E572BD@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Brian Stucker" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: sip@ietf.org, rai@ietf.org, Avshalom Houri X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rai-bounces@ietf.org Same here. I prefer the whole list. I checked again the list in the current document, and I didn't see anything that was "controversial" (i.e., all the drafts quoted are mature working group items). If some of them were considered immature, we should remove them. But otherwise, I'd rather we keep them in.=20 > -----Original Message----- > From: Stucker, Brian (RICH1:AR00)=20 > Sent: Thursday, November 01, 2007 07:58 > To: Jonathan Rosenberg; Audet, Francois (SC100:3055) > Cc: sip@ietf.org; Avshalom Houri; rai@ietf.org > Subject: RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 >=20 > I would also prefer that I-D references be left in the=20 > document. It's very helpful to the community to not only know=20 > where SIP is at when you read the guide, but to know where=20 > it's headed. If for no other reason than it prevents someone=20 > from thinking they've discovered a novel problem and go off=20 > implementing a solution parallel to what will soon=20 > (hopefully) be an RFC. Likewise, if they find that the I-D is=20 > incomplete, it gives them a reference to make comments=20 > against that they may not have otherwise discovered. >=20 > It's an informative document. What if we just copy paragraphs=20 > two and three of from the boilerplate "status of this memo"=20 > into the introduction as a warning to those who read the=20 > document later as an RFC that I-D's referenced by the guide=20 > can change.=20 >=20 > Is there any harm in doing this? >=20 > Regards, > Brian=20 >=20 > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > Sent: Thursday, November 01, 2007 9:36 AM > > To: Audet, Francois (SC100:3055) > > Cc: sip@ietf.org; Avshalom Houri; rai@ietf.org > > Subject: Re: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 > >=20 > > inline: > >=20 > > Francois Audet wrote: > > > What about SIPS, which is already in hitchiker's guide, and > > which is > > > waiting on outbound because of a normative reference? > > >=20 > > > =20 > > -------------------------------------------------------------- > > ---------- > > > *From:* DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > > *Sent:* Tuesday, October 30, 2007 01:01 > > > *To:* Avshalom Houri; rai@ietf.org; sip@ietf.org; > > jdrosen@cisco.com > > > *Subject:* RE: [RAI] RAI review of > > > draft-ietf-sip-hitchhikers-guide-03 > > >=20 > > > (As WG chair) > > > =20 > > > Just a note that I should have included with the WGLC. > > > =20 > > > The intention with this document is to republish on a=20 > recurring > > > basis, and therefore to keep it up to date (say once a > > year or so). > > > =20 > > > The 1st versions is intended to include gruu, outbound > > and ice, but > > > apart from that, anything that is not published in that > > timeframe > > > will probably be removed unless there is exceptional > > justification > > > for keeping it, with the idea that it will appear in > > the next version. > >=20 > > This is news to me... > >=20 > > What I thought would happen is that we have references to=20 > everything=20 > > in the guide, and when the guide appears as an RFC, whatever=20 > > references are at RFC status at that time, get RFC numbers.=20 > Everything=20 > > else is referenced as an I-D. > >=20 > > I think you are suggesting that, instead, when we send this=20 > to IESG,=20 > > we remove any content and references associated with=20 > documents which=20 > > are not on track to publication around the same timeframe as=20 > > hitchhikers guide itself. Indeed it will require us to change those=20 > > references to normative in order to get rfc-editor to do a=20 > REF hold on=20 > > hitchhikers till its dependencies clear. > >=20 > > If my interpretation is correct, my next question is whether this=20 > > applies to just the core specs or all of the specs. > >=20 > > I personally would rather leave the document as is - include=20 > > everything, and recognize that some references will be=20 > drafts rather=20 > > than RFCs when hitchhikers is published. Next round of hitchhikers=20 > > will have more of them as RFCs. > >=20 > > -Jonathan R. > >=20 > > --=20 > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ=20 > > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.com > >=20 > > _______________________________________________ > > RAI mailing list > > RAI@ietf.org > > https://www1.ietf.org/mailman/listinfo/rai > >=20 >=20 _______________________________________________ RAI mailing list RAI@ietf.org https://www1.ietf.org/mailman/listinfo/rai From rai-bounces@ietf.org Thu Nov 01 13:30:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Indro-00024z-6z; Thu, 01 Nov 2007 13:30:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Indrl-000240-Vk; Thu, 01 Nov 2007 13:30:01 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Indrk-0001qH-OI; Thu, 01 Nov 2007 13:30:01 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQU00LJT8M020@usaga01-in.huawei.com>; Thu, 01 Nov 2007 10:30:00 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JQU00HCJ8LY5B@usaga01-in.huawei.com>; Thu, 01 Nov 2007 10:30:00 -0700 (PDT) Date: Thu, 01 Nov 2007 12:29:19 -0500 From: Spencer Dawkins Subject: Re: [Sip] RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 To: sip@ietf.org, rai@ietf.org Message-id: <0bde01c81cac$bc7e0ff0$6401a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <5D1A7985295922448D5550C94DE291800188609F@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF12DC4A04@zrc2hxm0.corp.nortel.com> <4729E458.6030703@cisco.com> <1ECE0EB50388174790F9694F77522CCF12E572BD@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF12EADA8C@zrc2hxm0.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rai-bounces@ietf.org OK, two categories of drafts here. If it's completed/approved, absolutely treat it like an RFC. If it's mature but hasn't been completed/approved, it seems reasonable to put this in an "upcoming" section, where it's easier to provide guidance about "subject to change". Thanks, Spencer ----- Original Message ----- From: "Francois Audet" To: "Brian Stucker" ; "Jonathan Rosenberg" Cc: ; ; "Avshalom Houri" Sent: Thursday, November 01, 2007 11:25 AM Subject: [Sip] RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 Same here. I prefer the whole list. I checked again the list in the current document, and I didn't see anything that was "controversial" (i.e., all the drafts quoted are mature working group items). If some of them were considered immature, we should remove them. But otherwise, I'd rather we keep them in. > -----Original Message----- > From: Stucker, Brian (RICH1:AR00) > Sent: Thursday, November 01, 2007 07:58 > To: Jonathan Rosenberg; Audet, Francois (SC100:3055) > Cc: sip@ietf.org; Avshalom Houri; rai@ietf.org > Subject: RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 > > I would also prefer that I-D references be left in the > document. It's very helpful to the community to not only know > where SIP is at when you read the guide, but to know where > it's headed. If for no other reason than it prevents someone > from thinking they've discovered a novel problem and go off > implementing a solution parallel to what will soon > (hopefully) be an RFC. Likewise, if they find that the I-D is > incomplete, it gives them a reference to make comments > against that they may not have otherwise discovered. > > It's an informative document. What if we just copy paragraphs > two and three of from the boilerplate "status of this memo" > into the introduction as a warning to those who read the > document later as an RFC that I-D's referenced by the guide > can change. > > Is there any harm in doing this? > > Regards, > Brian > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > Sent: Thursday, November 01, 2007 9:36 AM > > To: Audet, Francois (SC100:3055) > > Cc: sip@ietf.org; Avshalom Houri; rai@ietf.org > > Subject: Re: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 > > > > inline: > > > > Francois Audet wrote: > > > What about SIPS, which is already in hitchiker's guide, and > > which is > > > waiting on outbound because of a normative reference? > > > > > > > > -------------------------------------------------------------- > > ---------- > > > *From:* DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > > *Sent:* Tuesday, October 30, 2007 01:01 > > > *To:* Avshalom Houri; rai@ietf.org; sip@ietf.org; > > jdrosen@cisco.com > > > *Subject:* RE: [RAI] RAI review of > > > draft-ietf-sip-hitchhikers-guide-03 > > > > > > (As WG chair) > > > > > > Just a note that I should have included with the WGLC. > > > > > > The intention with this document is to republish on a > recurring > > > basis, and therefore to keep it up to date (say once a > > year or so). > > > > > > The 1st versions is intended to include gruu, outbound > > and ice, but > > > apart from that, anything that is not published in that > > timeframe > > > will probably be removed unless there is exceptional > > justification > > > for keeping it, with the idea that it will appear in > > the next version. > > > > This is news to me... > > > > What I thought would happen is that we have references to > everything > > in the guide, and when the guide appears as an RFC, whatever > > references are at RFC status at that time, get RFC numbers. > Everything > > else is referenced as an I-D. > > > > I think you are suggesting that, instead, when we send this > to IESG, > > we remove any content and references associated with > documents which > > are not on track to publication around the same timeframe as > > hitchhikers guide itself. Indeed it will require us to change those > > references to normative in order to get rfc-editor to do a > REF hold on > > hitchhikers till its dependencies clear. > > > > If my interpretation is correct, my next question is whether this > > applies to just the core specs or all of the specs. > > > > I personally would rather leave the document as is - include > > everything, and recognize that some references will be > drafts rather > > than RFCs when hitchhikers is published. Next round of hitchhikers > > will have more of them as RFCs. > > > > -Jonathan R. > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ > > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.com > > > > _______________________________________________ > > RAI mailing list > > RAI@ietf.org > > https://www1.ietf.org/mailman/listinfo/rai > > > _______________________________________________ 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 _______________________________________________ RAI mailing list RAI@ietf.org https://www1.ietf.org/mailman/listinfo/rai From rai-bounces@ietf.org Thu Nov 01 16:46:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IngvX-0001A1-Ul; Thu, 01 Nov 2007 16:46:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IngvV-00018Q-Gb; Thu, 01 Nov 2007 16:46:05 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IngvU-0001be-2g; Thu, 01 Nov 2007 16:46:05 -0400 X-IronPort-AV: E=Sophos;i="4.21,359,1188802800"; d="scan'208";a="245677252" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 01 Nov 2007 13:46:03 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lA1Kk35h031204; Thu, 1 Nov 2007 13:46:03 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lA1KjxXt012564; Thu, 1 Nov 2007 20:46:03 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 13:46:00 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 13:46:00 -0700 Message-ID: <472A3B25.7090008@cisco.com> Date: Thu, 01 Nov 2007 16:46:29 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Francois Audet Subject: Re: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 References: <5D1A7985295922448D5550C94DE291800188609F@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF12DC4A04@zrc2hxm0.corp.nortel.com> <4729E458.6030703@cisco.com> <1ECE0EB50388174790F9694F77522CCF12E572BD@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF12EADA8C@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF12EADA8C@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2007 20:46:00.0717 (UTC) FILETIME=[36201BD0:01C81CC8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5475; t=1193949963; x=1194813963; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[RAI]=20RAI=20review=20of=20draft-ietf-sip-hitchhiker s-guide-03 |Sender:=20; bh=yt77iIsD8hcpISNjaD7QdFhmf1Kzw2XvyGzoLN9gH6g=; b=qjjUmHBhNNPhe33NFPet57i1oYAkLYQHQclVzoyEehSn/BN2WSnbDYxzZ1s0Nbgs6CBFXBIB pgIrgb3hMplKdKEBdGbOBzRBeNdSckXC3QMpvOCsvJ2LPRDX7TYRJeXL; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: sip@ietf.org, rai@ietf.org, Avshalom Houri X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rai-bounces@ietf.org The document includes any normative sip extension once it has been adopted as a WG Item. So this does include stuff that is "earlier" in the process; for example the sip-saml stuff which (IMHO) is still a little on the early side. But once it is a wg item it gets in there. I still think its fine to publish hitchhikers as an RFC with those as references (to drafts). -Jonathan R. Francois Audet wrote: > Same here. I prefer the whole list. > > I checked again the list in the current document, and I didn't see > anything that was "controversial" (i.e., all the drafts quoted are > mature working group items). > > If some of them were considered immature, we should remove them. But > otherwise, I'd rather we keep them in. > >> -----Original Message----- >> From: Stucker, Brian (RICH1:AR00) >> Sent: Thursday, November 01, 2007 07:58 >> To: Jonathan Rosenberg; Audet, Francois (SC100:3055) >> Cc: sip@ietf.org; Avshalom Houri; rai@ietf.org >> Subject: RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 >> >> I would also prefer that I-D references be left in the >> document. It's very helpful to the community to not only know >> where SIP is at when you read the guide, but to know where >> it's headed. If for no other reason than it prevents someone >> from thinking they've discovered a novel problem and go off >> implementing a solution parallel to what will soon >> (hopefully) be an RFC. Likewise, if they find that the I-D is >> incomplete, it gives them a reference to make comments >> against that they may not have otherwise discovered. >> >> It's an informative document. What if we just copy paragraphs >> two and three of from the boilerplate "status of this memo" >> into the introduction as a warning to those who read the >> document later as an RFC that I-D's referenced by the guide >> can change. >> >> Is there any harm in doing this? >> >> Regards, >> Brian >> >>> -----Original Message----- >>> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>> Sent: Thursday, November 01, 2007 9:36 AM >>> To: Audet, Francois (SC100:3055) >>> Cc: sip@ietf.org; Avshalom Houri; rai@ietf.org >>> Subject: Re: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 >>> >>> inline: >>> >>> Francois Audet wrote: >>>> What about SIPS, which is already in hitchiker's guide, and >>> which is >>>> waiting on outbound because of a normative reference? >>>> >>>> >>> -------------------------------------------------------------- >>> ---------- >>>> *From:* DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] >>>> *Sent:* Tuesday, October 30, 2007 01:01 >>>> *To:* Avshalom Houri; rai@ietf.org; sip@ietf.org; >>> jdrosen@cisco.com >>>> *Subject:* RE: [RAI] RAI review of >>>> draft-ietf-sip-hitchhikers-guide-03 >>>> >>>> (As WG chair) >>>> >>>> Just a note that I should have included with the WGLC. >>>> >>>> The intention with this document is to republish on a >> recurring >>>> basis, and therefore to keep it up to date (say once a >>> year or so). >>>> >>>> The 1st versions is intended to include gruu, outbound >>> and ice, but >>>> apart from that, anything that is not published in that >>> timeframe >>>> will probably be removed unless there is exceptional >>> justification >>>> for keeping it, with the idea that it will appear in >>> the next version. >>> >>> This is news to me... >>> >>> What I thought would happen is that we have references to >> everything >>> in the guide, and when the guide appears as an RFC, whatever >>> references are at RFC status at that time, get RFC numbers. >> Everything >>> else is referenced as an I-D. >>> >>> I think you are suggesting that, instead, when we send this >> to IESG, >>> we remove any content and references associated with >> documents which >>> are not on track to publication around the same timeframe as >>> hitchhikers guide itself. Indeed it will require us to change those >>> references to normative in order to get rfc-editor to do a >> REF hold on >>> hitchhikers till its dependencies clear. >>> >>> If my interpretation is correct, my next question is whether this >>> applies to just the core specs or all of the specs. >>> >>> I personally would rather leave the document as is - include >>> everything, and recognize that some references will be >> drafts rather >>> than RFCs when hitchhikers is published. Next round of hitchhikers >>> will have more of them as RFCs. >>> >>> -Jonathan R. >>> >>> -- >>> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>> Cisco Fellow Parsippany, NJ >>> 07054-2711 >>> Cisco Systems >>> jdrosen@cisco.com FAX: (973) 952-5050 >>> http://www.jdrosen.net PHONE: (973) 952-5000 >>> http://www.cisco.com >>> >>> _______________________________________________ >>> RAI mailing list >>> RAI@ietf.org >>> https://www1.ietf.org/mailman/listinfo/rai >>> > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ RAI mailing list RAI@ietf.org https://www1.ietf.org/mailman/listinfo/rai From rai-bounces@ietf.org Thu Nov 01 16:52:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inh14-0005I7-Hk; Thu, 01 Nov 2007 16:51:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inh11-0005Ff-Qx; Thu, 01 Nov 2007 16:51:47 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Inh0v-0001o2-L9; Thu, 01 Nov 2007 16:51:47 -0400 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 lA1KpMk12309; Thu, 1 Nov 2007 20:51:22 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 Subject: RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 Date: Thu, 1 Nov 2007 15:51:01 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF12EAE461@zrc2hxm0.corp.nortel.com> In-Reply-To: <472A3B25.7090008@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 Thread-Index: AcgcyFs1FpUX8ixjRlyFwQxl1vV4NgAAF65A References: <5D1A7985295922448D5550C94DE291800188609F@DEEXC1U01.de.lucent.com> <1ECE0EB50388174790F9694F77522CCF12DC4A04@zrc2hxm0.corp.nortel.com> <4729E458.6030703@cisco.com> <1ECE0EB50388174790F9694F77522CCF12E572BD@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF12EADA8C@zrc2hxm0.corp.nortel.com> <472A3B25.7090008@cisco.com> From: "Francois Audet" To: "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: sip@ietf.org, rai@ietf.org, Avshalom Houri X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rai-bounces@ietf.org I'm fine with it. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Thursday, November 01, 2007 13:46 > To: Audet, Francois (SC100:3055) > Cc: Stucker, Brian (RICH1:AR00); sip@ietf.org; Avshalom=20 > Houri; rai@ietf.org > Subject: Re: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 >=20 > The document includes any normative sip extension once it has=20 > been adopted as a WG Item. So this does include stuff that is=20 > "earlier" in the process; for example the sip-saml stuff=20 > which (IMHO) is still a little on the early side. But once it=20 > is a wg item it gets in there. I still think its fine to=20 > publish hitchhikers as an RFC with those as references (to drafts). _______________________________________________ RAI mailing list RAI@ietf.org https://www1.ietf.org/mailman/listinfo/rai From rai-bounces@ietf.org Sat Nov 03 12:03:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoLTU-0001LU-Gd; Sat, 03 Nov 2007 12:03:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoLTS-0001JZ-AN; Sat, 03 Nov 2007 12:03:50 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IoLTR-0004JA-1Q; Sat, 03 Nov 2007 12:03:50 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id lA3G3bui012703; Sat, 3 Nov 2007 11:03:45 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 3 Nov 2007 11:03:42 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.26]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 3 Nov 2007 17:03:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 Date: Sat, 3 Nov 2007 17:03:40 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918001886B88@DEEXC1U01.de.lucent.com> In-Reply-To: <472A3B25.7090008@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 Thread-Index: AcgcyI5xeMQlnEj7RTemjya+DxQtbQBaFyXw References: <5D1A7985295922448D5550C94DE291800188609F@DEEXC1U01.de.lucent.com><1ECE0EB50388174790F9694F77522CCF12DC4A04@zrc2hxm0.corp.nortel.com><4729E458.6030703@cisco.com><1ECE0EB50388174790F9694F77522CCF12E572BD@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12EADA8C@zrc2hxm0.corp.nortel.com> <472A3B25.7090008@cisco.com> From: "DRAGE, Keith \(Keith\)" To: "Jonathan Rosenberg" , "Francois Audet" X-OriginalArrivalTime: 03 Nov 2007 16:03:40.0623 (UTC) FILETIME=[19DE65F0:01C81E33] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Cc: sip@ietf.org, Avshalom Houri , rai@ietf.org X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rai-bounces@ietf.org I guess I got this wrong. My starting point was a misinterpretation of Jonathan's indication way = back that we were waiting for outbound, gruu and ice before we pushed = this forward.=20 Having thought about this some more: - Yes we should include internet drafts, but with some sort of = explanation that they are included to encourage early implementation and = demonstrations of interoperability of the protocol, and thus aid in the = standards setting process; also that they identify were the WG is = targetting a solution at a particular problem space and thus aid work = towards a common solution. Additionally a warning that final IANA = assignment of codepoints does not take place until shortly before = publication, and thus codepoint assignments may change. - No we should not automatically include all WG drafts, but should = assert some form of expert review. We seem to have somewhere up to 25% = of working group documents that never make it to completion, and another = fair average that still are not going to be there in the the next 3 = years, judging by past performance. We are never obviously going to get = this 100% right, and I don't think we should spill any blood arguing = about the inclusion or exclusion of any draft, but I do think we should = attempt to preguess this and miss some of these out. We want the market = to try out the drafts in the document, but not get put off by us = marketing to them something that will never fulfil their product = timescales. - Yes we should include some author drafts, probably on the basis that = an AD has sponsored them, or is about to sponsor them, through the IESG, = and certainly if they have reached the RFC editor's queue. I suspect the above is pretty much what is in the hitchhiker draft now, = but I thought it worth at least putting it down on paper. Regards Keith > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Thursday, November 01, 2007 8:46 PM > To: Francois Audet > Cc: sip@ietf.org; rai@ietf.org; Avshalom Houri > Subject: Re: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 >=20 > The document includes any normative sip extension once it has=20 > been adopted as a WG Item. So this does include stuff that is=20 > "earlier" in the process; for example the sip-saml stuff=20 > which (IMHO) is still a little on the early side. But once it=20 > is a wg item it gets in there. I still think its fine to=20 > publish hitchhikers as an RFC with those as references (to drafts). >=20 > -Jonathan R. >=20 > Francois Audet wrote: > > Same here. I prefer the whole list. > >=20 > > I checked again the list in the current document, and I didn't see=20 > > anything that was "controversial" (i.e., all the drafts quoted are=20 > > mature working group items). > >=20 > > If some of them were considered immature, we should remove=20 > them. But=20 > > otherwise, I'd rather we keep them in. > >=20 > >> -----Original Message----- > >> From: Stucker, Brian (RICH1:AR00) > >> Sent: Thursday, November 01, 2007 07:58 > >> To: Jonathan Rosenberg; Audet, Francois (SC100:3055) > >> Cc: sip@ietf.org; Avshalom Houri; rai@ietf.org > >> Subject: RE: [RAI] RAI review of=20 > draft-ietf-sip-hitchhikers-guide-03 > >> > >> I would also prefer that I-D references be left in the=20 > document. It's=20 > >> very helpful to the community to not only know where SIP=20 > is at when=20 > >> you read the guide, but to know where it's headed. If for no other=20 > >> reason than it prevents someone from thinking they've discovered a=20 > >> novel problem and go off implementing a solution parallel to what=20 > >> will soon > >> (hopefully) be an RFC. Likewise, if they find that the I-D is=20 > >> incomplete, it gives them a reference to make comments=20 > against that=20 > >> they may not have otherwise discovered. > >> > >> It's an informative document. What if we just copy=20 > paragraphs two and=20 > >> three of from the boilerplate "status of this memo" > >> into the introduction as a warning to those who read the document=20 > >> later as an RFC that I-D's referenced by the guide can change. > >> > >> Is there any harm in doing this? > >> > >> Regards, > >> Brian > >> > >>> -----Original Message----- > >>> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > >>> Sent: Thursday, November 01, 2007 9:36 AM > >>> To: Audet, Francois (SC100:3055) > >>> Cc: sip@ietf.org; Avshalom Houri; rai@ietf.org > >>> Subject: Re: [RAI] RAI review of=20 > draft-ietf-sip-hitchhikers-guide-03 > >>> > >>> inline: > >>> > >>> Francois Audet wrote: > >>>> What about SIPS, which is already in hitchiker's guide, and > >>> which is > >>>> waiting on outbound because of a normative reference? > >>>> > >>>> =20 > >>> -------------------------------------------------------------- > >>> ---------- > >>>> *From:* DRAGE, Keith (Keith)=20 > [mailto:drage@alcatel-lucent.com] > >>>> *Sent:* Tuesday, October 30, 2007 01:01 > >>>> *To:* Avshalom Houri; rai@ietf.org; sip@ietf.org; > >>> jdrosen@cisco.com > >>>> *Subject:* RE: [RAI] RAI review of > >>>> draft-ietf-sip-hitchhikers-guide-03 > >>>> > >>>> (As WG chair) > >>>> =20 > >>>> Just a note that I should have included with the WGLC. > >>>> =20 > >>>> The intention with this document is to republish on a > >> recurring > >>>> basis, and therefore to keep it up to date (say once a > >>> year or so). > >>>> =20 > >>>> The 1st versions is intended to include gruu, outbound > >>> and ice, but > >>>> apart from that, anything that is not published in that > >>> timeframe > >>>> will probably be removed unless there is exceptional > >>> justification > >>>> for keeping it, with the idea that it will appear in > >>> the next version. > >>> > >>> This is news to me... > >>> > >>> What I thought would happen is that we have references to > >> everything > >>> in the guide, and when the guide appears as an RFC, whatever=20 > >>> references are at RFC status at that time, get RFC numbers. > >> Everything > >>> else is referenced as an I-D. > >>> > >>> I think you are suggesting that, instead, when we send this > >> to IESG, > >>> we remove any content and references associated with > >> documents which > >>> are not on track to publication around the same timeframe as=20 > >>> hitchhikers guide itself. Indeed it will require us to=20 > change those=20 > >>> references to normative in order to get rfc-editor to do a > >> REF hold on > >>> hitchhikers till its dependencies clear. > >>> > >>> If my interpretation is correct, my next question is whether this=20 > >>> applies to just the core specs or all of the specs. > >>> > >>> I personally would rather leave the document as is - include=20 > >>> everything, and recognize that some references will be > >> drafts rather > >>> than RFCs when hitchhikers is published. Next round of=20 > hitchhikers=20 > >>> will have more of them as RFCs. > >>> > >>> -Jonathan R. > >>> > >>> --=20 > >>> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >>> Cisco Fellow Parsippany, NJ=20 > >>> 07054-2711 > >>> Cisco Systems > >>> jdrosen@cisco.com FAX: =20 > (973) 952-5050 > >>> http://www.jdrosen.net PHONE:=20 > (973) 952-5000 > >>> http://www.cisco.com > >>> > >>> _______________________________________________ > >>> RAI mailing list > >>> RAI@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/rai > >>> > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www1.ietf.org/mailman/listinfo/rai >=20 _______________________________________________ RAI mailing list RAI@ietf.org https://www1.ietf.org/mailman/listinfo/rai From rai-bounces@ietf.org Thu Nov 08 16:09:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqEd8-00074L-2L; Thu, 08 Nov 2007 16:09:38 -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, 8 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" To: "Jonathan Rosenberg" , , "sip" X-Spam-Score: 0.0 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Cc: Subject: [RAI] RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rai-bounces@ietf.org Jonathan, Thanks for putting the document together. It took quite awhile to just review it!=20 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 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:=20 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.=20 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?=20 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! _______________________________________________ RAI mailing list RAI@ietf.org https://www1.ietf.org/mailman/listinfo/rai From rai-bounces@ietf.org Thu Nov 08 21:47:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqJuG-00063g-Hv; Thu, 08 Nov 2007 21:47:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqJuE-0005yq-8U; Thu, 08 Nov 2007 21:47:38 -0500 Received: from mail146.messagelabs.com ([216.82.245.131]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqJuD-0000T8-QK; Thu, 08 Nov 2007 21:47:38 -0500 X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-14.tower-146.messagelabs.com!1194576456!6074302!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 15933 invoked from network); 9 Nov 2007 02:47:36 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-14.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 9 Nov 2007 02:47:36 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id lA92laQd016151; Thu, 8 Nov 2007 21:47:36 -0500 Received: from OCCLUST04EVS1.ugd.att.com (ocst08.ugd.att.com [135.38.164.13]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id lA92lW9O016145; Thu, 8 Nov 2007 21:47:32 -0500 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, 8 Nov 2007 20:47:32 -0600 Message-ID: <28F05913385EAC43AF019413F674A0171246E604@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <4733A781.7020906@stpeter.im> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide Thread-Index: AcgiZgLRMXrGMq/pSueaEMcVUTpqcgAE5wYg References: <1ECE0EB50388174790F9694F77522CCF13132B06@zrc2hxm0.corp.nortel.com> <4733A781.7020906@stpeter.im> From: "DOLLY, MARTIN C, ATTLABS" To: "Peter Saint-Andre" , "Brian Stucker" X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: sip , rai@ietf.org Subject: [RAI] RE: [Sip] RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rai-bounces@ietf.org Do you believe that the call/session flows are normative or informative? RFC 3665 call/session flows are very good illustrative examples, but do not really depict real deployments (measured in number of calls).=20 And further, RFC 3666 does not interoperate with the PSTN, thereby not a good example. Cheers, Martin -----Original Message----- From: Peter Saint-Andre [mailto:stpeter@stpeter.im]=20 Sent: Thursday, November 08, 2007 7:19 PM To: Brian Stucker Cc: sip; rai@ietf.org Subject: Re: [Sip] RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide Brian Stucker wrote: Sorry to hijack this thread, but I'd like to second a comment that Mary Barnes made during the WGLC: http://www1.ietf.org/mail-archive/web/sip/current/msg20981.html *** It seems that all the call flow BCPs are missing and I do think those are really important and should be included in this document. The only BCP (type (B) document) listed in this document is 3PCC. The basic call flow document (RFC 3665) should be listed in section 3 (Core SIP). The PSTN call flows (RFC 3666, BCP 76) should be in PSTN Interworking section 4. The SIPPING NAT scenarios document should be in the NAT section 6. These docs are all icing on the cake IMHO and help to guide implementers in using all the other docs. *** I agree that the call flow documents are very useful and that a reference to them would be a good thing. Peter _______________________________________________ RAI mailing list RAI@ietf.org https://www1.ietf.org/mailman/listinfo/rai From rai-bounces@ietf.org Fri Nov 09 11:50:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqX3i-0003un-6Q; Fri, 09 Nov 2007 11:50:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqX3f-0003pJ-Po; Fri, 09 Nov 2007 11:50:15 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqX3d-0004hm-Ax; Fri, 09 Nov 2007 11:50:15 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lA9Go8J18750; Fri, 9 Nov 2007 16:50:08 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: Fri, 9 Nov 2007 10:50:00 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF1317953B@zrc2hxm0.corp.nortel.com> In-Reply-To: <28F05913385EAC43AF019413F674A0171246E604@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide Thread-Index: AcgiZgLRMXrGMq/pSueaEMcVUTpqcgAE5wYgAB2YciA= References: <1ECE0EB50388174790F9694F77522CCF13132B06@zrc2hxm0.corp.nortel.com> <4733A781.7020906@stpeter.im> <28F05913385EAC43AF019413F674A0171246E604@OCCLUST04EVS1.ugd.att.com> From: "Brian Stucker" To: "DOLLY, MARTIN C, ATTLABS" , "Peter Saint-Andre" X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: sip , rai@ietf.org Subject: [RAI] RE: [Sip] RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rai-bounces@ietf.org Callflows: they're such a double-edged sword. They do a good job of quickly explaining something, but can't cover off all the vagaries of the spec. They do such a good job, in fact, that it's not uncommon for implementors to simply implement the easy-to-understand call flow thinking they've captured all of the important bits of the underlying specifications; that they never properly check to see that they've, in fact, actually implemented the spec correctly at all. If we're going to include those, then there needs to be a considerable amount of warning text exhorting the reader to use the callflows as a study aid for the specifications and not as a substitute. Regards, Brian > -----Original Message----- > From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com]=20 > Sent: Thursday, November 08, 2007 8:48 PM > To: Peter Saint-Andre; Stucker, Brian (RICH1:AR00) > Cc: sip; rai@ietf.org > Subject: RE: [Sip] RAI-ART Review Comments for=20 > draft-ietf-sip-hitchhikers-guide >=20 > Do you believe that the call/session flows are normative or=20 > informative? >=20 >=20 > RFC 3665 call/session flows are very good illustrative=20 > examples, but do not really depict real deployments (measured=20 > in number of calls).=20 >=20 > And further, RFC 3666 does not interoperate with the PSTN,=20 > thereby not a good example. >=20 > Cheers, >=20 > Martin >=20 >=20 >=20 > -----Original Message----- > From: Peter Saint-Andre [mailto:stpeter@stpeter.im] > Sent: Thursday, November 08, 2007 7:19 PM > To: Brian Stucker > Cc: sip; rai@ietf.org > Subject: Re: [Sip] RAI-ART Review Comments for=20 > draft-ietf-sip-hitchhikers-guide >=20 > Brian Stucker wrote: >=20 > >=20 > Sorry to hijack this thread, but I'd like to second a comment=20 > that Mary Barnes made during the WGLC: >=20 > http://www1.ietf.org/mail-archive/web/sip/current/msg20981.html >=20 > *** >=20 > It seems that all the call flow BCPs are missing and I do=20 > think those are really important and should be included in=20 > this document. The only BCP (type (B) document) listed in=20 > this document is 3PCC. The basic call flow document (RFC=20 > 3665) should be listed in section 3 (Core SIP). The PSTN=20 > call flows (RFC 3666, BCP 76) should be in PSTN Interworking=20 > section 4. The SIPPING NAT scenarios document should be in=20 > the NAT section 6. These docs are all icing on the cake IMHO=20 > and help to guide implementers in using all the other docs. >=20 > *** >=20 > I agree that the call flow documents are very useful and that=20 > a reference to them would be a good thing. >=20 > Peter >=20 _______________________________________________ RAI mailing list RAI@ietf.org https://www1.ietf.org/mailman/listinfo/rai From rai-bounces@ietf.org Fri Nov 09 12:07:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqXK1-000694-Li; Fri, 09 Nov 2007 12:07:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqXJz-00067I-7h; Fri, 09 Nov 2007 12:07:07 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqXJy-0002QX-Mo; Fri, 09 Nov 2007 12:07:07 -0500 X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-9.tower-121.messagelabs.com!1194628023!22665561!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 23387 invoked from network); 9 Nov 2007 17:07:04 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-9.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 9 Nov 2007 17:07:04 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id lA9H72Bc029448; Fri, 9 Nov 2007 12:07:03 -0500 Received: from OCCLUST04EVS1.ugd.att.com (ocst08.ugd.att.com [135.38.164.13]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id lA9H6xID029406; Fri, 9 Nov 2007 12:06:59 -0500 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: Fri, 9 Nov 2007 11:06:59 -0600 Message-ID: <28F05913385EAC43AF019413F674A0171246E611@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1317953B@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide Thread-Index: AcgiZgLRMXrGMq/pSueaEMcVUTpqcgAE5wYgAB2YciAAALe8IA== References: <1ECE0EB50388174790F9694F77522CCF13132B06@zrc2hxm0.corp.nortel.com> <4733A781.7020906@stpeter.im> <28F05913385EAC43AF019413F674A0171246E604@OCCLUST04EVS1.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1317953B@zrc2hxm0.corp.nortel.com> From: "DOLLY, MARTIN C, ATTLABS" To: "Brian Stucker" , "Peter Saint-Andre" X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: sip , rai@ietf.org Subject: [RAI] RE: [Sip] RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rai-bounces@ietf.org Brian, I agree. Martin=20 -----Original Message----- From: Brian Stucker [mailto:bstucker@nortel.com]=20 Sent: Friday, November 09, 2007 11:50 AM To: DOLLY, MARTIN C, ATTLABS; Peter Saint-Andre Cc: sip; rai@ietf.org Subject: RE: [Sip] RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide Callflows: they're such a double-edged sword. They do a good job of quickly explaining something, but can't cover off all the vagaries of the spec. They do such a good job, in fact, that it's not uncommon for implementors to simply implement the easy-to-understand call flow thinking they've captured all of the important bits of the underlying specifications; that they never properly check to see that they've, in fact, actually implemented the spec correctly at all. If we're going to include those, then there needs to be a considerable amount of warning text exhorting the reader to use the callflows as a study aid for the specifications and not as a substitute. Regards, Brian > -----Original Message----- > From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com]=20 > Sent: Thursday, November 08, 2007 8:48 PM > To: Peter Saint-Andre; Stucker, Brian (RICH1:AR00) > Cc: sip; rai@ietf.org > Subject: RE: [Sip] RAI-ART Review Comments for=20 > draft-ietf-sip-hitchhikers-guide >=20 > Do you believe that the call/session flows are normative or=20 > informative? >=20 >=20 > RFC 3665 call/session flows are very good illustrative=20 > examples, but do not really depict real deployments (measured=20 > in number of calls).=20 >=20 > And further, RFC 3666 does not interoperate with the PSTN,=20 > thereby not a good example. >=20 > Cheers, >=20 > Martin >=20 >=20 >=20 > -----Original Message----- > From: Peter Saint-Andre [mailto:stpeter@stpeter.im] > Sent: Thursday, November 08, 2007 7:19 PM > To: Brian Stucker > Cc: sip; rai@ietf.org > Subject: Re: [Sip] RAI-ART Review Comments for=20 > draft-ietf-sip-hitchhikers-guide >=20 > Brian Stucker wrote: >=20 > >=20 > Sorry to hijack this thread, but I'd like to second a comment=20 > that Mary Barnes made during the WGLC: >=20 > http://www1.ietf.org/mail-archive/web/sip/current/msg20981.html >=20 > *** >=20 > It seems that all the call flow BCPs are missing and I do=20 > think those are really important and should be included in=20 > this document. The only BCP (type (B) document) listed in=20 > this document is 3PCC. The basic call flow document (RFC=20 > 3665) should be listed in section 3 (Core SIP). The PSTN=20 > call flows (RFC 3666, BCP 76) should be in PSTN Interworking=20 > section 4. The SIPPING NAT scenarios document should be in=20 > the NAT section 6. These docs are all icing on the cake IMHO=20 > and help to guide implementers in using all the other docs. >=20 > *** >=20 > I agree that the call flow documents are very useful and that=20 > a reference to them would be a good thing. >=20 > Peter >=20 _______________________________________________ RAI mailing list RAI@ietf.org https://www1.ietf.org/mailman/listinfo/rai From rai-bounces@ietf.org Fri Nov 09 13:13:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqYMa-0004yK-2H; Fri, 09 Nov 2007 13:13:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqYMX-0004tY-AV; Fri, 09 Nov 2007 13:13:49 -0500 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqYMW-0005O1-IX; Fri, 09 Nov 2007 13:13:49 -0500 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JR90086P3Y9RF@siemenscomms.co.uk>; Fri, 09 Nov 2007 18:13:21 +0000 (GMT) Date: Fri, 09 Nov 2007 18:13:46 +0000 From: "Elwell, John" Subject: RE: [RAI] RE: [Sip] RAI-ART Review Comments fordraft-ietf-sip-hitchhikers-guide In-reply-to: <28F05913385EAC43AF019413F674A0171246E611@OCCLUST04EVS1.ugd.att.com> To: "DOLLY, MARTIN C, ATTLABS" , Brian Stucker , Peter Saint-Andre Message-id: <0D5F89FAC29E2C41B98A6A762007F5D03E9577@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [RAI] RE: [Sip] RAI-ART Review Comments fordraft-ietf-sip-hitchhikers-guide Thread-Index: AcgiZgLRMXrGMq/pSueaEMcVUTpqcgAE5wYgAB2YciAAALe8IAACT4/A Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1ECE0EB50388174790F9694F77522CCF13132B06@zrc2hxm0.corp.nortel.com> <4733A781.7020906@stpeter.im> <28F05913385EAC43AF019413F674A0171246E604@OCCLUST04EVS1.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1317953B@zrc2hxm0.corp.nortel.com> <28F05913385EAC43AF019413F674A0171246E611@OCCLUST04EVS1.ugd.att.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: sip , rai@ietf.org X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rai-bounces@ietf.org So do I. People interpreting call flows as definitive have caused us lots of grief in the past. John > -----Original Message----- > From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] > Sent: 09 November 2007 17:07 > To: Brian Stucker; Peter Saint-Andre > Cc: sip; rai@ietf.org > Subject: [RAI] RE: [Sip] RAI-ART Review Comments > fordraft-ietf-sip-hitchhikers-guide > > Brian, > > I agree. > > Martin > > -----Original Message----- > From: Brian Stucker [mailto:bstucker@nortel.com] > Sent: Friday, November 09, 2007 11:50 AM > To: DOLLY, MARTIN C, ATTLABS; Peter Saint-Andre > Cc: sip; rai@ietf.org > Subject: RE: [Sip] RAI-ART Review Comments for > draft-ietf-sip-hitchhikers-guide > > Callflows: they're such a double-edged sword. > > They do a good job of quickly explaining something, but can't > cover off > all the vagaries of the spec. They do such a good job, in fact, that > it's not uncommon for implementors to simply implement the > easy-to-understand call flow thinking they've captured all of the > important bits of the underlying specifications; that they never > properly check to see that they've, in fact, actually implemented the > spec correctly at all. > > If we're going to include those, then there needs to be a considerable > amount of warning text exhorting the reader to use the callflows as a > study aid for the specifications and not as a substitute. > > Regards, > Brian > > > > -----Original Message----- > > From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] > > Sent: Thursday, November 08, 2007 8:48 PM > > To: Peter Saint-Andre; Stucker, Brian (RICH1:AR00) > > Cc: sip; rai@ietf.org > > Subject: RE: [Sip] RAI-ART Review Comments for > > draft-ietf-sip-hitchhikers-guide > > > > Do you believe that the call/session flows are normative or > > informative? > > > > > > RFC 3665 call/session flows are very good illustrative > > examples, but do not really depict real deployments (measured > > in number of calls). > > > > And further, RFC 3666 does not interoperate with the PSTN, > > thereby not a good example. > > > > Cheers, > > > > Martin > > > > > > > > -----Original Message----- > > From: Peter Saint-Andre [mailto:stpeter@stpeter.im] > > Sent: Thursday, November 08, 2007 7:19 PM > > To: Brian Stucker > > Cc: sip; rai@ietf.org > > Subject: Re: [Sip] RAI-ART Review Comments for > > draft-ietf-sip-hitchhikers-guide > > > > Brian Stucker wrote: > > > > > > > > Sorry to hijack this thread, but I'd like to second a comment > > that Mary Barnes made during the WGLC: > > > > http://www1.ietf.org/mail-archive/web/sip/current/msg20981.html > > > > *** > > > > It seems that all the call flow BCPs are missing and I do > > think those are really important and should be included in > > this document. The only BCP (type (B) document) listed in > > this document is 3PCC. The basic call flow document (RFC > > 3665) should be listed in section 3 (Core SIP). The PSTN > > call flows (RFC 3666, BCP 76) should be in PSTN Interworking > > section 4. The SIPPING NAT scenarios document should be in > > the NAT section 6. These docs are all icing on the cake IMHO > > and help to guide implementers in using all the other docs. > > > > *** > > > > I agree that the call flow documents are very useful and that > > a reference to them would be a good thing. > > > > Peter > > > > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www1.ietf.org/mailman/listinfo/rai > _______________________________________________ RAI mailing list RAI@ietf.org https://www1.ietf.org/mailman/listinfo/rai From rai-bounces@ietf.org Wed Nov 14 00:12:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsAY0-0001VA-Fy; Wed, 14 Nov 2007 00:12:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsAXx-0001MI-HO; Wed, 14 Nov 2007 00:12:17 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsAXw-0002mn-TM; Wed, 14 Nov 2007 00:12:17 -0500 X-IronPort-AV: E=Sophos;i="4.21,413,1188802800"; d="scan'208";a="100314" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 13 Nov 2007 21:12:16 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAE5CGjp025725; Tue, 13 Nov 2007 21:12:16 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id lAE5CBFn002005; Wed, 14 Nov 2007 05:12:11 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 21:12:11 -0800 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 21:12:10 -0800 Message-ID: <473A83C9.6030509@cisco.com> Date: Wed, 14 Nov 2007 00:12:41 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "DRAGE, Keith \(Keith\)" Subject: Re: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03 References: <5D1A7985295922448D5550C94DE291800188609F@DEEXC1U01.de.lucent.com><1ECE0EB50388174790F9694F77522CCF12DC4A04@zrc2hxm0.corp.nortel.com><4729E458.6030703@cisco.com><1ECE0EB50388174790F9694F77522CCF12E572BD@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF12EADA8C@zrc2hxm0.corp.nortel.com> <472A3B25.7090008@cisco.com> <5D1A7985295922448D5550C94DE2918001886B88@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE2918001886B88@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Nov 2007 05:12:10.0968 (UTC) FILETIME=[E929A580:01C8267C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3916; t=1195017136; x=1195881136; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[RAI]=20RAI=20review=20of=20draft-ietf-sip-hitchhiker s-guide-03 |Sender:=20; bh=pWaJ0zvP09pUDSCP1I+mtY14VvwTD+NvibJX7KyOw5s=; b=xlC1jeUru3uIReT+8oSA9yD2Wxw86osO9nrGHqSkWex3A5brT/WoFCpsOc+gCZ1dTz6Ufjxx ThFGRRRk33nbAKvFM8Ka9az2b9y21Qj4Dj39q0zwTU/FM4o1YL9VUb92; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: sip@ietf.org, Avshalom Houri , rai@ietf.org X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rai-bounces@ietf.org Keith, I'm in the process of trying to revise this before the cutoff on Monday. I don't agree with one of your points below: DRAGE, Keith (Keith) wrote: > I guess I got this wrong. > > My starting point was a misinterpretation of Jonathan's indication > way back that we were waiting for outbound, gruu and ice before we > pushed this forward. Right, which I meant as, we won't send this off to IESG until those drafts are done. > > Having thought about this some more: > > - Yes we should include internet drafts, but with some sort of > explanation that they are included to encourage early implementation > and demonstrations of interoperability of the protocol, and thus aid > in the standards setting process; also that they identify were the WG > is targetting a solution at a particular problem space and thus aid > work towards a common solution. Additionally a warning that final > IANA assignment of codepoints does not take place until shortly > before publication, and thus codepoint assignments may change. I will add such a warning. > > - No we should not automatically include all WG drafts, but should > assert some form of expert review. We seem to have somewhere up to > 25% of working group documents that never make it to completion, and > another fair average that still are not going to be there in the the > next 3 years, judging by past performance. We are never obviously > going to get this 100% right, and I don't think we should spill any > blood arguing about the inclusion or exclusion of any draft, but I do > think we should attempt to preguess this and miss some of these out. > We want the market to try out the drafts in the document, but not get > put off by us marketing to them something that will never fulfil > their product timescales. I disagree here. Pretty much the only thing in this draft that got discussed, and agreed upon, was the criteria for draft inclusion. I really want that criteria to be objective, so we don't need to debate and whine on every single document. This criteria we spelled out is captured in the document and it says: Any specification that defines an extension to SIP itself, where an extension is a mechanism that changes or updates in some way a behavior specified in RFC 3261 Any specification that defines an extension to SDP whose primary purpose is to support SIP Any specification that defines a MIME object whose primary purpose is to support SIP Excluded from this list are requirements, architectures, registry definitions, non-normative frameworks, and processes. Best Current Practices are included when they normatively define mechanisms for accomplishing a task. I really do not want to revisit this. Based on these rules, I have been adding every working group document that meets the criteria above. Period. > > - Yes we should include some author drafts, probably on the basis > that an AD has sponsored them, or is about to sponsor them, through > the IESG, and certainly if they have reached the RFC editor's queue. As long as they are AD-sponsored and meet the criteria above, they should be included. However I am not aware of a single author draft that meets the above criteria which is AD-sponsored. Indeed I believe the SIP change process would require a SIP WG item for anything that extends SIP. If you are aware of any author drafts that meet the criteria above please let me know. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ RAI mailing list RAI@ietf.org https://www1.ietf.org/mailman/listinfo/rai From rai-bounces@ietf.org Wed Nov 14 01:18:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsBZb-0006dX-Vg; Wed, 14 Nov 2007 01:18:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsBZY-0006R9-1w; Wed, 14 Nov 2007 01:18:00 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsBZS-0006g6-Cq; Wed, 14 Nov 2007 01:17:59 -0500 X-IronPort-AV: E=Sophos;i="4.21,414,1188802800"; d="scan'208";a="186553015" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 13 Nov 2007 22:17:53 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAE6Hrie029947; Tue, 13 Nov 2007 22:17:53 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id lAE6HNYq012577; Wed, 14 Nov 2007 06:17:48 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 22:17:41 -0800 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 22:17:40 -0800 Message-ID: <473A9323.3010609@cisco.com> Date: Wed, 14 Nov 2007 01:18:11 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Stucker References: <1ECE0EB50388174790F9694F77522CCF13132B06@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF13132B06@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Nov 2007 06:17:40.0931 (UTC) FILETIME=[0F9A6930:01C82686] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=15852; t=1195021073; x=1195885073; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20RAI-ART=20Review=20Comments=20for=20draft-ietf-sip-hi tchhikers-guide |Sender:=20; bh=XDkdxZqKfx6MMQg8kizDuvx9KnnjJ3KOKx4CZmwgZBU=; b=mlt6nvYed/CC9fpYb8RP79syFuX3D+jAvH9/BuC35EFlIjK/Y7uJ1Scl3jJv5cBSmRrXdfql OqsYjQ2IeVyrlHA2hR0GHS3NkgCigHanYbfh1bQAPahqfmrJjz+sv6qO; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8f3b9db08b8c0fe2301a77f547096e31 Cc: sip , rai@ietf.org Subject: [RAI] Re: RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rai-bounces@ietf.org Thanks for the detailed review. Responses below: Brian Stucker wrote: > 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 > 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." Actually this is not true. The next section provides a concrete criteria for inclusion. This is a criteria that was discussed on the mailer and in meetings. The idea is NOT to have, on a doc by doc basis, discussion and consensus on whether to include it. I changed the wording in the last sentence to "It is an informational document, meant to guide newcomers, implementors and deployers to the many of the specifications associated with SIP." > > 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). I'll add the warning per Keiths comment. I'm not sure that the web links bring any value in an era of Google. > > > > 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. This document isn't meant to be the cure for the interop problems of SIP. Its scope is to help people understand what specs form "SIP" and what they are for. Thats it. That includes registry references. I am going to stick hard to the original scope of this document. > > > 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. I disagree with this. I think the IETF's view of what is an 'update' vs. an 'extension' is academic for implementors. I think its worth noting so there is no surprise, but I don't want this long list of things which "are" 3261 when they each have their own RFC number. Essential corrections is already listed in the core specifications list so I am not worried about it being missed. I will mention in the sections on 3853, 4320, 4916 that they formally update 3261. > > 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? That document is informational. It is meant as a clarification to rfc3264. The scope of the hitchhikers document doesn't include such documents. If you want to further expand the scope to include documents that are informational clarifications, please post a note to sip and raise this as proposed scope change for hitchhikers. As I said above though, I disagree with any proposed increases in scope beyond our original agreed set. > > 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. Changed to "network asserted". > > 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). I removed and added a pointer to the section. > > 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. Well, we'll be revising the hitchhikers guide every year or so. Should this statement no longer be true we can adjust it. > > SIPS: > > Should note that this will formally update RFC3261 when approved > to highlight that newcomers should ignore what's in RFC3261. OK. > > > > Section 4: > > RFC2848/3910: > > If this has seen little deployment and is very narrowly scoped, > then why are we including it in the guide? Because they are extensions and that is the scope of hitchhikers. > > 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. OK. > > 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. Added: Early media is a complex topic, and this specification does not fully address the problems associated with it. > > 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. Mentioned. > > > Shouldn't we have an entry in this section for RFC3966 to cover tel > URIs? > No. It does not meet the defined scope: * SIP extensions * MIME objects just for SIP * SDP stuff just for SIP > > > 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. Agree its not just there; the draft says that was the origin of it, and that it is 'most common' in PSTN interworking devices. I believe this to be true. I'll change "mild" to "moderate". > > 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. changed to: RFC 3311 defines the UPDATE method for SIP. 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 to update other information, such as the identity of the participant , without involving an updated offer/answer exchange. It was developed initially to support RFC 3312 but has found other uses. > > 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. I assume you mean the 3gpp route set validation based on service route? Not sure what else you might mean by "capture route set of a registration to know how to route future requests". The route header field in client requests is used to route future requests. In terms of DEPLOYMENT of this, if you mean the 3gpp stuff there is little deployment so far so I think my statement remains accurate. > > RFC 3841: > > Should probably call out the relationship between this RFC and > 3840. ok > > Need to remove duplicate entry for SDP negotiation under PSTN > interworking. which duplicate entry? > > RFC4244: > > Should remove reference to voicemail here. It has broader scope. > RFC4758 is intended for this purpose now (later comment). Hmm, well I didn't think there had been WG consensus to use 4458 for voicemail over 4424 - thats why it got published as informational (and indeed it was an individual submission IIRC). I agree it is more broad but its original target and most common usage AFAIK remains voicemail. Suggest: came to be routed to a particular destination. Its primary application was in support of voicemail services though it has more broad applicability. > > > Shouldn't we have an entry in this section for RFC3880, CPL? No, it doesn't meet the scope of this document: * SIP extensions * MIME objects just for SIP * SDP stuff just for SIP > > > > 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? The spec says that certain docs get listed in multiple areas for convenience. It appears in the core specs because of the formal definition of core specs: The core SIP specifications represent the set of specifications whose functionality is broadly applicable. An extension is broadly applicable if it fits into one of the following categories: For specifications that impact SIP session management, the extension would be used for almost every session initiated by a user agent For specifications that impact SIP registrations, the extension would be used for almost every registration initiated by a user agent For specifications that impact SIP subscriptions, the extension would be used for almost every subscription initiated by a user agent Our intention with ICE is that a client should always be using it; the majority of deployments involve at least one endpoint that MIGHT have a NAT issue, and thus ICE gets used. WHen ICE is used 3605 comes along for the ride. > > 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? Yes, and it is listed there. > > RFC3890: > > It's used extensively in other SDOs, paricularly wireless. Well, defined by an SDO is not the same as deployed. But anyway I'll remove the statement in this case since its a minor spec in any case. > > 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. OK. > > > > 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. I added 4896. 3486 doesn't meet the scope of hitchhikers: * SIP extensions * MIME objects just for SIP * SDP stuff just for SIP > > > > Section 14: > > I think we should add an entry for RFC4758 to capture the voicemail > service URI as another important service URI RFC. added. > > > 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. Update noted. However its not core since SMIME is not used in every call. See above for the definition of a core spec. Just because a document updates SIP does not make it a core spec. > > RFC3893: > > Should RFC3893 entry simply say something to the effect of 'use > RFC4474', or be dropped altogether? It basically does say that. > > 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. I think this is a useful piece of guidance. I know I have answered this question many times about whether this feature is needed. > > > > Section 16: > > Shouldn't we perhaps move RFC4796 from section 7 to this section? Why? > > > Section 17: > > Providing a pointer off to ECRIT seems useful here. That scope comment again. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ RAI mailing list RAI@ietf.org https://www1.ietf.org/mailman/listinfo/rai From rai-bounces@ietf.org Wed Nov 14 01:20:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsBbj-0003C3-8o; Wed, 14 Nov 2007 01:20:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsBbg-00033G-0S; Wed, 14 Nov 2007 01:20:12 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsBbf-0004UR-HU; Wed, 14 Nov 2007 01:20:11 -0500 X-IronPort-AV: E=Sophos;i="4.21,414,1188802800"; d="scan'208";a="12431" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 13 Nov 2007 22:20:10 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lAE6KAXv028173; Tue, 13 Nov 2007 22:20:10 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id lAE6K8Ye013467; Wed, 14 Nov 2007 06:20:08 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 22:20:08 -0800 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 22:20:07 -0800 Message-ID: <473A93B6.1030405@cisco.com> Date: Wed, 14 Nov 2007 01:20:38 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Peter Saint-Andre References: <1ECE0EB50388174790F9694F77522CCF13132B06@zrc2hxm0.corp.nortel.com> <4733A781.7020906@stpeter.im> In-Reply-To: <4733A781.7020906@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Nov 2007 06:20:07.0904 (UTC) FILETIME=[6734B600:01C82686] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2184; t=1195021210; x=1195885210; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20RAI-ART=20Review=20Comments=20for=20draft-iet f-sip-hitchhikers-guide |Sender:=20; bh=JZZouCnUBcIGZP6X1PuKHCrkm4L2I2InwQuaJRYTLJk=; b=dGcmISzqAFHsA8LrEBGBb2XufZh2RLoFH4JN4M8Ox9dPZfaosJermJ6cllTml92oqj9l6Igi e1nmTekkBCIiwOMGF8Sz6BVos4qbQDWJcnC1rz+rhGxnXTzPkwPFQPR6; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: sip , rai@ietf.org Subject: [RAI] Re: [Sip] RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rai-bounces@ietf.org The call flow documents do not meet the current criteria defined by hitchhikers for inclusion. That criteria is: It is very difficult to enumerate the set of SIP specifications. This is because there are many protocols that are intimately related to SIP and used by nearly all SIP implementations, but are not formally SIP extensions. As such, this document formally defines a "SIP specification" as: o Any specification that defines an extension to SIP itself, where an extension is a mechanism that changes or updates in some way a behavior specified in RFC 3261 o Any specification that defines an extension to SDP whose primary purpose is to support SIP o Any specification that defines a MIME object whose primary purpose is to support SIP Example call flows do not meet this criteria. -Jonathan R. Peter Saint-Andre wrote: > Brian Stucker wrote: > > > > Sorry to hijack this thread, but I'd like to second a comment that Mary > Barnes made during the WGLC: > > http://www1.ietf.org/mail-archive/web/sip/current/msg20981.html > > *** > > It seems that all the call flow BCPs are missing and I do think those > are really important and should be included in this document. The only > BCP (type (B) document) listed in this document is 3PCC. The basic call > flow document (RFC 3665) should be listed in section 3 (Core SIP). The > PSTN call flows (RFC 3666, BCP 76) should be in PSTN Interworking > section 4. The SIPPING NAT scenarios document should be in the NAT > section 6. These docs are all icing on the cake IMHO and help to guide > implementers in using all the other docs. > > *** > > I agree that the call flow documents are very useful and that a > reference to them would be a good thing. > > Peter -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ RAI mailing list RAI@ietf.org https://www1.ietf.org/mailman/listinfo/rai From rai-bounces@ietf.org Wed Nov 14 09:51:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJah-0005pD-1q; Wed, 14 Nov 2007 09:51:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJae-0005lV-PU; Wed, 14 Nov 2007 09:51:40 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsJab-0000yB-GX; Wed, 14 Nov 2007 09:51:40 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lAEEpT022833; Wed, 14 Nov 2007 14:51:29 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: Wed, 14 Nov 2007 08:48:42 -0600 Message-ID: In-Reply-To: <473A93B6.1030405@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide Thread-Index: Acgmhm/BplAj/O+pQsaU5SDXsWEN2AAQyyYA References: <1ECE0EB50388174790F9694F77522CCF13132B06@zrc2hxm0.corp.nortel.com> <4733A781.7020906@stpeter.im> <473A93B6.1030405@cisco.com> From: "Mary Barnes" To: "Jonathan Rosenberg" , "Peter Saint-Andre" X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: sip , rai@ietf.org Subject: [RAI] RE: [Sip] RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rai-bounces@ietf.org Jonathan, =20 I honestly think that not having the call flows, which are BCPs, leaves a huge gap in the document. And, I think not having them is contrary to these statements in the hitchiker's guide (from the intro): "It is an informational document, meant to guide newcomers, implementors and deployers to the SIP suite of specifications." And (in the paragraph following the text you extracted):=20 "Best Current Practices are included when they normatively define mechanisms for accomplishing a task." IMHO, that is the case with all the call flow BCPs, per the basic definition of BCP in RFC 2026: A BCP document is subject to the same basic set of procedures as standards track documents and thus is a vehicle by which the IETF community can define and ratify the community's best current thinking on a statement of principle or on what is believed to be the best way to perform some operations or IETF process function. At a minimum, basic call flows fits into this category because the ones in RFC 3261 are not comprehensive.=20 If we don't tell newcomers about the call flows in this document, they will likely miss them, since the whole point of this document is to help them navigate the specs. It would be okay of the call flows were referenced in the other documents, since more astute developers would have the sense to look at referenced docs, as well, many of them are not referenced. For example, the only document that seems to reference basic call flows is RFC 4083 (3GPP requirements). If the reluctance to include the call flow BCPs is a concern that they no longer reflect "Best" current practices, then we need to start updating those documents or we need to obsolete them. =20 I also just noticed that one BCP that wasn't mentioned yet was RFC 4579. It would be difficult to figure out how to put together a SIP based conferencing implementation based only on the other docs in section 8 (conferencing) without the call flow document. =20 Regards, Mary.=20 -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 Sent: Wednesday, November 14, 2007 12:21 AM To: Peter Saint-Andre Cc: sip; rai@ietf.org; Stucker, Brian (RICH1:AR00) Subject: Re: [Sip] RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide The call flow documents do not meet the current criteria defined by hitchhikers for inclusion. That criteria is: It is very difficult to enumerate the set of SIP specifications. This is because there are many protocols that are intimately related to SIP and used by nearly all SIP implementations, but are not formally SIP extensions. As such, this document formally defines a "SIP specification" as: o Any specification that defines an extension to SIP itself, where an extension is a mechanism that changes or updates in some way a behavior specified in RFC 3261 o Any specification that defines an extension to SDP whose primary purpose is to support SIP o Any specification that defines a MIME object whose primary purpose is to support SIP Example call flows do not meet this criteria. -Jonathan R. Peter Saint-Andre wrote: > Brian Stucker wrote: >=20 > >=20 > Sorry to hijack this thread, but I'd like to second a comment that=20 > Mary Barnes made during the WGLC: >=20 > http://www1.ietf.org/mail-archive/web/sip/current/msg20981.html >=20 > *** >=20 > It seems that all the call flow BCPs are missing and I do think those=20 > are really important and should be included in this document. The=20 > only BCP (type (B) document) listed in this document is 3PCC. The=20 > basic call flow document (RFC 3665) should be listed in section 3=20 > (Core SIP). The PSTN call flows (RFC 3666, BCP 76) should be in PSTN=20 > Interworking section 4. The SIPPING NAT scenarios document should be=20 > in the NAT section 6. These docs are all icing on the cake IMHO and=20 > help to guide implementers in using all the other docs. >=20 > *** >=20 > I agree that the call flow documents are very useful and that a=20 > reference to them would be a good thing. >=20 > Peter --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ RAI mailing list RAI@ietf.org https://www1.ietf.org/mailman/listinfo/rai From rai-bounces@ietf.org Wed Nov 14 10:52:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsKX9-0000KD-RX; Wed, 14 Nov 2007 10:52:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsKX6-0000EE-R1; Wed, 14 Nov 2007 10:52:04 -0500 Received: from exprod6og50.obsmtp.com ([64.18.1.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsKX3-00082e-TQ; Wed, 14 Nov 2007 10:52:04 -0500 Received: from source ([192.150.20.142]) by exprod6ob50.postini.com ([64.18.5.12]) with SMTP; Wed, 14 Nov 2007 07:51:48 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lAEFpjKn020417; Wed, 14 Nov 2007 07:51:46 -0800 (PST) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lAEFpiFV013000; Wed, 14 Nov 2007 07:51:45 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 00:51:43 +0900 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 Subject: RE: [RAI] RE: [Sip] RAI-ART Review Comments fordraft-ietf-sip-hitchhikers-guide Date: Wed, 14 Nov 2007 07:51:31 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE2AA@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAI] RE: [Sip] RAI-ART Review Comments fordraft-ietf-sip-hitchhikers-guide Thread-Index: Acgmhm/BplAj/O+pQsaU5SDXsWEN2AAQyyYAAAKztXA= References: <1ECE0EB50388174790F9694F77522CCF13132B06@zrc2hxm0.corp.nortel.com><4733A781.7020906@stpeter.im> <473A93B6.1030405@cisco.com> From: "Henry Sinnreich" To: "Mary Barnes" , "Jonathan Rosenberg" , "Peter Saint-Andre" X-OriginalArrivalTime: 14 Nov 2007 15:51:43.0505 (UTC) FILETIME=[40FA2010:01C826D6] X-Spam-Score: -4.0 (----) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: sip , rai@ietf.org X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rai-bounces@ietf.org I fully agree with Mary and wish we would have similar call flow examples for SIMPLE as well instead of a guide only.=20 The hitch-hikers guides without references to (1) call flow examples and yes, (2) OS code seems like a band-aid instead of the real thing. Call flow examples and OS code are IMHO the only proof the guides are anchored in reality. Example: IETF meetings use Jabber instead of SIMPLE and no guide will change this fact. This makes me question the usefulness of these hitchhikers guides for SIP and SIMPLE, unless they have references to call flow examples and OS code or similar.=20 I suggest both guides for SIP and SIMPLE to be re-edited with such references. Thanks, Henry -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com]=20 Sent: Wednesday, November 14, 2007 6:49 AM To: Jonathan Rosenberg; Peter Saint-Andre Cc: sip; rai@ietf.org Subject: [RAI] RE: [Sip] RAI-ART Review Comments fordraft-ietf-sip-hitchhikers-guide Jonathan, =20 I honestly think that not having the call flows, which are BCPs, leaves a huge gap in the document. And, I think not having them is contrary to these statements in the hitchiker's guide (from the intro): "It is an informational document, meant to guide newcomers, implementors and deployers to the SIP suite of specifications." And (in the paragraph following the text you extracted):=20 "Best Current Practices are included when they normatively define mechanisms for accomplishing a task." IMHO, that is the case with all the call flow BCPs, per the basic definition of BCP in RFC 2026: A BCP document is subject to the same basic set of procedures as standards track documents and thus is a vehicle by which the IETF community can define and ratify the community's best current thinking on a statement of principle or on what is believed to be the best way to perform some operations or IETF process function. At a minimum, basic call flows fits into this category because the ones in RFC 3261 are not comprehensive.=20 If we don't tell newcomers about the call flows in this document, they will likely miss them, since the whole point of this document is to help them navigate the specs. It would be okay of the call flows were referenced in the other documents, since more astute developers would have the sense to look at referenced docs, as well, many of them are not referenced. For example, the only document that seems to reference basic call flows is RFC 4083 (3GPP requirements). If the reluctance to include the call flow BCPs is a concern that they no longer reflect "Best" current practices, then we need to start updating those documents or we need to obsolete them. =20 I also just noticed that one BCP that wasn't mentioned yet was RFC 4579. It would be difficult to figure out how to put together a SIP based conferencing implementation based only on the other docs in section 8 (conferencing) without the call flow document. =20 Regards, Mary.=20 -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 Sent: Wednesday, November 14, 2007 12:21 AM To: Peter Saint-Andre Cc: sip; rai@ietf.org; Stucker, Brian (RICH1:AR00) Subject: Re: [Sip] RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide The call flow documents do not meet the current criteria defined by hitchhikers for inclusion. That criteria is: It is very difficult to enumerate the set of SIP specifications. This is because there are many protocols that are intimately related to SIP and used by nearly all SIP implementations, but are not formally SIP extensions. As such, this document formally defines a "SIP specification" as: o Any specification that defines an extension to SIP itself, where an extension is a mechanism that changes or updates in some way a behavior specified in RFC 3261 o Any specification that defines an extension to SDP whose primary purpose is to support SIP o Any specification that defines a MIME object whose primary purpose is to support SIP Example call flows do not meet this criteria. -Jonathan R. Peter Saint-Andre wrote: > Brian Stucker wrote: >=20 > >=20 > Sorry to hijack this thread, but I'd like to second a comment that=20 > Mary Barnes made during the WGLC: >=20 > http://www1.ietf.org/mail-archive/web/sip/current/msg20981.html >=20 > *** >=20 > It seems that all the call flow BCPs are missing and I do think those=20 > are really important and should be included in this document. The=20 > only BCP (type (B) document) listed in this document is 3PCC. The=20 > basic call flow document (RFC 3665) should be listed in section 3=20 > (Core SIP). The PSTN call flows (RFC 3666, BCP 76) should be in PSTN=20 > Interworking section 4. The SIPPING NAT scenarios document should be=20 > in the NAT section 6. These docs are all icing on the cake IMHO and=20 > help to guide implementers in using all the other docs. >=20 > *** >=20 > I agree that the call flow documents are very useful and that a=20 > reference to them would be a good thing. >=20 > Peter --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ RAI mailing list RAI@ietf.org https://www1.ietf.org/mailman/listinfo/rai _______________________________________________ RAI mailing list RAI@ietf.org https://www1.ietf.org/mailman/listinfo/rai From rai-bounces@ietf.org Wed Nov 14 14:11:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsNeJ-0005He-9m; Wed, 14 Nov 2007 14:11:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsNeH-0005De-GJ; Wed, 14 Nov 2007 14:11:41 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsNeB-000570-8l; Wed, 14 Nov 2007 14:11:41 -0500 X-IronPort-AV: E=Sophos;i="4.21,417,1188802800"; d="scan'208";a="193802" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 14 Nov 2007 11:09:47 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAEJ9mMO027841; Wed, 14 Nov 2007 11:09:48 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAEJ9lIw004448; Wed, 14 Nov 2007 19:09:47 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 11:09:47 -0800 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 11:09:47 -0800 Message-ID: <473B481A.2040802@cisco.com> Date: Wed, 14 Nov 2007 14:10:18 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mary Barnes References: <1ECE0EB50388174790F9694F77522CCF13132B06@zrc2hxm0.corp.nortel.com> <4733A781.7020906@stpeter.im> <473A93B6.1030405@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Nov 2007 19:09:47.0340 (UTC) FILETIME=[EC4B70C0:01C826F1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6242; t=1195067388; x=1195931388; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20RAI-ART=20Review=20Comments=20for=20draft-iet f-sip-hitchhikers-guide |Sender:=20; bh=veltQX270p/ieDcU97nJTmvkT0AuxMy7QD29qhUoFLQ=; b=gVHBuqiogNNnG2kxj9/M7/2TCF0Khyt/KC/RSM2bCQrHgTJquLhdXJ1ZwAsDp1T6CVjlECKp 1hQKM+4033Er4y+0CKGw8Ry8FGhHOxyNXYbxhYv8pBIsmAMstzXFfAxt; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: sip , rai@ietf.org, Peter Saint-Andre Subject: [RAI] Re: [Sip] RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rai-bounces@ietf.org Mary, Don't get me wrong - I'm not passing judgement on the value of the call flow specs, or on any other spec for that matter. I'm just trying to keep the scope of this document to a point where there is an objective definition we can agree to which defines the contents of the document. The current definition focuses squarely on protocol specs - extensions and object specs and the like. Those collected together define the functionality provided by SIP. I do agree that a BCP can, for all intents and purpsoes, be thought of as a protocol spec in that it normatively defines behavior. We have a BCP in there now (3pcc). Whats interesting is that the call flow specs (3665, 3666) are BCP, but frankly I'm not sure why. RFC 3665 for example contains the definitions of RFC 2119 terms, but never once uses any of them. To me, a BCP is a BCP and not informational because it has such terms - it describes behavior in some way. We could choose to expand the definition of the scope of the hitchhikers guide to include example call flow documents, whether they be informational or BCP. That would throw in a few more (torture tests for example). The main question I would ask is whether we view those kinds of informational documents as different from ones like RFC 5057 (multiple dialog usage) which, I would argue, is closer to what BCP ought to be, in terms of defining behaviors explicitly that are non-obvious or unspecified in the base specs. -Jonathan R. Mary Barnes wrote: > Jonathan, > > I honestly think that not having the call flows, which are BCPs, leaves > a huge gap in the document. And, I think not having them is contrary to > these statements in the hitchiker's guide (from the intro): > "It is an informational document, meant to guide newcomers, > implementors and deployers to the SIP suite of specifications." > And (in the paragraph following the text you extracted): > "Best Current Practices are included when they normatively define > mechanisms for > accomplishing a task." > > IMHO, that is the case with all the call flow BCPs, per the basic > definition of BCP in RFC 2026: > > A BCP document is subject to the same basic set of procedures as > standards track documents and thus is a vehicle by which the IETF > community can define and ratify the community's best current thinking > on a statement of principle or on what is believed to be the best way > to perform some operations or IETF process function. > > At a minimum, basic call flows fits into this category because the ones > in RFC 3261 are not comprehensive. > If we don't tell newcomers about the call flows in this document, they > will likely miss them, since the whole point of this document is to help > them navigate the specs. It would be okay of the call flows were > referenced in the other documents, since more astute developers would > have the sense to look at referenced docs, as well, many of them are not > referenced. For example, the only document that seems to reference basic > call flows is RFC 4083 (3GPP requirements). If the reluctance to > include the call flow BCPs is a concern that they no longer reflect > "Best" current practices, then we need to start updating those documents > or we need to obsolete them. > > I also just noticed that one BCP that wasn't mentioned yet was RFC 4579. > It would be difficult to figure out how to put together a SIP based > conferencing implementation based only on the other docs in section 8 > (conferencing) without the call flow document. > > Regards, > Mary. > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Wednesday, November 14, 2007 12:21 AM > To: Peter Saint-Andre > Cc: sip; rai@ietf.org; Stucker, Brian (RICH1:AR00) > Subject: Re: [Sip] RAI-ART Review Comments for > draft-ietf-sip-hitchhikers-guide > > The call flow documents do not meet the current criteria defined by > hitchhikers for inclusion. That criteria is: > > It is very difficult to enumerate the set of SIP specifications. > This is because there are many protocols that are intimately related > to SIP and used by nearly all SIP implementations, but are not > formally SIP extensions. As such, this document formally defines a > "SIP specification" as: > > o Any specification that defines an extension to SIP itself, where > an extension is a mechanism that changes or updates in some way a > behavior specified in RFC 3261 > > o Any specification that defines an extension to SDP whose primary > purpose is to support SIP > > o Any specification that defines a MIME object whose primary > purpose > is to support SIP > > > Example call flows do not meet this criteria. > > -Jonathan R. > > Peter Saint-Andre wrote: >> Brian Stucker wrote: >> >> >> >> Sorry to hijack this thread, but I'd like to second a comment that >> Mary Barnes made during the WGLC: >> >> http://www1.ietf.org/mail-archive/web/sip/current/msg20981.html >> >> *** >> >> It seems that all the call flow BCPs are missing and I do think those >> are really important and should be included in this document. The >> only BCP (type (B) document) listed in this document is 3PCC. The >> basic call flow document (RFC 3665) should be listed in section 3 >> (Core SIP). The PSTN call flows (RFC 3666, BCP 76) should be in PSTN >> Interworking section 4. The SIPPING NAT scenarios document should be >> in the NAT section 6. These docs are all icing on the cake IMHO and >> help to guide implementers in using all the other docs. >> >> *** >> >> I agree that the call flow documents are very useful and that a >> reference to them would be a good thing. >> >> Peter > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ RAI mailing list RAI@ietf.org https://www1.ietf.org/mailman/listinfo/rai From rai-bounces@ietf.org Wed Nov 14 18:03:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsRGU-0004aT-91; Wed, 14 Nov 2007 18:03:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsRGQ-0004ZZ-W3; Wed, 14 Nov 2007 18:03:19 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsRGL-0003zO-2D; Wed, 14 Nov 2007 18:03:18 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 14 Nov 2007 15:03:12 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAEN3AGv032123; Wed, 14 Nov 2007 15:03:10 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lAEN2M8M028523; Wed, 14 Nov 2007 23:03:10 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 15:03:08 -0800 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 15:03:07 -0800 Message-ID: <473B7ECA.1080504@cisco.com> Date: Wed, 14 Nov 2007 18:03:38 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Avshalom Houri References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Nov 2007 23:03:07.0732 (UTC) FILETIME=[852DB940:01C82712] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11678; t=1195081390; x=1195945390; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20RAI=20review=20of=20draft-ietf-sip-hitchhikers-guide- 03 |Sender:=20; bh=jvtg/bfv05pzs+lE+EZalajgKTtKIXwl/pCVS4kYKUg=; b=sfKMR0QLdIcWy5mEu76km5MqLX03jVnAAn8DuI9233PPNhmJ4siNY5U4Nh/1CsPmm5nlX8OS RZ1KKYHskhbLSfyYxWiK5CPaCQO3pYZqssnpWY35hUyrK6rYqbs0H19I; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1 Cc: sip@ietf.org, rai@ietf.org Subject: [RAI] Re: RAI review of draft-ietf-sip-hitchhikers-guide-03 X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rai-bounces@ietf.org Thanks for the comments, Avshalom. Responses below: Avshalom Houri wrote: > > I have been assigned to review of draft-ietf-sip-hitchhikers-guide-03 > from the perspective of presence and the SIMPLE group but ended up in > commenting on the whole document at the end. > > For background on RAI-ART, please see the FAQ at > _http://www.softarmor.com/rai/art/rai-art-FAQ.html_ > > > Please resolve these comments along with any other Last Call comments > you may receive. > > In my opinion this draft is basically ready for publication, but has > nits that should be fixed before publication. > > Citations from the draft are marked by <<< text from draft >>> > > General comments > ---------------- > > By its nature there are a lot of reference to drafts in the document. > It will take a lot of time for these documents to become and RFC. > So how we are going to publish this as an RFC? Since when the > referenced drafts will become an RFC, this draft would have to be > updated with new drafts, will it be held in the > RFC ED queue for ever? We had a whole thread on this, so I won't address this again here, but rather focus on your other comments. > > How do we gauge the usage of an RFC or a draft? There are many places > here that it is said that this or that RFC/draft got widely implemented > or not. > How it is measured? The wide implementation test is used to decide > whether an RFC or draft are core or not and therefore there should be > some text explaining how the wide implementation was determined. No. Wide usage is not used to determine core or not. There is a litmus test defined for inclusion as a core spec: For specifications that impact SIP session management, the extension would be used for almost every session initiated by a user agent For specifications that impact SIP registrations, the extension would be used for almost every registration initiated by a user agent For specifications that impact SIP subscriptions, the extension would be used for almost every subscription initiated by a user agent this definition is based entirely on the functionality of the spec and not judgement on its deployment. The comments on deployment in the document are based on my own observation and awareness. Please feel free to suggest changes, that part of the description can only be improved with data from additional folks. > > Better change RFC XXXX (before the reference number in []) to the name > of the draft (with no version number), it will make the ride smoother. OK. Changing to symrefs helps a lot. > > An introduction that details the various grouping should be added. It > should include additional text on the group and what was the criteria > for putting an RFC/draft in the group. OK, I added a list in the introduction along with brief classification description. > > 2. Scope of this Document > -------------------------- > > <<< > o Any specification that defines an extension to SIP itself, where > an extension is a mechanism that changes or updates in some way a > behavior specified in RFC 3261 > >>> > > "to SIP itself" sounds vague. It will be better to say:"to RFC 3261" > instead. > Maybe there should be an earlier definition of RFC 3261 as the SIP nucleus > (or the president of the galaxy) and that RFCs/drafts mentioned in this > document are based on their relation to it. changed this sentence to: 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. > > <<< > Excluded from this list are requirements, architectures, registry > definitions, non-normative frameworks, and processes. Best Current > Practices are included when they normatively define mechanisms for > accomplishing a task. > >>> > > "normatively define" not sure what is meant by normative with > respect to BCP. Seems like a contradiction in terms. Actually BCPs can contain normative text and are, in many ways, very much like a PS. > > 3. Core SIP Specifications > --------------------------- > > If we think on presence as eventually replacing registration, since it > carries much more information about the availability of the user, > should we consider also presence as a towel? > > <<< > RFC 3261, The Session Initiation Protocol (S): RFC 3261 [1] is the > core SIP protocol itself. RFC 3261 is an update to RFC 2543 [9]. > It is the president of the galaxy [42] as far as the suite of SIP > specifications is concerned. > >>> > > RFC 3261 is a very big document. Should it be treated as one or it can > be divided into parts in this document e.g. proxy, client etc.? I am not > sure what would be better. The purpose here is to just enumerate the specs and describe each. I don't think the aim is to break it up here. > > 4. Public Switched Telephone Network (PSTN) Interworking > --------------------------------------------------------- > > Regarding RFC 3578 > Ugly in one corner of the galaxy may be beautiful on the other of it :-) > > 7. Minor Extensions > -------------------- > > <<< > RFC XXXX, Referring to Multiple Resources in SIP (S): RFC XXXX [44] > allows a UA sending a REFER to ask the recipient of the REFER to > generate multiple SIP requests, not just one. This is useful for > conferencing, where a client would like to ask a conference server > to eject multiple users. > >>> > > Should not this be referred to in the conferencing section also? ok > > <<< > RFC 4483, A Mechanism for Content Indirection in Session Initiation > Protocol (SIP) Messages (S): RFC 4483 [89] defines a mechanism for > content indirection. Instead of carrying an object within a SIP > body, a URL reference is carried instead, and the recipient > dereferences the URL to obtain the object. The specification has > potential applicability for sending large instant messages, but > has yet to find much actual use. > >>> > > The specification has also potential for sending large presence > documents via a URL. sure, but I don't think it would really be classified as a presence-related spec. > > <<< > RFC 4583, Session Description Protocol (SDP) Format for Binary Floor > Control Protocol (BFCP) Streams (S): RFC 4583 [91] defines a > mechanism in SDP to signal floor control streams that use BFCP. > It is used for Push-To-Talk and conference floor control. > >>> > > Should not this be referred to in the conferencing section also? ok > > <<< > RFC XXXX, Connectivity Preconditions for Session Description Protocol > Media Streams (S): RFC XXXX [93] defines a usage of the precondition > framework [59]. The connectivity precondition makes sure that the > session doesn't get established until actual packet connectivity > is checked. > >>> > > Should not this be referred to in the QoS section also? Well, the line is fine, but connectivity preconditions is not about QoS as most folks think of it (i.e., bandwidth reservation). > > 8. Conferencing > ---------------- > > The Conferencing section should be before or after "Instant Messaging, > Presence and Multimedia" as it is also an application. See the comment > on whether presence is an application or not later. moved. > > 10. Event Framework and Packages > ---------------------------------- > > Suggest to divide this section to event framework section and to > packages section. The event framework should include 3265, 3903, 4662 > and subnot-etags which define the event framework itself. > The other section will the packages sections that will list the > packages. OK. > > Alternatively, many of the packages are mentioned in their proper > section so it may be that all the event packages can be fit into > their relevant section and there is not a need for packages section. I think its useful to list them. > > 11. Quality of Service > ----------------------- > > <<< > RFC 3313, Private SIP Extensions for Media Authorization (I): RFC > 3313 [61] defines a P-header that provides a mechanism for passing > an authorization token between SIP and a network QoS reservation > protocol like RSVP. Its purpose is to make sure network QoS is > only granted if a client has made a SIP call through the same > providers network. This specification is sometimes referred to as > the SIP walled garden specification by the truly paranoid androids > in the SIP community. This is because it requires coupling of > signaling and the underlying IP network. > >>> > > Understand that being a "truly paranoid" is a virtue? :-) > > 15. Security Mechanisms > ------------------------ > > Should not RFC 3323 (Privacy), RFC 3325 (Asserted-ID) and RFC 4474 > (Identity) be mentioned here also? Hmm, well Brian had suggested that RFC 3325 has nothing to do with 'secure caller ID' so that one is definitely debatable. 4474 definitely fits here. 3323 is kind of fuzzy, but I'll include. > > 16. Instant Messaging, Presence and Multimedia > ----------------------------------------------- > > Maybe create an applications section and put also conferencing as a type > of an application. Applications is really broad. The service URI stuff could be considered an app too. I think its valuable to have finer granularity than that. > > Including presence here with IM and multimedia seems that presence is > regarded as an additional type of media. I am not sure that I agree with > this. Presence is an enabler for many other applications and it deserves > a section of its own. Certainly its valuable, sufficiently so that simple-simple addresses it more completely and obviously separates IM from presence. But its not the emphasis of this document. If I split off presence there is only two docs in there (winfo and presence package), and only one in IM (3428) so this seems to argue for keeping them together. I did add a reference to simple-simple in the intro to let people know there is a more complete source of presence specs elsewhere. > > It is very tempting to include the simple-simple content here > (as an appendix?). If simple-simple is not to be included here, there > should be at least a reference to simple-simple as for presence > there are so many documents that are essential for doing presence and > are not mentioned here (e.g. watcher format, RPID, presence rules, > partial notify and publish and many many more). done. > Roughly counting, there > are about 20-25 RFCs/drafts that are very relevant to presence that are > mentioned in simple-simple in addition to the ones that are mentioned here. right, since they are not sip extensions. > > The MSRP drafts seem to be forgotten? Not a sip extension. RTP isn't listed here either. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ RAI mailing list RAI@ietf.org https://www1.ietf.org/mailman/listinfo/rai From rai-bounces@ietf.org Wed Nov 14 18:15:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsRSc-0001Na-Kf; Wed, 14 Nov 2007 18:15:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsRSZ-0001HP-Nl; Wed, 14 Nov 2007 18:15:51 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsRSV-0004Xb-76; Wed, 14 Nov 2007 18:15:51 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 14 Nov 2007 15:15:46 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAENFkkL020065; Wed, 14 Nov 2007 15:15:46 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAENFdCX021348; Wed, 14 Nov 2007 23:15:39 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 15:15:39 -0800 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 15:15:39 -0800 Message-ID: <473B81BA.10405@cisco.com> Date: Wed, 14 Nov 2007 18:16:10 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joerg Ott References: <472878ED.9070009@netlab.hut.fi> In-Reply-To: <472878ED.9070009@netlab.hut.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Nov 2007 23:15:39.0120 (UTC) FILETIME=[450A6F00:01C82714] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3088; t=1195082146; x=1195946146; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20RAI-ART=20review=20of=20draft-ietf-sip-hitchhikers-gu ide-03 |Sender:=20; bh=JYF085WkNTmsktJ8Bnshrrv9Bj6MBQtk9Gnad0ldeZM=; b=2Dthb40vYg98DmQYyQBJo9/Fg95eilwBsYWH1qdM3Tl2R8J7dWQXyDpYtDolrBHz9x+xlWUU /rTwpprZYJZQ0GNODsJgFq7SILYQiU9zxMaO9YGAddyo/gexSlenigB8; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: sip ietf , rai@ietf.org Subject: [RAI] Re: RAI-ART review of draft-ietf-sip-hitchhikers-guide-03 X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rai-bounces@ietf.org Thanks for the review, Joerg. Responses below: Joerg Ott wrote: > Hi, > > I am the assigned RAI-ART reviewer for draft-ietf-sip-hitchhikers-guide-03 > > For background on RAI-ART, please see the FAQ at > . > > Please resolve the comments below along with any other > Last Call comments you may receive. > > It may be worthwhile to include the advice in the beginning: > > "Do not print all the specs cited here at once, as they > might share the fate of the rules of Brockian Ultracricket > when bound together: collapse under their own gravity and > form a black hole. [42]" Nice! Added. > > Joerg > > > Review of draft-ietf-sip-hitchhikers-guide-03: > > > This draft is ready for publication as an Informational RFC. > Please consider the suggestions and nits listed below. > > > Observations and suggestions: > > Sect. 5, p10, RFC4244: > > "Its primary purpose _was_ in support of voicemail services." > > This reads like the document became obsolete already. > Is this intentional? If so, would it be useful to also > indicate which other purposes it now serves (or none > at all)? No - its broader now in fact. Brian had a similar comment. Text currently reads: defines the History-Info header field, which indicates information on how a call came to be routed to a particular destination. Its initial application was in support of voicemail services, though it now has more broad applicability. > > > Sect. 7, p13, RFC4583: > > This should go to the conferencing section (sect. 8). Its been added to that section, but it has non-conferencing applicability too (PTT). So I think it should also remain in this section. > > > Sect. 7, p13, RFCXXXX [59]: > > This should explicitly state that it builds upon the general > mechanisms of RFC 3312 (which only is described later). [59] *is* RFC3312 so I am confused about which item you are referring to. > > > Sect. 9, p14, RFC3515: > > It may be useful to add a warning clause concerning REFER, > e.g., along the following lines: > > "Beware that not all potential uses of REFER (neither for all > methods nor for all URI schemes) are well defined. Be advised > to use only the well-defined ones and not to second guess or > freely assume behavior for the others to avoid unexpected > behavior of remote UAs, interoperability issues, and other > bad surprises." > ok > > > Nits: > > Sect. 9, p14, RFC3515: > > 2nd sentence: "Its" -> "It is" > fixed. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ RAI mailing list RAI@ietf.org https://www1.ietf.org/mailman/listinfo/rai From rai-bounces@ietf.org Thu Nov 15 01:21:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsY6K-0002Es-5d; Thu, 15 Nov 2007 01:21:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsY6G-0002EE-LT; Thu, 15 Nov 2007 01:21:16 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsY6E-0003bx-Pk; Thu, 15 Nov 2007 01:21:16 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lAF6L6t03761; Thu, 15 Nov 2007 06:21:06 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, 15 Nov 2007 00:20:38 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF1336266E@zrc2hxm0.corp.nortel.com> In-Reply-To: <473A9323.3010609@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide Thread-Index: AcgmhhxjUJpKvDeuSJe5T7b9fxUlcgAwVd9Q References: <1ECE0EB50388174790F9694F77522CCF13132B06@zrc2hxm0.corp.nortel.com> <473A9323.3010609@cisco.com> From: "Brian Stucker" To: "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: d01c7b9466fe967a5df27b46fdb03146 Cc: sip , rai@ietf.org Subject: [RAI] RE: RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rai-bounces@ietf.org Thanks for the updates. Replies below. Regards, Brian=20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Wednesday, November 14, 2007 12:18 AM > To: Stucker, Brian (RICH1:AR00) > Cc: rai@ietf.org; sip > Subject: Re: RAI-ART Review Comments for=20 > draft-ietf-sip-hitchhikers-guide >=20 > Thanks for the detailed review. Responses below: >=20 > Brian Stucker wrote: > > Jonathan, > >=20 > > Thanks for putting the document together. It took quite=20 > awhile to just=20 > > review it! > >=20 > > Here are the comments that I have as part of the RAI-ART=20 > review of the=20 > > document. Apologies for the probable repeats in here from list=20 > > comments, I was not able to try to correlate my comments=20 > with others=20 > > on the various reflectors. > >=20 > > I tried to break my comments up by section and document so=20 > hopefully=20 > > it's coherent in plain-text. > >=20 > > Regards, > > Brian > >=20 > > ---- > >=20 > > Section 1: > >=20 > >=20 > > This document itself is not an update to RFC 3261=20 > > or an extension to > > SIP. It is an informational document, meant to guide newcomers, > > implementors and deployers to the SIP suite of specifications. > >=20 > > May want to change "meant to guide newcomers, implementors and=20 > > deployers to the SIP suite of specifications" since many of the=20 > > documents are not predicated upon SIP itself. For example,=20 > RFC-4566,=20 > > 3388, 3264. Also, I don't think we want to imply that this=20 > document is=20 > > exhaustive. Perhaps "It is an information document, meant=20 > to introduce=20 > > newcomers, implementors and deployers to many of the important IETF=20 > > specifications associated with SIP. Specifications=20 > referenced by this=20 > > document were chosen based on working group consensus and the list=20 > > presented here is not intended to be exhaustive or confer=20 > any special=20 > > status over documents not included." >=20 > Actually this is not true. The next section provides a=20 > concrete criteria for inclusion. This is a criteria that was=20 > discussed on the mailer and in meetings. The idea is NOT to=20 > have, on a doc by doc basis, discussion and consensus on=20 > whether to include it. >=20 > I changed the wording in the last sentence to "It is an=20 > informational document, meant to guide newcomers,=20 > implementors and deployers to the many of the specifications=20 > associated with SIP." Fair enough. >=20 > >=20 > > Might also want to include some pointers to the relevant WG=20 > webpages=20 > > to give newcomers a place to go for further information. As well as=20 > > include some boilerplate about the dangers of implementing I-D's=20 > > before they become RFCs (I think this was already discussed=20 > somewhat=20 > > on the RAI mailing list). >=20 > I'll add the warning per Keiths comment. I'm not sure that=20 > the web links bring any value in an era of Google. Fair enough. >=20 >=20 > >=20 > >=20 > >=20 > > Section 2: > >=20 > > Although I agree that documents defining relevant registries > > should be excluded, what about pointers to the registries=20 > 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. >=20 > This document isn't meant to be the cure for the interop problems of=20 > SIP. Its scope is to help people understand what specs form "SIP" and=20 > what they are for. Thats it. That includes registry references. I am=20 > going to stick hard to the original scope of this document. Not the cure, certainly, but if the IANA registration process for SIP extensions is considered out of scope, then perhaps a pointer to 4485 somewhere instead? Seems mostly harmless. :) >=20 > >=20 > >=20 > > Section 3: > >=20 > > RFC3261:=20 > >=20 > > I think it would be useful to provide a reverse-lookup list of > > RFCs that formally update 3261 under the 3261 entry:=20 > RFC-3583, RFC-4320 > > and RFC-4916. There is a statement under 4320 that it=20 > formally updates > > 3261, but there is no mention under 4916 that it formally=20 > updates 3261, > > it just looks like any other extension. Putting a pointer=20 > 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=20 > 3261 entry so > > that people don't skip over that material would be good as well. >=20 > I disagree with this. I think the IETF's view of what is an=20 > 'update' vs.=20 > an 'extension' is academic for implementors. I think its=20 > worth noting so=20 > there is no surprise, but I don't want this long list of things which=20 > "are" 3261 when they each have their own RFC number. >=20 > Essential corrections is already listed in the core=20 > specifications list=20 > so I am not worried about it being missed. >=20 > I will mention in the sections on 3853, 4320, 4916 that they formally=20 > update 3261. Thanks. >=20 > >=20 > > RFC3264: > >=20 > > Should we perhaps put a pointer here to the offer/answer draft > > for further clarification of 3264 since it seems pretty=20 > clear that the > > baseline specification did not entirely capture all of the=20 > interactions > > that arise in implementations? >=20 > That document is informational. It is meant as a clarification to=20 > rfc3264. The scope of the hitchhikers document doesn't include such=20 > documents. If you want to further expand the scope to include=20 > documents=20 > that are informational clarifications, please post a note to sip and=20 > raise this as proposed scope change for hitchhikers. As I said above=20 > though, I disagree with any proposed increases in scope beyond our=20 > original agreed set. So you'd rather have a document that formally lists which other unclear documents comprise the SIP specification as an aid to the implementor for a core function of the protocol?=20 Informational or not, we have real debates at the meetings around what is correct and what is not correct in terms of how offer/answer is used and that is captured in the offer/answer draft.=20 I would agree that informational documents that do not clarify other normative statements are out of scope, but that does not seem to be the case here. The offer/answer draft isn't trying to make changes to mechanism but to clarify unclear points of the existing normative language so that people can implement the existing mechanisms properly. It's informational only in that it does not need to be normative to do the job. It is clearly not the same type of informative documents as some others, or even, arguably, some of the BCP documents. I'd argue that including a normative document that nobody uses is of equal or lesser utility in this case. Is this really then out of scope? Since this post is cross-posted to the SIP list, please consider the note posted. One thing I noticed while going back through the document during this reply is that you include a reference to RFC-4091 which is obsoleted by ICE. Don't know how you want to handle that one. >=20 > >=20 > > RFC3325: > >=20 > > 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.=20 >=20 > Changed to "network asserted". Thanks. >=20 >=20 > >=20 > > RFC3581: > >=20 > > Rport is necessary to routing a response through a NAT, but does > > not solve NAT traversal for SIP signaling. Perhaps a=20 > 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=20 > traversal section > > to discover it there as it's not necessary at all if you=20 > have no NATs to > > traverse (ALGs and SBCs aside). >=20 > I removed and added a pointer to the section. Thanks. >=20 > >=20 > > RFC4474: > >=20 > > I don't think it's necessary that we should highlight the > > deployment size of the various RFCs in this way, especially=20 > given that > > the RFC is much newer (and has more complicated requirements) than > > RFC3325. >=20 > Well, we'll be revising the hitchhikers guide every year or=20 > so. Should=20 > this statement no longer be true we can adjust it. Fair enough. >=20 > >=20 > > SIPS: > >=20 > > Should note that this will formally update RFC3261 when approved > > to highlight that newcomers should ignore what's in RFC3261. >=20 > OK. Thanks. >=20 >=20 > >=20 > >=20 > >=20 > > Section 4: > >=20 > > RFC2848/3910: > >=20 > > If this has seen little deployment and is very narrowly scoped, > > then why are we including it in the guide?=20 >=20 > Because they are extensions and that is the scope of hitchhikers. >=20 > >=20 > > RFC3372: > >=20 > > 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. >=20 > OK. Thanks. >=20 > >=20 > > RFC3960: > >=20 > > Early media is not just generated by the PSTN. We should be fair > > here and acknowledge that 3960 does not solve all of the=20 > various issues > > associated with early media (without enumerating them). We=20 > all know this > > to be the case, so just a sentence or two should suffice to warn the > > reader. >=20 > Added: >=20 > Early media > is a complex topic, and this specification does not fully address > the problems associated with it. Perfect. >=20 >=20 > >=20 > > RFC3959: > >=20 > > We should highlight that this specification has not seen > > widespread deployment. As of a few IETFs ago nobody=20 > indicated that they > > had developed anything with regards to this specification=20 > when asked at > > a working group meeting. This is only important in that=20 > 3960 does not > > solve all of the early media issues. >=20 > Mentioned. Thanks. >=20 > >=20 > >=20 > > Shouldn't we have an entry in this section for RFC3966 to cover tel > > URIs? > >=20 >=20 > No. It does not meet the defined scope: >=20 > * SIP extensions > * MIME objects just for SIP > * SDP stuff just for SIP But TEL URIs are mentioned in RFC-3261, section 19.1.6. It's not explicitly an extension to SIP but it's used an awful lot with SIP. Still out of scope? >=20 > >=20 > >=20 > > Section 5: > >=20 > > RFC3262: > >=20 > > PRACK is complicated, for sure, but it's used for more than just > > PSTN interworking and is more than mildly deployed=20 > depending upon the > > environment. >=20 > Agree its not just there; the draft says that was the origin=20 > of it, and=20 > that it is 'most common' in PSTN interworking devices. I=20 > believe this to=20 > be true. I'll change "mild" to "moderate". Fine. No need to split hairs on this one, just highlighting the point. Thanks. >=20 > >=20 > > RFC3311: > >=20 > > ..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=20 > because a header is > > not allowed in a response message type. We should also=20 > point out here > > that when UPDATE is used to convey SDP, support for RFC3262=20 > is required > > in some scenarios. I don't think this is widely recognized.=20 > Should also > > call out that it can be used to convey mid-call information as well. >=20 > changed to: >=20 > RFC 3311 target=3D"RFC3311"/> defines the UPDATE method for SIP. 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 to > update other information, such as the identity of the participant > , > without involving an updated offer/answer exchange. It was=20 > developed > initially to support RFC 3312 but has found > other uses. > Excellent, thanks. >=20 >=20 > >=20 > > RFC3608: > >=20 > > You've captured the client perspective of the usage of > > service-route, but from a server perspective, it's used by=20 > 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. >=20 > I assume you mean the 3gpp route set validation based on=20 > service route?=20 > Not sure what else you might mean by "capture route set of a=20 > registration to know how to route future requests". The route header=20 > field in client requests is used to route future requests. >=20 > In terms of DEPLOYMENT of this, if you mean the 3gpp stuff there is=20 > little deployment so far so I think my statement remains accurate. Yes. Upon further reflection, I'll withdraw the comment. >=20 > >=20 > > RFC 3841: > >=20 > > Should probably call out the relationship between this RFC and > > 3840. >=20 > ok >=20 > >=20 > > Need to remove duplicate entry for SDP negotiation under PSTN > > interworking. >=20 > which duplicate entry? Sorry, you are correct. I misread reference to [105] to be duplicate to later reference to [106]. Nevermind. >=20 > >=20 > > RFC4244: > >=20 > > Should remove reference to voicemail here. It has broader scope. > > RFC4758 is intended for this purpose now (later comment). >=20 > Hmm, well I didn't think there had been WG consensus to use 4458 for=20 > voicemail over 4424 - thats why it got published as=20 > informational (and=20 > indeed it was an individual submission IIRC). >=20 > I agree it is more broad but its original target and most=20 > common usage=20 > AFAIK remains voicemail. Suggest: >=20 > came to be routed to a particular destination. Its primary application > was in support of voicemail services though it has more broad > applicability. Sounds fine. >=20 >=20 > >=20 > >=20 > > Shouldn't we have an entry in this section for RFC3880, CPL? >=20 > No, it doesn't meet the scope of this document: >=20 > * SIP extensions > * MIME objects just for SIP > * SDP stuff just for SIP Ok. Fair enough. I'm sure it'll come up in a BLISS document anyhow. >=20 > >=20 > >=20 > >=20 > > Section 6: > >=20 > > RFC3605: > >=20 > > Should this be here and under the core specifications section? I > > don't see this attribute show up in SDP very often=20 > (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? >=20 > The spec says that certain docs get listed in multiple areas for=20 > convenience. >=20 > It appears in the core specs because of the formal definition=20 > of core specs: >=20 > > The core SIP specifications represent the set of specifications whose > functionality is broadly applicable. An extension is broadly > applicable if it fits into one of the following categories: > >=20 > >=20 > For specifications that impact SIP session management, the > extension would be used for almost every session initiated by a user > agent > >=20 > For specifications that impact SIP registrations, the extension > would be used for almost every registration initiated by a user agent > >=20 > For specifications that impact SIP subscriptions, the extension > would be used for almost every subscription initiated by a user agent > >=20 > >=20 > Our intention with ICE is that a client should always be=20 > using it; the=20 > majority of deployments involve at least one endpoint that=20 > MIGHT have a=20 > NAT issue, and thus ICE gets used. WHen ICE is used 3605=20 > comes along for=20 > the ride. Fair enough. >=20 > >=20 > > OUTBOUND: > >=20 > > Doesn't outbound satisfy the requirements of a broadly > > applicable extension to SIP? Seems like if ICE is a core=20 > specification, > > that OUTBOUND should be considered one as well? >=20 > Yes, and it is listed there. >=20 > >=20 > > RFC3890: > >=20 > > It's used extensively in other SDOs, paricularly wireless. >=20 >=20 > Well, defined by an SDO is not the same as deployed. But anyway I'll=20 > remove the statement in this case since its a minor spec in any case. The text used the term 'usage' so I didn't know precisely what you meant (usage by other specifications vs. deployment). Just trying to capture as much as we can, I agree it's a minor spec. >=20 > >=20 > > RFC4730: > >=20 > > Should probably explain here briefly, that 2833/4733 is most > > commonly used to convey DTMF for SIP deployments, but the=20 > difference is > > that KPML does it on the signaling path as opposed to the=20 > media path. > > This is somewhat important given the low current deployment of KPML. >=20 > OK. >=20 > >=20 > >=20 > >=20 > > Section 13: > >=20 > > 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=20 > draft text). > > The important bit for an entry to RFC3485 is that there are=20 > a few bugs > > in the dictionary such that you'd need to refer to section=20 > 12 of RFC4896 > > to come up with a BCP implementation. >=20 > I added 4896. > 3486 doesn't meet the scope of hitchhikers: >=20 > * SIP extensions > * MIME objects just for SIP > * SDP stuff just for SIP Huh? How is 3486 not an extension to SIP? It defines a URI parameter for the SIP/SIPS URI scheme along with other normative behavior specifically for SIP (it's even in the title). >=20 > >=20 > >=20 > >=20 > > Section 14: > >=20 > > I think we should add an entry for RFC4758 to capture the voicemail > > service URI as another important service URI RFC. >=20 > added. >=20 > >=20 > >=20 > > Section 15: > >=20 > > RFC3853: > >=20 > > May want to state that RFC3853 'formally' updates RFC3261, and > > put a pointer to this from the core specifications section=20 > as a result > > since it's a correction to 3261. >=20 > Update noted. > However its not core since SMIME is not used in every call. See above=20 > for the definition of a core spec. Just because a document=20 > updates SIP=20 > does not make it a core spec. Fair enough. >=20 > >=20 > > RFC3893: > >=20 > > Should RFC3893 entry simply say something to the effect of 'use > > RFC4474', or be dropped altogether? >=20 > It basically does say that. Ok. Agree. >=20 > >=20 > > RFC3329: > >=20 > > There are now three possible security models now in 3GPP: HTTP > > DIGEST, AKA, and early-IMS. As early-IMS doesn't really=20 > involve much in > > the way of security mechanisms within the SIP protocol, the=20 > coexistance > > of it with digest or AKA seems to be very probable. Perhaps=20 > we should > > just remove the last sentence and leave it up to the reader=20 > to decide if > > it's needed for their purpose. >=20 > I think this is a useful piece of guidance. I know I have=20 > answered this=20 > question many times about whether this feature is needed. Ok. I hadn't even heard that question, but if it's being asked, then I'm ok with the reader figuring it out for themselves either way. >=20 > >=20 > >=20 > >=20 > > Section 16: > >=20 > > Shouldn't we perhaps move RFC4796 from section 7 to this section? >=20 > Why? Section 16:=20 16. Instant Messaging, Presence and Multimedia SIP provides extensions for instant messaging, presence, and multimedia. Entry for RFC4796: RFC 4796, The SDP (Session Description Protocol) Content Attribute (S): RFC 4796 [94] defines an SDP attribute for describing the purpose of a media stream. =20 Seems more related to multimedia than that it's a minor extension although I don't feel strongly either way. If you want to leave it alone, I'm ok with that. Was only a suggestion. >=20 > >=20 > >=20 > > Section 17: > >=20 > > Providing a pointer off to ECRIT seems useful here. >=20 > That scope comment again. Ok. >=20 > Thanks, > Jonathan R. >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 _______________________________________________ RAI mailing list RAI@ietf.org https://www1.ietf.org/mailman/listinfo/rai From rai-bounces@ietf.org Thu Nov 15 02:56:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsZaW-0003My-4f; Thu, 15 Nov 2007 02:56:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsZaN-00039Y-Tr; Thu, 15 Nov 2007 02:56:28 -0500 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsZaL-0007G1-6E; Thu, 15 Nov 2007 02:56:27 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.8/8.13.8) with ESMTP id lAF7uMD6030096; Thu, 15 Nov 2007 07:56:22 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.6) with ESMTP id lAF7uMrE2326754; Thu, 15 Nov 2007 08:56:22 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id lAF7uLhb003061; Thu, 15 Nov 2007 08:56:22 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id lAF7uLqm003055; Thu, 15 Nov 2007 08:56:21 +0100 In-Reply-To: <473B7ECA.1080504@cisco.com> References: <473B7ECA.1080504@cisco.com> To: Jonathan Rosenberg MIME-Version: 1.0 Subject: Re: [RAI] Re: RAI review of draft-ietf-sip-hitchhikers-guide-03 X-Mailer: Lotus Notes Release 8.0NP August 02, 2007 From: Avshalom Houri Message-ID: Date: Thu, 15 Nov 2007 09:56:21 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 15/11/2007 09:56:21, Serialize complete at 15/11/2007 09:56:21 X-Spam-Score: 0.0 (/) X-Scan-Signature: be1e5ad20f6e15b349a42c2dfbdd71ac Cc: sip@ietf.org, rai@ietf.org X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1981597310==" Errors-To: rai-bounces@ietf.org This is a multipart message in MIME format. --===============1981597310== Content-Type: multipart/alternative; boundary="=_alternative 002B83F2C2257394_=" This is a multipart message in MIME format. --=_alternative 002B83F2C2257394_= Content-Type: text/plain; charset="US-ASCII" Jonathan, Agree with your all replies. One comment only: First paragraph in section 5: These extensions are general purpose enhancements to SIP, SDP and MIME that can serve a wide variety of uses. However, they are not as widely used or as essential as the core specifications. Maybe should be changed to put more emphasize that these RFCs are not core specs and less on the wide deployment of them. Current wording seems to say (at least to me) that wide deployment was the main criteria. --Avshalom Jonathan Rosenberg 15/11/2007 01:03 To Avshalom Houri/Haifa/IBM@IBMIL cc sip@ietf.org, rai@ietf.org Subject [RAI] Re: RAI review of draft-ietf-sip-hitchhikers-guide-03 Thanks for the comments, Avshalom. Responses below: Avshalom Houri wrote: > > I have been assigned to review of draft-ietf-sip-hitchhikers-guide-03 > from the perspective of presence and the SIMPLE group but ended up in > commenting on the whole document at the end. > > For background on RAI-ART, please see the FAQ at > _http://www.softarmor.com/rai/art/rai-art-FAQ.html_ > > > Please resolve these comments along with any other Last Call comments > you may receive. > > In my opinion this draft is basically ready for publication, but has > nits that should be fixed before publication. > > Citations from the draft are marked by <<< text from draft >>> > > General comments > ---------------- > > By its nature there are a lot of reference to drafts in the document. > It will take a lot of time for these documents to become and RFC. > So how we are going to publish this as an RFC? Since when the > referenced drafts will become an RFC, this draft would have to be > updated with new drafts, will it be held in the > RFC ED queue for ever? We had a whole thread on this, so I won't address this again here, but rather focus on your other comments. > > How do we gauge the usage of an RFC or a draft? There are many places > here that it is said that this or that RFC/draft got widely implemented > or not. > How it is measured? The wide implementation test is used to decide > whether an RFC or draft are core or not and therefore there should be > some text explaining how the wide implementation was determined. No. Wide usage is not used to determine core or not. There is a litmus test defined for inclusion as a core spec: For specifications that impact SIP session management, the extension would be used for almost every session initiated by a user agent For specifications that impact SIP registrations, the extension would be used for almost every registration initiated by a user agent For specifications that impact SIP subscriptions, the extension would be used for almost every subscription initiated by a user agent this definition is based entirely on the functionality of the spec and not judgement on its deployment. The comments on deployment in the document are based on my own observation and awareness. Please feel free to suggest changes, that part of the description can only be improved with data from additional folks. > > Better change RFC XXXX (before the reference number in []) to the name > of the draft (with no version number), it will make the ride smoother. OK. Changing to symrefs helps a lot. > > An introduction that details the various grouping should be added. It > should include additional text on the group and what was the criteria > for putting an RFC/draft in the group. OK, I added a list in the introduction along with brief classification description. > > 2. Scope of this Document > -------------------------- > > <<< > o Any specification that defines an extension to SIP itself, where > an extension is a mechanism that changes or updates in some way a > behavior specified in RFC 3261 > >>> > > "to SIP itself" sounds vague. It will be better to say:"to RFC 3261" > instead. > Maybe there should be an earlier definition of RFC 3261 as the SIP nucleus > (or the president of the galaxy) and that RFCs/drafts mentioned in this > document are based on their relation to it. changed this sentence to: 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. > > <<< > Excluded from this list are requirements, architectures, registry > definitions, non-normative frameworks, and processes. Best Current > Practices are included when they normatively define mechanisms for > accomplishing a task. > >>> > > "normatively define" not sure what is meant by normative with > respect to BCP. Seems like a contradiction in terms. Actually BCPs can contain normative text and are, in many ways, very much like a PS. > > 3. Core SIP Specifications > --------------------------- > > If we think on presence as eventually replacing registration, since it > carries much more information about the availability of the user, > should we consider also presence as a towel? > > <<< > RFC 3261, The Session Initiation Protocol (S): RFC 3261 [1] is the > core SIP protocol itself. RFC 3261 is an update to RFC 2543 [9]. > It is the president of the galaxy [42] as far as the suite of SIP > specifications is concerned. > >>> > > RFC 3261 is a very big document. Should it be treated as one or it can > be divided into parts in this document e.g. proxy, client etc.? I am not > sure what would be better. The purpose here is to just enumerate the specs and describe each. I don't think the aim is to break it up here. > > 4. Public Switched Telephone Network (PSTN) Interworking > --------------------------------------------------------- > > Regarding RFC 3578 > Ugly in one corner of the galaxy may be beautiful on the other of it :-) > > 7. Minor Extensions > -------------------- > > <<< > RFC XXXX, Referring to Multiple Resources in SIP (S): RFC XXXX [44] > allows a UA sending a REFER to ask the recipient of the REFER to > generate multiple SIP requests, not just one. This is useful for > conferencing, where a client would like to ask a conference server > to eject multiple users. > >>> > > Should not this be referred to in the conferencing section also? ok > > <<< > RFC 4483, A Mechanism for Content Indirection in Session Initiation > Protocol (SIP) Messages (S): RFC 4483 [89] defines a mechanism for > content indirection. Instead of carrying an object within a SIP > body, a URL reference is carried instead, and the recipient > dereferences the URL to obtain the object. The specification has > potential applicability for sending large instant messages, but > has yet to find much actual use. > >>> > > The specification has also potential for sending large presence > documents via a URL. sure, but I don't think it would really be classified as a presence-related spec. > > <<< > RFC 4583, Session Description Protocol (SDP) Format for Binary Floor > Control Protocol (BFCP) Streams (S): RFC 4583 [91] defines a > mechanism in SDP to signal floor control streams that use BFCP. > It is used for Push-To-Talk and conference floor control. > >>> > > Should not this be referred to in the conferencing section also? ok > > <<< > RFC XXXX, Connectivity Preconditions for Session Description Protocol > Media Streams (S): RFC XXXX [93] defines a usage of the precondition > framework [59]. The connectivity precondition makes sure that the > session doesn't get established until actual packet connectivity > is checked. > >>> > > Should not this be referred to in the QoS section also? Well, the line is fine, but connectivity preconditions is not about QoS as most folks think of it (i.e., bandwidth reservation). > > 8. Conferencing > ---------------- > > The Conferencing section should be before or after "Instant Messaging, > Presence and Multimedia" as it is also an application. See the comment > on whether presence is an application or not later. moved. > > 10. Event Framework and Packages > ---------------------------------- > > Suggest to divide this section to event framework section and to > packages section. The event framework should include 3265, 3903, 4662 > and subnot-etags which define the event framework itself. > The other section will the packages sections that will list the > packages. OK. > > Alternatively, many of the packages are mentioned in their proper > section so it may be that all the event packages can be fit into > their relevant section and there is not a need for packages section. I think its useful to list them. > > 11. Quality of Service > ----------------------- > > <<< > RFC 3313, Private SIP Extensions for Media Authorization (I): RFC > 3313 [61] defines a P-header that provides a mechanism for passing > an authorization token between SIP and a network QoS reservation > protocol like RSVP. Its purpose is to make sure network QoS is > only granted if a client has made a SIP call through the same > providers network. This specification is sometimes referred to as > the SIP walled garden specification by the truly paranoid androids > in the SIP community. This is because it requires coupling of > signaling and the underlying IP network. > >>> > > Understand that being a "truly paranoid" is a virtue? :-) > > 15. Security Mechanisms > ------------------------ > > Should not RFC 3323 (Privacy), RFC 3325 (Asserted-ID) and RFC 4474 > (Identity) be mentioned here also? Hmm, well Brian had suggested that RFC 3325 has nothing to do with 'secure caller ID' so that one is definitely debatable. 4474 definitely fits here. 3323 is kind of fuzzy, but I'll include. > > 16. Instant Messaging, Presence and Multimedia > ----------------------------------------------- > > Maybe create an applications section and put also conferencing as a type > of an application. Applications is really broad. The service URI stuff could be considered an app too. I think its valuable to have finer granularity than that. > > Including presence here with IM and multimedia seems that presence is > regarded as an additional type of media. I am not sure that I agree with > this. Presence is an enabler for many other applications and it deserves > a section of its own. Certainly its valuable, sufficiently so that simple-simple addresses it more completely and obviously separates IM from presence. But its not the emphasis of this document. If I split off presence there is only two docs in there (winfo and presence package), and only one in IM (3428) so this seems to argue for keeping them together. I did add a reference to simple-simple in the intro to let people know there is a more complete source of presence specs elsewhere. > > It is very tempting to include the simple-simple content here > (as an appendix?). If simple-simple is not to be included here, there > should be at least a reference to simple-simple as for presence > there are so many documents that are essential for doing presence and > are not mentioned here (e.g. watcher format, RPID, presence rules, > partial notify and publish and many many more). done. > Roughly counting, there > are about 20-25 RFCs/drafts that are very relevant to presence that are > mentioned in simple-simple in addition to the ones that are mentioned here. right, since they are not sip extensions. > > The MSRP drafts seem to be forgotten? Not a sip extension. RTP isn't listed here either. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ RAI mailing list RAI@ietf.org https://www1.ietf.org/mailman/listinfo/rai --=_alternative 002B83F2C2257394_= Content-Type: text/html; charset="US-ASCII"
Jonathan,

Agree with your all replies.

One comment only:

First paragraph in section 5:

   These extensions are general purpose enhancements to SIP, SDP and
   MIME that can serve a wide variety of uses.  However, they are not as
   widely used or as essential as the core specifications.

Maybe should be changed to put more emphasize that these RFCs are not
core specs and less on the wide deployment of them.
Current wording seems to say (at least to me) that wide deployment was the main
criteria.

--Avshalom


Jonathan Rosenberg <jdrosen@cisco.com>

15/11/2007 01:03

To
Avshalom Houri/Haifa/IBM@IBMIL
cc
sip@ietf.org, rai@ietf.org
Subject
[RAI] Re: RAI review of draft-ietf-sip-hitchhikers-guide-03





Thanks for the comments, Avshalom. Responses below:

Avshalom Houri wrote:
>
> I have been assigned to review of draft-ietf-sip-hitchhikers-guide-03
> from the perspective of presence and the SIMPLE group but ended up in
> commenting on the whole document at the end.
>
> For background on RAI-ART, please see the FAQ at
> _http://www.softarmor.com/rai/art/rai-art-FAQ.html_
> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> In my opinion this draft is basically ready for publication, but has
> nits that should be fixed before publication.
>
> Citations from the draft are marked by <<< text from draft >>>
>
> General comments
> ----------------
>
> By its nature there are a lot of reference to drafts in the document.
> It will take a lot of time for these documents to become and RFC.
> So how we are going to publish this as an RFC? Since when the
> referenced drafts will become an RFC, this draft would have to be
> updated with new drafts, will it be held in the
> RFC ED queue for ever?

We had a whole thread on this, so I won't address this again here, but
rather focus on your other comments.

>
> How do we gauge the usage of an RFC or a draft? There are many places
> here that it is said that this or that RFC/draft got widely implemented
> or not.
> How it is measured? The wide implementation test is used to decide
> whether an RFC or draft are core or not and therefore there should be
> some text explaining how the wide implementation was determined.

No. Wide usage is not used to determine core or not. There is a litmus
test defined for inclusion as a core spec:

<list style="symbols">

<t>For specifications that impact SIP session management, the
extension would be used for almost every session initiated by a user
agent
</t>

<t>For specifications that impact SIP registrations, the extension
would be used for almost every registration initiated by a user agent
</t>

<t>For specifications that impact SIP subscriptions, the extension
would be used for almost every subscription initiated by a user agent
</t>

</list>

this definition is based entirely on the functionality of the spec and
not judgement on its deployment.

The comments on deployment in the document are based on my own
observation and awareness. Please feel free to suggest changes, that
part of the description can only be improved with data from additional
folks.

>
> Better change RFC XXXX (before the reference number in []) to the name
> of the draft (with no version number), it will make the ride smoother.

OK. Changing to symrefs helps a lot.

>
> An introduction that details the various grouping should be added. It
> should include additional text on the group and what was the criteria
> for putting an RFC/draft in the group.

OK, I added a list in the introduction along with brief classification
description.

>
> 2.  Scope of this Document
> --------------------------
>
> <<<
>    o  Any specification that defines an extension to SIP itself, where
>       an extension is a mechanism that changes or updates in some way a
>       behavior specified in RFC 3261
>  >>>
>
> "to SIP itself" sounds vague. It will be better to say:"to RFC 3261"
> instead.
> Maybe there should be an earlier definition of RFC 3261 as the SIP nucleus
> (or the president of the galaxy) and that RFCs/drafts mentioned in this
> document are based on their relation to it.

changed this sentence to:

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


>
> <<<
>    Excluded from this list are requirements, architectures, registry
>    definitions, non-normative frameworks, and processes.  Best Current
>    Practices are included when they normatively define mechanisms for
>    accomplishing a task.
>  >>>
>    
> "normatively define" not sure what is meant by normative with
> respect to BCP. Seems like a contradiction in terms.

Actually BCPs can contain normative text and are, in many ways, very
much like a PS.

>
> 3.  Core SIP Specifications
> ---------------------------
>
> If we think on presence as eventually replacing registration, since it
> carries much more information about the availability of the user,
> should we consider also presence as a towel?
>
> <<<
>    RFC 3261, The Session Initiation Protocol (S):  RFC 3261 [1] is the
>       core SIP protocol itself.  RFC 3261 is an update to RFC 2543 [9].
>       It is the president of the galaxy [42] as far as the suite of SIP
>       specifications is concerned.
>  >>>
>
> RFC 3261 is a very big document. Should it be treated as one or it can
> be divided into parts in this document e.g. proxy, client etc.? I am not
> sure what would be better.

The purpose here is to just enumerate the specs and describe each. I
don't think the aim is to break it up here.

>
> 4.  Public Switched Telephone Network (PSTN) Interworking
> ---------------------------------------------------------
>
> Regarding RFC 3578
> Ugly in one corner of the galaxy may be beautiful on the other of it :-)
>
> 7.  Minor Extensions
> --------------------
>
> <<<
>    RFC XXXX, Referring to Multiple Resources in SIP (S):  RFC XXXX [44]
>       allows a UA sending a REFER to ask the recipient of the REFER to
>       generate multiple SIP requests, not just one.  This is useful for
>       conferencing, where a client would like to ask a conference server
>       to eject multiple users.
>  >>>
>
> Should not this be referred to in the conferencing section also?

ok

>
> <<<
>    RFC 4483, A Mechanism for Content Indirection in Session Initiation
>    Protocol (SIP) Messages (S):  RFC 4483 [89] defines a mechanism for
>       content indirection.  Instead of carrying an object within a SIP
>       body, a URL reference is carried instead, and the recipient
>       dereferences the URL to obtain the object.  The specification has
>       potential applicability for sending large instant messages, but
>       has yet to find much actual use.
>  >>>
>
> The specification has also potential for sending large presence
> documents via a URL.

sure, but I don't think it would really be classified as a
presence-related spec.

>
> <<<
>    RFC 4583, Session Description Protocol (SDP) Format for Binary Floor
>    Control Protocol (BFCP) Streams (S):  RFC 4583 [91] defines a
>       mechanism in SDP to signal floor control streams that use BFCP.
>       It is used for Push-To-Talk and conference floor control.
>  >>>
>
> Should not this be referred to in the conferencing section also?

ok

>
> <<<
>    RFC XXXX, Connectivity Preconditions for Session Description Protocol
>    Media Streams (S):  RFC XXXX [93] defines a usage of the precondition
>       framework [59].  The connectivity precondition makes sure that the
>       session doesn't get established until actual packet connectivity
>       is checked.
>  >>>
>
> Should not this be referred to in the QoS section also?

Well, the line is fine, but connectivity preconditions is not about QoS
as most folks think of it (i.e., bandwidth reservation).

>
> 8.  Conferencing
> ----------------
>
> The Conferencing section should be before or after "Instant Messaging,
> Presence and Multimedia" as it is also an application. See the comment
> on whether presence is an application or not later.

moved.

>
> 10.  Event Framework and Packages
> ----------------------------------
>
> Suggest to divide this section to event framework section and to
> packages section. The event framework should include 3265, 3903, 4662
> and subnot-etags which define the event framework itself.
> The other section will the packages sections that will list the
> packages.

OK.

>
> Alternatively, many of the packages are mentioned in their proper
> section so it may be that all the event packages can be fit into
> their relevant section and there is not a need for packages section.

I think its useful to list them.

>
> 11.  Quality of Service
> -----------------------
>
> <<<
>    RFC 3313, Private SIP Extensions for Media Authorization (I):  RFC
>       3313 [61] defines a P-header that provides a mechanism for passing
>       an authorization token between SIP and a network QoS reservation
>       protocol like RSVP.  Its purpose is to make sure network QoS is
>       only granted if a client has made a SIP call through the same
>       providers network.  This specification is sometimes referred to as
>       the SIP walled garden specification by the truly paranoid androids
>       in the SIP community.  This is because it requires coupling of
>       signaling and the underlying IP network.
>  >>>      
>
> Understand that being a "truly paranoid" is a virtue? :-)
>
> 15.  Security Mechanisms
> ------------------------
>
> Should not RFC 3323 (Privacy), RFC 3325 (Asserted-ID) and RFC 4474
> (Identity) be mentioned here also?    

Hmm, well Brian had suggested that RFC 3325 has nothing to do with
'secure caller ID' so that one is definitely debatable.

4474 definitely fits here. 3323 is kind of fuzzy, but I'll include.

>
> 16.  Instant Messaging, Presence and Multimedia
> -----------------------------------------------
>
> Maybe create an applications section and put also conferencing as a type
> of an application.

Applications is really broad. The service URI stuff could be considered
an app too. I think its valuable to have finer granularity than that.

>
> Including presence here with IM and multimedia seems that presence is
> regarded as an additional type of media. I am not sure that I agree with
> this. Presence is an enabler for many other applications and it deserves
> a section of its own.

Certainly its valuable, sufficiently so that simple-simple addresses it
more completely and obviously separates IM from presence. But its not
the emphasis of this document. If I split off presence there is only two
docs in there (winfo and presence package), and only one in IM (3428) so
this seems to argue for keeping them together. I did add a reference to
simple-simple in the intro to let people know there is a more complete
source of presence specs elsewhere.

>
> It is very tempting to include the simple-simple content here
> (as an appendix?). If simple-simple is not to be included here, there
> should be at least a reference to simple-simple as for presence
> there are so many documents that are essential for doing presence and
> are not mentioned here (e.g. watcher format, RPID, presence rules,
> partial notify and publish and many many more).

done.

>  Roughly counting, there
> are about 20-25 RFCs/drafts that are very relevant to presence that are
> mentioned in simple-simple in addition to the ones that are mentioned here.

right, since they are not sip extensions.

>
> The MSRP drafts seem to be forgotten?

Not a sip extension. RTP isn't listed here either.

-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
RAI mailing list
RAI@ietf.org
https://www1.ietf.org/mailman/listinfo/rai
--=_alternative 002B83F2C2257394_=-- --===============1981597310== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAI mailing list RAI@ietf.org https://www1.ietf.org/mailman/listinfo/rai --===============1981597310==-- From rai-bounces@ietf.org Fri Nov 23 18:23:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivhrz-0004zE-E0; Fri, 23 Nov 2007 18:23:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivhrw-0004nS-VF for rai@ietf.org; Fri, 23 Nov 2007 18:23:33 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ivhrt-0003mb-Nv for rai@ietf.org; Fri, 23 Nov 2007 18:23:32 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 23 Nov 2007 15:23:29 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lANNNTRN018579 for ; Fri, 23 Nov 2007 15:23:29 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83]) by sj-core-5.cisco.com (8.12.10/8.12.6) with SMTP id lANNNTB0024175 for ; Fri, 23 Nov 2007 23:23:29 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <62CDFED6-B148-4C28-AD82-C521A972EFA5@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Fri, 23 Nov 2007 15:22:54 -0800 To: rai@ietf.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=352; t=1195860209; x=1196724209; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20RAI=20Reading=20for=20IETF=2070 |Sender:=20; bh=rYVCLzv/rC3g3WhDaVoBfd9FphicFXVpfgIvCAGdqg4=; b=IKTC1P52FE8ml+XXw9Wi8ki5ZODh7GAM4qKmSQRQ1SSJzitBrBUB/BkE7/GRZeZq+qy2aLKQ elQeg3DDhdZ8pMbW0SiWtXSlquSfSsYioMQZ3PUrhtAbMjV1TzmQP9ni0LeuEjmnT4cZkzuiXt V7uTFw/nc9q1DQvEmkt+trQJk=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [RAI] RAI Reading for IETF 70 X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rai-bounces@ietf.org Most of the RAI WG agenda's are close enough to final that you can get a reasonable reading list at this point. There is about 3000 pages of drafts on the agenda's of RAI WGs. In addition there is about another 2000 pages of drafts related to RAI that were updated in the last 30 days that are not on an agenda. Happy Reading. Cullen _______________________________________________ RAI mailing list RAI@ietf.org https://www1.ietf.org/mailman/listinfo/rai