Subject: RE: [Sip] Manyfolks: Unified local/remote model

From: "Alan O'Neill" <[email-masked]>
Date: Tue, 26 Mar 2002 01:38:56 -0500

in-line.

Gonzalo,

I'll make this my last one (if you will :-) though given the end of last
call which I think is appropriate to unburden the list. I'll leave future
feedback to a new draft (my only reasonable course) in a while which will
cover more general requirements, the alternative general solution, our
specific longerterm requirements and feature / efficiency comparisons to
manyfolks work.

Good luck with the IESG,

Regards,  Alan.

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]]
Sent: 25 March 2002 18:02
To: Alan O'Neill
Cc: 'David R. Oran '; [email-masked] '
Subject: Re: [Sip] Manyfolks: Unified local/remote model

Hello,

The problem with your suggestion is that the offerer specifies what he
will do, not what he wants. 

AWO> No the offer/answer combination says what each will do whilst the
offerer says what it is prepared to do. This is fine since the requirement
is always known and doesn't need to be signalling. "I want 'strength' end to
end QoS please for this session in this direction please."

For instance, if the offerer says "remote",
it means (in your model) that he will perform resource reservations in
the answerer's access network. But what we really want to say is: I want
QoS in your access network. Do whatever to ensure that.

AWO> No I say the same thing as you. The offerer is saying I want QoS in
your access network by virtue of setting a precondition. If the answerer
can, it will. If it can't the offerer can try to itself. The offerer saying
remote can lead to four different answerer responses and four different sets
of mechanism by the two endpoints. In eachc ase the response is clear about
whether or not an update is needed.

You claim that in manyfolks-05 the offerer chooses the status type
(segmented or e2e) and that the answerer cannot change it. This is not a
problem. If I ask for mandatory e2e, I do not want the answerer to
change it to segmented. 

AWO> You don't want the change because of what these mean in your model, not
because of any basic requirement about what we are trying to achieve. The
requirement for preconditions is always e2e (pointless otherwise generally)
so the only thing to resolve is who does what and the resulting
feedback...The strength indicates what we should do if any QoS mech fails..

However, if I ask for segmented and I support
e2e, it will be acceptable for me that the status type is changed from
segmented to e2e. Manyfolks-05 already covers this, since the offerer
will include mandatory local/remote and optional e2e (to indicate
support for the e2e status type). The answerer can upgrade the e2e line
to mandatory, and assume that the local/remote preconditions are met
once the e2e preconditions are met.

AWO> Sure so interoperability is obtained by doubling everything up in the
offer, or by using a subsequent offer. Seems a shame somehow.

Alan.

> ----------------------------------------------------------------
> Notice Regarding Intellectual Property Rights
> 
> Flarion's submissions will conform with RFC 2026.  Flarion may seek patent
> protection on some or all of the technical information submitted by its
> employees in connection with the IETF's standards process.  If part(s) of
a
> submission by Flarion is (are) included in a standard and Flarion owns
> patent(s) and/or pending patent application(s) that are essential to
> implementation of such included part(s) in said standard, Flarion is
> prepared to grant a license on fair, reasonable, reciprocal (license back)
> and non-discriminatory terms on such included part(s).
> 

_______________________________________________
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: Gonzalo Camarillo <[email-masked]>
Date: Tue, 26 Mar 2002 19:20:30 +0200

Hello Alan,

A few clarifications.

1) When you talk about "my design" (which is wrong in your opinion) you
are talking about a mechanism that was designed by a bunch of people
which did not include myself, and was available in the WG for comments
for a long while. The fact that I am the editor now does not make this
draft "my design". It is the design of many people.

2) you claim that I want to "get this out of the door as soon as
possible". This is not the first time that folks in the WG complain
because we try to meet the deadlines. When we were finishing the SIP
spec (bis), folks in the WG also complained... as Jonathan said then, it
is unfair that people within the WG, rather than recognizing the
incredible amount of work, including evenings, nights and weekends, that
we all have put into both bundle 1 and 2, are only complaining about
"our" designs. In order to meet the deadlines, we need commited authors
and also commited reviewers. The fact that folks wait until the end to
throw comments about the whole contents of the draft , is not the
author's fault. The manyfolks mechanism has been available for review a
long time ago already... and the new additions to manyfolks-04 were
discussed in the mailing list a long while before manyfolks-04 was
actually released.

3) You have already mentioned several times the "beauty contest" between
e2e and segmented. As far as I know, you are the only one saying that
one is better than the other. As I said previously, both have advantages
and disadvantages, and the draft does not state that one is better or
preferrable than the other. Anyway, if you want me to remove the sentece
that troubles you so much (the one that says that the segmented status
type does not say anything about the backbone), I can remove it. It is
only motivational text, and if you feel so unconfortable with the
sentence, I will get rid of it (although I still think that it is a
perfectly OK sentence). Let me know how you want me to proceed on this.

4) This draft has been around for a long while, and you are throwing
your comments a few days before WGLC is finished (which is alright).
Since it seems that many people in the WG are happy with this solution,
and what you want is a brand new solution, since the current one is
completely useless for your needs, I believe that you should write a
contribution (as you suggested) which will be available for everybody in
the near future. Due to unfortunate time constrains that don't depend on
me, we cannot wait for it before the IESG last call. 

Anyway, I believe that we are missunderstanding each other. If you want
to discuss any issue related to this mail thread or to this draft, feel
free to give me a call to +1 212 939 7171 (New York time zone). We may
be able to get a better understanding of the problem on the phone than
we have done on the mail so far. If the time difference makes it
impossible for you to call me during office hours, let me know in a
personal mail and I can try to arrange a conference bridge at a suitable
time.

Best regards,

Gonzalo

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]