Re: [Sipping] [Technical Errata Reported] RFC3398 (2580)

["Ong, Lyndon" <[e-mail]>]

That would be fine with me also.

Cheers,

Lyndon

-----Original Message-----
From: Gonzalo Camarillo [mailto:[e-mail]] 
Sent: Tuesday, January 18, 2011 7:30 AM
To: Robert Sparks
Cc: Adam Roach; Jon Peterson; Ong, Lyndon; Mary Barnes; [e-mail]; sipping LIST
Subject: Re: [Technical Errata Reported] RFC3398 (2580)

Hi,

for the record, I am also OK with "hold for document update".

Cheers,

Gonzalo

On 18/01/2011 5:16 PM, Robert Sparks wrote:
> Also,
> 
> The report is not complete - there are other examples in the document with the same bug.
> If you're going to fix one of them by errata, you probably need to fix all of them.
> 
> I agree with "hold for document update". At the worst case, if something sends the CANCEL,
> it's introducing traffic into a network that is too congested to handle the CANCEL. In the best case,
> it introduces a message (and its retransmissions) that get ignored, or a single message that gets
> an error response. (And for completeness, there is one situation that we traded-off to get
> congestion protection that sending the cancel will actually improve - when you have lost the path
> for responses to get back, but the requests (like the INVITE) was actually processed.)
> 
> So, the question that tips the balance on choosing between verify (for an amended report) and
> "hold for document update" is, I believe, "Does this cause a deployment problem".
> 
> RjS
> 
> On Jan 18, 2011, at 8:14 AM, Adam Roach wrote:
> 
>> Yes, it seems correct. I would tag it as accurate, and set the action to "hold for document update".
>>
>> /a
>>
>> On 1/18/11 02:51, Jan 18, Gonzalo Camarillo wrote:
>>> Hi,
>>>
>>> Stephen seems to be correct here. The gateway should not send the CANCEL
>>> because it has not received any provisional response. I suggest we
>>> accept the erratum. Comments?
>>>
>>> Cheers,
>>>
>>> Gonzalo
>>>
>>> On 19/10/2010 8:31 PM, RFC Errata System wrote:
>>>> The following errata report has been submitted for RFC3398,
>>>> "Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping".
>>>>
>>>> --------------------------------------
>>>> You may review the report below and at:
>>>> http://www.rfc-editor.org/errata_search.php?rfc=3398&eid=2580
>>>>
>>>> --------------------------------------
>>>> Type: Technical
>>>> Reported by: Stephen James<[e-mail]>
>>>>
>>>> Section: 8.1.3
>>>>
>>>> Original Text
>>>> -------------
>>>> Item 6.
>>>>
>>>> The gateway also sends a CANCEL message to the SIP node to
>>>>
>>>> terminate any initiation attempts.
>>>>
>>>>
>>>>
>>>> Corrected Text
>>>> --------------
>>>> Drop this statement.
>>>>
>>>> Notes
>>>> -----
>>>> No CANCEL is sent on INVITE transaction timeout. This is per 3261 "If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request."
>>>>
>>>> Instructions:
>>>> -------------
>>>> This errata is currently posted as "Reported". If necessary, please
>>>> use "Reply All" to discuss whether it should be verified or
>>>> rejected. When a decision is reached, the verifying party (IESG)
>>>> can log in to change the status and edit the report, if necessary.
>>>>
>>>> --------------------------------------
>>>> RFC3398 (draft-ietf-sipping-isup-06)
>>>> --------------------------------------
>>>> Title               : Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping
>>>> Publication Date    : December 2002
>>>> Author(s)           : G. Camarillo, A. B. Roach, J. Peterson, L. Ong
>>>> Category            : PROPOSED STANDARD
>>>> Source              : Session Initiation Proposal Investigation
>>>> Area                : Real-time Applications and Infrastructure
>>>> Stream              : IETF
>>>> Verifying Party     : IESG
>>>>
>>
>