Subject: I-D Action: draft-ietf-6man-rfc6434-bis-04.txt

From: [email-masked]
Date: Thu, 22 Feb 2018 14:52:27 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance WG of the IETF.

        Title           : IPv6 Node Requirements
        Authors         : Tim Chown
                          John Loughney
                          Timothy Winters
	Filename        : draft-ietf-6man-rfc6434-bis-04.txt
	Pages           : 40
	Date            : 2018-02-22

Abstract:
   This document defines requirements for IPv6 nodes.  It is expected
   that IPv6 will be deployed in a wide range of devices and situations.
   Specifying the requirements for IPv6 nodes allows IPv6 to function
   well and interoperate in a large number of situations and
   deployments.

   This document obsoletes RFC 6434, and in turn RFC 4294.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6434-bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-6man-rfc6434-bis-04
https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc6434-bis-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc6434-bis-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Timothy Winters <[email-masked]>
Date: Thu, 22 Feb 2018 17:54:52 -0500

Version 04 includes all the current feedback we have gotten on list.  In
particular the Network Management Section was updated.

~Tim

On Thu, Feb 22, 2018 at 5:52 PM, <[email-masked]> wrote:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

-- 

Now offering testing for SDN applications and controllers in our SDN switch
test bed. Learn more today http://bit.ly/SDN_IOLPR

---

From: Bob Hinden <[email-masked]>
Date: Thu, 22 Feb 2018 15:36:14 -0800

Tim,

Thanks for getting the new draft out.  The working group last call ended two days ago.

Folks commenting on this version, please review the changes.  Assuming there aren’t any significant issues, I will plan to advance it to the IESG early next week.

Thanks,
Bob

> On Feb 22, 2018, at 2:54 PM, Timothy Winters <[email-masked]> wrote:
> 
> Version 04 includes all the current feedback we have gotten on list.  In particular the Network Management Section was updated.
> 
> ~Tim
> 
> Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 23 Feb 2018 08:00:38 +0100

> Folks commenting on this version, please review the changes.  Assuming there aren’t any significant issues, I will plan to advance it to the IESG early next week.

I still think the text is not quite accurate. See my original post for
reasoning and explanations.

https://mailarchive.ietf.org/arch/msg/ipv6/t5elEjSE6-D3izL2cdVO6gqAqjI

Concrete issues in -04:

- "IPv6 MIBs have been updated since the last release of the document"

  I think the statement is false.

- "The following YANG data models SHOULD be supported by nodes that
   support a NETCONF agent."

  I think this also applies to RESTCONF. And terminology wise, we talk
  about NETCONF and RESTCONF servers (not agents). So perhaps this should
  be "The following YANG data models SHOULD be supported by nodes 
  supporting a NETCONF or RESTCONF server."

- RFC 7277 and RFC 7223 have revisions in the RFC editor queue.

- I fail to see why we say SHOULD for the SNMP forwarding MIB module
  but are silent about the IP routing YANG models.

- MIBs

  Please use MIB modules instead of MIBs. A MIB really is something
  different than a MIB module. (Bert has been fighting this for a long
  time.)

I personally find one subsection per sentence a bit ugly but that is a
pure stylistic issue and at the end something the authors have to
decide.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Tim Chown <[email-masked]>
Date: Fri, 23 Feb 2018 10:38:20 +0000

Hi,

> On 23 Feb 2018, at 07:00, Juergen Schoenwaelder <[email-masked]> wrote:
> 

>  I think the statement is false.

Perhaps we can change

"IPv6 MIBs have been updated since the last release of the document; [RFC8096] obseletes several MIBs, which nodes need no longer support."

to

"The status of many IPv6 MIB modules has changed since the last release of the document; [RFC8096] obseletes several MIB modules, which nodes need no longer support."

?

>  supporting a NETCONF or RESTCONF server."

Yes, we should have added RESTCONF, in three places I think.

> - RFC 7277 and RFC 7223 have revisions in the RFC editor queue.

Perhaps Bob can suggest whether we should include the RFCs, or their -bis drafts.

>  but are silent about the IP routing YANG models.

Well, that's conditional on the node being a router?  Those would be good suggestions for the V6OPS draft on router requirements.

>  different than a MIB module. (Bert has been fighting this for a long

Agreed.

> pure stylistic issue and at the end something the authors have to

I think we have; I really don't mind either way though.

Best wishes,
Tim

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 23 Feb 2018 13:38:03 +0100

> "The status of many IPv6 MIB modules has changed since the last release of the document; [RFC8096] obseletes several MIB modules, which nodes need no longer support."

These MIB modules are obsolete since 2005-2006 (!), see the Obsoletes:
headers in RFC 4293 et al. The problem is that the Obsoletes: headers
in RFCs are often ignored and RFC 8096 was an action to republish the
MIB modules with the status of all definitions changed to obsolete so
that people more likely understand that these MIB modules are
obsolete.  In other words, RFC 8096 does not obsolete the MIB modules,
it just reinforces that these MIB modules are obsolete. I also think
it should be sufficient to say in this document what the current IPv6
node requirements are (and to ignore how we got there). Hence, in my
view, the entire sentence is not needed. This is also what RFC 6434
did - it refers to the IP-MIB and it is silent about the MIB modules
that were already obsolete a couple of years when RFC 6434 was
published.

/js

---

From: Tim Chown <[email-masked]>
Date: Fri, 23 Feb 2018 14:51:41 +0000

Hi Juergen,

> On 23 Feb 2018, at 12:38, Juergen Schoenwaelder <[email-masked]> wrote:
> 

I'd say that RFC 8096 is worth referring to; the fact that it was published implies the WG felt it was needed, and it is relatively recent. But from what you say we could have better wording.

Maybe:

"[RFC8096] clarifies the obsoleted status of various IPv6-specific MIB modules."

Or suggest something else?

Tim

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 23 Feb 2018 15:56:59 +0100

> "[RFC8096] clarifies the obsoleted status of various IPv6-specific MIB modules."

This is a more accurate statement. Thanks.

/js

---

From: Bob Hinden <[email-masked]>
Date: Fri, 23 Feb 2018 08:23:54 -0800

Tim,

> On Feb 23, 2018, at 2:38 AM, Tim Chown <[email-masked]> wrote:
> 
> Hi,
> 

If they are in the RFC editor queue, I think pointing to the bis drafts would be best.  In the worst case, if when this draft gets to the RFC Editor, and if they are still in the queue we can deal with it then.

Bob