[registrars] gTLD Registry Maintenance Notices

Paul Stahura stahura at enom.com
Mon Apr 26 15:54:03 UTC 2004


I agree with Ross's requirements list.
I would add the word "standardized" in there somewhere because we do not
want each registry to do something different.
It has to be the same across registries.
I also agree with using RSS/RDF to implement, as long as the requirements do
not include out-of-band stuff involving say specific domain names, but stick
to meta-information (registry downtime notifications, etc).
Run it in parallel with the current email notifications, at least for a
while.
It may take too much policy dev to modify EPP, IMO, but we may (have to?) go
there if the out-of-band info is domain name or registrar specific.

-----Original Message-----
From: owner-registrars at gnso.icann.org
[mailto:owner-registrars at gnso.icann.org] On Behalf Of Ross Wm. Rader
Sent: Monday, April 26, 2004 4:10 AM
To: Donny Simonton
Cc: 'tbarrett'; 'Larry Erlich'; 'Tim Ruiz'; michael at palage.com;
registrars at dnso.org; dam at icann.org; 'Marie. Zitkova'; 'Miriam Sapiro'
Subject: Re: [registrars] gTLD Registry Maintenance Notices

On 4/25/2004 9:09 PM Donny Simonton noted that:

> I don't like the email system we currently have, and I think RSS feeds
would
> be just as bad if not worse than what we have right now.  The reason is
very
> simple, if a registry goes down they wouldn't have to notify us, they
would
> just post something via RSS feed.  So what would happen, people would be
> checking it every 30 seconds to make sure there are no problems.

If the net utility exceeds the net efficiency, then the sum still 
works out in the customer's (registrar's) favor. We need a more useful 
notification format - lets not over-analyze the various proposals, 
lets encourage them. Registrars have a really bad habit of 
pre-negotiating with themselves instead of keeping maximum options open.

> If we had a combination of email and RSS that would probably help.  Hell,
> why not just allow us to poll it via EPP.  Why involve RSS when we already
> have a system in place.

EPP is basically just a message format - RSS is basically a document 
format. Very similar animals. You are talking about the merits of 
different transport mechanisms. Very different from document and 
message formats. I don't think that making EPP recognize another 
message/document format really makes a ton of sense any more than 
scrapping the existing mail system in favor of the "one correct 
implementation" (whatever that may be...)

So lets talk requirements...here's a list that we can all add to...

We need...

1. the registries to improve their out of band notifications mechanisms.

2. to be able to parse registry notifications more effectively.

3. to be able to repurpose the registry notification payload more 
easily. These notification messages will be used by registrars for 
purposes the registries did not intend nor expect.

4. to ensure that the right people internally receive only the 
notifications appropriate to their job function.

5. to minimize changes to existing systems.

6. to minimize implementation and operational costs for all parties.


> 
> Problem solved!  Next problem.
> 
> If that doesn't work, at least an option via the registries to have a
> downtime mailing list.  So at least we could send it to the people who
> actually need the information.  Our CFO really doesn't care if .name will
be
> down for 4 hours on Saturday.  But CS and Network Operations do.

Unless the messages are parseable, we just create a larger 
problem...I'd love to be able to parse these messages on this end and 
trigger various events based on their contents.

-- 


                        -rwr








                 "Don't be too timid and squeamish about your actions.
                                            All life is an experiment.
                             The more experiments you make the better."
						- Ralph Waldo Emerson

Got Blog? http://www.blogware.com
My Blogware: http://www.byte.org



More information about the registrars mailing list