Subject: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-07.txt

From: [email-masked]
Date: Mon, 17 Jun 2013 13:41:46 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.

	Title           : YANG Data Model for System Management
	Author(s)       : Andy Bierman
                          Martin Bjorklund
	Filename        : draft-ietf-netmod-system-mgmt-07.txt
	Pages           : 37
	Date            : 2013-06-17

Abstract:
   This document defines a YANG data model for the configuration and
   identification of some common system properties within a device
   containing a NETCONF server.  This includes data node definitions for
   system identification, time-of-day management, user management, DNS
   resolver configuration, and some protocol operations for system
   management.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-netmod-system-mgmt-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-system-mgmt-07

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 18 Jun 2013 11:24:17 +0200

Hi,

I have a question regarding DNS resolver configuration. If the resolver receives a truncated response (TC flag set), it has to switch to TCP. So I don't understand why the only case in the "transport" choice is "udp" and how is the resolver supposed to behave.

Lada

Begin forwarded message:

> From: [email-masked]
> Subject: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-07.txt
> Date: June 17, 2013 10:41:46 PM GMT+02:00
> To: [email-masked]
> Cc: [email-masked]
> 
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

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

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 18 Jun 2013 12:57:15 +0200 (CEST)

Hi,

Ladislav Lhotka <[email-masked]> wrote:
> Hi,
> 
> I have a question regarding DNS resolver configuration. If the
> resolver receives a truncated response (TC flag set), it has to switch
> to TCP. So I don't understand why the only case in the "transport"
> choice is "udp" and how is the resolver supposed to behave.

Right.  In the previous version the udp&tcp transport was implicit.

So what do we do; consider udp&tcp as one transport (with a single
port number)?  Define udp and tcp as separate transports where both
can be present at the same time?   Or do we go back to the old model
where additional transports could not be defined in the future?

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 18 Jun 2013 14:42:23 +0200

> where additional transports could not be defined in the future?

I'd suggest to return almost to the old version, but with the ability to specify port number for each server, or perhaps also one common port for all servers.

I am not aware of any resolver implementations using anything else than UDP/TCP. Was there anybody requesting the extensibility of transports?

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 18 Jun 2013 14:52:09 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> I'd suggest to return almost to the old version, but with the ability
> to specify port number for each server, or perhaps also one common
> port for all servers.
> 
> I am not aware of any resolver implementations using anything else
> than UDP/TCP. Was there anybody requesting the extensibility of
> transports?

Yes, but it was in the form of a question:

  r) The model does not allow me to configure a DNS server using a
     non-standard port number. Should we not generally allow to
     configure complete transport layer endpoints?

And in general I agree.  But maybe this is an exception.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 18 Jun 2013 15:22:04 +0200

> And in general I agree.  But maybe this is an exception.

I think the "server" list could be left for the standard UDP/TCP. If any other transport was ever defined, which is IMO not very likely, it can be added in a separate container under "dns-resolver".

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 19 Jun 2013 10:32:43 +0200

> I have a question regarding DNS resolver configuration. If the resolver receives a truncated response (TC flag set), it has to switch to TCP. So I don't understand why the only case in the "transpo…

If a protocol internally switches the transport used, I think this is
outside the scope of the _configuration_ of the protocol, no?

/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: Martin Bjorklund <[email-masked]>
Date: Wed, 19 Jun 2013 11:00:41 +0200 (CEST)

> outside the scope of the _configuration_ of the protocol, no?

The point is that the standard mandates the use of both UDP and TCP to
the server, so the current choice doesn't really work.  You need to be
able to configure both udp and tcp for the same server.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 19 Jun 2013 11:19:14 +0200

> able to configure both udp and tcp for the same server.

My understanding was the ietf-netmod-system applies to the DNS
resolver client, not to a DNS server. By default, a resolver uses UDP
today, unless I set RES_USEVC in my application as a resolver option,
no? The resolver may switch to TCP if necessary but is this not a
protocol internal mechanism?

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 19 Jun 2013 12:00:23 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> resolver client, not to a DNS server.

Yes.

> By default, a resolver uses UDP

If we have configured the resolver with:

   <server>
     <name>foo</name>
     <udp>
       <address>10.0.0.1</address>
     </udp>
   </server>

how can we expect it to ever connect over TCP?

Some alternatives are:

   <server>
     <name>foo</name>
     <udp>
       <address>10.0.0.1</address>
     </udp>
     <tcp>
       <address>10.0.0.1</address>
     </tcp>
   </server>

or:

   <server>
     <name>foo</name>
     <udp-or-tcp>
       <address>10.0.0.1</address>
     </udp-or-tcp>
   </server>

or:

   <server>
     <name>foo</name>
     <address>10.0.0.1</address>
   </server>

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 19 Jun 2013 14:16:54 +0200

> how can we expect it to ever connect over TCP?

It is a protocol internal upgrade - you have to understand the
protocol to know about it. 

Trying an analogy: If I put a http: URL in a config and then the web
server redirects it to a https: URL (or even something totally
different like a ftp: URL) then this does not affect the validity of
my config either.

The config says what I start with. The rest is something determined at
runtime. Does this make sense?

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 19 Jun 2013 14:35:12 +0200 (CEST)

> runtime. Does this make sense?

Ok, yes I guess you can see it this way.  It is a bit unclear to me
how this "internal protocol upgrade" is specified.  Does it say that
the client tries TCP on the same port as it tried UDP, or to the TCP
port found in the local config?  -- Note how we allow a port to be
configured, but the protocol spec (1123) only talks about port 53.

Also, how would you handle the RES_USEVC flag?  Note how RFC 5966
says:

   Regarding the choice of when to use UDP or TCP, Section 6.1.3.2 of
   RFC 1123 also says:

      ... a DNS resolver or server that is sending a non-zone-transfer
      query MUST send a UDP query first.

   That requirement is hereby relaxed.  A resolver SHOULD send a UDP
   query first, but MAY elect to send a TCP query instead if it has good
   reason to expect the response would be truncated if it were sent over
   UDP (with or without EDNS0) or for other operational reasons, [...]

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 19 Jun 2013 14:35:18 +0200

> outside the scope of the _configuration_ of the protocol, no?

A resolver may start with TCP right away. RFC 5966: "A resolver SHOULD send a UDP query first, but MAY elect to send a TCP query instead if it has good reason to expect the response would be truncated if it were sent over UDP ...". If a different port is configured under "udp", it is not clear whether the resolver is supposed to use the same port for TCP as well, or stick to the default 53.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 19 Jun 2013 14:46:33 +0200

or:

    <server>
      <name>foo</name>
      <address>10.0.0.1</address>
      <port>6378</port>                  <-- optional, with default 53.
    </server>

I would prefer this, and the description should state that the address and port is used for both UDP and TCP connections.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 25 Jun 2013 09:56:41 +0200 (CEST)

Hi,

I would like to resolve the issue about DNS transport.

I had a chat with Lars-Johan Liman about this, and he basically
acknowledged what we have said: the protocol architecturally supports
other transports; the default transport is a mix of UDP and TCP.

Here are some alternatives, both data model and XML instance example:

  A. Explicit transport type
  --------------------------

  list server {
    key name;
    ...
    choice transport {
      case udp-and-tcp {
        container udp-and-tcp {
          leaf address { ... }
          leaf port { ... default 53; }
        }
      }
    }
  }

   <server>
     <name>foo</name>
     <udp-and-tcp>
     </udp-and-tcp>
   </server>

  Q: What is a good name for the transport?  "udp-and-tcp" is a bit
     awkward.

  B. Implicit transport type
  --------------------------

  list server {
    key name;
    ...
    choice transport {
      case udp-and-tcp {
        leaf address { ... }
        leaf port { ... default 53; }
      }
    }
  }

   <server>
     <name>foo</name>

  Pro: Straightforward, and still extensible
  Con: Does not follow the same patterns as NTP and RADIUS.

  C. Multiple transports
  ----------------------

  list server {
    key name;
    ...
    container udp {
      leaf address { ... }
      leaf port { ... default 53; }
    }
    container tcp {
      leaf address { ... }
      leaf port { ... default 53; }
    }
  }

   <server>
     <name>foo</name>
     <udp>

  Con: Allows you to configure different IP / Port for the same server
       for different protocols, might be confusing.  Lars-Johan Liman
       recommended against this.

My personal preference is A followed by B.

Please comment!

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 25 Jun 2013 11:24:12 +0200

> other transports; the default transport is a mix of UDP and TCP.

I think RFC 5966 is an interesting relevant read and we likely should
point to it somewhere.

>   A. Explicit transport type

The name says what it is and RFC 5966 provides some explanation under
which circumstances udp and tcp is used. I think this is essential
since the name "udp-and-tcp" at first glance seems to leave it open
which transport is actually used once configured.
 
>   B. Implicit transport type

This variation simply hides the issue well. ;-)

>   C. Multiple transports

Yes, this looks non-obvious or redundant or potentially confusing.
My preference is also A over B.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 25 Jun 2013 14:14:42 +0200

> other transports; the default transport is a mix of UDP and TCP.

Well, the fact that an application protocol can in principle be used over another transport protocol doesn't necessarily mean that a choice of transports makes sense in reality. I asked several DNS experts in my company, including active developers of two DNS servers (BIND 10 and Knot), and none of them is aware of any plans or proposals for running DNS over anything else than the standard UDP/TCP.

In a similar vein, whilst NTP could possibly be run over something else than UDP, it makes little sense in reality because anything else than UDP would most likely increase the transport protocol overhead and hence latency.

So, given the three alternatives, my preference would be B, because it doesn't add an extra level of hierarchy. And I'd suggest to do the same for NTP client configuration.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 25 Jun 2013 06:54:09 -0700

I guess (B) is fine but I wonder why we are future-proofing against
something nobody plans to change. If one followed this logic to the end,
then
every YANG object would need to be in a choice with 1 case, because somebody
in the future might want an alternative to the current solution, but still
wants
to use the same module.

Andy

On Tue, Jun 25, 2013 at 5:14 AM, Ladislav Lhotka <[email-masked]> wrote:

> Well, the fact that an application protocol can in principle be used over
> another transport protocol doesn't necessarily mean that a choice of
> transports makes sense in reality. I asked several DNS experts in my
> company, including active developers of two DNS servers (BIND 10 and Knot),
> and none of them is aware of any plans or proposals for running DNS over
> anything else than the standard UDP/TCP.
>
> In a similar vein, whilst NTP could possibly be run over something else
> than UDP, it makes little sense in reality because anything else than UDP
> would most likely increase the transport protocol overhead and hence
> latency.
>
> So, given the three alternatives, my preference would be B, because it
> doesn't add an extra level of hierarchy. And I'd suggest to do the same for
> NTP client configuration.
>
> Lada
>
> >

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 25 Jun 2013 16:40:04 +0200 (CEST)

> in the future might want an alternative to the current solution, but still

I don't think this is the right conclusion from this logic.  It was
Juergen who pointed out that if the protocol architecturally supports
multiple transports, we should allow this in the data model, even if
there is only one transport currently in use.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 25 Jun 2013 17:16:59 +0200

>> in the future might want an alternative to the current solution, but still

I agree with Andy.

> there is only one transport currently in use.

If I remember correctly, the scope for the initial set of modules was to take into account what the current standards, commonly used devices and service implementations support. Future-proofing against generalisations that are nowhere is sight leads to unnecessary complications that will not make the modules more attractive - just the opposite.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 25 Jun 2013 08:46:52 -0700

On Tue, Jun 25, 2013 at 8:16 AM, Ladislav Lhotka <[email-masked]> wrote:

> If I remember correctly, the scope for the initial set of modules was to
> take into account what the current standards, commonly used devices and
> service implementations support. Future-proofing against generalisations
> that are nowhere is sight leads to unnecessary complications that will not
> make the modules more attractive - just the opposite.
>
>
I don't might solution (B), but it does presume that we know any other
transport added in the future will not use address and/or port (because they
can't if it's in a choice).

YANG also provides must-stmt and when-stmt, so new objects added
in the future can enforce whatever usage of address/port they need.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 25 Jun 2013 18:03:11 +0200

> can't if it's in a choice).

Why not, if they are defined in a different module/namespace?

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 25 Jun 2013 09:21:52 -0700

> Why not, if they are defined in a different module/namespace?
You're right.
I was assuming the reason we need a choice with 1 case is so
more cases can be added directly to this module later, but it
could be indirectly via augment-stmt as well.

Lada
Andy

---

From: "ietfdbh" <[email-masked]>
Date: Tue, 25 Jun 2013 16:01:26 -0400

+1

David Harrington
[email-masked]
+1-603-828-1401

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Martin Bjorklund
Sent: Tuesday, June 25, 2013 10:40 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-system-mgmt-07.txt

Andy Bierman <[email-masked]> wrote:
> something nobody plans to change. If one followed this logic to the 
> end, then every YANG object would need to be in a choice with 1 case, 
> because somebody in the future might want an alternative to the 
> current solution, but still wants to use the same module.

I don't think this is the right conclusion from this logic.  It was Juergen
who pointed out that if the protocol architecturally supports multiple
transports, we should allow this in the data model, even if there is only
one transport currently in use.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 25 Jun 2013 14:06:26 -0700

OK you convinced me this is a special case where choice-of-1 is a good idea.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 26 Jun 2013 13:13:33 +0200

> OK you convinced me this is a special case where choice-of-1 is a good idea.

This was not my intention, I only expressed my preference among the three choices that Martin offerred. I think we should carefully judge where the choice of transport protocol makes sense, and I am not convinced it is the case of DNS resolver and NTP client configuration. Option (B) is a compromise in that it doesn't introduce any extra data nodes, but it is still detrimental to the module readability.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Jun 2013 05:58:56 -0700

On Wed, Jun 26, 2013 at 4:13 AM, Ladislav Lhotka <[email-masked]> wrote:

> This was not my intention, I only expressed my preference among the three
> choices that Martin offerred. I think we should carefully judge where the
> choice of transport protocol makes sense, and I am not convinced it is the
> case of DNS resolver and NTP client configuration. Option (B) is a
> compromise in that it doesn't introduce any extra data nodes, but it is
> still detrimental to the module readability.
>
>
Maybe 'good' is over-stating it -- it is acceptable because the transport
is allowed to change
in the future.  This is the sort of thing you have to do with YANG in the
absence of a robust conformance model.

Lada

Andy

> >> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >> Of
> >> Martin Bjorklund
> Juergen