Subject: [v6ops] draft-gont-6man-slaac-renum

From: Ron Bonica <[email-masked]>
Date: Mon, 6 May 2019 14:36:09 +0000

Folks,

Each week between now and IETF 105, we will review and discuss one draft with an eye towards progressing it.

This week, please review and comment on draft-gont-6man-slaac-renum.

                                                             Fred and Ron

Non-Juniper

---

From: Ole Troan <[email-masked]>
Date: Tue, 7 May 2019 10:52:10 +0200

Ron,

> This week, please review and comment on draft-gont-6man-slaac-renum.

This document got lots of discussion and concerns raised in 6man/v6ops.
There was also a side meeting on it, in Bangkok (or Prague, it's all a blur to me)
Perhaps a start would be for the chairs/authors to summarise the issues already voiced?

Cheers,
Ole

---

From: Fred Baker <[email-masked]>
Date: Tue, 7 May 2019 13:53:59 -0700

If you wish. I'd suggest we ask the authors to do that.

> On May 7, 2019, at 1:52 AM, Ole Troan <[email-masked]> wrote:
> 
> Ron,
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

--------------------------------------------------------------------------------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 13 May 2019 10:37:15 +1200

Broadly, I support this draft.

I am puzzled however about whether it should be Standards Track or BCP. The core is section 5, which seems like a group of operational recommendations more than specific updates to standards track documents. So I'd be inclined to make it a BCP. Even then, this language is wrong:

> 5.  Possible workarounds
> 
>    The following subsections discuss possible workarounds for the
>    aforementioned problem.

No, these are not possible workarounds. They are formal recommendations.

Section 5.1.1.1. "Router Configuration Variables" changes a timer in 6.2.1. "Router Configuration Variables" of RFC 4861. That section starts out:

>>> A router MUST allow for the following conceptual variables to be
>>> configured by system management.

So there is no need to update 4861 or a conforming implementation of 4861; if the current draft is a BCP it can simply RECOMMEND new timer values.

My bottom line is that this draft would probably go quicker as a v6ops BCP than as a 6man Proposed Standard. But one way or the other, IMHO it should advance ASAP.

Regards
    Brianr