Subject: Decision on containers - status?

From: Robert Burbidge <[email-masked]>
Date: Mon, 15 Apr 2002 14:05:27 +0100

According to "Goals and Milestones" on
http://search.ietf.org/html.charters/provreg-charter.html, Apr02 is the
deadline for deciding whether to support containers. Has this decision been
made yet and if so what is it? If not, is there a more specific deadline for
the decision?

Rob Burbidge, Poptel

(PS: Hope we're dropping them, less work to implement :-))

---

From: Edward Lewis <[email-masked]>
Date: Mon, 15 Apr 2002 10:34:59 -0400

At the end of the month, Jaap and I will be able to talk at the RIPE
meeting, so we (the chairs) will have something to say then.  There are
three possible outcomes - dropping it, pushing on it, or letting it lie
(dormantly) around.  The third possibility is there in case there are some
folks that feel it is good, "but not right now."

As far as the PS - it might be that containers are left as an
implementation-specific option.

>(PS: Hope we're dropping them, less work to implement :-))

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

Last day is Wednesday, April 24, 2002...

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

---

From: Rick Wesson <[email-masked]>
Date: Mon, 15 Apr 2002 07:41:20 -0700 (PDT)

my vote is to drop it, if there isn't interst amend the charter.

-rick

---

From: Dave Crocker <[email-masked]>
Date: Mon, 15 Apr 2002 08:00:55 -0700

>implementation-specific option.

Containers offers the benefit of freedom.  It decouples the details of 
interacting with the registrar's customer from the details of interacting 
with the registry on behalf of that customer.

Without containers, the two are tied together.  For many registrar 
environments, this is not a problem.  For others -- particularly 
larger-scale ones -- the limitation requires many more registrary/registry 
interactions and more complicated bookkeeping.

And bookkeeping is the word.  I don't know enough about bookkeeping to know 
the standard term, but I know that this sort of decoupling is quite common 
for accounting systems that have any sort of scale.

So, folks, yes it is less work now.  And clearly many registrars will not 
reach the size that needs containers.  Others will grow into the 
need.  Will, not might.

That says that containers needs to be an option.  Specification of options 
often can be deferred.  And given the knowledge about them, now, the 
requirement is to make sure that the current specification does not make 
adding containers difficult.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.850.1850

---

From: Rick Wesson <[email-masked]>
Date: Mon, 15 Apr 2002 09:15:52 -0700 (PDT)

Dave,

I'd actually disagree as mainiaing the efficiencies of contains is not
very a complex task from a registrar point of view -- and since I've
implemented more registrar back ends than anyone else I'm speaking from
experence.

-rick

---

From: Dave Crocker <[email-masked]>
Date: Mon, 15 Apr 2002 09:30:52 -0700

>implemented more registrar back ends than anyone else I'm speaking from

Rick,

Personally I think the layer of abstractions that containers offers is 
quite excellent and that the added complexity is not that great.  So I was 
quite surprised at the resistance to it.  However I'd say that the working 
group rough consensus about NOT wanting in required (or, at least, not 
wanting it at the present time) was undeniable.

So I thought that the compromise of making it an option was exactly the 
right choice.

If we are not going to specify the details now, that leaves the requirement 
that we keep the future use in mind and try to make sure we do not 
unintentionally prevent the addition later.

d/

----------