RE: Comments on draft-nadas-vrrp-unified-spec-00.txt

Ok, thanks, will address these
-steve 

> -----Original Message-----
> From: Steve Bates [mailto:[email protected]] 
> Sent: Monday, August 20, 2007 11:01 AM
> To: Stephen Nadas (RL/TNT); [email protected]
> Subject: RE: Comments on draft-nadas-vrrp-unified-spec-00.txt 
> 
> Hi Steve,
> 
> With regard to number 4:
> In section 6.4.3 when a master receives a higher priority 
> advertisement then the master accepts the new advertisement 
> interval, needs to recompute the Master_Down_Interval, and 
> transition to backup.
> 
> Totally unrelated but far less important is the typo at 
> 5.2.6, which should be Rsvd.
> 
> Steve
> 
> -----Original Message-----
> From: Stephen Nadas (RL/TNT) [mailto:[email protected]]
> Sent: Monday, August 20, 2007 5:58 AM
> To: Steve Bates; [email protected]
> Subject: RE: Comments on draft-nadas-vrrp-unified-spec-00.txt 
> 
> Hi Steve, 
> 
> Thank you for reading and sending comments.  As to the 
> specifics, please see inline.  
> 
> Regards,
> Steve 
> 
> > -----Original Message-----
> > From: Steve Bates [mailto:[email protected]]
> > Sent: Friday, August 17, 2007 11:51 AM
> > To: Stephen Nadas (RL/TNT); [email protected]
> > Subject: Comments on draft-nadas-vrrp-unified-spec-00.txt
> > 
> > Steve,
> > 
> > Overall I like the new draft, but I would like to offer a few
> > comments:
> > 
> > 1) In the abstract and introduction you mention VRRP groups.  
> > I assume what you mean by this is that within a VRRP router the 
> > virtual routers in each address family are a domain unto themselves 
> > and do not overlap.  It might just be me, but the word 
> group implies 
> > some new organizational structure that we're not really adding.
> > Particularly in the second paragraph of section 3 where you 
> mention a 
> > group number.
> 
> I agree with your point and I'm not intending any "new 
> organizational sttructure"; I'll reword this to avoid the term. 
> 
> > 
> > 2) In section 6.4.1 when we transition from the initialize state to 
> > the backup state don't we want to set the Master_Down_Timer to the 
> > Master_Down_Interval (not the Adver_Timer)?
> > 
> 
> Yes. This appears to be a merge error on my part; I'll fix this. 
> 
> > 3) I think we should also mention in the two cases (both from the 
> > backup and master state) when we set the Master_Adver_Interval to 
> > Adver Interval contained in the ADVERTISEMENT that we need to 
> > recompute the Master_Down_Interval.
> > 
> 
> I see the text you mention in 6.4.2 (backup).  Unless there 
> are objections, I am okay adding a bullet here to "recompute 
> the Master_Down_Interval."
> However, I don't find this text in the master state - Did you 
> mean backup and initialize state (where the same text will 
> appear once I fix previous merge error?) 
> 
> > 4) In section 7.1 we now have a contradiction.  Since we 
> are accepting 
> > the Master's advertisement interval we can no longer reject a 
> > mismatch.
> > 
> 
> Right.  Need to fix.  (Also looks like a merge error from 3768.) 
> 
> > 5) In A.1 bullet item 2 you have a reference to VRRPv4.
> > 
> 
> Sure, this is a typo from pasted email text. 
> 
> > Thanks,
> > Steve
> > 
> > 
> 
> 

_______________________________________________
vrrp mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/vrrp