Subject: RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 1 Nov 2007 11:13:53 +0100

At the risk of committing myself - definitely in.
 
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.
 
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. 
 
regards
 
Keith

________________________________

	From: Francois Audet [mailto:[email-masked]] 
	Sent: Tuesday, October 30, 2007 11:56 PM
	To: DRAGE, Keith (Keith); Avshalom Houri; [email-masked];
[email-masked]; [email-masked]
	Subject: RE: [RAI] RAI review of
draft-ietf-sip-hitchhikers-guide-03

	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:[email-masked]] 
		Sent: Tuesday, October 30, 2007 01:01
		To: Avshalom Houri; [email-masked]; [email-masked];
[email-masked]
		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.
		 
		regards
		 
		Keith

________________________________

			From: Avshalom Houri
[mailto:[email-masked]] 
			Sent: Monday, October 29, 2007 10:40 AM
			To: [email-masked]; [email-masked];
[email-masked]
			Subject: [RAI] RAI review of
draft-ietf-sip-hitchhikers-guide-03

			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? 
			
			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. 
			
			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. 
			
			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. 
			
			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. 
			
			<<< 
			   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. 
			
			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. 
			
			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? 
			
			<<< 
			   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. 
			
			<<< 
			   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? 
			
			<<< 
			   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? 
			
			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. 
			
			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. 
			
			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. 
			
			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?     
			
			16.  Instant Messaging, Presence and Multimedia 
			----------------------------------------------- 
			
			Maybe create an applications section and put
also conferencing as a type 
			of an application. 
			
			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. 
			
			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).
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. 
			
			The MSRP drafts seem to be forgotten? 
			
			Thanks 
			--Avshalom

_______________________________________________
RAI mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rai

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 01 Nov 2007 10:36:08 -0400

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:[email-masked]]
>     *Sent:* Tuesday, October 30, 2007 01:01
>     *To:* Avshalom Houri; [email-masked]; [email-masked]; [email-masked]
>     *Subject:* RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03
> 
>     (As WG chair)
>      
>     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
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 1 Nov 2007 09:57:40 -0500

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:[email-masked]] 
> Sent: Thursday, November 01, 2007 9:36 AM
> To: Audet, Francois (SC100:3055)
> Cc: [email-masked]; Avshalom Houri; [email-masked]
> Subject: Re: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03
> 
> inline:
> 
> Francois Audet wrote:
> which is 
> and ice, but
> 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.
> 
> --

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 01 Nov 2007 10:09:58 -0500

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" <[email-masked]>

> at RFC status at that time, get RFC numbers. Everything else is referenced 
> as an I-D.
>
> 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.
>
> hitchhikers is published. Next round of hitchhikers will have more of them 
> as RFCs.

---

From: Avshalom Houri <[email-masked]>
Date: Thu, 1 Nov 2007 17:12:19 +0200

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" <[email-masked]> 
01/11/2007 16:57

To
"Jonathan Rosenberg" <[email-masked]>, "Francois Audet" 
<[email-masked]>
cc
<[email-masked]>, Avshalom Houri/Haifa/IBM@IBMIL, <[email-masked]>
Subject
RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03

Regards,
Brian

---

From: Andrew Booth <[email-masked]>
Date: Thu, 01 Nov 2007 12:08:51 -0400

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:
> *"Brian Stucker" <[email-masked]>*
>
> 01/11/2007 16:57
>
> 	
> To
> > http://www.jdrosen.net <http://www.jdrosen.net/>                     
>     PHONE: (973) 952-5000
> > http://www.cisco.com <http://www.cisco.com/>
> >

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 1 Nov 2007 11:25:10 -0500

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. 

> From: Stucker, Brian (RICH1:AR00) 
> Sent: Thursday, November 01, 2007 07:58
> To: Jonathan Rosenberg; Audet, Francois (SC100:3055)
> 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 
> 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. 
> 
> recurring
> 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.
> > 
> 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.
> > 
> > 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.
> > 
> > --

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 01 Nov 2007 12:29:19 -0500

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" <[email-masked]>
To: "Brian Stucker" <[email-masked]>; "Jonathan Rosenberg" 
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Avshalom Houri" <[email-masked]>
Sent: Thursday, November 01, 2007 11:25 AM
Subject: [Sip] RE: [RAI] RAI review of draft-ietf-sip-hitchhikers-guide-03

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 01 Nov 2007 16:46:29 -0400

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.

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 1 Nov 2007 15:51:01 -0500

I'm fine with it.

> Sent: Thursday, November 01, 2007 13:46
> Cc: Stucker, Brian (RICH1:AR00); [email-masked]; Avshalom 
> Houri; [email-masked]
> 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).

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Sat, 3 Nov 2007 17:03:40 +0100

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. 

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

> Sent: Thursday, November 01, 2007 8:46 PM
> To: Francois Audet
> Cc: [email-masked]; [email-masked]; Avshalom Houri
> 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
> >> 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.
> >>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 14 Nov 2007 00:12:41 -0500

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

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

<list style="symbols">

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

<t>Any specification that defines an extension to SDP whose primary
purpose is to support SIP
</t>

<t>Any specification that defines a MIME object whose primary purpose
is to support SIP
</t>

</list>

<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.
</t>

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.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 14 Nov 2007 18:03:38 -0500

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

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

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

>    o  Any specification that defines an extension to SIP itself, where
>       an extension is a mechanism that changes or updates in some way a
> "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

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.

> If we think on presence as eventually replacing registration, since it
> carries much more information about the availability of the user,
>    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
> 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

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

> 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
> Understand that being a "truly paranoid" is a virtue? :-)
> 
> 15.  Security Mechanisms
> ------------------------
> 
> Should not RFC 3323 (Privacy), RFC 3325 (Asserted-ID) and RFC 4474

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.

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

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.

---

From: Avshalom Houri <[email-masked]>
Date: Thu, 15 Nov 2007 09:56:21 +0200

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 <[email-masked]> 
15/11/2007 01:03

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

<list style="symbols">

</list>

ok

ok

moved.

OK.

done.

-Jonathan R.