Re: Elimination of Registration Response Success /w Wa rning/Modificat ion from ASAP draft

I also support this. It makes the protocol simpler.

Best regards
Michael

On Oct 14, 2004, at 23:37 Uhr, Silverton Aron-C1710C wrote:

> I agree with the proposal below.  The current method assumes that the 
> PE is capable of supporting whichever pool policy is returned in the 
> warnings/modifications.  I don't think that this is a safe assumption, 
> so I support the change.
>
> Aron
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of Johnson Walter-CWJ002
> Sent: Thursday, October 14, 2004 3:23 PM
> To: [email protected]
> Subject: [Rserpool] Elimination of Registration Response Success /w 
> Warning/Modificat ion from ASAP draft
>
>
> Currently the registration procedure of the ASAP draft in section 3.1 
> supports three cases.
>
> 1) Success
> 2) Success /w warnings/modifications
> 3) Failure
>
> I believe that the registration procedure should only result in either 
> success or failure eliminating case 2.
>
> Let me explain.
>
> For instance, let say the PE can't adapt its policy from the policy 
> sent in the registration message. If the PE receives a registration 
> success /w warnings/modifications and can't adapt, it should remove 
> itself from the pool. Then the PE would need to deregister or not 
> re-register itself to be removed from the pool. This would cause 
> updates to happen across all peer ENRP servers since the PE would need 
> to be removed from the pool to which it was recently added, resulting 
> in many messages being sent to maintain namespace synchronization. 
> Also before this deregistration occurred, several PUs could have 
> starting using this PE for service which results in its own problems.
>
> If instead the registration was rejected using the operation error 
> codes regarding the problem, the PE could simply send a single message 
> to register again if changes could be made. Otherwise no message would 
> be sent if the PE couldn't adapt.
>
> I believe this is much simpler and would result in fewer overall 
> messages being sent within the RSerPool architecture and would result 
> in a cleaner ASAP implementation.
>
> What does everyone think?
>
> _______________________________________________
> rserpool mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rserpool
>
> _______________________________________________
> rserpool mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rserpool
>