Re: New Version Notification for draft-farmer-6man-exceptions-64-05.txt

[神明達哉 <[e-mail]>]

At Wed, 8 Aug 2018 13:25:43 +1200,
Brian E Carpenter <[e-mail]> wrote:

> >> I think the answer depends on the final text of rfc4291bis. If the
> >> "or by exceptions..." text is retained there, that will be
> >> the governing document.
> >
> > I have a feeling that we're talking about slightly different
> > points...to be more specific, let's assume I'm writing a new
> > IPv6-over-link-type specification, where the IID length is 48 bits.
> > Also assume for simplicity that we retain the "or by exceptions..."
> > text in rfc4291bis.  In this case, are you saying that this new
> > IPv6-over-link-type must be a standard track document that updates
> > rfc4291bis so that it will be a document that meets the exception
> > requirement of "by exceptions defined in standards track documents"?
> > If yes, this essentially means the second interpretation of my
> > original message.
>
> Yes. But I don't think it matters too much. If we revised
> the text in rfc4291bis in some other way, the new IPv6-over-*
> document would formally update draft-farmer instead. The result
> would be the same.

I'm afraid I still failed to make my point clear.  It's not about
*which* of rfc4291bis and draft-farmer the new IPv6-over-* should
formally update.  It's about *whether* a new IPv6-over-* should
formally update these as part of "justification".

And I thought this was very critical in terms of whether we can reach
some consensus this time.  See this feedback for
draft-ietf-6man-rfc4291bis-09:
https://www.ietf.org/mail-archive/web/ipv6/current/msg27937.html

That is, if this attempt means a new IPv6-over-* document can
introduce a non-64 IID just by being published as a standards track
document without formally updating rfc4291bis (or draft-farmer), then
the discussion will simply become another round of the same endless
debate as before.  I don't think draft-farmer now magically solves
this gridlock.

--
JINMEI, Tatuya