Found 1 record.
Status: Verified (1)
RFC 6742, "DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)", November 2012Source of RFC: IRTF
Errata ID: 3413
Publication Format(s) : TEXT
Reported By: Miek Gieben
Date Reported: 2012-11-18
Verifier Name: Lars Eggert
Date Verified: 2012-12-10
Section 2.2.3. says:
host1.example.com. IN L32 10 10.1.02.0 host1.example.com. IN L32 20 10.1.04.0 host2.example.com. IN L32 10 10.1.08.0
It should say:
host1.example.com. IN L32 10 10.1.2.0 host1.example.com. IN L32 20 10.1.4.0 host2.example.com. IN L32 10 10.1.8.0
"As L32 values have the same syntax and semantics as IPv4 routing
prefixes, when displayed for human readership, the values are
presented in the same dotted-decimal format as IPv4 addresses. An
example of this syntax is shown above."
If this is the case I don't get the prefixed 0. Is it octal? Which clashes with the description, or is there some hidden meaning for using an extra 0.
The other example in 2.2.3 also uses these ip4 addresses.
From the authors:
It was not the intention of the authors to include the
additional zero prefix in the third byte of the IP address.
Although the published text was not identical to the authors'
intent, we believe that the numerical values presented in the
examples are still correct. However, the use of the zero in
this way is not conventional.
It is worth nothing that RFC-990, page 5, for example,
explicitly says the IP address of the string "010.003.000.052"
is equal to the IP address of the string "10.3.0.52". The BNF
and specifications of RFC-1034 and RFC-1035 does not contradict
that, as far as we can tell.
We do note that inet_aton(3)/inet_ntoa(3) (and associated API)
of the C programming language *does* use a leading zero to flag
an octal number. This is also likely to be true for some other
languages, e.g. python's inet_aton() API. However, this use of
a leading zero to indicate octal is not always true. For example,
the Java language InetAddress object API ignores the leading zero
and treats the number as decimal.
So, at the very least, the example in its present form could cause
confusion, while the suggested correction would leave the example
as being clear and unambiguous.
The authors are grateful to Miek Gieben for spotting the ambiguity
and suggesting a correction.