Subject: [dnsop] WGLC on draft-ietf-dnsop-respsize-00.txt

From: Rob Austein <[email-masked]>
Date: Fri, 21 Nov 2003 12:25:57 -0500

This is a working group last call on the DNS response size issues
document, draft-ietf-dnsop-respsize-00.txt, which we hope to submit to
the IESG for publication.

The WG has not expressed an clear opinion on whether this should be a
BCP or an Informational document, and the chairs could make a case
either way, so the WG needs to decide on this point as well.

This last call will terminate at 17:00 UTC on 5 December 2003.

Please clearly state to the mailing list whether you support or oppose
this draft going to the IESG; if you support the draft going to the
IESG, please state whether you believe that it should be a BCP or an
Informational document.

Please do not express an opinion if you have not read the draft.

As always, please discuss substantive issues on the WG mailing list.
Minor editorial comments may be sent directly to the draft authors
(please CC the WG chairs on any such comments so that we can track
this).

Thanks,

Rob & Dave
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Michael Richardson <[email-masked]>
Date: Fri, 21 Nov 2003 15:23:25 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Rob" == Rob Austein <[email-masked]> writes:
    Rob> This is a working group last call on the DNS response size issues
    Rob> document, draft-ietf-dnsop-respsize-00.txt, which we hope to submit to
    Rob> the IESG for publication.

  I have just read it.
  Very short and sweet.

    Rob> The WG has not expressed an clear opinion on whether this should be a
    Rob> BCP or an Informational document, and the chairs could make a case
    Rob> either way, so the WG needs to decide on this point as well.

  If I understood the document, it is recommending that TLD use a common
prefix name for NS records if they want to put as many records as possible
in. (It didn't occur to me why we have 13 root name servers. Now I know)
  The document wasn't that explicit in saying this.

  So, if this is to be meaningful, it should be a BCP.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: bill <[email-masked]>
Date: Fri, 21 Nov 2003 16:48:21 -0800 (PST)

resp-size  finally documents work started six years ago.
I think that it should be published, preferably as informational

--bill
.

---

From: Måns Nilsson <[email-masked]>
Date: Sun, 23 Nov 2003 14:56:04 +0100

> the IESG for publication.

This is a good document -- I see immediate educational uses for it. 
Put it forward. 
 
> either way, so the WG needs to decide on this point as well.

I prefer BCP, but this is not something I care very much about. Either
would work. 

-- 
Måns Nilsson		Systems Specialist
+46 70 681 7204		KTHNOC
			MN1334-RIPE

... I don't like FRANK SINATRA or his CHILDREN.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 24 Nov 2003 12:48:46 +0100

> IESG, please state whether you believe that it should be a BCP or an

I've read this draft and support it, it is good to have a stable
reference to this sort of information.

Since the content is purely written to be info instead of practice I
think it should be published as "Informational" although I wouldn't
mind BCP status.

One very minor nit: In 3.2 readers have to dive into the perlcode to understand
what the simulations mean. Some introduction would help.

Suggested text:

  The following output from a response simulator demonstrates these
  properties. thhe program simulates the packet sizes as a function of
  number of NS RRs, A and AA glue records. It returns the size of a
  packet and the number of glue records that fit in that packet for
  the cases that the NS RRs do or do not share a common name and for
  an average (64 byte) and a worst case (256 byte) sized QNAME.

  We the term "green" if all address records could fit, or "orange" if
  two or more could fit, or "red" if fewer than two could fit.  It's
  clear that without a common parent for nameserver names, much space
  would be lost.

      % perl respsize.pl 13 13 0
        common name, average case: msg:303    glue#13 (green)
        common name,   worst case: msg:495    glue# 1 (red)
      uncommon name, average case: msg:457    glue# 3 (orange)
      uncommon name,   worst case: msg:649(*) glue# 0 (red)
      % perl respsize.pl 13 13 2
        common name, average case: msg:303    glue#11 (orange)
        common name,   worst case: msg:495    glue# 1 (red)
      uncommon name, average case: msg:457    glue# 2 (orange)

I support the document even without this nit being addressed. Sorry
for bringing this up during last call.

-- Olaf

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC

.