windows-nt/Source/XPSP1/NT/net/rras/rtmv2/todo.lst

Do I have to validate the state of dest in RtmGetOpaquePtr ??

5)

Give opaque ptr instead of handle to the entity method.

7) In RtmAddNextHop, do u need to do the NextHopHandle validation after
   taking the Entity's Next Hop Lock ? Otherwise we might potentially
   update a next-hop that has been deleted (which might be OK as you 
   are not updating the state , and you have a ref count on the nexthop)

8) To work on a next hop directly, the next hop owner can keep a pointer,
   but he still needs to keep a handle around to be able to delete it ???

9) What about delete all next-hops in one stroke  if nexthophandle == null
   in RtmDelNextHop ?



Just keep direct RTM_NEXTHOP_INFO * in the next hop list, but
give out handles 

What if a call has handles from two diff address families/instances ... ?

Holddown protocol ? Do I keep track of it the registration ?
	- Affects GetDestInfo - do u give holddown route
	  Affects GetEnumDests, GetEnumRoutes - do u give helddown routes ..?

Do we need a state in the next-hop (that we understand) ?

If u expose RtmLockNextHop and RtmLockRoute, the caller has to be aware
of the locking mechanism ? Like the granularity of locking etc. ?



Improve EnumOverTable to take into account StopContext ??

and

Have macros to initialize the space for EnumContext.

and


Improve AdjustPrefixes to intelligently use StopContext instead
of getting everything and doung a PartialMatch....

Implement MAKE_DEST_INFO_FROM_DEST and also make GetDestInfo go through that.

Incorporate dave's preference comparision (BGP multi-byte preference)
How does this affect matching a specific pref ?

When u delete a dest from the tree , make sure that u are not in a state
when ref on dest has gone to zero and it is still in the tree. Does not
work well with RtmGetExactMatchRoute as u potentially might be trying to
ref dest with a ref count of zero. PS each held-down route also contribs
to ref count here.


How come DEST does have a state and we do check for deleted ....
in VALIDATE_DEST_HANDLE //// ****

Shift all error processing related to rtm route info  from  RtmNewRoute
to CreateRoute like views parameter checking etc.

Have a function to Get all routes that match a certain criteria ?
For example, RIP want to query all its routes for the route handle
to pass in update (it wants to get a route learnt from a certain
neighbour which is part of the opaque info block).

How do u know whether update route has been called after lockroute or not ?

See if can optimize NewRoute and NewNextHop to use CopyMemory instead of
copying field by field ?

Use a dynamic lock in dest instead of allocating a new lock ???

Do I need to ref a entity when a route is added (or) can I manage it by
keeping refs on the next hop (indirect reln) - Answer is a route guaranteed
to have atleast one nexthop at all times ????


UPDATE BelongsToViews in RtmDelRoute

Make sure you have a model from updating routes (and nexthops) in place
without having to copy stuff out.

Do we update the holddown route only for the last route deletion ? Or
for every best route change ? If u already have a holddown route (do
u change the holddown period for the old route), or do u update the
holddown ? The later defeats the purpose of holddown anyway.

Semantics of Ignore dests ? Do u ignore even if we have no changes at
ignore time ?

See if u are reinitializing after allocating and zerong block ?

We are processing the change list with a lock preventing all others 
from adding to the list ?

Does putting in the entity list lead to having a ref count ?

Serializing the operations on entity lists by keeping lock on entity ?

Do we need a read/write lock on the addr family change notifications block ?

Include TRACING statements in RTM >>

Check status code of Rtl


What will happen if we call ProcessChangedDestsList and kill timer
from outisde a timer func ?

Decide on whether u want to have a Interlocked op to make sure that
only one ProcessChangedDests happens at a time ??

Make sure that the caller entity does not de-register while you
give callbacks to him (route aged out callbacks etc). ????

Do u validate an entity handle to see if the de-registration has not
come up or not ? 


GetInstanceInfo and GetInstances should return supported address families
in an array ?

Make sure u delete all routes in the RTMv1 wrapper de-registration


GET UR ****ing DE-REGISTER STRATEGY RIGHT ? What happens if he deregisters
twice ? What about sync between a non-deregister and a de-register ???


-----Wrappper ------------------------------------------------------------

Do we ignore the VALIDATE and ROUTE_CHANGE callbacks to router manager ?

[ in RTMCreateRouteTable ]


RTM_ROUTE_CHANGE_BEST will be true even if the best route remained the same
but the best route's forwarding information changed ????

In the wrapper, what will happen if DeleteRouteTable happens before other
RTM calls (or during) ? Similarly with Deregister etc.

------For Later -----------------------------------------------------------

ComparePref in NT-64
{
    if (*(ULONGLONG *)Pref1 > *(ULONGLONG *)Pref2)
    {
	return +1;
    }
    else
    if (*(ULONGLONG *)Pref1 < *(ULONGLONG *)Pref2)
    {
	return -1;
    }

    return 0;
}

---------------------------------------------------------------------------


Make sure you stop the timers (CN timer) on the address family before
you DestroyAddressFamily (as they access AF locks...)

Make the distinction between counted type (ULONG) and bit-type (DWORD)

Do we put a route in hold if it is not the last route to the dest ????

Hold ref in each view .... (RIP and DVMRP putting same dest in holddown)

What about DestFlags (do we need it per view - who sets it ...)

---------------------------------------------------------------------------
Perf Improvements
---------------------------------------------------------------------------

Lookaside lists for common allocations for better locality ??