headers
Hannes Tschofenig | 3 May 2008 20:19
Picon

Re: [Ecrit] Emergency Services work in TSVWG

Hi Keith,

there are 4 types of emergency services:

-	citizen to authority
-	authority to authority
-	authority to citizen
-       citizen to citizen

Nowadays people tend to use "individuals" as a replacement for "citizen". 

These terms are defined in ETSI EMTEL documents (and typically used in 
the same fashion everywhere).

I have to check whether the ECRIT framework draft says that our work is 
about "citizen to authority" emergency services. The context should make 
it clear, however. It does not hurt to be explicit. I don't have fears 
that someone could get a wrong impression about the purpose of our work. 
I am obviously not so sure about the current TSVWG document.

We have organized a couple of workshops and talked to the different 
stakeholders in the space of "citizen to authority" emergency services 
and we had to realize that balancing the different interests is very 
challenging to accomplish some deployment.

Now, I claim that authority-to-authority and authority-to-citizen is not 
any easier to deploy.

We see a document that specifies a fairly small extension to RSVP 
(considering that some other work has been done in the context of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen Hanna | 3 May 2008 06:04
Favicon

Secdir review of draft-ietf-tsvwg-rsvp-user-error-spec-06

I have reviewed this document as part of the security directorate's  
ongoing effort to review all IETF documents being processed by the  
IESG.  These comments were written primarily for the benefit of the  
security area directors.  Document editors and others should treat  
these comments just like any other comments.

I should preface this security review by stating that I am not an
expert in RSVP. Please excuse any misunderstandings on that front.
And please excuse the lateness of my comments.

This document defines a standard for user-defined errors in RSVP.
It clearly defines the format and semantics for such errors as well
as the procedures to be followed in sending and processing the errors.
Backward compatibility is adequately considered.

The Security Considerations section of this document seems to
adequately address most of the security implications of this
specification. The only security-related suggestion that I have
regarding the document is that I think it might be good to add text
to section 4.2, warning recipients to carefully examine a received
USER_ERROR_SPEC object for malformed data or otherwise dangerous
before processing it. Otherwise, buffer overruns or injection
problems could arise. Here's a sample paragraph:

Like any other data received from a partially trusted party,
the recipient MUST carefully check the USER_ERROR_SPEC object
and its contents to make sure that it does not contain any malformed
or illegal values and will not cause any buffer overruns or other
processing errors that could cause reliability or security problems.
The Error Description should be examined especially carefully
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lars Eggert | 5 May 2008 11:48
Picon
Gravatar

Re: [tsv-area] Proposed Liaison Statement to ITU-T SG 11 on Flow State Aware signalling

On 2008-4-25, at 15:06, ext Magnus Westerlund wrote:
> Please provide any comments on this draft LS before the 5th of May.  
> The ADs will judge if there is consensus on this statement before  
> sending it.

We've submitted the LS with a few wording changes. Find it at https://datatracker.ietf.org/liaison/447/

Lars
Permalink | Reply | 0 comments |
headers
Adrian Farrel | 8 May 2008 17:02
Picon

Fw: DISCUSS: draft-ietf-tsvwg-rsvp-user-error-spec

Hi,

Does anyone have any opinions on this Discuss?

Thanks,
Adrian
----- Original Message ----- 
From: "Chris Newman" <chris.newman <at> sun.com>
To: <iesg <at> ietf.org>
Cc: <tsvwg-chairs <at> tools.ietf.org>; 
<draft-ietf-tsvwg-rsvp-user-error-spec <at> tools.ietf.org>
Sent: Thursday, May 08, 2008 3:44 PM
Subject: DISCUSS: draft-ietf-tsvwg-rsvp-user-error-spec

> Discuss:
> The IETF has a policy on character sets and languages (BCP #18, RFC
> 2277) that I believe would apply to this protocol. If you believe BCP 18
> / RFC 2277 does not apply, you need to make the argument why and
> preferably do so in the document.
>
> While I applaud the realization that numeric codes alone are not
> sufficient for debugging real-world product interactions, moving to the
> richer solution (pairing numeric codes with freeform text and perhaps
> parameters) comes with issues.  Do you allow multi-line text as is
> useful if the error relates to a multi-line element or is complex to
> explain clearly?  Do you allow text in the native language of the
> admins/operators?  Do you tag the text with a language?
>
> In the SMTP world, we do get complaints about the English-only nature of
> the protocol-level error text, and with Spam making it more important to
(Continue reading)

Permalink | Reply | 501 comments |
headers
Magnus Westerlund | 9 May 2008 09:40
Picon
Favicon

Re: Fw: DISCUSS: draft-ietf-tsvwg-rsvp-user-error-spec

WG,

I have to say unless there is a really good reason, why not allow UTF-8. 
We also have to discuss if we should add language tags or not.

Cheers

Magnus

Adrian Farrel skrev:
> Hi,
> 
> Does anyone have any opinions on this Discuss?
> 
> Thanks,
> Adrian
> ----- Original Message ----- From: "Chris Newman" <chris.newman <at> sun.com>
> To: <iesg <at> ietf.org>
> Cc: <tsvwg-chairs <at> tools.ietf.org>; 
> <draft-ietf-tsvwg-rsvp-user-error-spec <at> tools.ietf.org>
> Sent: Thursday, May 08, 2008 3:44 PM
> Subject: DISCUSS: draft-ietf-tsvwg-rsvp-user-error-spec
> 
> 
>> Discuss:
>> The IETF has a policy on character sets and languages (BCP #18, RFC
>> 2277) that I believe would apply to this protocol. If you believe BCP 18
>> / RFC 2277 does not apply, you need to make the argument why and
>> preferably do so in the document.
>>
(Continue reading)

Permalink | Reply | 501 comments |
headers
Sridhar Bhaskaran | 12 May 2008 12:34
Picon
Gravatar

How to set SCTP send buffer size per association?

Hi,

The setsockopt option in SCTP to set SO_SNDBUF will set the send
buffer size for the whole socket, in the case of a one-to-many socket,
if the HAVE_SCTP_MULTIBUF is set to 0 in the kernel. Are there any
other way by which I can set the send buffer size per association
instead of at the socket level? There is a way to set the receive
buffer size per association using the
sctp_assocparams.sasoc_local_rwnd field with SCTP_ASSOCINFO option on
setsockopt.

Any help is appreciated.

Regards
Sridhar
Permalink | Reply | 1 comment |
headers
Lars Eggert | 12 May 2008 16:57
Picon
Gravatar

Re: [tsv-area] TSVWG last call on "UDP Usage Guidelines for Application Designers" to BCP

Hi,

On 2008-4-21, at 23:14, ext Robert Hancock wrote:
> - this document restricts its scope to UDP, but is there any reason  
> why the
> same content would not apply to 'applications' using any other
> non-congestion-controlled protocol? (Is there some reason to  
> restrict to UDP
> in particular?)

are you referring to datagram-based protocols other than UDP, e.g.,  
stuff that uses a custom IP protocol number? If so, I agree that many  
of these guidelines would probably apply in spirit, but it depends a  
lot on the individual case. I'd assume that if something runs directly  
on top of IP, it (1) fulfills a very specific (narrow) need and (2) is  
designed by folks that should be ore clueful than the average UD-based  
application designer - you need a standards action or IESG approval to  
get an IP number assigned.

But if people think it would be worth mentioning - in an informal way  
- that the spirit of these guidelines is worth keeping in mind when  
designing such IP-based protocols, that'd be fine with me. But I'd  
like to see some WG support before I make this addition.

> - is it intended that adherence to these principles will be standard  
> IESG
> review criteria (e.g. will this start to get referenced from
> http://www.ietf.org/ID-Checklist.html?)

I don't think we want to make compliance with this BCP-to-be a strict
(Continue reading)

Permalink | Reply | 10 comments |
headers
Lars Eggert | 13 May 2008 09:25
Picon
Gravatar

Re: Comments on draft-ietf-tsvwg-udp-guidelines-06

Hi, Pasi,

On 2008-4-21, at 17:48, ext Pasi.Eronen <at> nokia.com wrote:
> In general, the document is clear and well written.

thanks!

> Couple of
> additional suggestions follow:
>
> Two topics which could be useful to mention in Section 3.5
> (middlebox traversal guidelines):
>
> - Typically, TCP needs keep-alives much less frequently than UDP.
> Sending frequent keep-alive messages can, depending on the underlying
> technology, consume significant amounts of energy, which can be a
> problem especially for battery-powered devices. In this kind of
> situation, if an application needs to maintain connectivity for long
> periods with little traffic (e.g., VoIP phone that's just waiting
> for an incoming call), TCP could be more suitable than UDP.
>
> - Techniques such as ICE allow two hosts behind different middleboxes
> to establish direct communication in some circumstances. Reputedly,  
> the
> real-world success rate is much higher for UDP than for TCP, and this
> alone may be a reason for using UDP in some situations.

Although I agree with both of your observations, I'm not convinced  
that this is the document for them.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Lars Eggert | 13 May 2008 09:36
Picon
Gravatar

Re: A few comments to draft-ietf-tsvwg-udp-guidelines-06

Hi,

On 2008-4-25, at 9:59, ext Jukka MJ Manner wrote:
> - Related to Rob's comments, the document could be extended to cover  
> also
>  protocols that run directly over IP. The introduction could highlight
>  this, but then say that what the document says about UDP applies also
>  to other like protocols. So, no need to write long additional text,
>  just note that there are, and will be, also protocols that do are not
>  run over UDP.

please see my response to Rob's email from yesterday.

> - The introduction talks about multicast, but then leaves the topic  
> quite
>  open. At least one subsection could be usefull to discuss the topic a
>  bit furhter.

The only way in which the document talks about multicast is to note  
that:

"This document provides guidelines to designers of applications that  
use UDP for unicast transmission. A special class of applications uses  
UDP for IP multicast transmissions. Congestion control, flow control  
or reliability for multicast transmissions is more difficult to  
establish than for unicast transmissions, because a single sender may  
transmit to multiple receivers across potentially very heterogeneous  
paths at the same time. Designing multicast applications requires  
expertise that goes beyond the simple guidelines given in this  
document. The IETF has defined a reliable multicast framework <xref
(Continue reading)

Permalink | Reply | 16 comments |
headers
Jukka MJ Manner | 13 May 2008 09:48
Picon
Picon
Favicon

Re: A few comments to draft-ietf-tsvwg-udp-guidelines-06


Hi Lars,

See below, I pretty much agree on your points made.

Jukka

On Tue, 13 May 2008, Lars Eggert wrote:

> Hi,
> 
> On 2008-4-25, at 9:59, ext Jukka MJ Manner wrote:
> >- Related to Rob's comments, the document could be extended to cover also
> > protocols that run directly over IP. The introduction could highlight
> > this, but then say that what the document says about UDP applies also
> > to other like protocols. So, no need to write long additional text,
> > just note that there are, and will be, also protocols that do are not
> > run over UDP.
> 
> please see my response to Rob's email from yesterday.
> 

Yes, I read it, and think that a statement about the "spirit" would be 
good to have.

> >- The introduction talks about multicast, but then leaves the topic quite
> > open. At least one subsection could be usefull to discuss the topic a
> > bit furhter.
> 
> The only way in which the document talks about multicast is to note that:
(Continue reading)

Permalink | Reply | 15 comments |

Gmane