Subject: last call for <draft-ietf-6man-rfc6434-bis-03.txt>: NETCONF/SNMP/RESTCONF

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 7 Feb 2018 14:28:58 +0000

I disagree with 
" A node supporting network management SHOULD support NETCONF [RFC6241]
   and SNMP configuration [RFC3411]."

This makes absolutely no sense for the vast majority of nodes. It makes no sense for smartphones, tablets, laptops, or any other consumer-oriented device. It doesn't make sense for IoT devices (restconf maybe, but not netconf and SNMP). Many of these do support a management protocol (e.g., OMA-DM, Lightweight M2M), but NETCONF and SNMP are not protocols I would recommend for them. I recommend deleting this sentence. I also do not recommend adding a similar RESTCONF statement, though I think it would be good in 16.2. YANG Data Models (and subsections) to say "NETCONF or RESTCONF" everywhere you say "NETCONF".

Or perhaps I don't understand the distinction between a "network" management protocol and a management protocol that supports configuration/management/statistics/etc. of network parameters. If "network" management protocol is distinct from or a special type of management protocol, a definition might be useful.
Barbara

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
> Sent: Tuesday, February 06, 2018 6:24 PM
> To: IPv6 List <[email-masked]>
> Cc: Bob Hinden <[email-masked]>
> Subject: 6man w.g. last call for <draft-ietf-6man-rfc6434-bis-03.txt> [Second
> try]
> 
> 
> This message starts a two week 6MAN Working Group Last Call on advancing:
> 
>       Title           : IPv6 Node Requirements
>       Authors         : Tim Chown
>                         John Loughney
>                         Timothy Winters
>       Filename        : draft-ietf-6man-rfc6434-bis-03.txt
>       Pages           : 40
>       Date            : 2018-02-06
> 
>       https://tools.ietf.org/html/draft-ietf-6man-rfc6434-bis-03
> 
> as a Best Current Practice (BCP).  Substantive comments and statements of
> support for publishing this document should be directed to the mailing list.
> Editorial suggestions can be sent to the author.  This last call will end on 20
> February 2018.
> 
> Thanks,
> Bob & Ole
> 
> 
>

---

From: Timothy Winters <[email-masked]>
Date: Wed, 7 Feb 2018 12:50:32 -0500

Hi Barbara,

I agree with the RESTCONF or NETCONF comment, I was suppose to make that
change before I pushed and seem to have missed it.

For your general arguement about suggesting SNMP, NETCONF, or RESTCONF.
 In this case we start with the following for network management

" Network management MAY be supported by IPv6 nodes."

So it's a MAY in general.  I do think that in this case it's very different
for a router or host.  I think SNMP, NETCONF, and RESTCONF apply to router
but as you point out doesn't apply so well in other areas.

What about updating it to the following?

"A *router* supporting network management SHOULD support NETCONF [RFC6241
<https://tools.ietf.org/html/rfc6241>], RESTCONF

   and SNMP configuration [RFC3411 <https://tools.ietf.org/html/rfc3411>]."

Regards,
Tim

On Wed, Feb 7, 2018 at 9:28 AM, STARK, BARBARA H <[email-masked]> wrote:

> This makes absolutely no sense for the vast majority of nodes. It makes no
> sense for smartphones, tablets, laptops, or any other consumer-oriented
> device. It doesn't make sense for IoT devices (restconf maybe, but not
> netconf and SNMP). Many of these do support a management protocol (e.g.,
> OMA-DM, Lightweight M2M), but NETCONF and SNMP are not protocols I would
> recommend for them. I recommend deleting this sentence. I also do not
> recommend adding a similar RESTCONF statement, though I think it would be
> good in 16.2. YANG Data Models (and subsections) to say "NETCONF or
> RESTCONF" everywhere you say "NETCONF".
>
> Or perhaps I don't understand the distinction between a "network"
> management protocol and a management protocol that supports
> configuration/management/statistics/etc. of network parameters. If
> "network" management protocol is distinct from or a special type of
> management protocol, a definition might be useful.
> Barbara
>
> --------------------------------------------------------------------
> 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: Brian E Carpenter <[email-masked]>
Date: Thu, 8 Feb 2018 07:47:07 +1300

Is SNMP configuration really a thing? My understanding is perhaps
wrong, but I thought nobody used it in practice.

   Brian

---

From: [email-masked]
Date: Wed, 07 Feb 2018 19:53:35 +0100 (CET)

> wrong, but I thought nobody used it in practice.

It exists and there are probably organizations using it. We *do not*
use it, and disagree about having this as a SHOULD.

NETCONF and RESTCONF are fine.

Steinar Haug, AS2116

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 7 Feb 2018 20:51:44 +0100

I think section 16 needs several updates.

OLD

   A node supporting network management SHOULD support NETCONF [RFC6241]
   and SNMP configuration [RFC3411].

NEW

   A node supporting network management SHOULD support NETCONF [RFC6241]
   or RESTCONF [8040] for configuration and SNMP [RFC3411] for monitoring.

Concerning section 16.1, first note that we talk about MIB modules not
about MIBs. That said, the first statement seems incorrect. Which IPv6
MIB module has been updated since RFC 6434? I do not know any. If you
read the abstract of RFC8096, then it becomes clear that we have
version neutral IP and forwarding MIB modules for >12 years and the
IPv6 specific modules are specifically not to be implemented.  Note
the the IF-MIB is also needed to implement the other MIB modules. So
it might be best to delete the entire first paragraph. I think it
makes sense to collapse 16.1 and 16.1.1 and 16.1.2 into just this:

16.1.   Management Information Base (MIB) Modules

   The IF-MIB MIB module [RFC2863], the IP-MIB MIB module [RFC4293]
   and the IP-FORWARD-MIB MIB module [RFC4292] SHOULD be supported by
   nodes that support the SNMP protocol.

Concerning section 16.2, please note that updates of the YANG modules
have recently been approved and are now sitting in the RFC editor
queue. I also propose to collapse Section 16.2 into just this:

16.2.   YANG Data Models

   The 'ietf-interfaces' data model [draft-ietf-netmod-rfc7223bis],
   the 'ietf-ip' data model [draft-ietf-netmod-rfc7277bis] and the
   'ietf-routing' and 'ietf-ipv6-unicast-routing' data models
   [draft-ietf-netmod-rfc8022bis] SHOULD be supported by nodes that
   support NETCONF or RESTCONF protocols.

The text in the current I-D also talks about the System Management
YANG Model but I am not sure why this needs to be listed in _this_
document. If there is a specific reason why this should be listed,
then with the same reason we would likely have to list additional MIB
modules.

Reading things again, I am also not sure about the second sentence
right at the start of Section 16. I would probably drop that as
well. Summing things up, I propose this replacement for the entire
section 16:

NEW

16.  Network Management

   Network management MAY be supported by IPv6 nodes. A node
   supporting network management SHOULD support NETCONF [RFC6241] or
   RESTCONF [8040] for configuration and SNMP [RFC3411] for
   monitoring.

16.1.   Management Information Base (MIB) Modules

   The IF-MIB MIB module [RFC2863], the IP-MIB MIB module [RFC4293]
   and the IP-FORWARD-MIB MIB module [RFC4292] SHOULD be supported by
   nodes that support the SNMP protocol.

16.2.   YANG Data Models

   The 'ietf-interfaces' data model [draft-ietf-netmod-rfc7223bis],
   the 'ietf-ip' data model [draft-ietf-netmod-rfc7277bis] and the
   'ietf-routing' and 'ietf-ipv6-unicast-routing' data models
   [draft-ietf-netmod-rfc8022bis] SHOULD be supported by nodes that
   support NETCONF or RESTCONF protocols.

/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: Bob Hinden <[email-masked]>
Date: Wed, 7 Feb 2018 12:34:50 -0800

Steinar,

> On Feb 7, 2018, at 10:53 AM, [email-masked] wrote:
> 

While I agree for IPv4, is it used to configure IPv6 nodes?

Thanks,
Bob

---

From: [email-masked]
Date: Wed, 07 Feb 2018 21:49:39 +0100 (CET)

> While I agree for IPv4, is it used to configure IPv6 nodes?

We don't use SNMP to configure IPv6 nodes.

Steinar Haug, AS2116

---

From: Bob Hinden <[email-masked]>
Date: Wed, 7 Feb 2018 13:49:44 -0800

> On Feb 7, 2018, at 12:49 PM, [email-masked] wrote:
> 

Does anyone?

Bob

---

From: Brian Jones <[email-masked]>
Date: Wed, 07 Feb 2018 21:56:58 +0000

> > We don't use SNMP to configure IPv6 nodes.
We do not use SNMP to configure IPv6 nodes today but plan to in the future
as we move our management networks to IPv6 only. We do use SNMP to
configure some IPv4 node attributes today.

—
Brian
Virginia Tech

---

From: Bob Hinden <[email-masked]>
Date: Wed, 7 Feb 2018 14:13:06 -0800

> On Feb 7, 2018, at 1:56 PM, Brian Jones <[email-masked]> wrote:
> 
> 
> 
> We do not use SNMP to configure IPv6 nodes today but plan to in the future as we move our management networks to IPv6 only. We do use SNMP to configure some IPv4 node attributes today.

Thanks, that answers the question.

Bob

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 07 Feb 2018 22:41:54 +0000

>> We don't use SNMP to configure IPv6 nodes.

snmp is used extensively to configure docsis cable modems.  It's a
provisioning choice as to whether the transport is v4 or v6.

Nick

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 7 Feb 2018 22:52:24 +0000

Tim said:
> "A router supporting network management SHOULD support NETCONF [RFC6241], RESTCONF

Issues of SNMP for IPv6 aside...
Globally, there are hundreds of millions of CE routers that are unlikely to support any of these. I have personally written requirements that CE routers procured by my employer MUST NOT support SNMP. Which is very much the opposite of SHOULD. I disagree strongly with a recommendation that all CE routers globally SHOULD support either NETCONF or RESTCONF. When smartphones are used to tether other devices, they become routers from the perspective of how that term is used in this document. Smartphones are unlikely to ever support network management using any of these protocols. 
So, no. I recommend leaving this sort of router management debate to the v6ops router debate (which includes debate on scope of which routers to talk about). 6434bis does not need to mirror the current proposed router requirements draft. 6434 has been a very important reference for *all* IPv6 nodes. I expect 6434bis to be the same. Please don't turn 6434bis into something people feel free to ignore because it tries to impose requirements that aren't necessary.
Barbara

---

From: Fred Baker <[email-masked]>
Date: Thu, 8 Feb 2018 13:35:28 -0800

> On Feb 7, 2018, at 12:34 PM, Bob Hinden <[email-masked]> wrote:
> 

My perception is that SNMP is not widely used for configuration. Once upon a time, I worked for a company for whom it was the ONLY method of configuration (if you did something else, it was translated to SNMP), but that was a while back. If we're going to *require* something of all implementations, I would hope it was something that was widely used.

And I don't see how something two or more layers down is relevant. If I deliver the packets by pony express, does that affect what they contain?

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 09 Feb 2018 00:16:35 +0000

Fred Baker wrote:
> My perception is that SNMP is not widely used for configuration. Once
> upon a time, I worked for a company for whom it was the ONLY method
> of configuration (if you did something else, it was translated to
> SNMP), but that was a while back.

SNMP is currently the internal (and optionally external) transport
configuration mechanism for timos, i.e. Nokia SR7k routers.  This will
no doubt change in future.

I doubt there are any new network operating systems which will be built
to use snmp as a primary configuration mechanism. Although it exists in
a very real sense and will continue as long as DOCSIS is a thing, the
writing is on the wall in the longer term.

Nick

---

From: Bob Hinden <[email-masked]>
Date: Fri, 9 Feb 2018 08:21:01 -0800

Nick,

> On Feb 8, 2018, at 4:16 PM, Nick Hilliard <[email-masked]> wrote:
> 
> Fred Baker wrote:

Sounds to me that the appropriate language for SNMP configuration in the bis document is “MAY”.

Bob

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 09 Feb 2018 16:46:30 +0000

> Sounds to me that the appropriate language for SNMP configuration in the bis document is “MAY”.

Probably yes.  A long time ago it was clearer what a router was, but
these days pretty much every kernel will forward packets if you set a
flag one way or another.  As Barbara noted, there isn't a compelling
case for many types of devices which forward IP packets to support
netconf, restconf, snmp, or any other specific management layer, simply
because the deployment requirements are so heterogeneous.

Nick

---

From: Timothy Winters <[email-masked]>
Date: Fri, 9 Feb 2018 11:50:33 -0500

The Section for Network Management is MAY (as it was in past version of
this document) for this reason.   So I think what we are saying is if you
want network management you SHOULD use NETCONF/RESTCONF and MAY use SNMP.

~Tim

--

---

From: Mark Smith <[email-masked]>
Date: Sat, 10 Feb 2018 09:41:03 +1100

On 10 Feb. 2018 3:51 am, "Timothy Winters" <[email-masked]> wrote:

Just as a data point, the Nokia (originally Timetra) platforms use SNMP as
the configuration protocol between the NEs and the matching NMS (5620 SAM).
As it isn't an active choice made by the operator, it may not be as widely
known or remembered.

Regards,
Mark.

~Tim

--

---

From: Tim Chown <[email-masked]>
Date: Mon, 19 Feb 2018 15:07:34 +0000

> On 9 Feb 2018, at 16:50, Timothy Winters <[email-masked]> wrote:
> 
> The Section for Network Management is MAY (as it was in past version of this document) for this reason.   So I think what we are saying is if you want network management you SHOULD use NETCONF/RESTCONF and MAY use SNMP.

Indeed, in 6434 the (very short) network management section said that 'Network management MAY be supported by IPv6 nodes.' but also that 'for IPv6 nodes that are embedded devices, network management may be the only possible way of controlling these nodes.'

That part remains unchanged; network management support is still a MAY; what we need to agree are the additional words on NETCONF and - as proposed and not in -03 - RESTCONF for nodes that *do* support network management.

There will no doubt be legacy stuff that has SNMP and will never be updated or changed.  The question is what recommendation we add for the newer NETCONF and RESTCONF.  

Tim

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

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 19 Feb 2018 15:50:11 +0000

Tim C. said:
> There will no doubt be legacy stuff that has SNMP and will never be updated
> or changed.  The question is what recommendation we add for the newer
> NETCONF and RESTCONF.

I do not believe there is any place in 6434bis for a SHOULD or even MAY for any of these specific protocols. I fully support the conditional SHOULD statements related to MIBs (if SNMP) and YANG modules (if NETCONF/RESTCONF). I also fully support the existing statement "Network management MAY be supported by IPv6 nodes."

I think the added sentence "A node supporting network management SHOULD support NETCONF [RFC6241] and SNMP configuration [RFC3411]." needs to be deleted. There are vast quantities of nodes (wireless, IoT, home networking) that do support network management, but do not support it using SNMP, NETCONF, or RESTCONF. IETF has no business "strongly recommending" that they do support any of these. Many of these nodes can be configured to act as routers. So changing "node" to "router" would not be any better.

The text works fine without this added sentence.
Barbara

---

From: Tim Chown <[email-masked]>
Date: Mon, 19 Feb 2018 16:05:57 +0000

> On 19 Feb 2018, at 15:50, STARK, BARBARA H <[email-masked]> wrote:
> 
> Tim C. said:
> I think the added sentence "A node supporting network management SHOULD support NETCONF [RFC6241] and SNMP configuration [RFC3411]." needs to be deleted.

I agree a SHOULD for both (and potentially RESTCONF) is too greater a requirement, certainly at this stage given the intended BCP status.

Perhaps we can say instead say "Existing network management protocols include SNMP [RFC3411], NETCONF [RFC6241] and RESTCONF [RFC8040]", for the context of the SHOULDs that follow, which you agree with. 

If so, is there anything to add for RESTCONF to match the SHOULDs for nodes supporting SNMP or NETCONF?

> There are vast quantities of nodes (wireless, IoT, home networking) that do support network management, but do not support it using SNMP, NETCONF, or RESTCONF. IETF has no business "strongly recommending" that they do support any of these. Many of these nodes can be configured to act as routers. So changing "node" to "router" would not be any better.
> 

Best wishes,
Tim

---

From: Bob Hinden <[email-masked]>
Date: Mon, 19 Feb 2018 08:12:13 -0800

Tim,

> On Feb 19, 2018, at 8:05 AM, Tim Chown <[email-masked]> wrote:
> 

Perhaps add something like “but are not limited to”.  That is, there are other network management protocols used besides these three.

Bob

---

From: Tim Chown <[email-masked]>
Date: Mon, 19 Feb 2018 16:13:39 +0000

> On 19 Feb 2018, at 16:12, Bob Hinden <[email-masked]> wrote:
> 
> Tim,
> 

Yes, we can make that explicit.

Tim

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 19 Feb 2018 16:19:14 +0000

> >>> Tim C. said:
> >>>> There will no doubt be legacy stuff that has SNMP and will never be
> >>>> updated or changed.  The question is what recommendation we add
> for
> >>>> the newer NETCONF and RESTCONF.
> >>>
> >>> I do not believe there is any place in 6434bis for a SHOULD or even MAY
> for any of these specific protocols. I fully support the conditional SHOULD
> statements related to MIBs (if SNMP) and YANG modules (if
> NETCONF/RESTCONF). I also fully support the existing statement "Network
> management MAY be supported by IPv6 nodes."
> >>>
> >>> I think the added sentence "A node supporting network management
> SHOULD support NETCONF [RFC6241] and SNMP configuration [RFC3411]."
> needs to be deleted.
> >>
> >> I agree a SHOULD for both (and potentially RESTCONF) is too greater a
> requirement, certainly at this stage given the intended BCP status.
> >>
> >> Perhaps we can say instead say "Existing network management protocols
> include SNMP [RFC3411], NETCONF [RFC6241] and RESTCONF [RFC8040]", for
> the context of the SHOULDs that follow, which you agree with.
> >
> > Perhaps add something like “but are not limited to”.  That is, there are
> other network management protocols used besides these three.
> 

Yes, thx, I think that would be good.
 
> nodes supporting SNMP or NETCONF?

I would think the same YANG models would apply to RESTCONF as to NETCONF. So just change "NETCONF" to "NETCONF or RESTCONF" in 16.2, 16.2.1-3.
Barbara

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 19 Feb 2018 17:55:39 +0100

> I would think the same YANG models would apply to RESTCONF as to NETCONF. So just change "NETCONF" to "NETCONF or RESTCONF" in 16.2, 16.2.1-3.

Let me point again to what I believe is a short and concise proposal.

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

NEW

16.  Network Management

16.2.   YANG Data Models

/js

---

From: Tim Chown <[email-masked]>
Date: Mon, 19 Feb 2018 17:24:10 +0000

Hi,

> On 19 Feb 2018, at 16:55, Juergen Schoenwaelder <[email-masked]> wrote:
> 

I think we're hearing pushback against those SHOULDs on NETCONF/RESTCONF.

>   nodes that support the SNMP protocol.

So that's adding RFC 2863 to the existing text; the other two are included.

>   support NETCONF or RESTCONF protocols.

So 7227bis and 7223bis replace RFC7277 and RFC7223 (I didn't realise they were under revision), and we no longer mention RFC 7317?

The latter three seem router specific?

Tim

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 19 Feb 2018 17:30:50 +0000

>    RESTCONF [8040] for configuration and SNMP [RFC3411] for

This (2nd sentence) has the same phrasing I object to. IETF should not be trying to force NETCONF/RESTCONF/SNMP to be supported by smartphones, IoT devices, desktops/laptops, and home networked devices. Many of these do support some sort of "network management". Just not through IETF-created protocols. Most people consider device management protocols as including "support for network management". If there is some intent to distinguish between "device management" and "network management", then we really need for these terms to be defined.

I prefer the suggestion from Tim C and Bob H: 
Existing network management protocols include, but are not limited to, SNMP [RFC3411], NETCONF [RFC6241] and RESTCONF [RFC8040].
And then proceed from there as you suggest.
 
> Fax:   +49 421 200 3103
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-
> 2Duniversity.de_&d=DwIBAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8Tq4vrfog&m=Q87yVbxoOvDZLBqU_0wgs-
> kKKFMEZPdglA_RpqgVg_8&s=HoEcGKTyUGIupkbpkruL9xIA6Zg8R2wQbo_3T
> YHPecE&e= >