Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 23 February 2017 at 16:33, Fernando Gont <fgont@xxxxxxxxxxxxxxx> wrote:
On 02/23/2017 03:24 AM, Lorenzo Colitti wrote:
> On Thu, Feb 23, 2017 at 1:25 PM, Fernando Gont <fgont@xxxxxxxxxxxxxxx
> <mailto:fgont@xxxxxxxxxxxxxxx>> wrote:
>
>     > (I do also happen to think that it would be better if we waited a decade
>     > before changing this, because we're only 5 or so years into large-scale
>     > deployment that will hopefully last at least 3 or 4 decades. However, I
>     > don't expect many people to agree with me on that, so I'm not trying to
>     > make that argument here.)
>
>     Isn't that actually an argument for waiting before moving rfc4291bis to
>     full standard?
>
>     If you'd wait to change it, why would you want to cast this into stone
>     now? So that, later you can argue that "it's a full standard document...
>     so we shouldn't change it"?
>
>
> I don't see why that argument would carry any weight. Full standards can
> be changed and updated, too.
>
> What I most care about is that if we make fundamental changes like this,
> then it's not done as part of a reclassification, and the working group
> has its say.
>
> Whether the document says "full standard" or "draft standard" is not as
> important as whether it says the right thing.

Exactly. And if a document does not reflect operational reality, it has
a big problem.

My understanding is that Randy et al are trying to get rfc4291bis to
reflect operational reality, but you want to progress the document with
no changes, essentially meaning that you want to publish a document as
full standard which doesn't agree with how the protocol is being deployed.

If, even at the time of publication our documents already do not reflect
reality, we are not going to be taken seriously.

If you're argument is that we cannot do what is right because moving
rfc4291 to full standard doesn't allow it, then you're implicitly asking
not to move rfc4291bis to full standard (or are just aasking us to do
the wrong thing).

Actually, I was saying that I don't see that there's a real problem with the current text.

<<attachment: smime.p7s>>


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]