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

[Avshalom Houri <[e-mail]>]

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

To
Avshalom Houri/Haifa/IBM@IBMIL
cc
[e-mail], [e-mail]
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
[e-mail]                              FAX:   [phone]
http://www.jdrosen.net                         PHONE: [phone]
http://www.cisco.com

_______________________________________________
RAI mailing list
[e-mail]
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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip