Subject: LOC record rounding policy

From: Brian Wellington <[email-masked]>
Date: Sun, 27 Jan 2002 13:39:30 -0800 (PST)

The LOC record spec (RFC 1876) says that the latitude and longitude are
specified to thousandths of a second of arc.  It does not say how text
input that specifies additional precision should be handled.  The sample
code in the RFC reads up to three digits following the decimal point in
the seconds field, and ignores all remaining text until the next
whitespace.

Randy Bush mentioned that he thinks rounding to the nearest thousandth of
a second would be a better policy.  I don't really care either way, but
I'm hesitant to change existing code to do rounding if it's not specified
in either the draft's text or sample code.

Does anyone care about this?  If so, is consensus on the list enough?  (A
clarification draft seems like overkill)

Brian

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: [email-masked]
Date: Mon, 28 Jan 2002 10:21:51 +1100

> the seconds field, and ignores all remaining text until the next

	Simple.  It is format error to specify more than thousandths of
	a second.  If you round or truncate it will be wrong for someone.
	Force the decision back to the person entering the data.

	Mark

--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Randy Bush <[email-masked]>
Date: Sun, 27 Jan 2002 15:56:54 -0800

> a second.

so, you contend that in

       s1, s2: [0 .. 59.999]        (seconds latitude/longitude)

59.999 is in fixed point arithmetic with a limited precision.  if
so, it would be best if it said so explicitly.

the normal reader would see it as any real number in the range.
in fact, that is how bind8 implemented it.

randy

---

From: Brian Wellington <[email-masked]>
Date: Sun, 27 Jan 2002 17:24:47 -0800 (PST)

> 	Force the decision back to the person entering the data.

This strongly violates the "be generous with what you accept" principle.
It's specified as being sent on the wire in thousandths of an arc second,
not in text format.  Rejecting something as being too precise seems
absurd.

Brian

---

From: Randy Bush <[email-masked]>
Date: Sun, 27 Jan 2002 17:36:32 -0800

> and yet, silently truncating violates the principal of least astonishment.

i will 'fess up.  i was the instigator of this.  imiho, if you are not going
to terminate with a hard diagnostic, at least round as opposed to truncate.

> i suggest a warning in the operations log be emitted whenever the zone
> file contains something that the wire format can only approximate.

i can live with this too, but please round.  less surprise.

randy

---

From: Paul Vixie <[email-masked]>
Date: Sun, 27 Jan 2002 17:33:30 -0800

i suggest a warning in the operations log be emitted whenever the zone file
contains something that the wire format can only approximate.

---

From: [email-masked]
Date: Mon, 28 Jan 2002 15:17:05 +1100

> i can live with this too, but please round.  less surprise.

	I hate warnings.  They get ignored.  Too many times we have issued
	warnings in the past only to have to turn them into errors because
	they caused operational errors, bug reports etc.  If you know the
	input is in error you should emit a error.

	Randy why knowing that the precision is thousandths of a second
	do you want to continue adding data specified to a precision that
	cannot be handled by the protocol?

	Mark

---

From: Brian Wellington <[email-masked]>
Date: Sun, 27 Jan 2002 23:51:42 -0800 (PST)

> 	cannot be handled by the protocol?

Out of curiosity, how is this different from normal computer floating
point arithmetic?  There's less precision, sure, but it's basically the
same thing.  You wouldn't want scanf() to return an error if you specified
too many decimal places when reading a float, would you?

Brian

---

From: [email-masked]
Date: Tue, 29 Jan 2002 00:29:02 +1100

> too many decimal places when reading a float, would you?

	Floating point introduces errors.  This is fixed point
	arithmetic.  The field is defined to be specified in
	thousandths of a second.

	This in no different to dollars and cents except that it
	would be dollars and millis.  If someone asked you to enter
	the amount in dollars and cents would you start entering it
	in tenths of a cent, hundredths of a cent?

	Mark

---

From: Brian Wellington <[email-masked]>
Date: Mon, 28 Jan 2002 23:50:20 -0800 (PST)

> 	in tenths of a cent, hundredths of a cent?

I wouldn't, but I'd expect the application to handle it sanely if I did.
Sanely doesn't include rejecting it outright.

As an example, try entering "1.111 dollars" into units.  It accepts it.
Try entering a number with more decimal places than are in a double.
units still accepts it, even though the precision is meaningless.

Brian

---

From: Edward Lewis <[email-masked]>
Date: Tue, 29 Jan 2002 08:49:37 -0500

>clarification draft seems like overkill)

If the original draft is incorrect, it (the document) should be fixed.
Remember, the IETF is about interoperability above all else.  A new code
base author should be able to read the documents and generate an
interoperable implementation without resorting to

What ever is decided (regarding rounding), please update the draft and do
not rely on any one implementation as a reference plaftorm, no matter how
well-intentioned the effort is.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Opinions expressed are property of my evil twin, not my employer.

---

From: Robert Elz <[email-masked]>
Date: Mon, 28 Jan 2002 15:55:57 +0700

Date:        Mon, 28 Jan 2002 15:17:05 +1100
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	Randy why knowing that the precision is thousandths of a second
  | 	do you want to continue adding data specified to a precision that
  | 	cannot be handled by the protocol?

Most people don't know.

But I can't begin to think why we're discussing this here, as long as the
correct thing is on the wire (ie: 1000'ths) then how that is input is a
quality of implementation issue - for me, I don't think I'd want to be dealing
in radians (or their fractions) at all, I still prefer degrees, minutes, ...
(including decimals of a second if appropriate).

If an implementation insists on issuing warnings or errors about stupidities,
then I'll fix or replace the implementation.  If an implementation when given
precise input (actually specified to 3 decimal places of radians) doesn't put
exactly that value in the RR when it sends it, then I will fix or replace it.
Anything else (rounding when I give more digits, what it does with 3.1234
seconds, etc) is just frills, and can be dealt with, it just should be
documented.

So Brian, round, truncate, whatever you like ...  This is only an issue for
human edited files, zone files obtained via *XFR or DynDNS will have a
precise value in 1/1000 radian units, which should be preserved and reissued
without change.

kre

---

From: [email-masked]
Date: Thu, 31 Jan 2002 13:14:48 +1100

> (including decimals of a second if appropriate).

	Because master files are defined to be a transport format in
	RFC 103[45].  They should be able to be read by all
	implementations.

	It is bad thing if the same input does not produce the same
	results on all servers.

> precise value in 1/1000 radian units, which should be preserved and reissued

	If one implementation rounds and one truncates then there is a
	50% probability that a LOC record signed zone (assuming the LOC
	passes through unchanged) will cause verification failures when
	loaded on the other implementation.

	Ftp, scp etc. are still used to get zones onto master servers.

	Mark

---

From: "Al Costanzo" <[email-masked]>
Date: Tue, 29 Jan 2002 21:41:07 -0500

Is this discussion a good example of why the draft I wrote on GPOS should be turned into an RFC?  Plain and simple addresses, no precision, no rounding.

Regards,

Al Costanzo

--------------------------------------------------------------------------------
 Promote Your Website with the Pros -- Dynamic Submission 2000 
Best Internet Services: 
Domain Registration -  Web Hosting - DialUp - FrameRelay - T1 -DSL 

 AKC Computer Service Corporation SINCE 1989

  ----- Original Message ----- 
  From: Robert Elz 
  To: [email-masked] 
  Cc: [email-masked] 
  Sent: Monday, January 28, 2002 3:55 AM
  Subject: Re: LOC record rounding policy 

  Most people don't know.

  kre

---

From: Chris Thompson <[email-masked]>
Date: Thu, 31 Jan 2002 02:42:36 +0000 (GMT)

[email-masked] (Robert Elz) writes
[...]
> 
> But I can't begin to think why we're discussing this here, 

I sort of assumed that 1 April had come early this year.

>                                                            as long as the

No-one (and that includes RFC 1876) has even mentioned radians! 

> precise value in 1/1000 radian units, which should be preserved and reissued

Well striking out all that nonsense about radians, there is indeed just
one and only one important point: the conversion from on-the-wire format
to master-file format and back must be idempotent.

Please bear in mind that 0.001" on the surface of the earth is about 3.1 cm
(1.2 in). [0.001" of longtitude may be less, of course, depending on latitude.]
Someone might indeed feed in more significant digits as a result of some
sort of automation, but no-one is going to be devastated by losing them,
whatever the rounding/truncation algorithm used. ["Fred, help me move this
rack one inch to the north-east: we've got to do it to make the LOC record
right."]

Chris Thompson
Email: [email-masked]

---

From: Randy Bush <[email-masked]>
Date: Wed, 30 Jan 2002 18:55:04 -0800

> quality of implementation issue - for me,

it is a quirk of history that the format of the zone files is a matter
of ietf standard.  blame rob, pvm, ...

randy

---

From: Derek Atkins <[email-masked]>
Date: 30 Jan 2002 22:19:20 -0500

> precise value in 1/1000 radian units, which should be preserved and reissued

Um, not quite.  If you plan to sign the data you need to make sure
that what goes into your signature algorithm == what is transmitted
on the wire, otherwise the signature will fail on the receiving end.

> kre

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Robert Elz <[email-masked]>
Date: Thu, 31 Jan 2002 10:48:16 +0700

Date:        Thu, 31 Jan 2002 13:14:48 +1100
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	Because master files are defined to be a transport format in
  | 	RFC 103[45].  They should be able to be read by all
  | 	implementations.

And this is how $GENERATE and $TTL and other useful stuff like
that appeared, right?

Master files as a transfer format was always a silly idea (even if it proved
useful to help around implementation bugs for  long time).   These days less
and less people actually use master files in human editable form.

  | 	It is bad thing if the same input does not produce the same
  | 	results on all servers.

Yes, it is, but it isn't fatal - and it only matters if someone
actually gives excess precision (so if you give just the amount that
is defined, you should get the same result everywhere - if you give more
then you can get (slightly) undefined results - big deal).

  | 	If one implementation rounds and one truncates then there is a
  | 	50% probability that a LOC record signed zone (assuming the LOC
  | 	passes through unchanged) will cause verification failures when
  | 	loaded on the other implementation.

We're signing the text format of the records now?   Since when?   As long
as the records are signed in their internal form (which is the only thing
that makes sense) then if it is correctly signed on the implementation that
loads the zone, it will verify correctly everywhere.   If you sign using one
implementation and then load that into something that reads the data in a
different manner, and you have taken advantage of the differences, then yes
of course you lose.

  | 	Ftp, scp etc. are still used to get zones onto master servers.

Yes, as are SQL servers, and all kinds of other things.

kre

---

From: [email-masked]
Date: Thu, 31 Jan 2002 15:00:30 +1100

> And this is how $GENERATE and $TTL and other useful stuff like

	$GENERATE is clearly documented as being a extention.

	LOC is standardised.
	$TTL is standardised.

> We're signing the text format of the records now?

	No.

	Nothing in DNSSEC says that you have to write out the entire
	zone contents.  A signer could just as easily just generate
	the SIG and NXT records and append them to the master file,
	create a seperate file with just the SIG and NXT records
	that could then be $INCLUDED.  Either of these perfectly
	reasonable behaviours would preserve the textual form of
	the LOC record but would result in invalid signatures.

>   Since when?   As long

	So now I can't sign my zone using whatever DNSSEC implementation
	ship it to my ISP who happens use something else and have it work.
	
> Yes, as are SQL servers, and all kinds of other things.

	SQL servers arn't part of the standard.  Transmitting in
	master file format is.

	Mark

---

From: "D. J. Bernstein" <[email-masked]>
Date: 31 Jan 2002 04:19:37 -0000

> 	RFC 103[45].  They should be able to be read by all

Hypocrite. Your format extensions ($GENERATE, new record types, etc.)
allowed master files that were _not_ readable to other implementations,
even your own previous implementations. People who replicated zone files
through FTP had to avoid the extensions or use the same software on both
sides.

---Dan

---

From: Paul Vixie <[email-masked]>
Date: Wed, 30 Jan 2002 20:46:06 -0800

> on the wire, otherwise the signature will fail on the receiving end.

conceptually, what's being signed is "whatever would go out in an AXFR".

some known DNS implementations do not parse "zone file format" at all,
preferring to take all of their zone data in the form of RFC2136 dynamic
updates.

i agree with randy (second time this year): standardizing zone file 
format was always silly, and gets sillier every year.

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>