Subject: [Sip] Summary of Last Call comments on draft-ietf-sip-manyfolks-resource-02

From: William Marshall <[email-masked]>
Date: Mon, 12 Nov 2001 23:42:50 -0500 (EST)

The period for last call comments on the "manyfolks" draft has now passed,
so I am posting a summary of the comments/discussion and resolution of the
issues raised.  (While this is quite lengthy, I shudder to think of the
corresponding email regarding 2543bis.)

A new version of the draft will be submitted shortly.

============================================================================
Comments sent to [email-masked] prior to August 28 were incorporated
into version -02 of the I-D.  Those changes included the NITS
review and the LC review by Shriram Natarajan.  Those comments, and
my responses, were:

Spelling:
---------
- Figure 1. The caption should be "Basic Call Flow" instead of "FLow"
- Full Copyright Statement: "implmentation" should be "implementation"

WTM:  both fixed.

Consistency:
------------
- In some places (3. Introduction) the term "codecs" is used; in other
places (3.1 Requirements) the term is written capitalised "CODECS". The term
can be used consistently. 

WTM:  change to consistently be lower case.

Readability:
------------
- No page numbers. No content page.

WTM:  Added a Table of Contents.  Page numbers appear in my MSWord
source file, but got dropped somewhere in converting to raw text,
along with the rest of the page footer.  I think it is a Win95 bug
with the generic text printer.  I'll use WinNT for next version.

More Specification:
-------------------
- 5.3 Message Body Inclusion. Maybe the content type can also be specified
to be application/SDP only.

WTM:  added.

Option Tag Name:
----------------
- (Pardon the newbie question) where do I confirm that the tag
"precondition" has been allocated for the exclusive use of implementations
based on this draft?

WTM:  This is tied in with the Supported header, which establishes the
IANA registration for option tags.  Unfortunately we depend on that
draft, and can't easily drop the linkage.  Our tag value is included
in the initial IANA data.

References:
-----------
- Hard references are made to 100Rel and Supported headers. The respective
RFCs are still pending. Is that all right? Are those drafts going to
IESG/RFC Editor at the same time frame with the same probability of success
as this?

WTM:  Unfortunately we depend on both of these, and can't easily drop
the normative references.  (Or, more accurately, we depend on 100rel,
which depends on Supported).  These drafts have been the the IESG queue
for quite some time, and hopefully will get moved out soon.

============================================================================
Last Call Review by James Undery included the following comments:

NITS (Doing LC so I didn't really check)
====

The table numbering is messed up there are two tables 3 and 4.
Table 4 Summary of header fields, P-Z, not in alphabetical order ;-)
Section 16 is vague to the point of uselessness as no IPR statements on the
IETF page refer directly to this draft.

WTM: Table numbering is fixed.  Table 4 alphabetized.  IPR statement has 
been sent to IESG and is available on the web page.  Section 16 is the
proscribed text from RFC2026, though I agree with the comment.

LC Review
=========

Generally, I believe this draft uses functionality only working in the bis
drafts, large portions repeat the base spec (sometimes inaccurately),
however, nothing is a major problem and with these corrections I'd be happy
with the draft.

WTM:  The intention is that this draft be an extension of RFC2543, and not bis.
Therefore, several sections of bis are repeated (but just those portions 
that are needed for this mechanism).  The hope is that nothing will
directly conflict with bis, when it becomes an RFC.  I believe that
is true except for the prohibited use of Record-Route from the provisional
response (noted below, and which will be fixed).

Section 3
=========

"QoS Assured" vs "QoS Enabled"
------------------------------

QoS Assured, how can this be backwardly compatible, if the UAC goes straight
to ringing this will fail. I am not sure if this draft can guarantee QoS
Assured sessions and backwards compatibility. (Unless Requires header is
used, but this isn't explicitly stated, and then the call will fail)

WTM: The draft defines an option value for the Requires header (section 10).
Agreed it is not possible to be QoS Assured and backwards compatible.
The tag is optional to quickly recover from a UAS that does not support
preconditions (by letting the session proceed without them).  If that is
not the desired recovery, then the option tag would be used in the request.
I've added text to section 10 to make this point clearer.

Section 5.1
===========

Really a NIT, but I'd remove the i,u and e values for clarity of the example
SDP

WTM: done.

Section 6
=========

Record-Route issues
-------------------

Firstly Record-Route is broken in rfc2543, so I'll base comments on the bis
version.

"If the initial request contained Record-Route headers, the provisional
response MUST contain a copy of these headers...", The MUST conflicts with
the SHOULD in section 16.2 of bis04 and some of the text later on in the
section.

WTM: It is intended that this draft make this a MUST, while the base spec is
only a SHOULD.  The Route header is needed for the COMET (just as for
the PRACK).  I believe this is valid for the manyfolks extension to
strengthen the requirement language of the base spec.  

WTM: Inclusion of the Route header in the COMET is more of a problem.  The
current text says it MUST be placed in the COMET, and MUST NOT be placed 
in any other request.  I'm removing the MUST NOT line to not conflict with 
bis.  However, it is true that this "MUST be placed in the COMET" directly 
conflicts with the "MUST NOT be placed in any other request" in 100rel,
and therefore should be taken to override 100rel as well.

WTM: This comment also applies to 100rel, since that is the source
of the text I lifted for manyfolks.  I'll fix the wording in manyfolks
to be compatible with the bis definition.

Retransmission Strategy
-----------------------

This differs (unintentionally ?) from the retransmission strategy of
non-INVITEs. Why not just reference standard retransmission? (Requests are
retransmitted every T2 seconds after a provisional response has been
received, until 11 messages have been sent or a final response is received.)

WTM:  wording changed to make reference to the base spec, instead of
unintentionally inaccurately restating the spec.

Section 6.1
===========

Content-Length should be "m*"

WTM: 2543 didn't define "m*" for this table, and has Content-Length marked
as optional.  I'd agree that based on bis it should be "m*", but based
on 2543 it should be kept as "o".

Hide is depreciated

The following are missing

Authentication-Info
Alert-Info
Call-Info
Content-Disposition
Content-Language
In-Reply-To
MIME-version
Supported

WTM:  since manyfolks is an extension to 2543, these headers are not yet
defined.  Again I'd agree that based on bis they should be in the table,
but based on 2543 they should not be.

Sections 7 & 8
==============

The section numbers are wrong for the bis. The whole section would be
better, not trying to be errata to the SIP spec.

WTM:  The section numbers match 2543.

Section 9
=========

Content-Disposition is in the bis.

WTM:  but not in 2543 and needed for this feature.  Therefore duplicated
here.  Hopefully this will not conflict with the final text in bis.

===========================================================================
Last Call Review from Crister Holmberg made the following points:

Chapter 6 says:
===============

"The Route header that is constructed from some provisional response
MUST NOT be placed in any other request except for the COMET for that
provisional response".

I guess that is wrong, since we now have other pre-call requests, ie
INFO and BYE.

WTM:  This is essentially the same comment as above.  See section 6
comment from James Undery for common resolution.

Chapter 12.1.
=============

The text says that the 180 Ringing provisional response is also sent
using the reliability mechanism, ie PRACK. 

First, I would like to have it as a MUST/SHOULD/MAY/whatever - just to
clarify.

Second, it if is a MUST I would like to know why. I DO understand why
the 183 needs PRACK in this scenario, but why the 180?

WTM: Chapter 11 contains all the SIP usage rules, and contains all
the MUST/SHOULD/MAY/whatevers.  There is nothing in there about
using reliable provisional response for the 180 Ringing.
You are right there is no reason why it needs to.

WTM:  Chapter 12 is a set of examples; the example does use 100rel
for the 180.  So I think the current wording in section 12,
that "the 180-Ringing provisional response ... is also sent
using the reliability mechanism..." matches the figure and
intentionally contains no spec language.

Chapter 13.
===========

First, since it has been decided that forking WILL be a part of the
spec, I think that the idea of having a chapter like this in the draft
is very good (more on that in another thread).

Anyway, since we now do support the sending of BYE for a specific call
leg, using the tag, before the call is established, I think it could be
added to this chapter. Ie would not be mandatory to do multiple resource
reservation.

WTM:  These mechanisms are available only in 2543bis.  Wording will be
added to chapter 13 indicating such mechanisms may be used, if available.

==========================================================================
List open discussion made the following points.  In most cases, I have
tried to summarize the rather lengthy chain of emails.

[email-masked] wrote:
> > There is an issue here with document dependencies, and I really
> > don't want manyfolks to have a dependency on bis...
> 
> As I said in my last call comment I believe it does, because it
> mentions Record Route which never worked (or was even implemented
> properly) to my knowledge.
my response to the list:
> It is certainly true that any working SIP implementation
> needs to follow the revised rules for Record-Route given
> in bis.  However, the headers are defined in 2543 and
> (somewhat incomplete and/or incorrect) rules for their
> use are given in 2543.  My intent in the manyfolks draft
> is to not contradict any of the new bis procedures, and
> to specify the minimum of corrections to 2543 procedures.
> 
> In this way any implementation true to 2543, when extended
> with the manyfolks-resource procedures, will work as well
> as it did before, and do resource reservation too.
> 
> An implementation that is tracking 2543bis, when extended
> with the manyfolks-resource procecures, will not have to
> deal with any conflicting MUSTs.  And it will work.
> 
> I certainly recognize this is a compromise position, and wish
> the timing had worked out better.  However, the end state
> of bis+manyfolks is a complete and correct specification.

[email-masked] wrote:
> The 2543bis says clearly that the 200 OK for an INVITE must
> contain SDP. SDP is present in INVITE and 200 OK or in 200
> OK and ACK, but always in 200 OK.
>
> However, if preconditions are used (manyfolks), the SDP is
> already known by both parties before the 200 OK, usually in
> INVITE and 183. As such, one may think if the SDP is still
> needed in 200 OK for the INVITE when preconditions are used.
>
my response to the list:
> ... But in the end, I believe the following is the resulting set of
> MUSTs and options for SDP with manyfolks+bis:
>
> case 1:	SDP in INVITE
> 		SDP in 183
> 		optional SDP in PRACK
> 		SDP in COMET (if COMET is requested)
> 		SDP in 200
>
> case 2:	SDP in 183
> 		SDP in PRACK
> 		SDP in COMET (if COMET is requested)
> 		SDP in 200
> 		SDP in ACK
>
> The need for the SDP in case#1 in the 200-OK was discussed on the
> last earlier this year, and concluded to keep it.  Though the
> SDP in 200/ACK in case#2 wasn't discussed, the reasoning seems
> the same - uniformity with cases that don't use manyfolks.

[email-masked]
> In another thread it has been mentioned that the manyfolks draft should
> not be "bis dependent", and the rules for Record-Routing was given as
> one example.
> 
> I don't know how important it is, but there are others too. For example,
> manyfolks says that one may CANCEL a COMET, but I think the current
> status is that we won't allow that, right?
> 
> Also, it says that one can terminate a call leg using CANCEL, but that
> doesn't take forking environments into account, where we have decided
> that BYE must be used (if we don't want to terminate the WHOLE call
> setup, that is).

The wording of these statements will be changed to utilize the mechanisms
available in the existing SIP specification, thus avoiding the bis vs. 2543
differences.

(a long exchange involving [email-masked] and [email-masked])
Miguel A. Garcia writes:
> What IETF has to do is to publish standards that are general enough to
> have enough support. In this case, the manyfolks draft is already in
> use by PacketCable networks, and planned to by used by 3GPP networks.
> I think this is enough support to publish this standard.
Juha Heinanen wrote:
> i didn't say that you should not publish it, but that it currently lacks
> an applicability statement and evaluation of its effects on call setup
> delay and network resource utilization.
Miguel A. Garcia writes:
> This sounds like another internet draft on the applicability statement 
> of the manyfolks draft. *If* such a document is needed, I would like to 
> have it separated from the manyfolks standards track document.
[email-masked] wrote:
> may be i missed it, but the i-d should also try to analyze if the
> mechanism will scale if every phone call in the world would use it and
> how much additional delay will be introduced by it to the call setup
> process.

All of the content needed for such a section is already contained in
the introductory and overview sections of the I-D.  I see no reason
to duplicate it (the draft is already long enough), or to generate 
another I-D and increase the workload on all of us.

[email-masked] wrote:
> Manyfolks should clearly state that the SDP returned in the 200 OK for the 
> INVITE MUST NOT be used to change the "agreed" SDP negotiated in the INVITE,
> 183 (and PRACK) process. The SDP in the 200 OK MUST be sent to allow backward
> compatibility of middle proxies, but not to change the SDP itself.

Agreed.  The same principle holds for the SDP contained in the COMET, and the
SDP contained in the ACK (if necessary).

[email-masked] and [email-masked] said:
> ... the idea of 
> interleaving an end-to-end resource reservation mechanism 
> with sip signaling sounds an overkill that will introduce 
> lots of new complexity, delay, and processing in the network 
> devices to the call setup process.  ...
> ... for the more general interdomain model we showed call flows 
> with SIP and RSVP with up to 40+ messages, too complex.

No question that the integration of resource reservation and SIP is
complex.  The initial dcsgroup proposal of a two-stage invite was far
more optimized, especially for the proxies; but that wasn't the agreed
direction for this work.  No change to the draft.

[email-masked] said:
> ... in an emergency, making QoS a precondition makes no sense anyway IMHO.

And, what good is it to tie up an operator at the Emergency Services
Center with no resources for an RTP stream?  Even more important in
those cases, IMHO.  If the tool is available, the carrier can decide.
No change to the draft.

Finally, [email-masked] said:
> in section 11.3 (Behavior of Destination) 7th paragraph states
>  "When procesing of all preconditions is complete, if a precondition
>   in the initial INVITE specified a confirmation request, the UAS MUST
>   send a COMET message to the UAC ..."
> 
> This should be changed to "a precondition in the SDP specified ..."
> in order to cover both the offer SDP contained in the initial INVITE
> and (when an offer SDP was sent by the UAS in the 183) the answer SDP 
> contained in the PRACK.

I obviously agree with that change.

============================================================================
Remaining open issue.

The issue of bis dependency has been complicated by the decision to 
incorporate 100rel and serverfeatures into bis-06.  If there is no longer 
an RFC defining PRACK, and defining the Supported header, then manyfolks 
will be forced to reference bis and sit in the RFC editor's queue until 
that draft goes through last call and IESG review.

This is a non-technical issue for the chairs and ADs to decide, based on the 
needs expressed by 3GPP and ITU-SG9 for timely publication of RFCs.

Bill Marshall
[email-masked]

_______________________________________________
Sip mailing list  http://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