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

From: Avshalom Houri <[email-masked]>
Date: Mon, 29 Oct 2007 12:39:59 +0200

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?

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: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 30 Oct 2007 09:01:17 +0100

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

	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. 

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

	
	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. 

	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. 

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

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

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

	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. 

	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. 

	15.  Security Mechanisms 
	------------------------ 
	
	Should not RFC 3323 (Privacy), RFC 3325 (Asserted-ID) and RFC
4474 
	(Identity) be mentioned here also?     

	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. 

	Thanks 
	--Avshalom

---

From: Avshalom Houri <[email-masked]>
Date: Tue, 30 Oct 2007 10:37:30 +0200

Keith,

Thanks for the clarification.

Maybe this clarification should be part of the document itself?

BR
--Avshalom

"DRAGE, Keith \(Keith\)" <[email-masked]> 
30/10/2007 10:01

To
Avshalom Houri/Haifa/IBM@IBMIL, <[email-masked]>, <[email-masked]>, 
<[email-masked]>
cc

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

General comments 
---------------- 

<<< 

<<< 

<<< 

Regarding RFC 3578 

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

<<< 

<<< 

<<< 

<<< 

8.  Conferencing 
---------------- 

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

<<< 

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

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

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 30 Oct 2007 18:56:04 -0500

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

		Subject: [RAI] RAI review of

		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. 

		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. 

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

		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. 

		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. 

		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?     

		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. 

		Thanks 
		--Avshalom