Subject: Re: [netmod] [appsdir] Fwd: APPSDIR review of draft-ietf-netmod-rfc6021-bis-01

From: Martin Thomson <[email-masked]>
Date: Tue, 30 Apr 2013 12:29:02 -0700

One meta-comment.  I don't consider the contents of RFC 6021 to have
any bearing on the review of this document.  I'm not familiar with
6021, so I consider all of this to be new.

On 30 April 2013 01:32, Juergen Schoenwaelder
<[email-masked]> wrote:
>> There is an RFC that describes a canonical textual representation of
>> IPv6 addresses.  You should use that: RFC 5952.
>
> The typedef ipv6-address has a reference to RFC 5952. I believe the
> text in the description statement is inline with RFC 5952. Note that
> this text did not change since RFC 6021 (and other than clarifications
> we likely do not want changes).

That's unfortunate because I can't tell whether RFC 5952 and the
following are the same very easily:

   "The canonical format of IPv6 addresses uses the compressed
         format described in RFC 4291, Section 2.2, item 2 with the
         following additional rules: the :: substitution must be
         applied to the longest sequence of all-zero 16-bit chunks
         in an IPv6 address.  If there is a tie, the first sequence
         of all-zero 16-bit chunks is replaced by ::.  Single
         all-zero 16-bit chunks are not compressed.  The canonical
         format uses lowercase characters and leading zeros are
         not allowed.  The canonical format for the zone index is
         the numerical format as described in RFC 4007, Section
         11.2."

Suggest:
   "The canonical format of IPv6 addresses is described in RFC5952;
the canonical form of the zone index is described in RFC 4007, Section
11.2."

Adding something to references is not the same as providing normative
text that stipulates how the information is intended to be consumed.
If the intent is to have the reference as normative, informative
references are fine as disassociated links.

>> domain-name doesn't mention RFC 5890 at all (5891 is cited, but not
>> used in the text).  I assume that these are LDH-labels:
>> http://tools.ietf.org/html/rfc5890#section-2.3.1 and that this
>> document should say as much.
>
> I am not sure what you think is unclear. Note that the definition of
> the typedef domain-name is unchanged from the one in RFC 6021. Perhaps
> you can make a concrete text change proposal so I better understand
> what your concern is.

The pattern for domain-name implies LDH label, however the textual
description does not.

OLD:
Internet domain names are only loosely specified.  Section
         3.5 of RFC 1034 recommends a syntax (modified in Section
         2.1 of RFC 1123).  The pattern above is intended to allow
         for current practice in domain name use, and some possible
         future expansion.  It is designed to hold various types of
         domain names, including names used for A or AAAA records
         (host names) and other records, such as SRV records.  Note
         that Internet host names have a stricter syntax (described
         in RFC 952) than the DNS recommendations in RFCs 1034 and
         1123, and that systems that want to store host names in
         schema nodes using the domain-name type are recommended to
         adhere to this stricter standard to ensure interoperability.
NEW:
  "A domain-name MUST consist of LDH-labels as defined in RFC 5890.

  Note: If fields of this type are used to store host names [RFC0952],
host names use a stricter syntax.  Systems that store host names
SHOULD enforce stronger restrictions or use a derived type for host
names."

>> phys-address: why is this optionally empty?  Maybe explain why in the
>> document - value absent?
>
> The primary reason is to be consistent with the PhysAddress textual
> convention of RFC 2579. Note that this definition did not change since
> RFC 6021. What an empty address means needs to be defined where the
> type is used. I do not think we can regulate that in the type
> definition itself. All we could do is add a 'warning' that this type
> allows zero-length strings as values and hence users of this type
> either need to subtype this type or explain the semantics of a
> zero-length string.

Yes, either would be nice, but I'm not that concerned about these.  I
prefer to see such surprises explained in some way.  e.g.,
"phys-address permits an empty string to so that the textual
convention established in RFC 2579 can be used.  An empty string has
no defined semantics here, subtypes SHOULD either assign semantics to
this value or eliminate it."

>> hex-string: why is this required to include at least one octet? The
>> text does not mention this at all, I tend to find lots of uses for
>> empty octet strings, so this seems odd.
>
> I will take this to the WG. Note that in YANG you often use choices to
> model situations where in other frameworks you give special meanings
> to say zero-length strings.

> ipv6 pattern
> Note sure what the "official" ABNF definition is but we believe that
> the two pattern are correct. So far nobody was able to find a case
> that was not properly accepted by the pattern. You are welcome to try
> to find something where our two pattern break. ;-)

Sorry, "official" is my shorthand for saying: there is an RFC out
there that defines this ABNF but I was too lazy to go and look for it
because I know that chances are I will find the wrong one.

The first pattern is overly restrictive, I think (only double colon at
the start?).  The second is definitely overly permissive.
This:sentence:is::actually:valid.  (I think).

> /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: Thu, 2 May 2013 09:41:57 +0200

> 6021, so I consider all of this to be new.

But most of the definitions are not new and I am reluctant to make
changes to published RFC text.

[...]

> This:sentence:is::actually:valid.  (I think).

Please give me an example of an IPv6 address that the ipv6-address
pattern does not handle so we have something concrete to talk about. I
am appending some test cases to make it easier for you to find one.

If you mean by "second" the ipv6-address-no-zone typedef, please see
my response to Joel. This is a type derived from ipv6-address.

/js

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 May 2013 13:28:46 -0700

> changes to published RFC text.

I thought that was the purpose of revising an RFC.  If you were just
looking to add types, an update might be more appropriate.

> my response to Joel. This is a type derived from ipv6-address.

Ahh, both patterns apply.  My mistake; I had assumed OR (like XML
schema), not AND.  Interesting approach.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 3 May 2013 10:16:08 +0200

> looking to add types, an update might be more appropriate.

The new types go into existing YANG module and this requires to
republish the whole module. This is what we have been doing >20 years
for MIB modules - so there is experience with this.
 
> schema), not AND.  Interesting approach.

In XML schema, you have both:

   If multiple <pattern> element information items appear as
   [children] of a <simpleType>, the [value]s should be combined as if
   they appeared in a single ·regular expression· as separate
   ·branch·es.  Note: It is a consequence of the schema representation
   constraint Multiple patterns (§4.3.4.3) and of the rules for
   ·restriction· that ·pattern· facets specified on the same step in a
   type derivation are ORed together, while ·pattern· facets specified
   on different steps of a type derivation are ANDed together.

I believe YANG is actually following XML schema here.

/js

---

From: S Moonesamy <[email-masked]>
Date: Wed, 08 May 2013 10:03:43 -0700

>you can make a concrete text change proposal so I better understand

I read draft-ietf-netmod-rfc6021-bis-02.  In Section 4:

   "The domain-name type represents a DNS domain name.  The
    name SHOULD be fully qualified whenever possible."

That sounds like a MAY.

The text in RFC 6021 and the draft is clear.  I don't think that the 
fact that DNS-related text is already in RFC 6021 means that it is correct.

   "Internationalized domain names MUST be encoded in punycode as described
    in RFC 3492";

RFC 5891 discusses about IDNA-aware implementations.  It also 
discusses about A-labels and U-labels.  The above text jumps directly 
to punycode.

Regards,
S. Moonesamy

---

From: Randy Bush <[email-masked]>
Date: Wed, 08 May 2013 21:53:01 +0200

>     name SHOULD be fully qualified whenever possible."

MAY != SHOULD

---

From: S Moonesamy <[email-masked]>
Date: Wed, 08 May 2013 13:44:44 -0700

>MAY != SHOULD

The text is as follows: "The name SHOULD be fully qualified whenever 
possible".  If the working group would like a RFC 2119 SHOULD it 
would help if there is an explanation in the sentence for the reader 
weigh the implications of not following that.

For what it is worth Eric Burger posted an analysis of "SHOULD" usage 
in a different draft ( 
http://www.ietf.org/mail-archive/web/mile/current/msg01021.html ).

Regards,
S. Moonesamy

---

From: Joe Abley <[email-masked]>
Date: Wed, 8 May 2013 17:55:49 -0400

On 2013-05-08, at 17:30, S Moonesamy <[email-masked]> wrote:

> The text is as follows: "The name SHOULD be fully qualified whenever possible".  If the working group would like a RFC 2119 SHOULD it would help if there is an explanation in the sentence for the reader weigh the implications of not following that.

My knee-jerk reaction is to use MUST. Partially-qualified domain names
are ambiguous at best.

Similarly, "wherever possible" is unhelpful; if it's not possible to
fully-qualify a domain name then ambiguity is guaranteed.

Joe

---

From: [email-masked] (Martin Rex)
Date: Thu, 9 May 2013 08:31:01 +0200 (CEST)

>     name SHOULD be fully qualified whenever possible."

That is a MAY.  That probably needs to be a may.

How do you recognize a "fully qualified" name anyway?

Today a huge number of machines simply does not have a
"fully qualified domain name" (and uses private address space).

My DSL router (a brand that is pretty common in Germany)
does _not_ provide a domain name via DHCP and will resolve
plain hostnames for all addresses that it hands out via DHCP.
And a lot of stuff that you attach to home networks comes
with a Web-UI (my DVB-S Set-Top Box, my HomeNAS, my DSL-router
(although the latter recognizes "fritz.box" as a name for itself).

-Martin

---

From: Jonathan Hansford <[email-masked]>
Date: Fri, 10 May 2013 09:52:47 +0100

On 2013-05-09 07:31, [email-masked] wrote:

>>> the typedef domain-name is unchanged from the one in RFC 6021.
>>> Perhaps you can make a concrete text change proposal so I better
>>> understand what your concern is.
>> I read draft-ietf-netmod-rfc6021-bis-02. In Section 4: "The
>> domain-name type represents a DNS domain name. The name SHOULD be 
>> fully
>> qualified whenever possible." That sounds like a MAY.
>

RFC 1033 states:

    A domain name is a sequence of labels separated by dots.

    Domain names in the zone files can be one of two types, either
    absolute or relative.  An absolute name is the fully qualified 
domain
    name and is terminated with a period.

You recognise an FQDN by the terminating period.

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 11 May 2013 12:51:34 +0200

>    name SHOULD be fully qualified whenever possible."

When RFC 6021 was published, the WGs concensus was SHOULD as defined
in RFC 2119:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.
 
> fact that DNS-related text is already in RFC 6021 means that it is

Sure, RFCs can be buggy. But then it needs to be clear what the bug is
- so far that is not clear to me and hence I am reluctant to make any
changes.

> discusses about A-labels and U-labels.  The above text jumps
> directly to punycode.

Please help the WG understand what is wrong with the current text (in
the sense that it affects interoperable implementations). Perhaps you
can tell the WG also what you think the proper fix would look like.

/js