Re: FW: IESG Review Comments -- 1-6, 8

Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net> Thu, 17 October 2002 21:43 UTC

Received: from nic.cafax.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27022 for <provreg-archive@ietf.org>; Thu, 17 Oct 2002 17:43:28 -0400 (EDT)
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g9HLffcE002989 for <ietf-provreg-outgoing@nic.cafax.se>; Thu, 17 Oct 2002 23:41:41 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g9HLffdh002988 for ietf-provreg-outgoing; Thu, 17 Oct 2002 23:41:41 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g9HLfdcE002983 for <ietf-provreg@cafax.se>; Thu, 17 Oct 2002 23:41:40 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id g9HLf8pt041344; Thu, 17 Oct 2002 17:41:08 -0400 (EDT) (envelope-from brunner@nic-naa.net)
Message-Id: <200210172141.g9HLf8pt041344@nic-naa.net>
To: "Hollenbeck, Scott" <shollenbeck@verisign.com>
cc: "'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>, brunner@nic-naa.net
Subject: Re: FW: IESG Review Comments -- 1-6, 8
In-Reply-To: Your message of "Thu, 17 Oct 2002 14:51:01 EDT." <3CD14E451751BD42BA48AAA50B07BAD603370077@vsvapostal3.prod.netsol.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <41342.1034890868.1@nic-naa.net>
Date: Thu, 17 Oct 2002 17:41:08 -0400
From: Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
Sender: owner-ietf-provreg@cafax.se
Precedence: bulk

1. Mailing list names and URLs

   During the development of a specification, draft versions of the
   document are made available for informal review and comment by
   placing them in the IETF's "Internet-Drafts" directory, which is
   replicated on a number of Internet hosts.  This makes an evolving 
   working document readily available to a wide audience, facilitating 
   the process of review and revision.

Having mailing list, the url for the IETF's "Internet-Drafts" directory [1],
for the working group, its archive, seems to meet the clear sense of sec2.2
of 2026. After the development is complete, they do seem likly to "age".

In any case, this is an RFC editor issue, and rather cosmetic..

2. Manditory to implement transport confidentiality or confidentiality and
   integrity.

Hmm. This was not a requirement when the prevailing model of access was
described in rfc518. How about rfc597? Nope. How about at the dawn of the
classical period with rfc625? Nope. Let's try rfc756 (keep this in mind,
I do), and Nope again. ... Skipping ahead to the dawn of the modern age
there is rfc1261 -- and another Nope. Not until we get to rfc2832 does
the possibility even begin to exist.

There is, or are, one or more use-case assumptions buried in this that
must be beaten out of the mush of "Security". I don't know what they are,
yet.

3.,4. Sigh. the authInfoType isn't of type token. Fix language (not
schema).

5. Now there is a catch worth paying for. Thanks Steve!

6. Scott's note (Bradner I assume) interests me.

What would interoperating implementations of EPP look like, if they either
attempted congestion control themselves (now there's an extension), or if
they could cause congestive collapse of some transited link. For it to be
of any but local interest, and not expose some fatally stupid bandwidth
under provisioning at the registry (I can think of one) and constitute a
(self-inflicted) DOS attack, the failed transit link would have to be a
core link.

Even counting-to-infinity type events didn't cause congestive collapse
when I was younger and an operator.

Feel free to think out loud folks, why does congestion control really
matter? This seems rather far from the VGRS "storm" events.

I've commented on 7 seperately.

I'll think about 8. This is on-par with element-level XML encryption.
(Ironically, the XMLP activity is "on the other line" about just this.)

Eric