Re: Benjamin Kaduk's No Objection on draft-ietf-6man-ra-pref64-08: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Thu, Dec 19, 2019 at 03:30:34PM +1100, Jen Linkova wrote:
> Hi Benjamin,
> 
> On Tue, Dec 17, 2019 at 12:36 PM Benjamin Kaduk <[e-mail]> wrote:
> > > > I don't
> > > > have any proposed alternative text, though (would just predicating the
> > > > discussion on having a host that needs/wants the NAT64 prefix suffice?).
> > >
> > > How about this: we'll start the section 2 with smth like:
> > > 'While RFC6147 assumes that a NAT64/DNS64 environment does not require
> > > any changes on hosts for applications that work through NATs, there
> > > are some cases when  it is useful for hosts to know the NAT64 prefix
> > > ..."
> > > ?
> >
> > I think that would assuage my concerns; thanks!
> 
> Sorry for bringing this topic back but the authors have discussed the
> proposed changes and we believe it would be better to avoid mentioning
> that assumption the RFC6147 made..
> First of all that assumption is not true nowadays anyway - there are a
> lot of applications which work just fine on NAT44 networks but fail on
> NAT64 ones.
> If it was not the case, we would not have clat on mobile phones.
> Just mentioning that assumption w/o detailed discussion might be even
> more confusing for a reader and 'm not sure that this draft is the
> right place to discuss RFC6147 assumptions in details..
> The draft enumerates the use cases when - whatever RFC6147 is saying -
> the host might need to know the prefix and hopefully it should be
> clear for a reader why we are doing this..
> 
> It's not like I feel very strongly about it but I'd definitely prefer
> to keep the text as it is...
> What do you think?

I also don't feel strongly about it (and it was only a COMMENT-level note
to begin with).  I was just noting that if a reader came in with context
from RFC 6147 and started reading this text, they might make a false
assumption.  Your argument that this is not the right place to get into a
comprehensive discussion, and that a superficial discussion would not be
helpful, is pretty compelling, though.  So it seems that leaving as-is is
the best path forward.

Thanks,

Ben