Mukesh Gupta | 1 May 2006 21:45
Favicon

FW: IETF Meeting Survey

FYI.

Please take time to complete the survey.

-----Original Message-----
From: Ray Pelletier [mailto:rpelletier <at> isoc.org] 
Sent: Monday, May 01, 2006 8:25 AM
To: wgchairs <at> ietf.org
Subject: IETF Meeting Survey

All;
It has been suggested that if I really wanted to get feedback on the 
Meeting Survey (and I do)  I should have it forwarded by the WG Chairs 
to the working groups - so this is a request that you ask members of the

working groups to complete a short survey that focuses primarily, but 
not exclusively, on their meeting experience in Dallas. 

I truly want the info to make the changes members of the community want,

if possible and greatly appreciate your assistance in this regard.

Those interested in taking the survey can find it at:
http://www.surveymonkey.com/s.asp?u=649182049947

Thanks
Ray Pelletier
IETF Admininstrative Director

_______________________________________________
(Continue reading)

Bhargavi Rajaraman | 29 May 2006 13:08

values for VRRP AuthType field

Hi All

RFC 2338 - which is a standards RFC for VRRP has defined values for
authentication type as

0 -  No authentication
1 - Simple text password
2 -  IP Authentication header.

but RFC 2787 which has definitions for all VRRP managed objects has defined
the values for vrrpOperAuthType
 as

1 -  No authentication
2 - Simple text password
3 -  IP Authentication header.

Why is there a conflict between the values specified in RFC 2338 (protocol
RFC) and RFC 2787 (RFC for managed objects). When ethereal is used to
capture and decode packets, it takes the values for AuthType as mentioned in
RFC 2338 .

Thanks
Bhargavi.

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp

(Continue reading)

Wijnen, Bert (Bert | 29 May 2006 15:55
Picon
Favicon

RE: values for VRRP AuthType field

In principle, when ENUMerated INTEGERs are used in MIB modules,
then we prefer to start the list of enumerations at 1 (and not zero).
So possibly MIB doctor review (or the MIB editor already knew)
has suggested to start at 1. 

If there are good underlying reasons to start at zero, then we
(MIB doctors) tend to accept that (certainly these days). But we
then want some text to the DESCRIPTION clause that explains WHY 
the list starts at zero. Possibly the MIB authors and the WG did
not feel strong that there had to be an exact mapping.

So possibly it would have been OK to map the values from the
protocol (2338) directly onto values in the ENUMerated list.
But since that was not done back when RFC2787 was approved,
I think it is best to live with it. It means you have to add one
to the value in the protocol in order to get to the value in the
MIB and vise versa.

Bert

> -----Original Message-----
> From: Bhargavi Rajaraman
> [mailto:Bhargavi.Rajaraman <at> flextronicssoftware.com]
> Sent: Monday, May 29, 2006 13:08
> To: vrrp <at> ietf.org
> Subject: [VRRP] values for VRRP AuthType field
> 
> 
> Hi All
> 
(Continue reading)

Mukesh Gupta | 29 May 2006 18:26
Favicon

RE: values for VRRP AuthType field

Moreover, the whole VRRP authentication mechanism has been obsoleted in
3768 (that obsoletes 2338).  The new values are:

      0 - No Authentication
      1 - Reserved
      2 - Reserved

Regards
Mukesh

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen <at> lucent.com]
> Sent: Monday, May 29, 2006 6:55 AM
> To: Bhargavi Rajaraman; vrrp <at> ietf.org
> Subject: RE: [VRRP] values for VRRP AuthType field
> 
> In principle, when ENUMerated INTEGERs are used in MIB modules,
> then we prefer to start the list of enumerations at 1 (and not zero).
> So possibly MIB doctor review (or the MIB editor already knew)
> has suggested to start at 1.
> 
> If there are good underlying reasons to start at zero, then we
> (MIB doctors) tend to accept that (certainly these days). But we
> then want some text to the DESCRIPTION clause that explains WHY
> the list starts at zero. Possibly the MIB authors and the WG did
> not feel strong that there had to be an exact mapping.
> 
> So possibly it would have been OK to map the values from the
> protocol (2338) directly onto values in the ENUMerated list.
> But since that was not done back when RFC2787 was approved,
(Continue reading)


Gmane