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

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