Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Address

On 23 February 2017 at 16:33, Fernando Gont <fgont(_at_)si6networks(_dot_)com> 
wrote:

> On 02/23/2017 03:24 AM, Lorenzo Colitti wrote:
> > On Thu, Feb 23, 2017 at 1:25 PM, Fernando Gont 
> > <fgont(_at_)si6networks(_dot_)com
> > <mailto:fgont(_at_)si6networks(_dot_)com>> 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.

smime.p7s
Description: S/MIME Cryptographic Signature