[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: André Cormier <Andre.Cormier@viagenie.qc.ca>, "Provreg (E-mail)" <ietf-provreg@cafax.se>
From: Richard Shockey <rshockey@ix.netcom.com>
Date: Wed, 27 Dec 2000 13:33:51 -0500
In-Reply-To: <5.0.0.25.2.20001226233040.00a91a18@localhost>
Sender: owner-ietf-provreg@cafax.se
Subject: RE: My personal comments on the requirements.


>>
>>[SAH] I don't have a problem with the basic idea here, but I'd like to
>>suggest that this doesn't need to be a MUST in the protocol itself.  Other
>>layers can do this as well; for example, BEEP offers just such a negotiation
>>mechanism and I think it would be overkill to do the negotiation within both
>>BEEP and another application layer protocol.  Would this re-wording be
>>acceptable?:
>
>[AC]Yes it would be overkill to do it in both BEEP and the protocol. But i 
>still think it should be part of the requirements. If BEEP is used with 
>the proposed protocol than BEEP will meet the negociation requirement. If 
>BEEP is not used, the protocol should include this kind of negociation.
>
>What do you think ?

Well I think you are correct... and that is one reason I would encourage us 
to look at the BEEP framework as the transport for this protocol 
application ..though I'm told there may be some limitations on its use 
during the pre-sale search mechanism that puts heavy stress on the registry.



>>"[3] The protocol or another layered protocol MUST provide services to
>>negotiate an authentication mechanism acceptable to both the server and the
>>client."
>>
>>I don't think the advertisement requirement is necessary if the mechanism
>>must be negotiated.  Some kind of information exchange has to happen as part
>>of the negotiation process.

BEEP offers this as a option ..another reason to consider its adoption ...



>>[SAH] Can you be more specific about the purpose of this new field?  I'd
>>much prefer to enumerate required information vs. providing some kind of
>>unformatted registry-specific field.
>
>[AC] For each objects, registries may require additionnal fields. I'd like 
>to see what other ccTLDs or gTLDs needs for the contact object or for 
>other objects. I do not say that the objects are incomplete but i think 
>that it should not be too restrictive. This way if such a need arise, than 
>the protocol will not need an update to support a new field for the 
>contact object.

I'd like to see some additional information on what registries are thinking 
about this. I'm beginning to believe that certain registries may have 
different requirements than others. The needs of .de are clearly different 
from .com or .biz for that matter ..this goes to extensibility again.



 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Technical Industry Liaison
NeuStar Inc.
1120 Vermont Avenue N.W., Suite 550, Washington DC. 20005
Voice: 202.533.2811,  Cell : 314.503.0640,  Fax: 815.333.1237
<mailto: rshockey@ix.netcom.com> or
<mailto: rich.shockey@neustar.com>
<http://www.neustar.com>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


Home | Date list | Subject list