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
- FW: IESG Review Comments Hollenbeck, Scott
- Re: FW: IESG Review Comments -- item 7 Eric Brunner-Williams in Portland Maine
- RE: IESG Review Comments Liu, Hong
- Conformance with ICANN Redemption Grace Periods Ram Mohan
- Re: FW: IESG Review Comments -- 1-6, 8 Eric Brunner-Williams in Portland Maine