Kalyan.Tata | 12 Jul 02:05 2006
Picon

RE: MIB Dr. Review of draft-ietf-vrrp-unified-mib-05.txt

Hi Joan,
Thanks once again for the detailed review. I was shooting for some
deadline at work and couldn't
Reply in detail earlier.

My comments/ explanation  inline : (I removed the parts of your mail to
which I agree and do not have comments )

5) I consulted with other MIB Doctors and the rough consensus was to
leave deprected objects where they are in the MIB, even though they are
deprecated but to make it very obvious that they are deprected.
Also, Guidelines state to add the reason why they have been deprecated
to the DESCRIPTION.

-- I moved the order to the end of the MIB based on Bill Fenner's review
comments in the last revision.
-- Will move it back if it is required.

      vrrpNodeVersion  OBJECT-TYPE  --  ****  DEPRECATED OBJECT ****
        SYNTAX       Integer32
        MAX-ACCESS   read-only
        STATUS       deprecated
        DESCRIPTION
           "This value identifies the particular version of the VRRP
            supported by this node.
            This object is deprecated in the IP Version Independent
            MIB.

            This object has been deprecated and replaced by
            the vrrpOperationsVersion object in the
(Continue reading)

Bill Fenner | 12 Jul 17:40 2006
Picon

RE: MIB Dr. Review of draft-ietf-vrrp-unified-mib-05.txt


>5) I consulted with other MIB Doctors and the rough consensus was to
>leave deprected objects where they are in the MIB, even though they are
>deprecated but to make it very obvious that they are deprected.

As Kaylan mentions, in my AD + RFC4181 review I suggested moving
these, based on having received the same suggestion when we did
RFC 4293, 4113, 4022.  I thought that was the accepted procedure
(it made sense to me, since we want a new MIB user to see and use
the current objects before the deprecated ones).

  Bill

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

jcucchiara | 13 Jul 12:57 2006
Picon

Re: MIB Dr. Review of draft-ietf-vrrp-unified-mib-05.txt


----- Original Message -----
From: Bill Fenner <fenner <at> research.att.com>
To: <Kalyan.Tata <at> nokia.com>
Cc: <jcucchiara <at> mindspring.com>; <dromasca <at> avaya.com>; <vrrp <at> ietf.org>
Sent: Wednesday, July 12, 2006 11:40 AM
Subject: RE: MIB Dr. Review of draft-ietf-vrrp-unified-mib-05.txt

Hi Bill,

>
> >5) I consulted with other MIB Doctors and the rough consensus was to
> >leave deprected objects where they are in the MIB, even though they are
> >deprecated but to make it very obvious that they are deprected.
>
> As Kaylan mentions, in my AD + RFC4181 review I suggested moving
> these, based on having received the same suggestion when we did
> RFC 4293, 4113, 4022.  I thought that was the accepted procedure
> (it made sense to me, since we want a new MIB user to see and use
> the current objects before the deprecated ones).
>

Yes, there does seem to be 2 ways deprecated objects are handled
(i.e., leave the deprecated objects in place or move them to the end
of the MIB Module).  My motivation for consulting the
other MIB Drs was to see if there was a recommended way of
handling deprecated objects.

The MIB Drs. that commented on my question seemed to prefer leaving the
deprecated objects where they were.  This is also my preference because
(Continue reading)

jcucchiara | 13 Jul 13:32 2006
Picon

Re: Re: MIB Dr. Review of draft-ietf-vrrp-unified-mib-05.txt


> 
> ----- Original Message ----- 
> From: <Kalyan.Tata <at> nokia.com>
> To: <jcucchiara <at> mindspring.com>; <dromasca <at> avaya.com>
> Cc: <vrrp <at> ietf.org>; <fenner <at> research.att.com>
> Sent: Tuesday, July 11, 2006 8:05 PM
> Subject: RE: MIB Dr. Review of draft-ietf-vrrp-unified-mib-05.txt
> 
> 
> Hi Joan,
> Thanks once again for the detailed review. I was shooting for some
> deadline at work and couldn't
> Reply in detail earlier.
> 
> My comments/ explanation  inline : (I removed the parts of your mail to
> which I agree and do not have comments )
> 
> 

Great!  Thanks for your reply.
My comments are inline.

-Joan

> 
> 5) I consulted with other MIB Doctors and the rough consensus was to
> leave deprected objects where they are in the MIB, even though they are
> deprecated but to make it very obvious that they are deprected.
> Also, Guidelines state to add the reason why they have been deprecated
(Continue reading)

Kalyan.Tata | 13 Jul 21:42 2006
Picon

RE: Re: Re: MIB Dr. Review of draft-ietf-vrrp-unified-mib-05.txt

Thanks Joan again for an excelent review.  
I will make the changes you mntioned and get back to you if
I have any other questions.

Thanks
Kalyan

-----Original Message-----
From: ext vrrp-bounces <at> ietf.org [mailto:vrrp-bounces <at> ietf.org] 
Sent: Thursday, July 13, 2006 4:33 AM
To: Tata Kalyan (Nokia-ES/MtView); dromasca <at> avaya.com
Cc: fenner <at> research.att.com; vrrp <at> ietf.org
Subject: [VRRP] Re: Re: MIB Dr. Review of
draft-ietf-vrrp-unified-mib-05.txt

> 
> ----- Original Message -----
> From: <Kalyan.Tata <at> nokia.com>
> To: <jcucchiara <at> mindspring.com>; <dromasca <at> avaya.com>
> Cc: <vrrp <at> ietf.org>; <fenner <at> research.att.com>
> Sent: Tuesday, July 11, 2006 8:05 PM
> Subject: RE: MIB Dr. Review of draft-ietf-vrrp-unified-mib-05.txt
> 
> 
> Hi Joan,
> Thanks once again for the detailed review. I was shooting for some 
> deadline at work and couldn't Reply in detail earlier.
> 
> My comments/ explanation  inline : (I removed the parts of your mail 
> to which I agree and do not have comments )
(Continue reading)

Stephen Nadas (RL/TNT | 26 Jul 21:58 2006
Picon

VRRPv3 and Timer Enhancements Drafts - advertisement format

Hi, 

I was reading draft-ietf-vrrp-ipv4-timers-02 as well as 
draft-ietf-vrrp-ipv6-spec-07.  I have two comments:   

1) It seems that the VRRP advertisement format in the IPv6 
spec could be very similar to the format as proposed in 
draft-ietf-vrrp-ipv4-timers-02 (except version=3, not 2).  

The advantages are similar parsing, support of second, 
centisec, and millisec timers, and adding support for 
specifying the number of lost packets before declaring 
failure.  This would also set up the IPv6 spec to also 
support fast timers (version=3, type = 2) - and if this 
is the direction it seems that for IPv6 the two drafts 
could then be merged.    

2) Also, there is some discussion on the list about 
whether a wider AIG field is good in order to support more 
granular timer units (microsecs was mentioned) - I think 
for this to be useful a larger advertisement-interval (20 
bits) is needed as well.  Something like the below seems 
fairly future proof in terms of fast timers (note AIG 
is wider by a bit and Adv-Cnt could be wider as well if 
that is desirable). 

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version| Type  | Virtual Rtr ID|   Priority    | Count IP Addrs|
(Continue reading)

Picon

RE: VRRPv3 and Timer Enhancements Drafts - advertisement format

Steve,
	I agree with your observation that the IPv6 specification could be adjusted to support the type of changes
that were suggested in draft-ietf-vrrp-ipv4-timers-02. Steve Bates asked about aligning IPv4 and IPv6
specifications many months ago. As an end user, I see the need for this capability but I am not sure the need
for the capability has taken hold within this list. I know that this capability has been added in various
ways by several vendors. I would like to see it standardized (for both IPv4 and IPv6).

	draft-ietf-vrrp-ipv4-timers-02 needs to be updated to discuss which timers to use. Steve Bates
proposed enhancements for timer granularity and posed the question regarding the need for passing the
advertisement count.

	Personally, I like the idea of not passing an advertisement count. I suggested passing a failover time,
instead of an advertisement interval. My thought was that implementations could send advertisements as
often as they like but if an advertisement was not heard with the failover time, the implementation would
assume the master went away.

	The list has been silent regarding draft-ietf-vrrp-ipv4-timers-02 and it looks like
raft-ietf-vrrp-ipv6-spec-07 is being evaluated for "proposed standard". I do think that IPv4 and IPv6
could be aligned but I am not sure if there is a desire to do so and if the ideas for subsecond timers
(discussed on the list and in the draft) are widely accepted.

	With regard to your recommendations for aligning IPv4 and IPv6, if we were to proceed with passing the
granularity, count, and interval, I might suggest co-locating the reserved areas. I wonder if 16 bits
would be enough for the Advertisement Interval. Especially if you are going to add more bits to the granularity.

	If you moved away from transmitting the advertisement count, then granularity and failover time would
only be needed. If you could get rid of the first reserved bits, then you would not have to add the extra 32 bits.

	I think your suggestion of bringing the two in sync is a good suggestion. I am just not sure if there is a
general desire to standardize the feature.
(Continue reading)

Stephen Nadas (RL/TNT | 27 Jul 17:35 2006
Picon

RE: VRRPv3 and Timer Enhancements Drafts - advertisement format

Hi, 
Pls see "> SJN " inline.
Thanks,
-Steve  

-----Original Message-----
From: Hott, Robert W CIV B35-Branch [mailto:robert.hott <at> navy.mil] 
Sent: Thursday, July 27, 2006 9:59 AM
To: Stephen Nadas (RL/TNT); vrrp <at> ietf.org
Subject: RE: [VRRP] VRRPv3 and Timer Enhancements Drafts - advertisement
format 

Steve,
	I agree with your observation that the IPv6 specification could
be adjusted to support the type of changes that were suggested in
draft-ietf-vrrp-ipv4-timers-02. Steve Bates asked about aligning IPv4
and IPv6 specifications many months ago. As an end user, I see the need
for this capability but I am not sure the need for the capability has
taken hold within this list. I know that this capability has been added
in various ways by several vendors. I would like to see it standardized
(for both IPv4 and IPv6).

>SJN I agree w/you.

	draft-ietf-vrrp-ipv4-timers-02 needs to be updated to discuss
which timers to use. Steve Bates proposed enhancements for timer
granularity and posed the question regarding the need for passing the
advertisement count.

	Personally, I like the idea of not passing an advertisement
(Continue reading)


Gmane