Subject: [netmod] rfc6991bis: inet:host

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 17 Jul 2020 21:17:17 +0200

- Lada suggested to replace the inet:domain-name usage in
    the union with a new host-name definition that follows
    the NR-LDH definition in RFC 5890.

  - Unclear which problem is fixed and how this works from a
    backwards compatibility perspective.

  - See the thread '6991bis: host' in your private list archive
    (I can't find it in the IETF archive)

  - I can't tell for sure that Lada's proposal is (i) correct and (ii)
    not breaking anything

  - Proposal: ?
    
-- 
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: tom petch <[email-masked]>
Date: Mon, 20 Jul 2020 08:53:45 +0000

From: netmod <[email-masked]> on behalf of Juergen Schoenwaelder <[email-masked]>
Sent: 17 July 2020 20:17

<tp>
host and domain are two separate concepts with different semantics and different syntax, something that those not familiar with the RFC often confuse (but which most text books get right) so I have no problem with having host and domain but am not a fan of changing the existing definition.

Tom Petch

  - Proposal: ?

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 Jul 2020 11:04:55 +0200

>   - I can't tell for sure that Lada's proposal is (i) correct and (ii)

Maybe it is better to basically keep the existing inet:domain name for use e.g. in host names that appear in all kinds of non-DNS configuration, and leave the definition of a domain name type appropriate for use in DNS zone data etc. to DNSOP WG.

So my proposal is to only modify the description accordingly, and in particular remove the comment about the use in A/AAAA/SRV resource records, because the existing type isn't really suitable for this purpose.

Lada

-- 
Ladislav Lhotka 
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 Jul 2020 21:44:34 +0200

> So my proposal is to only modify the description accordingly, and in particular remove the comment about the use in A/AAAA/SRV resource records, because the existing type isn't really suitable for…

Can you please send OLD NEW text? I do not really see what needs
changes. Note that this type definition gets tweaked everytime by IESG
members as well.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 22 Jul 2020 08:59:45 +0200

> changes. Note that this type definition gets tweaked everytime by IESG

We actually agreed on NEW already here:

https://mailarchive.ietf.org/arch/msg/netmod/FYMAQSJQsPiPSkWTs4lOWIgM2bI/

Lada

---

From: tom petch <[email-masked]>
Date: Wed, 22 Jul 2020 09:54:00 +0000

Sent: 21 July 2020 20:44

> >     (I can't find it in the IETF archive)

Try the NETMOD WG list archive 21 July 2019

Tom Petch

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 22 Jul 2020 13:00:30 +0200

Tom,

my understanding is that Lada is now proposing something slightly
different but I am not sure what exactly, hence I asked again.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 22 Jul 2020 13:46:38 +0200

> different but I am not sure what exactly, hence I asked again.

Oh yes, I messed it up by mixing different things together, sorry. I
checked again the ML archive, and the message that is relevant to this
thread is this:

https://mailarchive.ietf.org/arch/msg/netmod/PISOifrtow4oWLGW7meBBSri7nM/

The aim of that proposal was to limit the "inet:host" type to DNS names
that are reasonable as host names, i.e. eliminate values like "." or "_".

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 24 Jul 2020 10:36:17 +0200

> that are reasonable as host names, i.e. eliminate values like "." or "_".

You are proposing to change the length restriction from 1..253 to
2..253 following RFC 952:

   [...] Single character names
   or nicknames are not allowed.

And you add

        pattern '(.*\.)?..\-\-.*' {
          modifier invert-match;
        }

to restrict things to non-reserved letter-digit-hyphen labels as per
RFC 5890. Is it clear that this second restriction applies to host
names? How do you represent internationalized host names? Perhaps we
need a collection of examples? And is the pattern correct? RFC 5890
says:

   Reserved LDH labels, known as "tagged domain names" in some other
   contexts, have the property that they contain "--" in the third and
   fourth characters but which otherwise conform to LDH label rules.

What is the '(.*\.)?' part doing in your pattern?

Finally, would it be useful to derive a host-name type from the
domain-name type (if host-names are really a strict subset of what
domain-name allows), e.g.:

  typedef host-name {
    type domain-name {
      pattern '(.*\.)?..\-\-.*' {
        modifier invert-match;
      }
      length "2..max";
    }
    description
      "Host names  must be at least two characters long (see RFC 952)
       and they are restricted to non-reserved letter-digit-hyphen
       (NR-LDH) labels (see RFC ????).";
    reference
      "RFC  952: DoD Internet Host Table Specification
       RFC ????: ????";
  }

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 24 Jul 2020 10:43:38 +0200

> What is the '(.*\.)?' part doing in your pattern?

OK, I figured it out, the NR-LDH label and be in anywhere in the
sequence of labels.
 
/js

---

From: Erik Auerswald <[email-masked]>
Date: Fri, 24 Jul 2020 12:14:17 +0200

Hi,

>    or nicknames are not allowed.

What about single character host names currently used, e.g.,
a.root-servers.net.?

There are single character subdomain labels in use as well, e.g., l.de..

Best regards,
Erik

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 24 Jul 2020 13:09:21 +0200

> There are single character subdomain labels in use as well, e.g., l.de..

The description of 'host name' in RFC 8499 explains that host names
are considerd to be domain names but in some contexts a host name is
considered to be just the first label of a domain name. In our
context, however, it is pretty clear that we consider a host name to
be a domain name. Hence, what Lada suggests is to formally disallow
names like 'a.' while 'a.root-servers.net.' would not be affected.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 26 Jul 2020 15:11:15 +0200

> domain-name allows), e.g.:

The current definition of "inet:domain-name" in 6991bis also permits the underscore character in labels, so it is not LDH.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 26 Jul 2020 22:24:27 +0200

So would the following do the right thing?

    typedef host-name {
      type domain-name {
	pattern	'[a-zA-Z0-9\-\.]+';
        length "2..max";
      }
      description
        "Host names must be at least two characters long (see RFC 952)
         and they are restricted to labels consisting of letters, digits
       	 and hyphens separated by dots (see RFC1123 and RFC 952).";
      reference
        "RFC  952: DoD Internet Host Table Specification
	"RFC 1123: Requirements for Internet Hosts: Application and Support";
    }

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 27 Jul 2020 10:51:31 +0200

> 	"RFC 1123: Requirements for Internet Hosts: Application and Support";

I am also not convinced that deriving host-name from domain-name is a good thing to do. Apart from being somewhat complicated, this coupling can also cause problems, e.g. if domain-name was to be obsoleted in the future.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 27 Jul 2020 12:44:12 +0200

> The invert-match pattern also needs to be added in order to avoid reserved labels:

Why are they illegal? If we make them illegal, how are we going to
deal with hosts that have non-ASCII names?

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 27 Jul 2020 15:18:25 +0200

> deal with hosts that have non-ASCII names?

I am not able to find in what sense the "Reserved LDH" labels of RFC
5890 are really reserved, and I am not sure about the implications of
permitting "xn--..." hostnames to be explicitly configured.

If we want to allow non-ASCII names, then it would IMO be safer to use a
type that expects straight Unicode for lexical representation and leave
it to the implementations to convert to Punycode where necessary, e.g.
when querying DNS.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 28 Jul 2020 17:10:33 +0200

> permitting "xn--..." hostnames to be explicitly configured.

Right now, inet:domain-name as defined in RFC 6991 says:

      [...]
      Domain-name values use the US-ASCII encoding.  Their canonical
      format uses lowercase US-ASCII characters.  Internationalized
      domain names MUST be A-labels as per RFC 5890.";

Hence, if you want to configure a non-ASCII hostname using inet:host,
you have to write it in a sequence of A-labels, i.e., using the ASCII
Compatible Encoding (ACE). Hence, removing xn-- names seems to have a
significant potential to break things.
 
> it to the implementations to convert to Punycode where necessary, e.g.

Perhaps. But I am not sure this is the time to fix this or how this
can be done in a backwards compatible way. At least this likely can't
be done by disallowing ACE. It may be possible to add an additional
member to the inet:host union that catches internationalized names.
Since this would be enlarging the value space, I believe this is
inline with the spirit of section 11 of RFC 7950. Removing the ACE
names, however, restricts the value space and hence seem to contradict
section 11 of RFC 7950. (The explicit removal of underscore and single
letter hostnames may be considered a clarification since we have other
RFCs stating these constraints.)

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 29 Jul 2020 13:55:38 +0200

> significant potential to break things.

OK.

> member to the inet:host union that catches internationalized names.

I think it would be better to have an extra set of parallel definitions such as idn-domain-name, or perhaps u-domain-name.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 30 Jul 2020 15:44:04 +0200

> I think it would be better to have an extra set of parallel definitions such as idn-domain-name, or perhaps u-domain-name.

So if we define idn-domain-name, what do we do with your hostname?
Have hostname derived from domain-name (as discussed before) with

     typedef host {
       type union {
         type inet:ip-address;
         type inet:host-name;
     }

and we add

     typedef idn-host {
       type union {
         type inet:ip-address;
         type inet:idn-hostname;
     }

and then YANG module writers can opt-in to use the new definition if
they want idn host names without requiring ACE encoding?

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 30 Jul 2020 16:02:57 +0200

> they want idn host names without requiring ACE encoding?

Yes, that was my idea. If IDN becomes widespread (ever), the "idn-host"
version would be much easier to use.

Lada