Re: [v6ops] Erik Kline's Discuss on draft-ietf-v6ops-cpe-slaac-renum-05: (with DISCUSS and COMMENT)

I agree.  I just think then the text about "the lesser of two lifetime
values" doesn't quite read correctly nor give the impression that this
applies to things like ULA prefixes.  I think it's probably pretty
easy to fix with minimal text.

On Thu, Oct 22, 2020 at 7:11 AM Ted Lemon <mellon@fugue.com> wrote:
>
> I think it’s reasonable to assume that in some situations a ULA will be generated and not remembered, or that the /48 will be remembered but the subnetting will not be. E.g. this could happen in an HNCP-delegated network pretty easily. The set of behaviors we are seeing in existing border routers fairly constrained with respect to what is theoretically possible and even reasonable.  So I don’t think there’s a good reason to suggest different treatment for ULAs.
>
> > On Oct 22, 2020, at 01:37, Erik Kline via Datatracker <noreply@ietf.org> wrote:
> >
> > Erik Kline has entered the following ballot position for
> > draft-ietf-v6ops-cpe-slaac-renum-05: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > [ section 3.2 ]
> >
> > * I absolutely agree in principle at these other lifetimes should be updated
> >  to the shorter of the two applicable lifetimes, but I'm worried that this
> >  text is not sufficiently precise.  Specifically, this recommendation only
> >  applies to options that depend in any way on the change in the delegated
> >  prefix, yes?  Perhaps just this qualifier is sufficient?
> >
> >  For example, none of these comparative lifetime recommendations apply to
> >  a stable ULA for a router that meets requirements ULA-[1..5] and chooses
> >  to advertise a ULA /48 RIO and maybe even a ULA DNS server, I think.
> >
> >  That being said, should this document also be saying that the ULA-derived
> >  options SHOULD prefer the ND_{P,V}_LIMIT lifetime values, in case a reboot
> >  causes a new ULA to be generated (i.e. the one supposedly in stable storage
> >  is lost or otherwise unrecoverable)?
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > [[ comments ]]
> >
> > [ section 3.1 ]
> >
> > * With respect to the second bullet: the lifetimes need to be dynamically
> >  *updateable*, not necessarily updated if, for example, the ND_{P,V}_LIMIT
> >  values are always lower than the remaining PD lifetimes.  In this situation,
> >  the requirement is still that the lifetimes can be updated, but to the
> >  casual observer of the steady state the RA contents might appear static
> >  (e.g., while the PD'd prefix is continuously renewed).
> >
> >  Maybe there's no text required here, but I didn't want a reader to be left
> >  with the impression that no two RAs could be identical
> >
> >
> > [[ nits ]]
> >
> > [ section 3.3 ]
> >
> > * In the 2nd bullet's 2nd bullet (this might be easier if these lists were
> >  numbered), it might be good to clarify that "the *deprecated* prefix can
> >  simply be advertised..."
> >
> >
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops