Re: [v6ops] Benjamin Kaduk's Discuss on draft-ietf-v6ops-transition-ipv4aas-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Thu, Jan 10, 2019 at 05:43:32PM +0100, JORDI PALET MARTINEZ wrote:
> Hi Benjamin,
> 
> Thanks again for your detailed review.
> 
> I'm already working in a draft for a new version including all the nits that you mention (some already were corrected in -13).
> 
> Some clarifications to some of your comments.
>  
>     Section 3.2
>     
>        TRANS-2:  The IPv6 Transition CE Router MUST have a GUI, CLI and/or
>                  API option to manually enable/disable each of the supported
>                  transition mechanisms.
>     
>     Do we really need to pick and name interfaces, or can we just say "MUST
>     have a configuration interface"?
> 
> Yes, the point here is to make sure that at least there is a GUI and CLI (or API). The idea is that the customer is able to buy a CE and later on use it in a different ISP. So, having both facilitate that, even in the case of a manual configuration required by the user. Normally DHCP-based mechanisms should do it, and also is currently very common that both are already supported, so not a big issue.

Er, do you require both GUI and CLI, or not?  The current text only
requires at least one.  (But yes, I agree it's common to support both
already, so this is not likely to be a burdensome requirement.)

>        CONFIG-1:  Request the relevant configuration options for each
>                   supported transition mechanisms, which MUST remain
>                   disabled at this step.
>     
>     This seems like it could make for really bad UX in some cases, such as when
>     a user is only given one class of configuration information from their ISP
>     and is hopelessly confused by questions (about other mechanisms) that they
>     don't have answers for.  Is the MUST requirement (not quoted) to follow
>     this step really justified?
> 
> This is needed to allow the rest of the config/priority process. I believe you are misinterpreting as something done by the user in the GUI or something. While it may be possible, it not the case. It is all done by DHCP.

I think you are right about my confusion; thanks for picking up on it.

>     
>     Section 3.2.1
>     
>                                                      If 464XLAT is
>        supported, it MUST be implemented according to [RFC6877].  [...]
>     
>     Do we want to consider adding "or a successor document"?
> 
> I think if we do that, we could need doing that for every RFC ... that's why we have documents updating previous ones, so I don't think so.

Well, another alternative is (as Ben suggests) to just not include this
sentence at all.  Which would of course also address my point here :)

-Benjamin