Re: Elimination of Registration Response Success /w Wa rning/Modificat ion from ASAP draft
Qiaobing Xie <[email protected]>
| Newsgroups | gmane.ietf.rserpool |
|---|---|
| Message-ID | <[email protected]> |
Sounds good to me. -Q Michael Tuexen wrote: > 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 >> > > > _______________________________________________ > rserpool mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/rserpool >