Subject: [netmod] draft-ietf-netmod-routing-cfg-14.txt (review of changes)

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 23 May 2014 10:31:05 +0200

Lada,

I have reviewed the changes. A few more nits (sorry) before I am
fully happy.

- On page 21, you have changed the first path but also removed hte
  "as state data" phrase. I also note that it is 'routes' not 'route'.
  Perhaps this should also provide a more complete overview. Looking
  at the v4ur and v6ur models, perhaps it makes sense to list this:

  OLD

          /rt:routing-state/rt:ribs/rt:rib/rt:route

      and

          /rt:active-route/rt:output/rt:route,

  NEW

	  /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route
	  /rt:routing/rt:routing-instance/rt:routing-protocols/rt:routing-protocol
       and
	  /rt:active-route/rt:output

- Concerning cur-hop-limit, isn't the right approach to leave the default
  statement in the state tree and to remove the default from the config
  tree? (See the other thread.)

If you agree with these changes, please post another update and I will
finally hand it over to Benoit.

/js

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 23 May 2014 11:12:43 +0200

On 23 May 2014, at 10:31, Juergen Schoenwaelder <[email-masked]> wrote:

>  "as state data" phrase. I also note that it is 'routes' not 'route’.

Yes, you are right.

> 	  /rt:routing/rt:routing-instance/rt:routing-protocols/rt:routing-protocol

The ‘routing-protocol’ container and its contents have to be defined from scratch (see the third bullet) and its configuration in fact needn’t contain any explicit routes. So I think this line shouldn't be there.

>  tree? (See the other thread.)

Hmm, I am not sure what to do with this. The other modules only have the defaults in config. Can other people comment?

> finally hand it over to Benoit.

I will, but let’s resolve the defaults issue first.

Thanks, Lada

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 23 May 2014 12:09:52 +0200

> The ‘routing-protocol’ container and its contents have to be defined from scratch (see the third bullet) and its configuration in fact needn’t contain any explicit routes. So I think this line shou…

OK. Then just fix the first path.
 
> Hmm, I am not sure what to do with this. The other modules only have the defaults in config. Can other people comment?

My understanding is that defaults on config false objects only provide
an optimization for implementations that support 'trim' defaults
handling. The question is whether it is worth it. [Once I trouble
shoot something, I usually prefer to see all values being used,
filtering them out as needed for the task at hand, that is I would use
'report-all' anyway if available. But that is just me.]

That said, I like to take a pragmatic decision. I see two options:

- Add default 64 to cur-hop-limit to be consistent with the other
  state objects that have a default.

- Remove all defaults from all state objects because the real value
  of defaults is for config true objects.

Both work for me. We should decide this quickly. Lada? Martin?
Andy? Anyone else?

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 23 May 2014 13:21:30 +0200

> OK. Then just fix the first path.

Yes, done.

> 'report-all' anyway if available. But that is just me.]

[Another side-note: As you may remember, during the design session at IETF 70 I voted against having defaults in YANG. And I still think client software is a better place for dealing with them.]

>  of defaults is for config true objects.

If we do this and keep the leafs optional, the client has no way to force the server to report the value it is actually using. So I prefer the former option.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 23 May 2014 13:36:12 +0200

> If we do this and keep the leafs optional, the client has no way to force the server to report the value it is actually using. So I prefer the former option.

If I do not implement a leaf, I do not implement it. It does not
matter whether there is a default defined for the leaf or not. Yes,
using trim mode, the difference may be subtle and unclear.

Perhaps revised conformance coming out of YANG 1.1 will allow us to
specify what needs to be implemented or not. But lets not go there
here.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 23 May 2014 13:56:27 +0200 (CEST)

> Both work for me. We should decide this quickly. Lada? Martin?

Well, as I stated before, I think that the default statement should be
removed from the config leaf.  Thus, it doesn't make any sense to have
a default in the oper state for this leaf.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 23 May 2014 14:05:43 +0200

> removed from the config leaf.  Thus, it doesn't make any sense to have

Reasons? How is it different from, e.g., default-valid-lifetime in ietf-ip?

> a default in the oper state for this leaf.

Why not? As Juergen wrote, it is useful for the ‘trim’ mode, and it doesn’t matter whether the default is defined for the config leaf or not.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 23 May 2014 14:15:31 +0200 (CEST)

> Reasons? How is it different from, e.g., default-valid-lifetime in ietf-ip?

For default-valid-lifetime, there is an explicit default value in the
RFC.

For cur-hop-limit, the RFC says that the implementation should use the
value defined by IANA at the time of implementation, if it isn't
explicitily configured.  If you have a default statement here, and
IANA updates its value, it is impossible for an implementation to be
compliant with this YANG module and RFC 4861.

> Why not? As Juergen wrote, it is useful for the ‘trim’ mode, and it
> doesn’t matter whether the default is defined for the config leaf or
> not.

Correct, but it seems a bit arbitrary (even if the value 64 is
"stable").

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 23 May 2014 14:38:12 +0200

> For default-valid-lifetime, there is an explicit default value in the

Default TTL used to be in Assigned Numbers RFC and RFC 3232 handed it over to the online IANA database. IMO, this is no substantial difference.
  
> explicitily configured.  If you have a default statement here, and

As I wrote, I am prepared to remove that part of the description.

> compliant with this YANG module and RFC 4861.

The same will be true for default-valid-lifetime as soon as IETF updates its value.

> "stable”).

I don’t know what you mean by arbitrary. A server operating in the ‘trim’ mode will suppress the leaf if its value is 64. It is usually a good thing because this parameter is mostly uninteresting.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 23 May 2014 15:12:15 +0200

> The same will be true for default-valid-lifetime as soon as IETF updates its value.

Looking at RFC 4861, it seems there is explicit text saying that
CurHopLimit is under IANA control (i.e., designed to change without
updating RFC 4861).

        CurHopLimit    The default hop limit to be used when sending IP
                       packets.

                       Default: The value specified in the "Assigned
                       Numbers" [ASSIGNED] that was in effect at the
                       time of implementation.

A change to AdvDefaultLifetime likely requires a new RFC and since
there will be explicit dependencies between the documents, one could
hope that at the time such an update happens someone figures out that
the YANG data model may also need work. So I think there is (at least
in principle) a difference between the two things and I think we
better follow what RFC 4861 says (namely that control of the default
for CurHopLimit is with IANA).

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 23 May 2014 16:02:59 +0200

>                       Numbers" [ASSIGNED] that was in effect at the

It all seems a bit clumsy because the IANA page only talks about default TTL, which is an IPv4-specific parameter. Oh well …

> for CurHopLimit is with IANA).

OK. It seems Martin prefers a third solution, namely to have a default for cur-hop-limit neither in config nor in state data. Assuming the other defaults will stay as they are, I can live with that.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 May 2014 07:48:30 -0700

On Fri, May 23, 2014 at 3:09 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > On 23 May 2014, at 10:31, Juergen Schoenwaelder <
> [email-masked]> wrote:
> >
> > > Lada,
> > >
> > The 'routing-protocol' container and its contents have to be defined
> from scratch (see the third bullet) and its configuration in fact needn't
> contain any explicit routes. So I think this line shouldn't be there.
> >
>
> > Hmm, I am not sure what to do with this. The other modules only have the
> defaults in config. Can other people comment?
> >
>

I think we need to re-examine the default-stmt and mandatory-stmt
for config=false nodes. IMO they are both broken for the same reason:

NACM on the server can cause nodes to be silently dropped.
Unless the client is running as "root" (should be the exception)
then it does not know for sure why a leaf was missing in a <get>
reply.  Was it access control or was it the default for a "trim" basic-mode
server?

Both mandatory-stmt and default-stmt are unusable for config=false
nodes because of this ambiguity.

Short answer: remove defaults from all state objects.

/js

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 23 May 2014 17:33:16 +0200

On 23 May 2014, at 16:48, Andy Bierman <[email-masked]> wrote:

> 
> 
> 
> On Fri, May 23, 2014 at 3:09 AM, Juergen Schoenwaelder <[email-masked]> wrote:

But don’t config=true nodes have exactly the same problem in a reply to <get> or <get-config>?

Lada

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 May 2014 09:11:34 -0700

On Fri, May 23, 2014 at 8:33 AM, Ladislav Lhotka <[email-masked]> wrote:

> > > Hmm, I am not sure what to do with this. The other modules only have
> the defaults in config. Can other people comment?
> > >
> >
> But don't config=true nodes have exactly the same problem in a reply to
> <get> or <get-config>?
>
>
Yes, NACM has the same problem for config=true.  The operator needs
to know how NACM is configured -- clients that are not supposed to
know about some data node should not care if it is a default or not.

The ambiguity is wrt/ mandatory-stmt. (I think Martin pointed this out.)
The mandatory-stmt is 'false' if the default-stmt exists (has to be by
rule).

But if config=false and mandatory=false, the server
is not required to return instances of that node in an <rpc-reply>.
So the client does not know if the leaf is a 'trim' default or if the
server is electing not to include the leaf in the reply.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 23 May 2014 20:23:20 +0200

> know about some data node should not care if it is a default or not.

Hmm, maybe the nodes and subtrees blocked by NACM should be signalled somehow, e.g., by replacing the denied contents with <no-access/>.

> The mandatory-stmt is 'false' if the default-stmt exists (has to be by rule).
> 

I agree this needs to be reconsidered and clarified, but we have to decide about the defaults in the routing document now. So how about this modification of -14:

1. Remove all defaults in state data.
2. In config, remove only the default of ‘cur-hop-limit’.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 May 2014 12:27:04 -0700

On Fri, May 23, 2014 at 11:23 AM, Ladislav Lhotka <[email-masked]> wrote:

> Hmm, maybe the nodes and subtrees blocked by NACM should be signalled
> somehow, e.g., by replacing the denied contents with <no-access/>.
>
>
No -- generally you don't tell an unauthorized user anything about
the data they are not allowed to see.

> I agree this needs to be reconsidered and clarified, but we have to decide
> about the defaults in the routing document now. So how about this
> modification of -14:
>
>
OK

> 2. In config, remove only the default of 'cur-hop-limit'.
>
> Lada
>
>
> >
> >
> > Lada
> >
> >
> > Andy
> >
> > >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 23 May 2014 21:27:39 +0200

On Fri, May 23, 2014 at 08:23:20PM +0200, Ladislav Lhotka wrote:
> 
> So how about this modification of -14:
> 

Works well for me.

As said before, I personally find the possible optimization for trim
mode not worthwhile and we are better consistent how we do this in our
YANG modules.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 May 2014 12:48:44 -0700

> mode not worthwhile and we are better consistent how we do this in our
Agreed.

The thinking at the time RFC 6243 was written was based
on limited experience. One use case I had was a default
for a status knob, so if the status of lots of resources was
polled at once, only the "error" nodes would be returned
(e.g., default is "ok").

Since this RFC is optional, and trim mode is also optional,
we should not use defaults for config=false nodes in standard modules.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 25 May 2014 20:11:55 +0200

>> mode not worthwhile and we are better consistent how we do this in our

OK, see revision -15.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 25 May 2014 20:24:06 +0200

> the data they are not allowed to see.

I understand that firewalls use DROP rather than REJECT in order to avoid DoS attacks. For NACM, it doesn't make much sense to me because the client already has an open session and must have authenticated himself to the server. In filesystems and on the web, "access denied" replies are normal. 

Lada

---

From: Andy Bierman <[email-masked]>
Date: Sun, 25 May 2014 11:56:59 -0700

On Sun, May 25, 2014 at 11:24 AM, Ladislav Lhotka <[email-masked]> wrote:

> I understand that firewalls use DROP rather than REJECT in order to avoid
> DoS attacks. For NACM, it doesn't make much sense to me because the client
> already has an open session and must have authenticated himself to the
> server. In filesystems and on the web, "access denied" replies are normal.
>
>
That is not how NACM is defined.
I don't see any reason to redo the RFC.
The server sends 'access-denied' for RPC and edit authorization failures.
The instances and contents of unauthorized data are not disclosed.
NACM interprets a <get> or <get-config> as "retrieve the data I am
authorized to view".

Lada
Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 25 May 2014 21:04:49 +0200

> I don't see any reason to redo the RFC.

Then don’t complain about not being able to distinguish a trimmed default from a denied node. :-)

Lada

---

From: Andy Bierman <[email-masked]>
Date: Sun, 25 May 2014 12:20:52 -0700

On Sun, May 25, 2014 at 12:04 PM, Ladislav Lhotka <[email-masked]> wrote:

> > I understand that firewalls use DROP rather than REJECT in order to
> avoid DoS attacks. For NACM, it doesn't make much sense to me because the
> client already has an open session and must have authenticated himself to
> the server. In filesystems and on the web, "access denied" replies are
> normal.
> >
> >
> Then don't complain about not being able to distinguish a trimmed default
> from a denied node. :-)
>
>
I'm just pointing out that a client developer should think twice
before writing code that depends on 'trim' mode suppression of default
config=false leafs.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 May 2014 16:52:38 +0200

> >> mode not worthwhile and we are better consistent how we do this in our

Thanks. I will send this document to Benoit now.

/js