RE: Reliable Server Pooling Minutes from IETF #59

[email protected] <> wrote:
> Please send any comments or questions to the list.
> 
> snip   
> 
> Next we discussed the Rserpool architecture,
> draft-ietf-rserpool-arch-07.txt which is in IESG review.  The IESG
> requested some changes to this document which raised some issues. 
> Specifically questions were raised about whether the protocols should
> be split into more pieces to aid in its understanding and possibly to
> aid in implementation.  This topic needs to be investigated further. 
> 
> snip
> 
> -- maureen
> 

I'll weigh in here.  I agree that the current documents are at times difficult to understand and that there are some nomenclature inconsistencies that should be rectified.  I've been party to several individuals coming up to speed on RSERPOOL and always get the same comments about this stuff.  I'm not even sure myself, based on title alone, what some of the drafts are all about.

For our internal efforts related to RSERPOOL, we have decided not to split the protocols and their documentation up further, but instead to unify them in a single design document.  For a particular RSERPOOL action, e.g., PE registration, we will describe both the ASAP and ENRP interactions between the various system components.  I have also found that using the abstraction of a Service User (SU) to describe both a PE and a PU in regards to the RSERPOOL Name Server (RNS) is often easier for those new to the protocol to digest.  When the behavior of the PE and the PU differs, we then differentiate between the two entities.

While being somewhat aware of the historical reasons that things were partitioned and named as they are today, I, and those that I have introduced to RSERPOOL, have had issues with the naming of ENRP.  End Point Name Resolution or Name Resolution (NR) is a function provided by an ASAP interaction by an SU with an RNS.  Namespace Synchronization (NS) is the actual functionality of what we call ENRP.  As it is only employed between RNSs, it does not provide NR.  I have been pondering renaming the protocol for our internal work, but it has been pointed out to me that this could be bad from the standpoint that someday (hopefully) RSERPOOL will be a standard and we may have the appearance of non-compliance due to a difference in designation.

I'm not sure how further splitting the protocols would simplify anything or even what is actually meant by that suggestion.  Having three or four protocols making up RSERPOOL is contrary to the argument about loosely-coupled and tightly-coupled systems that has been made in the past to defend RSERPOOL against suggestions that the same functionality exists in some collection of other IETF protocols kludged together.

I suggest that the existing delimitations between the two protocols should be made more clear and more precise, that the documents should be made more consistent in the naming of fields, timers, primitives, etc., and that some of the documents, e.g., Services, could be more concise.  I'm afraid that these issues are impediments to others' understanding and their becoming involved with RSERPOOL.

And, I *really* think that ENRP needs to be changed to something else like Name-space Synchronization Protocol.  It could be NSP or NSSP for those of you that like acronyms.  I won't bother to get into too much detail about how ENRP is really a generic protocol for synchronizing namespaces and that the ASAP interactions are actually part of the name server application and have nothing to do with ENRP.  I will, however, acknowledge that promoting ENRP as a generic protocol would be an interesting proposition within the IETF and perhaps not the best course of action.  I know from experience that calling it what it really is and making a separation between the name server application that is also described in the ENRP draft and the protocol itself makes it a lot easier for people to understand.

I'm not trying to point out nits or make undo criticism.  I have a vested interest in the success of RSERPOOL in all arenas and would like to do my part to see it happen.  To those ends, I am volunteering to do my part to make this happen.

Regards,

Aron