Subject: Confirmation of consensus to adopt: draft-clw-rfc6434-bis-01

From: Bob Hinden <[email-masked]>
Date: Fri, 7 Apr 2017 13:38:01 -0700

At the Chicago IETF 6MAN session there was clear consensus for adopting draft-clw-rfc6434-bis as a 6MAN working group document.  This message starts a one week call on confirming the consensus from the WG meeting.

        Title           : IPv6 Node Requirements
        Authors         : Tim Chown
                          John Loughney
                          Tim Winters
	Filename        : draft-clw-rfc6434-bis-01.txt
	Pages           : 34
	Date            : 2017-03-13

        https://tools.ietf.org/html/draft-clw-rfc6434-bis-01

Please respond only if you think this document should _not_ be adopted.
This adoption call will end on April 14, 2017.

Regards,

Bob & Ole

---

From: [email-masked]
Date: Thu, 27 Apr 2017 20:39:49 +0200

As there were no objections this document is now adopted as a working group document.
Authors, can you please re-submit the last revision as draft-ietf-6man-rfc6434bis-00.

Best regards,
Ole & Bob

> On 7 Apr 2017, at 22:38, Bob Hinden <[email-masked]> wrote:
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Michael Richardson <[email-masked]>
Date: Thu, 27 Apr 2017 17:35:09 -0400

[email-masked] wrote:
    > As there were no objections this document is now adopted as a working
    > group document.  Authors, can you please re-submit the last revision as
    > draft-ietf-6man-rfc6434bis-00.

I agree with adopting it.

I think that, given the pushback we have on rfc2460bis, that I would like to
make some progress on 6434bis before we attempt to finalize 2460bis.

I think that we should not have done these one at a time.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Apr 2017 13:06:01 +1200

Hi Michael,
On 28/04/2017 09:35, Michael Richardson wrote:
...
> make some progress on 6434bis before we attempt to finalize 2460bis.

I disagree quite strongly. On the contrary, we should IMHO get 2460bis
frozen and in the RFC Editor queue ASAP. Otherwise, 6434bis will be built on
shifting sands and we'll never get out of the loop.

(I really wish we had a better mechanism than a rarely revised RFC for formally
defining the latest IPv6 node requirements, but that's not really an option.
IMHO, Node Requirements should up for revision every time a relevant RFC is
published, not once in a while when somebody thinks of it.)

   Brian

---

From: Tim Chown <[email-masked]>
Date: Fri, 28 Apr 2017 10:01:21 +0000

> On 28 Apr 2017, at 02:06, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi Michael,

I agree with Brian.  And 6434bis will only reflect what’s in 2460bis; we need to get 2460bis frozen so we know what to put in 6434bis.

> published, not once in a while when somebody thinks of it.)

An interesting point. You could for example keep a VersionN-bis draft updated as soon as VersionN is published, and publish VersionN+1 as an RFC at some agreed interval. On our current track record, that interval is every 6 years. Such an approach would mean the most up-to-date guidance is not in the most recently published RFC, but in the “living” I-D. 

Tim

---

From: Michael Richardson <[email-masked]>
Date: Fri, 28 Apr 2017 12:14:59 -0400

Brian E Carpenter <[email-masked]> wrote:
    > Hi Michael, On 28/04/2017 09:35, Michael Richardson wrote: ...
    >> I think that, given the pushback we have on rfc2460bis, that I would
    >> like to make some progress on 6434bis before we attempt to finalize
    >> 2460bis.

    > frozen and in the RFC Editor queue ASAP. Otherwise, 6434bis will be
    > built on shifting sands and we'll never get out of the loop.

I don't it's useful to discuss header insertion or not or HbH option being
examined or not, etc. unless we know what the end host will do with the
result.

    > (I really wish we had a better mechanism than a rarely revised RFC for
    > formally defining the latest IPv6 node requirements, but that's not
    > really an option.  IMHO, Node Requirements should up for revision every
    > time a relevant RFC is published, not once in a while when somebody
    > thinks of it.)

I would agree... I think newtrk had a mechanism for this that you designed :-)

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 28 Apr 2017 12:19:17 -0400

Hi Tim,

>> I think that, given the pushback we have on rfc2460bis, that I would
like to
> shifting sands and we'll never get out of the loop.

I agree with Brian.  And 6434bis will only reflect what’s in 2460bis; we
need to get 2460bis frozen so we know what to put in 6434bis.

> (I really wish we had a better mechanism than a rarely revised RFC for
formally
> published, not once in a while when somebody thinks of it.)

An interesting point. You could for example keep a VersionN-bis draft
updated as soon as VersionN is published, and publish VersionN+1 as an RFC
at some agreed interval. On our current track record, that interval is
every 6 years. Such an approach would mean the most up-to-date guidance is
not in the most recently published RFC, but in the “living” I-D.

That sounds reasonable to me. I was also thinking if a wiki could work but
keeping it updated as a draft gives us more options. E.g. We could publish
an RFC every x years with the current content if needed.

Regards
Suresh