Re: [PEPPERMINT] While we wait on the drafts

[Andrew Newton <andy at hxr.us>]

In-line...

On Jan 5, 2007, at 12:42 PM, Richard Shockey wrote:

> NeuStar has not implemented 4114 for that matter though we have  
> implemented
> EPP in our normal domain name registry operations.
>
>
> > -----Original Message-----
> > From: Uzelac, Adam [mailto:Adam.Uzelac at globalcrossing.com]
> >
> > Andy - If you are asking for a show of hands as to who has or hasn't
> > implemented/deployed 4114 - you can put Global Crossing as a company
> > that has NOT.

I was.  Thanks for understanding the obtuseness of the request.  For  
the record, SunRocket has not implemented 4114 (we'd be doing client- 
side), but have given it consideration and would have implemented it  
if any of our partners had.

> > As for the provisioning models that you put forth, is
> > there not room for a hybrid environment?  I think there has to be a
> > combination of the 2 models to achieve a practical implementation.
> > There must be an "entire catalog" download/upload to start before any
> > delta model can be realized.  But to do a full download of the  
> > catalog
> > at a regular interval would be unruly.

Yes, there is room for a hybrid model.  But in Model 1, there is no  
exact need for a model 2 style start up.  Startup is simply a truck- 
load of additions.  However, I think it reasonable that normal  
operations would be model 1 and startup and checkpoints/resyncs would  
be model 2.

> We would assume a incremental update of changes to the entire  
> cached catalog
> " aka registry" would be a MUST.

So why doesn't 4114 meet your needs?

As far as MUST/SHOULD language goes, I'd like to see both models (and  
their hybrid) be a MUST implement.  Must deploy is a different matter.

And while I'm reciting my wish list, I'd like to see a couple of  
protocol features:

Model 1 Transactions) It would be nice to group the deltas into  
discrete transactions, similar to SQL transactions.  If one fails,  
they all fail.

Model 2 Chunking) With a reasonably sized catalog, the number of  
octets in the catalog (especially if it uses XML) can get quite  
cumbersome.  Typical octet counting mechanisms (such as EPP or plain  
HTTP POST) would then require an enormous buffer.  It would be better  
if the catalog could be sent in chunks or different, sequential  
messages.

It is possible that both features could be achieved with the same  
mechanism.

> > What about a model that follows a "per query" methodology?  There  
> > would
> > be some minor upfront provisioning that would ensure that a  
> > preexisting
> > contractual or trust relationship exists, but then query the  
> > catalog of
> > your peers for reachability of the intended target.  I realize  
> > there are
> > scaling issues involved, but it's realistic that this model would  
> > exist,
> > no?
>
> Of course .. some folks will not want to cache the catalog/registry  
> and
> others will simply want a per dip model. The issue will be then  
> what are the
> appropriate per dip query mechanisms and do we want to limit the  
> scope of
> acceptable models limit discussion to just RFC 3761 (DNS) and SIP  
> Redirect?

I'd prefer we leave the actual mechanism for the query out of scope.

-andy

_______________________________________________
PEPPERMINT mailing list
PEPPERMINT at ietf.org
https://www1.ietf.org/mailman/listinfo/peppermint