Re: Fw: New Version Notification for draft-ietf-tsvwg-rsvp-user-error-spec-08

TSVWG

If you have any opinions on this change please express this quickly. I 
will give everyone a week to consider these changes.

Cheers

Magnus

Adrian Farrel skrev:
> Hi Chris,
> 
> The new revision of this I-D is intended to address your concerns.
> 
> I have moved over to UTF-8 with references and a recommendation to limit 
> to US-ASCII.
> 
> I have also commented on how to handle UTF-8 in an ASCII system, and 
> briefly noted the security risk of character strings in a protocol.
> 
> Having discussed language codes, we have decided not to include them. 
> The only reason for not including them is that no-one in the WG 
> expressed any support.
> 
> Let me know what you think. Hoping you will clear.
> 
> Cheers,
> Adrian
> 
> ----- Original Message ----- From: "IETF I-D Submission Tool" 

[SCTP] a small correction in RFC 4960

Re: [SCTP] a small correction in RFC 4960

Hi Ash,

yes, that is a (at least by me) known issue... This comes up, when you
dimension your parameters to fullfil a given path error detection  
time...

I'm not sure if we should start again an errata ID...

Best regards
Michael

On Jun 12, 2008, at 6:36 AM, Ash Kat wrote:

> Hello:
>
> 'Path.Max.Retrans' parmeters specifies the maximum number of  
> retransmission on a path before that path is marked down.
>
> Section 8.3 of RFC says:
>    When the value of this counter ""reaches"" the protocol parameter
>    'Path.Max.Retrans', the endpoint should mark the corresponding
>    destination address as inactive if it is not so marked, and may  
> also
>    optionally report to the upper layer the change of reachability of
>    this destination address.
>
> This will make the Heartbeat to be re-transmitted one count less  
> then 'Path.Max.Retrans'
>
> This is correct in Section 8.2 which says:
>    When the value in the error counter ""exceeds"" the protocol  
> parameter
>    'Path.Max.Retrans' of that destination address, the endpoint should
>    mark the destination transport address as inactive, and a
>    notification SHOULD be sent to the upper layer.
>
> So Section 8.3 should be modified and a path should be marked down  
> when error count exceeds 'Path.Max.Retrans'.
>
> Regards,
> Ashwani Kathuria
>
> Bring your gang together. Do your thing. Find your favourite Yahoo!  
> Group.

Re: [SCTP] a small correction in RFC 4960

Submit it as an errata to the RFC Editor for now.

Lars

On 2008-6-12, at 9:44, ext Michael Tüxen wrote:

> Hi Ash,
>
> yes, that is a (at least by me) known issue... This comes up, when you
> dimension your parameters to fullfil a given path error detection  
> time...
>
> I'm not sure if we should start again an errata ID...
>
> Best regards
> Michael
>
> On Jun 12, 2008, at 6:36 AM, Ash Kat wrote:
>
>> Hello:
>>
>> 'Path.Max.Retrans' parmeters specifies the maximum number of  
>> retransmission on a path before that path is marked down.
>>
>> Section 8.3 of RFC says:
>>   When the value of this counter ""reaches"" the protocol parameter
>>   'Path.Max.Retrans', the endpoint should mark the corresponding
>>   destination address as inactive if it is not so marked, and may  
>> also
>>   optionally report to the upper layer the change of reachability of
>>   this destination address.
>>
>> This will make the Heartbeat to be re-transmitted one count less  
>> then 'Path.Max.Retrans'
>>
>> This is correct in Section 8.2 which says:
>>   When the value in the error counter ""exceeds"" the protocol  
>> parameter
>>   'Path.Max.Retrans' of that destination address, the endpoint should
>>   mark the destination transport address as inactive, and a
>>   notification SHOULD be sent to the upper layer.
>>
>> So Section 8.3 should be modified and a path should be marked down  
>> when error count exceeds 'Path.Max.Retrans'.
>>
>> Regards,
>> Ashwani Kathuria
>>
>> Bring your gang together. Do your thing. Find your favourite Yahoo!  
>> Group.
>

Registering a socket for neighbour updates callback

Could anyone please tell me, how to register a socket to get neighbour
table update call back.

For example, one can get route table update, by creating a netlink
socket and registering it in "nl_groups" and then setting function
pointer "sk_data_ready" from sk.
This invoks the function pointer by "sk_data_ready" whenever route
table is modified.

Could somebody please tell the procedure to get the neighbour table callbacks .

Regards,
Bharati.

Re: Registering a socket for neighbour updates callback

Bharati Bhole wrote:
> Could anyone please tell me, how to register a socket to get neighbour
> table update call back.
> 
> For example, one can get route table update, by creating a netlink
> socket and registering it in "nl_groups" and then setting function
> pointer "sk_data_ready" from sk.
> This invoks the function pointer by "sk_data_ready" whenever route
> table is modified.
> 
> Could somebody please tell the procedure to get the neighbour table callbacks .
> 
> Regards,
> Bharati.
> 

This is a wrong mailing list for this question.  It sounds like you are
using linux and should direct these questions to linux-net <at> vger.kernel.org
or netdev <at> vger.kernel.org

-vlad

Re: [SCTP] a small correction in RFC 4960

Ash,

Yes, I agree.

This looks worth submitting to the RFC Editor as an
Errata to RFC 4960.

--brian

Ash Kat wrote:               (Thu, 12 Jun 2008 10:06:45)
> 
>    So Section 8.3 should be modified and a path should be marked
>    down when error count exceeds 'Path.Max.Retrans'.
> 

--

-- 
Brian F. G. Bidulock
bidulock <at> openss7.org
http://www.openss7.org/

Re: [Tsvwg] [SCTP] a small correction in RFC 4960

Hi Lars,

I have submitted an errata. The correct text should say in section 8.3:

    When the value of this counter exceeds the protocol parameter
    'Path.Max.Retrans', the endpoint should mark the corresponding
    destination address as inactive if it is not so marked, and may also
    optionally report to the upper layer the change of reachability of
    this destination address.

Best regards
Michael

On Jun 12, 2008, at 10:25 AM, Lars Eggert wrote:

> Submit it as an errata to the RFC Editor for now.
>
> Lars
>
> On 2008-6-12, at 9:44, ext Michael Tüxen wrote:
>
>> Hi Ash,
>>
>> yes, that is a (at least by me) known issue... This comes up, when  
>> you
>> dimension your parameters to fullfil a given path error detection  
>> time...
>>
>> I'm not sure if we should start again an errata ID...
>>
>> Best regards
>> Michael
>>
>> On Jun 12, 2008, at 6:36 AM, Ash Kat wrote:
>>
>>> Hello:
>>>
>>> 'Path.Max.Retrans' parmeters specifies the maximum number of  
>>> retransmission on a path before that path is marked down.
>>>
>>> Section 8.3 of RFC says:
>>>  When the value of this counter ""reaches"" the protocol parameter
>>>  'Path.Max.Retrans', the endpoint should mark the corresponding
>>>  destination address as inactive if it is not so marked, and may  
>>> also
>>>  optionally report to the upper layer the change of reachability of
>>>  this destination address.
>>>
>>> This will make the Heartbeat to be re-transmitted one count less  
>>> then 'Path.Max.Retrans'
>>>
>>> This is correct in Section 8.2 which says:
>>>  When the value in the error counter ""exceeds"" the protocol  
>>> parameter
>>>  'Path.Max.Retrans' of that destination address, the endpoint should
>>>  mark the destination transport address as inactive, and a
>>>  notification SHOULD be sent to the upper layer.
>>>
>>> So Section 8.3 should be modified and a path should be marked down  
>>> when error count exceeds 'Path.Max.Retrans'.
>>>
>>> Regards,
>>> Ashwani Kathuria
>>>
>>> Bring your gang together. Do your thing. Find your favourite  
>>> Yahoo! Group.
>>
>
>

I-D Action:draft-ietf-tsvwg-udp-guidelines-08.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group Working Group of the IETF.

	Title           : Guidelines for Application Designers on Using Unicast UDP
	Author(s)       : L. Eggert, G. Fairhurst
	Filename        : draft-ietf-tsvwg-udp-guidelines-08.txt
	Pages           : 27
	Date            : 2008-06-13

The User Datagram Protocol (UDP) provides a minimal, message-passing
transport that has no inherent congestion control mechanisms.
Because congestion control is critical to the stable operation of the
Internet, applications and upper-layer protocols that choose to use
UDP as an Internet transport must employ mechanisms to prevent
congestion collapse and establish some degree of fairness with
concurrent traffic.  This document provides guidelines on the use of
UDP for the designers of unicast applications and upper-layer
protocols.  Congestion control guidelines are a primary focus, but
the document also provides guidance on other topics, including
message sizes, reliability, checksums and middlebox traversal.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-udp-guidelines-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
I-D-Announce mailing list
I-D-Announce <at> ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Re: I-D Action:draft-ietf-tsvwg-udp-guidelines-08.txt

This revision fixes some language issues found by Alfred. No technical  
changes.

Lars

On 2008-6-13, at 17:45, ext Internet-Drafts <at> ietf.org wrote:
> 	Title           : Guidelines for Application Designers on Using  
> Unicast UDP
> 	Author(s)       : L. Eggert, G. Fairhurst
> 	Filename        : draft-ietf-tsvwg-udp-guidelines-08.txt