attachment-0001

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1"> <META content="MSHTML 6.00.2800.1491" name=GENERATOR></HEAD> <BODY> <DIV><SPAN class=438114018-25032005><FONT face=Arial color=#0000ff size=4>Hi,</FONT></SPAN></DIV> <DIV><SPAN class=438114018-25032005><FONT face=Arial color=#0000ff size=4></FONT></SPAN> </DIV> <DIV><SPAN class=438114018-25032005><FONT face=Arial color=#0000ff size=4>In IETF (e.g., IPP) and W3C the requirements are for the standard (NOT for</FONT></SPAN></DIV> <DIV><SPAN class=438114018-25032005><FONT face=Arial color=#0000ff size=4>the implementations of the eventual protocol).</FONT></SPAN></DIV> <DIV><SPAN class=438114018-25032005><FONT face=Arial color=#0000ff size=4></FONT></SPAN> </DIV> <DIV><SPAN class=438114018-25032005><FONT face=Arial color=#0000ff size=4>A naked list of requirements in a new section would satisfy the letter (though</FONT></SPAN></DIV> <DIV><SPAN class=438114018-25032005><FONT face=Arial color=#0000ff size=4>not the spirit) of this PWG Process/2.0 prerequisite.</FONT></SPAN></DIV> <DIV><SPAN class=438114018-25032005><FONT face=Arial color=#0000ff size=4></FONT></SPAN> </DIV> <DIV><SPAN class=438114018-25032005><FONT face=Arial color=#0000ff size=4>We've still got to write something about why Discovery is NOT included in</FONT></SPAN></DIV> <DIV><SPAN class=438114018-25032005><FONT face=Arial color=#0000ff size=4>WIMS (and contrary to recent notes is NOT necessary even out-of-band for</FONT></SPAN></DIV> <DIV><SPAN class=438114018-25032005><FONT face=Arial color=#0000ff size=4>WIMS implementations).  WIMS is not just an SNMP browser replacement.</FONT></SPAN></DIV> <DIV><SPAN class=438114018-25032005><FONT face=Arial color=#0000ff size=4>You can reconfigure systems and take them down with WIMS.  That needs</FONT></SPAN></DIV> <DIV><SPAN class=438114018-25032005><FONT face=Arial color=#0000ff size=4>explicit prior administrative configuration of roles, privileges, and parent/child</FONT></SPAN></DIV> <DIV><SPAN class=438114018-25032005><FONT face=Arial color=#0000ff size=4>relationships, not just discovery.</FONT></SPAN></DIV> <DIV><SPAN class=438114018-25032005><FONT face=Arial color=#0000ff size=4></FONT></SPAN> </DIV> <DIV><SPAN class=438114018-25032005><FONT face=Arial color=#0000ff size=4>Cheers,</FONT></SPAN></DIV> <DIV><SPAN class=438114018-25032005><FONT face=Arial color=#0000ff size=4>- Ira</FONT></SPAN></DIV> <DIV> </DIV> <P><FONT size=2>Ira McDonald (Musician / Software Architect)<BR>Blue Roof Music / High North Inc<BR>PO Box 221  Grand Marais, MI  49839<BR>phone: +1-906-494-2434<BR>email: imcdonald@sharplabs.com</FONT> </P> <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> wamwagner@comcast.net [mailto:wamwagner@comcast.net]<BR><B>Sent:</B> Friday, March 25, 2005 12:55 PM<BR><B>To:</B> McDonald, Ira; 'wims@pwg.org'<BR><B>Subject:</B> Re: WIMS> Move WIMS requirements to separate spec<BR><BR></FONT></DIV> <DIV>The inclusion of the earlier documents for scenarios and requirements (which documents did represent a major investment of time and energy) was a trial. I agree that this section overwhelms the WIMS spec and needs some severe editing if not complete elimination. Further, there were functional requirements implicit in the scenarios that were eventually dropped or pushed off.</DIV> <DIV> </DIV> <DIV>Although I think the scenarios (properly edited) are useful and aid in the understanding of the WIMS objectives, I have no objection to just including a summary requirements section in the spec.  I believe the Process document is unclear as to whether the statement of requirements is "of" the protocol or requirements "for" the protocol. Despite first sentence of  Process paragraph 4.4, "... the statement of requirements for the standard to be produced is required", the gist of the paragraph appears to relate to requirements of the standard. In this case (which seems to be the interpretation taken by other working groups), dropping the scenarios and just updating the requirements section in the current draft would appear to satisfy the intent of the process.</DIV> <DIV> </DIV> <DIV>Bill Wagner</DIV> <BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">-------------- Original message -------------- <BR><BR>> Hi, <BR>> <BR>> New thread for this topic - echoing Harry's concern. <BR>> <BR>> We had hoped to move the WIMS Protocol spec into 'last call' <BR>> much sooner by including the WIMS Requirements, because each <BR>> prerequisite Formal Approval will use up at least two PWG <BR>> face-to-face meeting cycles (one for 'last call' and one for <BR>> the editorial cleanups and subsequent vote on Formal Approval). <BR>> <BR>> But if we leave these WIMS Requirements in this single document, <BR>> we could waste a lot of time meant to be spent on substantive <BR>> issues in the body of the WIMS Protocol spec discussing the <BR>> editorial fixups for the requirements. <BR>> <BR>> Note that the PWG Process/2.0 does not require use cases. <BR>> It just mandates requirements, so some major trunca! tion is <BR>> possible, if we want to take that path. <BR>> <BR>> Opinions? <BR>> <BR>> Cheers, <BR>> - Ira <BR>> <BR>> <BR>> Ira McDonald (Musician / Software Architect) <BR>> Blue Roof Music / High North Inc <BR>> PO Box 221 Grand Marais, MI 49839 <BR>> phone: +1-906-494-2434 <BR>> email: imcdonald@sharplabs.com </BLOCKQUOTE></BODY></HTML>