> -----Original Message-----
> From: Juergen Schoenwaelder <[email protected]>
> Sent: 01 May 2019 16:53
> To: Mikael Abrahamsson <[email protected]>
> Cc: Rob Wilton (rwilton) <[email protected]>; [email protected]
> Subject: Re: [netmod] 6021 ipv4-prefix
>
> On Wed, May 01, 2019 at 03:12:47PM +0200, Mikael Abrahamsson wrote:
> >
> > I am fine with c), but I am also saying I disagree with your view that
> > this this behaviour has been specified "since the beginning". This
> > might have been obvious to you from the beginning, but it's not
> > wrotten down properly (at least I haven't seen text that makes me
> > clearly understand the expected behaviour). I think the text
> > specifying what "canonical format is" referring to "same *value*" is
> > wrong. +17 and 17 is the same integer, 192.168.0.1/24 and
> > 192.168.0.0/24 are not the same *value*. It's misleading to refer to
> > the canonical form having the *same* *value* when we're throwing away
> information.
> >
>
> The basic disconnect here may be that for me the prefix is the value while for
> you the value is the prefix plus the unused bits.
[To frame this comment, I don't object to your currently proposed solution]
I consider the extra bits after the valid part of the prefix to be unwanted
noise.
For me, one hypothetical question I have is whether the potential convenience
of allowing 192.168.0.1/24 (for some use cases) outweighs the risk that the
wrong value has been provided but cannot be checked (e.g. 192.168.0.1/2).
Similarly, if you consider strings with a max length, I would expect a server
to reject a configured string that was too long rather that treat the excessive
characters as noise and silently truncate the input.
If it was down to me, and I was defining this now, then I would choose the
stricter input (as per the should currently in the ipv6-prefix definition).
But no longer care if the consensus is in the other direction.
Whichever way we change the definitions, I believe that they are being changed
in a non-backwards-compatible way that will impact some clients or server
implementations.
Thanks,
Rob
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
