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

From: Pekka Savola <[email-masked]>
Date: Wed, 3 Dec 2003 21:20:04 +0200 (EET)

On Fri, 21 Nov 2003, Rob Austein wrote:
> 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.

I support the document going forward as Informational, but not without
revision; the document is clearly unfinished, and as it is, it could
only be published as Historic if that was possible :-)

I believe 1) and 2) MUST be done prior to this document can be useful.  
We also SHOULD do at least parts of 3) prior to going forward, to 
increase the usefulness of this document.

Major issues:
 
1) no references section, no security considerations, no
acknowledgements, no IPR or copyrights section, the lines go beyond 72
characters which is the allowed maximum, etc. --- don't even get me
started on editorial style :-)

2) The draft is short, but incomplete.  After reading, you get a 
"huh.. then what?" -feeling.  Suggested resolution: add a whole new 
section after 3.2, "4 - Conclusions" which should be at least 1.5 
pages long, describing the actual implications of the findings in 
section 3.2.

3) It would not hurt to actually do some of that "Further work" right 
now, before publishing this document. E.g., doing more tracing (4.1 
and 4.2), listing considerations for adding AAAA records to the zones 
(4.3).  4.4 appears to be clearly out of scope.

Nits:
 - two section numbers "5" -- the former should actually be the 
appendix
 - s/Author's Address/Authors' Addresses/

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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

---

From: Peter Koch <[email-masked]>
Date: Fri, 05 Dec 2003 17:44:56 +0100

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

I've read the document and used it in practice. However, I mostly agree with
Pekka that it's not yet ready for publication, because it's not explicitly
saying what it's aiming at. I'd prefer it go to BCP when a clear recommendation
is found. The suggestion for further work in section 4 is reasonable, but
that's more appropriate in a work plan. If there's the need for a document
really soon, I'd skip this section.

Questions/remarks {and also apologies for waiting until the last hour}:

o  Throughout the document (2.8 and output of perl script) the term "glue"
   should be replaced by "additional data". Glue is where it comes from,
   additional data is how it's delivered, and that's the point here.

   Also, the "glueing policy" is usually different for the root zone and
   TLDs, so that should be mentioned and discussed {I'm willing to
   to contribute text, coming duriong the weekend}.

o  The average case is based on 64 octet queries, but the document doesn't say
   what this number is based on. Olaf's text suggestion makes this explicit
   (and says "an" average, not "the" average), but for an off-the-shelf
   script that's a bit too vague IMHO. It's implicit or suggested in section 4
   that an average be measured, but that would need some additional text like:

   "For demonstration purposes we've chosen an average queue length of 64,
   which is based on {our measurements at X, ...}. Zone maintainers are
   encouraged to do their own measurements and use the results when apllying
   this algorithm."

   Also it's important to say that the queries to be measured are those for
   names in the to be delegated/glued zone, not those for the delegating
   zone in general.

o  2.4 suggests a common domain suffix for the servers' names, but it doesn't
   discuss "all eggs in one basket" and the consequences for the really
   necessary "glue".

o  2.5 says "255 characters of presentation data" and "256 octets of network
   data". Both differ by two, not one, and the network data is really limited
   to 255 octets by RFC 1034 (that only slightly changes the calculations).

o  For response size calculations discussed within CENTR earlier this year
   I've used a slightly modified script, which also takes into account the
   necessity of the additional data (i.e. what MUST be glued). Maybe something
   similar can be added to the appendix.

-Peter
.

---

From: Paul Vixie <[email-masked]>
Date: 05 Dec 2003 18:29:21 +0000

[email-masked] (Rob Austein) writes:

> 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.

as a coauthor, i want to thank rob for putting this up for WGLC, since
a total of zero comments were received before WGLC.  now that we've seen
some responses and suggestions, kato-san and i will get working on -01.

(one possible moral of this story is, please read the drafts before WGLC,
so that rob won't have to resort to cheap tricks to get attention, since
otherwise the meaning of "WGLC" will be diluted to "speak now or forever
hold your peace.)
-- 
Paul Vixie
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html