RE: Ready for IESG review: draft-ietf-sipping-toip-05.t xt

Hi, Mary:

As indicated, I am enclosing my comments in the enclosed paper.

I appreciate your lead in this respect.

Best regards,
Radhika

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP

Re: Ready for IESG review: draft-ietf-sipping-toip-05.txt

When compared to the version that was WGLC, there are a lot os  
substantial changes to this draft. Many of these changes do not come  
out of any minutes from meetings or mailing list discussions that I  
can find. Now I have not looked at it in detail - and the few changes  
I looked at looked like changes I expect people would agree with -  
but it did make me wonder if anyone other than a very small group had  
read it. Have people reviewed it?

On Jun 29, 2006, at 12:16 PM, Mary Barnes wrote:

> Hi all,
>
> An updated version of the "Framework for Realtime text over IP using
> SIP" document has been produced based on the post IETF-65 mailing list
> discussions:
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-toip-05.txt
>
> Since this document had previously completed WGLC, it is believed  
> to be
> ready for IESG review. However, we'd like to provide the working group
> one week to review to confirm its readiness or to highlight any
> remaining concerns, beyond the one already raised around the
> Editor/Author/Contributor approach.
>
> Feedback should be provided to the SIPPING WG mailing list by July  
> 7th,
> 2006.
>
> Regards,

Re: Ready for IESG review: draft-ietf-sipping-toip-05.t xt

As an RAI AD, this has me very concerned and defintely has my  
attention. Jon is the responsible AD for this WG but this hits on  
some topics that I would hope we can have some level of consistency  
on in the RAI area. It's a really busy time due to holiday and travel  
schedules not to mention the IETF work. I know there is some history  
on all this and I need to get back up to speed on the issues.

Please give the ADs and Chairs a little time to talk about this and  
figure out some of the issues.

Thanks, Cullen <with my AD hat on>

On Jul 1, 2006, at 5:30 AM, Roy, Radhika R. wrote:

> Hi, Mary:
>
> As indicated, I am enclosing my comments in the enclosed paper.
>
> I appreciate your lead in this respect.
>
> Best regards,
> Radhika
>
> <Comments on ToIP 30-June-06.doc>
> <mime-attachment.txt>

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP

RE: Ready for IESG review: draft-ietf-sipping-toip-05.t xt

Sorry to intervene, but as a list observer, the process is not clear for
me. I understand that following the WGLC there were a number of
substantial changes. I also see a document posted including a number of
other consistent comments. Yet, there is no re-doing of the WGLC, but a
one week 'review to confirm its readiness or to highlight any remaining
concerns' which also happens to fall on a long holiday weekend in the
US. Would not re-doing properly the WGLC (two weeks, no holidays in the
middle) be a normal procedure to follow in such a case in order to make
sure that we have a good consensus assessment in the WG? 

Dan

> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy <at> cisco.com] 
> Sent: Sunday, July 02, 2006 8:41 AM
> To: Mary Barnes; Gonzalo Camarillo; Jon Peterson
> Cc: sipping
> Subject: Re: [Sipping] Ready for IESG review: 
> draft-ietf-sipping-toip-05.t xt
> 
> 
> As an RAI AD, this has me very concerned and defintely has my 
> attention. Jon is the responsible AD for this WG but this 
> hits on some topics that I would hope we can have some level 
> of consistency on in the RAI area. It's a really busy time 
> due to holiday and travel schedules not to mention the IETF 
> work. I know there is some history on all this and I need to 
> get back up to speed on the issues.
> 
> Please give the ADs and Chairs a little time to talk about 

RE: Ready for IESG review: draft-ietf-sipping-toip-05.t xt

Let me provide some background that might help alleviate some of the
concerns and perhaps I should have included in my original posting of
the re-review for this doc. 
As a chair, I did re-review the updated document before the authors
submitted it to ensure that it aligned with Tom's changes and seemed
ready to go.  I guess my interpretation of the changes based on this
detailed review wasn't that there had been substantial changes, but
rather there was some reformatting of the document (for clarity) and I
viewed the changes more as a tightening and clarifying of the existing
requirements (some new ones were identified, but those were derived from
existing text). 

If others also feel that the changes were substantive enough to warrant
another WGLC and we can get at least one WG member
(non-author/contributor) that will volunteer to review the document,
then certainly we can extend the review period.  It was obviously my
mis-interpretation that the document had already been sufficiently
reviewed within the WG.

Mary

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:dromasca <at> avaya.com] 
Sent: Sunday, July 02, 2006 8:55 AM
To: Cullen Jennings; Barnes, Mary [RICH2:B601:EXCH]; Gonzalo Camarillo;
Jon Peterson
Cc: sipping
Subject: RE: [Sipping] Ready for IESG review:
draft-ietf-sipping-toip-05.t xt

RE: Ready for IESG review: draft-ietf-sipping-toip-05.t xt

Mary,

Radhika brings up some questions and want you to make the decisions.
Below are my comments and advice as a co-contributor, numbered as Radhika´s
comments:

2.1 and 2.2. The term real-time text
------------------------------------

There were unimportant historical reasons to use "interactive" and
"conversational".
I have not perceived the very strict distinction between "text" and
"real-time text" as Radhika´s comments indicate. But I am happy to be
consistent and use the term wherever it is suitable.
I thought it did not read well with "real-time text relay service" when in
practice in real world it is called "text relay" since long.

My advice: Accept to use the term "real-time text" in the places indicated.

2.3 The timing requirements on real-time text
---------------------------------------------
This comment is not correct. The delay requirements on real-time text are
less stringent than on audio and video. The bad effects of not meeting the
requirements are similar for all media but the timing values are different.

For audio and video the delay is noticable but not annoying at 400 ms.
For real-time text the same situation is seen with 1 s delay.

For audio and video the delay is annoying, but the connection can still be
used at 800 ms delay.

RE: Re: psychic early media behavior

Dale,
I'm sorry, but your proposal will not work, besides being unacceptable to TISPAN.  The UAC and network
cannot guarantee in advance to the UAS that early media will be rendered.  See RFC 3960 for known cases where
this cannot happen.

The problem is that the existing RFCs that Paul referenced have requirements that cannot always be met. 
That is the crux of our disagreement.

Your scheme attempts to prohibit a UAC/network from denying early media unless the UAS supports the
extension and allows it.  Early media denial already occurs in some cases according to existing RFCs, and
whether or not it occurs is not always known when the UAC issues its request, so this approach will just
cause more problems with existing RFCs than it solves.  

The cat's already out of the bag and you're not going to be able to put it back in.

Richard 

> -----Original Message-----
> From: Dale.Worley <at> comcast.net [mailto:Dale.Worley <at> comcast.net]
> Sent: Friday, June 30, 2006 11:11 AM
> To: sipping <at> ietf.org
> Subject: Re: [Sipping] Re: psychic early media behavior
> 
> 
>    From: "Michael Hammer \(mhammer\)" <mhammer <at> cisco.com>
> 
>    However, what I don't see is the case where it is the UAS that is
>    the one that requires the sending of early media vice the requestor
>    needing it.  It would be good to cover that case, as I suspect that
>    might occur more often.  Thus, discussion of inserting/modifying

draft-anil-sipping-bla-03

I was glad to see this - I think it is a problem that many  
implementers would like to have better advice on how to solve.

Few comments:

At a very high level, imagine you had three AOR, Bob <at> example.com,  
carol <at> example. and helpdesk <at> example.com. Bob and Carol both "staff"  
the helpdesk and Alice is calling it.
Imagine that helpdesk is a shared line and that Bob and Carol UAs are  
configured to know about it and both register for calls on it. Bob  
and Carol could use their own credentials in the digest  
authentication. It seems like if you did this, you could avoid the x- 
line-id and the sla tags. Both Bob and Carol would know that this  
helpdesk line required special "shared line" processing and would  
subscribe to the dialog package on it and also as you describe.

In the abstract, you might want to provide a sentence or two on what  
BLA is as some people might not be familiar with the term.

Cullen <with my individual hat on>  (and forgive me for slow  
responses - I'm going to be busy over next month and I am starting a  
lot of threads 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP

Question on ejzak-sipping-p-em-auth

Given the "gate" function requires SDP knowledge, why not just use  
the SDP parameters around send, receive, and send receive to do all  
this? I imagine there is a good answer to this, I'm just not able to  
think of it 

Cullen

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP

RE: Question on ejzak-sipping-p-em-auth

Hi Cullen,
This has come up at least twice during this long exchange.  The reason is also described in the draft.

Due to the transitive trust model, proxies on the path need to be able to modify the authorization
information depending on their relationships to their peer servers.  MIME attachments cannot be modified.

Richard

> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy <at> cisco.com]
> Sent: Sunday, July 02, 2006 1:16 PM
> To: sipping
> Subject: [Sipping] Question on ejzak-sipping-p-em-auth
> 
> 
> 
> Given the "gate" function requires SDP knowledge, why not just use  
> the SDP parameters around send, receive, and send receive to do all  
> this? I imagine there is a good answer to this, I'm just not able to  
> think of it 
> 
> Cullen
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors <at> cs.columbia.edu for questions on current sip
> Use sip <at> ietf.org for new developments of core SIP
>