Subject: [netmod] WG LC review of draft-ietf-netmod-system-mgmt-08.txt

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Fri, 09 Aug 2013 16:27:24 +0200

I did read and review document draft-ietf-netmod-system-mgmt-08.txt

- With regard to the use of MD5, I wonder if the security
   considerations section should discuss and point to RFC6151
   titled: "Updated Security Considerations for the MD5
            Message-Digest and the HMAC-MD5 Algorithms"

- I see
            leaf name {
              type string;
              description
                "An arbitrary name for the DNS server.";
            }
            choice transport {
              mandatory true;
              description
                "The transport protocol specific parameters for this
                 server.";

              case udp-and-tcp {
                container udp-and-tcp {
                  description
                    "Contains UDP and TCP specific configuration
                     parameters for DNS.";
                  reference
                    "RFC 1035: Domain Implementation and Specification
                     RFC 5966: DNS over TCP";

                  leaf address {
                    type inet:ip-address;
                    mandatory true;
                    description
                      "The address of the DNS server.";
                  }
                  leaf port {
                    if-feature dns-udp-tcp-port;
                    type inet:port-number;
                    default 53;
                    description
                      "The UDP and TCP port number of the DNS server.";
                  }
                }

    So it seems we are FORCING the tcp and udp port to be the same.
    I know that in reality this is often (always?) the case. But if you
    make it configurable, does it ALWAYS have to be the same port?

    I can live with it. Just wondering.

- I see:
        container clock {
          description
            "Monitoring of the system
             date and time properties.";

          leaf current-datetime {
            type yang:date-and-time;
            config false;
            description
              "The current system date and time.";
          }
          leaf boot-datetime {
            type yang:date-and-time;
            config false;
            description
              "The system date and time when the system last restarted.";
          }
        }

      }

    why not make the container a "config: false" ???
    I think nothing underneath this container will ever be config: true
    will it?

- But maybe, since I see:
     container system-state {
        config false;
        description
          "System group operational state.";

        container platform {
          config false;
          description
            "Contains vendor-specific information for
             identifying the system platform and operating system.";
          reference
            "IEEE Std 1003.1-2008 - sys/utsname.h";

          leaf os-name {
            type string;
            description

        .....

        container clock {
          description
            "Monitoring of the system
             date and time properties.";

          leaf current-datetime {
            type yang:date-and-time;
            config false;
            description
              "The current system date and time.";
          }
          leaf boot-datetime {
            type yang:date-and-time;
            config false;
            description
              "The system date and time when the system last restarted.";
          }
        }

      }

   container clock is underneath container system-state and so
   the leafs current-datetime and boot-datetime are already config:false
   by inheriting from container system-state.
   Same for container platform I guess?

Other than that, this document seems ready for publication as a stds track RFC.

Bert

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Mon, 12 Aug 2013 22:05:25 +0200

I did read and review document draft-ietf-netmod-iana-if-type-07.txt

This document seems ready for publication as a stds track RFC.

Bert

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Mon, 12 Aug 2013 23:05:52 +0200

I believe that this document is ready for publication as a stds track RFC.

Bert

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 13 Aug 2013 08:42:01 +0200 (CEST)

Hi,

>            Message-Digest and the HMAC-MD5 Algorithms"

I don't know.  Should it?

>    So it seems we are FORCING the tcp and udp port to be the same.

Yes.  I had an (off-line) discussion with Lars-Johan Liman and he
suggested that a single port would be enough (and even good).  Does
anyone know any resolver implementations that support configuration of
different ports?  (It seems that most implementations even hardcode
port 53...).

>    I think nothing underneath this container will ever be config: true

Correct.  Actually, since the container 'system-state' is config
false, we don't need these other config false statements.  They are
left-overs from previous versions.

/martin

---

From: David Harrington <[email-masked]>
Date: Tue, 13 Aug 2013 09:20:50 +0200

>suggested that a single port would be enough (and even good).

Good as an implementer engineering choice, or good as a standards
requirement?

>Does

I have a concern that forcing the tcp and udp port to be the same could
cause you DISCUSSES when this goes through IESG.

I suggest asking for a dnsdir review; I think that falls under INT ADs.
You might also ask for tsvdir review; ask Martin and Spencer to initiate
this.

One hurdle you may have to get over is Joe Touch, the port assignment
expert used by IANA during IANA review.
He sometimes raises points of contention that are not supported by the
ADs, but can really tie up the process.
Getting the ADs involved early can help prevent that.

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

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 13 Aug 2013 09:21:12 +0200

Inline

On 8/13/13 8:42 AM, Martin Bjorklund wrote:
> "Bert Wijnen (IETF)"<[email-masked]>  wrote:

Well, that document states that MD5 should not be used anymore, does it not?
So a warning (in my view) makes sense.

Not that I will loose sleep over it if we do not do that.
Could ask Sec ADs as to what they think.
Or just see if they bring it up in IESG review.

Bert

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 13 Aug 2013 09:57:56 +0200

On Aug 13, 2013, at 8:42 AM, Martin Bjorklund <[email-masked]> wrote:

> port 53…).

RFC 1035:

    Messages sent using UDP [use] server port 53 (decimal).

    Messages sent over TCP connections use server port 53 (decimal).

As I wrote earlier, the chance that a stub resolver (which is our case here) will ever uses any other transport protocol is also very slim. So this part of the module is IMO way too complicated - server address and optional port should be more than enough.

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: Tue, 13 Aug 2013 12:42:34 +0200

> cause you DISCUSSES when this goes through IESG.

My understanding is that if DNS signals an upgrade to a 'virtual
circuit' (yeah those were the times) through a truncated message, it
does not carry any further information so the only best guess a client
can make is to use the same port number over TCP.

/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: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 13 Aug 2013 12:45:20 +0200

> Or just see if they bring it up in IESG review.

It won't hurt but since we are modeling how a system stores password
hashes, the real-world impact will also be small - an implementor of
the system management data model is likely having little influence
over the policies used to store password hashes. But then, constant
repetition is sometimes the key to learning - so it won't hurt.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 13 Aug 2013 13:01:35 +0200

> cause you DISCUSSES when this goes through IESG.

I am pretty sure that a simple list of DNS server addresses (perhaps with optional port) will not cause any DISCUSSes, because this is (AFAIK) the maximum of what current implementations of stub resolvers allow. It is the purportedly sophisticated choice of the transport protocol for DNS that may raise eyebrows of reviewers.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 13 Aug 2013 13:14:09 +0200

> I am pretty sure that a simple list of DNS server addresses (perhaps with optional port) will not cause any DISCUSSes, because this is (AFAIK) the maximum of what current implementations of stub re…

Speculating about IESG DISCUSSES is IMHO a mood activity. Yes, there
are zero-cost provisions to be able to support other transports and I
think this is architecturally the right thing to do. We follow a
common architectural pattern for all the transports in this module and
I believe this is goodness.

Lets face it, people will take these modules as templates and I think
we will be better off providing proper templates. And as I said, the
cost of the extra XML element is zero.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 13 Aug 2013 14:49:01 +0200

> I believe this is goodness.

I don't agree, it goes against the Occam's Razor principle. A choice of transport protocols should be available only where the service or protocol spec supports it, or where there are at least indications that it may be so in the future.

Apart from DNS, I believe NTP is another example where it does NOT make sense, because anything else than UDP would increase latency. RFC 5905: "The NTP packet is a UDP datagram". Full stop.

> cost of the extra XML element is zero.

The significant cost is not in an extra XML element but rather in decreased readability of the data model, without any apparent gain.

Lada