headers
Worley, Dale R (Dale | 3 Jan 2011 19:22
Favicon

(resend) Errata reports on erratum 2580 on RFC 3398 (ISDN User Part (ISUP) to SIP Mapping) and errata 2121 and 2122 on RFC 5479 (Requirements and Analysis of Media Security Management Protocols)

There may have been a mailer problem with the first sending of this
report to the Sipping mailing list.

======================================================================
RFC3398, "ISDN User Part (ISUP) to SIP Mapping"
Source of RFC: sipping (rai)

Errata ID: 2580

Status: Reported
Type: Technical

Reported By: Stephen James
Date Reported: 2010-10-19

Section 8.1.3 says:

Item 6.
The gateway also sends a CANCEL message to the SIP node to
terminate any initiation attempts.

It should say:

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Allen | 5 Jan 2011 18:07
Favicon

Re: draft-ietf-sipping-media-policy-dataset issues: mediatypes

Dale

I am OK with your proposed changes. 

I also would like to see this draft progress.

Andrew

-----Original Message-----
From: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On
Behalf Of Worley, Dale R (Dale)
Sent: Friday, December 03, 2010 2:15 PM
To: rai <at> ietf.org; sipping <at> ietf.org
Subject: [Sipping] draft-ietf-sipping-media-policy-dataset issues:
mediatypes

I am working on draft-ietf-sipping-media-policy-dataset to clean up some
issues.  These issues are minor technical changes to make the standard
more technically coherent and easier to implement.  As such, I don't
think they will be controversial in their essence, but I would like
people to look them over to ensure that I am not introducing new
problems.

The first issues revolve around media types:

1. In -10, all media type names that are mentioned in a MPDF are
explicitly required to be IANA-registered.  Technically, this means that
experimental or private-use types can not be used, even in situations
where all participants are aware of non-registered media types.  In
practice, people will go ahead and use them anyway.  I am proposing to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Worley, Dale R (Dale | 8 Jan 2011 04:59
Favicon

draft-ietf-sipping-media-policy-dataset: The implied boolean logic of policy operations

I am starting work on a messy part of the media policy dataset
definition:  Specifying the logic when a policy is applied to a
session-info, and also specifying how two policies are combined to
apply jointly to session-infos.  The goal is to implement one's
intuitive expectations while introducing as few special cases as
possible.

My current analysis is:

- The primary operation is applying a session-policy to a session-info
  to produce a possibly more restricted session-info.  This is done by
  applying the session-policy to each stream in turn, which may
  "restrict" the stream (in regard to bandwidth, codecs, etc.).

- A stream may be restricted to the point that it permits no media
  whatsoever.  Such "null" streams are all logically equivalent,
  although a null stream can be represented in many different ways.
  When translated back into SDP, a null stream becomes a rejected
  m= line.

- The different <stream> elements in a session-policy are effectively
  ORed together, in that the policy intends to permit any stream that
  conforms to *any one* of the <stream> elements.  This is necessary
  because e.g. a session-policy can contain one <stream> that specifies
  audio media and restricts the codecs permitted for audio, and
  another <stream> that specifies video media and restricts the codecs
  permitted for video.

- Thus, applying a session-policy to a stream involves applying each
  session-policy <stream> to the stream, and then choosing the "best"
(Continue reading)

Permalink | Reply | 3 comments |
headers
Gonzalo Camarillo | 18 Jan 2011 09:51
Picon
Favicon

Re: [Technical Errata Reported] RFC3398 (2580)

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 <sjames_1958 <at> yahoo.com>
> 
> Section: 8.1.3
> 
> Original Text
> -------------
> Item 6.
> 
> The gateway also sends a CANCEL message to the SIP node to
(Continue reading)

Permalink | Reply | 7 comments |
headers
Adam Roach | 18 Jan 2011 15:14
Favicon

Re: [Technical Errata Reported] RFC3398 (2580)

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<sjames_1958 <at> yahoo.com>
>>
>> Section: 8.1.3
>>
(Continue reading)

Permalink | Reply | 6 comments |
headers
Robert Sparks | 18 Jan 2011 16:16
Favicon

Re: [Technical Errata Reported] RFC3398 (2580)

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?
>>
(Continue reading)

Permalink | Reply | 5 comments |
headers
Gonzalo Camarillo | 18 Jan 2011 16:29
Picon
Favicon

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".
>>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ong, Lyndon | 18 Jan 2011 16:35

Re: [Technical Errata Reported] RFC3398 (2580)

That would be fine with me also.

Cheers,

Lyndon

-----Original Message-----
From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo <at> ericsson.com] 
Sent: Tuesday, January 18, 2011 7:30 AM
To: Robert Sparks
Cc: Adam Roach; Jon Peterson; Ong, Lyndon; Mary Barnes; sjames_1958 <at> yahoo.com; 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Worley, Dale R (Dale | 19 Jan 2011 18:04
Favicon

Re: [Technical Errata Reported] RFC3398 (2580)

________________________________________
From: sipping-bounces <at> ietf.org [sipping-bounces <at> ietf.org] On Behalf Of Robert Sparks [rjsparks <at> nostrum.com]

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.
_______________________________________________

Yeah -- that's covered in my errata report of 21 Dec (resent 3 Jan):

http://www.ietf.org/mail-archive/web/sipping/current/msg17732.html

======================================================================
RFC3398, "ISDN User Part (ISUP) to SIP Mapping"
Source of RFC: sipping (rai)

Errata ID: 2580

Status: Reported
Type: Technical

Reported By: Stephen James
Date Reported: 2010-10-19

Section 8.1.3 says:

Item 6.
The gateway also sends a CANCEL message to the SIP node to
terminate any initiation attempts.

It should say:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Worley, Dale R (Dale | 19 Jan 2011 18:19
Favicon

Errata report on erratum 2310 on RFC 5923 ("Connection Reuse in SIP") and erratum 2502 on RFC 5954 (Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261")

======================================================================
RFC5923, "Connection Reuse in SIP"
Source of RFC: sip (rai)

Errata ID: 2310

Status: Reported
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2010-06-24

Section 8.2 says:

[[ in the last paragraph at the bottom of page 13: ]]

   The server, if it decides to reuse the connection, MUST cache in the
   alias table the identity (or identities) of the client as they appear
|  in the X.509 certificate subjectAlternativeName extension field.  [...]
                                   ^^^^^^^^^^^

It should say:

   The server, if it decides to reuse the connection, MUST cache in the
   alias table the identity (or identities) of the client as they appear
|  in the X.509 certificate subjectAltName extension field.  [...]
                                   ^^^

Notes:
(Continue reading)

Permalink | Reply | 0 comments |

Gmane