Re: [dhcwg] RAAN & SRSN drafts

Ralph Droms [mailto:rdroms@cisco.com] writes:

> Glen - I think Bernie has it right: the options are in two drafts as a
> matter of style.  Keeping the SRSN option in a separate doc keeps it
> easier to find, read and understand.  

I'm not sure how: all of the text could remain the same -- what we're really
talking about is adding a section to a draft.  Advancing two dependent
drafts simultaneously is always harder than advancing one...

> SRSN could certainly be
> referenced as part of a doc that defines RAAN.

It already is, in
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-agentopt-delegate-02:

9.  Reordering received DHCP messages

   The relay agent MUST use the Server Reply Sequence Number (SRSN)
   option [4] to detect and discard RAAN options contained in DHCP
   messages that are received out of order.

That's why I made the suggestion: if SRSN MUST be used with RAAN & there
aren't any other defined (only potential) uses for the SRSN option, why not
keep them together in one place?
> 
> Is there a particular advantage to putting the options in one doc?

Reducing 1) the number of documents to advance & 2) keeping dependent
options in one place.

> 
> - Ralph
> 
> On Apr 21, 2009, at 12:49 AM 4/21/09, Glen Zorn wrote:
> 
> > Bernie Volz (volz) [mailto:volz@cisco.com] writes:
> >
> >> I do think they should be. Ralph and I just re-spun the ones that
> had
> >> expired a while back without making any major changes.
> >>
> >> While I like the idea of avoiding layer violations which was, at
> >> least
> >> in my mind, the strongest motivation for RAAN (and thus SRSN), I'm
> >> not
> >> so sure that this now is a strong enough argument to proceed with
> >> RAAN/SRSN because there are already DHCPv6 relay agents that do the
> >> layer violations as they had no choice.
> >
> > Be that as it may, it's nice to have a clean way to do things.
> >
> >>
> >> SRSN might be useful for more than just RAAN (as it provides the
> >> 'ordering' data that is missing from DHCPv6 response flows over UDP
> >> from
> >> the server).
> >
> > True, but other documents can still reference the definition,
> > right?  That
> > idea was why I didn't suggest pushing everything into one option...
> >
> > ...
> >
> >
> > _______________________________________________
> > dhcwg mailing list
> > dhcwg@ietf.org
> > https://www.ietf.org/mailman/listinfo/dhcwg
> 