Re: ENRP Peer Name Update

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Freitag, 27. August 2004 17:39 schrieb Qiaobing Xie:
> > When a NS applies a deregistration from the namespace, it first calls a
> > function to delete the NS from the namespace. Then, the information about
> > the PE is gone (memory is deallocated). This implies, that the PE
> > information has to be duplicated (including malloc()/new calls -> error
> > handling becomes necessary) before the deregistration to be able to fill
> > out the
> > PeerNameUpdate message. It is not recommended to send PeerNameUpdates
> > before deregistering the element itself from the namespace, since a
> > deregistration may fail (permissions, etc.). Using only a PE ID, it is
> > simply necessary to remember a 32-bit integer value (fixed-size, no
> > malloc()/new necessary).
>
> This argument is rather implementation specific. There are another ways of
> implementing it without facing such difficulties. in fact, I didn't have
> this difficulty in my impl (Randy can testify :-).

Yes, it is possible. But IMHO, it requires more effort than simply using a PE 
Identifier parameter. In this case, you would simply scan for the PE 
Identifier Parameter instead of scanning for the Pool Element Parameter and 
looking there for the PE ID itself.


> > When parsing a Pool Element Parameter having fields set blank and things
> > like pool policy and user transport missing, all procedures requiring a
> > complete Pool Element Parameter have to check if the parsed parameter is
> > valid. If we do *not* allow to leave fields blank and skip user
> > transport/policy parameter, a pool element parameter scanner procedure
> > can directly verify if it is complete. No special cases are necessary.
> > And finally, a Pool Element Parameter having all fields except the ID set
> > blank, is nothing more than a degenerated Pool Element Identifier
> > Parameter.
>
> Again, this is not a strong argument IMO. E.g., my parser allows me to get
> a particular TLV while ignoring others, so I did not have this problem. So,
> when I find the action is a deletion, I would call the parser and ask it to
> return me the PE Id TLV, and after that I may choose not to check any other
> TLV at all.

But a parser should check if the complete message is valid and not malformed. 
For example a Pool Element Paramter is defined in the common parameters draft 
to be containing e.g. a user transport parameter and a policy parameter. When 
e.g. there is no user transport parameter or it contains no addresses etc., 
the message is IMHO malformed and should not be processed.

When only a PE identifier has to be specified, a Pool Element Identifier 
Parameter should be used. This parameter encapsulates the information 
necessary and requires nothing more, therefore it also more consistent. Why 
using a full Pool Element Parameter when a PE Identifier Parameter is 
sufficient?


Best regards
- -- 
=======================================================================
 Dipl.-Inform. Thomas Dreibholz

 University of Essen,                            Room ES210
 Inst. for Experimental Mathematics              Ellernstraße 29
 Computer Networking Technology Group            D-45326 Essen/Germany
- -----------------------------------------------------------------------
 E-Mail:     [email protected]
 Homepage:   http://www.exp-math.uni-essen.de/~dreibh
=======================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBL2IN32BbsHYPLWURAnLlAKC2KL47KDztXwegr1S/1Z3uq4E9awCeKmyW
M6KyyzyGQaJoFOiJnE2QyDs=
=IRq6
-----END PGP SIGNATURE-----