Subject: [Rserpool] Reliable Server Pooling Minutes from IETF #59

From: [email-masked]
Date: Mon, 15 Mar 2004 13:59:47 -0600

Please send any comments or questions to the list.  

-- maureen

Approximately 30 people attended the meeting at IETF #59.

Chairs:
Lyndon Ong; [email-masked]
Maureen Stillman; [email-masked]

We discussed the services document draft-ietf-rserpool-service-00.txt.  This document was recently updated and posted to the list.  We request that people read the document and send comments to the list.   

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.

The comparison document draft-ietf-rserpool-comparison-07.txt was added to the agenda because the issues raised by the reserpool architecture review also had impact on the comparison document.  Further issues were raised by the AD review concerning evaluation of other IETF protocols such as Dynamic Delegation Discovery System (DDDS) RFC 3401-6 and Extensible Provisioning Protocol (EPP) draft-ietf-provreg-epp-09 in relation to Rserpool.  We need to evaluate these protocols and reach a determination about their applicability to Rserpool.  Also the issue of using URN was raised.  Rserpool uses pool handle names in ASCII format rather than URN.  This is due to issues such as hierarchy in the name resolution process.  The Rserpool name space is not hierarchical.  The comment was that this seems to be an architectural issue rather than a comparison document issue.
 
The Rserpool security threat document draft-ietf-rserpool-threats-02.txt is also in AD review.  Comments were also received from the AD and have been added to -03.  This draft will be sent to be published after IETF 59.  A summary of the threats and mitigations was presented.  This is the text added to the security considerations section in response to AD review.  An issue was raised about the security of cookies. Cookies are not part of the Rserpool infrastructure, but it might make sense to provide security guidance on this area.  The security design team will evaluate this issue and make a recommendation.  This issue should also be discussed on the list.

We will continue to work on documents that have been reviewed by our ADs.  Updated internet-drafts are being generated in response to comments.

-- maureen

_______________________________________________
rserpool mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rserpool

---

From: Silverton Aron-C1710C <[email-masked]>
Date: Tue, 16 Mar 2004 18:59:13 -0600

[email-masked] <> wrote:
> 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

---

From: Silverton Aron-C1710C <[email-masked]>
Date: Tue, 16 Mar 2004 18:59:13 -0600

Regards,

Aron