RE: Question on security document

[Charles Monia <cmonia@NishanSystems.com>]

Hi:

I'm in agreement with the idea that the authoritative requirements are those
explicitly spelled out in the protocol specs and not by reference to an
informational document.  My expectation was that the informational security
spec being developed by the design team would provide the *language* or at
least a clear statement of the requirements to be incorporated directly into
the protocol specifications.

Charles

> -----Original Message-----
> From: Robert Snively [mailto:rsnively@brocade.com]
> Sent: Thursday, October 18, 2001 8:36 AM
> To: 'Paul Koning'; cmonia@NishanSystems.com
> Cc: ips@ece.cmu.edu
> Subject: RE: Question on security document
> 
> 
> Paul,
> 
> I rather prefer to see the security mandates carried in
> the primary documents, as our IETF mentors originally proposed.
> That way, there is less possibility of inconsistent
> language that may change the primary documents.  Then the
> security document would be a tutorial and remain informational.
> This will simplify the standardization process, because 
> each of us will only have to read the security document for
> guidelines to our development of the security section of the
> primary documents.  If we were to make the security document
> the standard, then each of us will have to
> read the entire document to make sure that some global
> restriction does not fall unintentionally on a particular
> protocol.  
> 
> If we do choose to make the security document the authoritative
> document (which I would vote against), then it needs a major 
> rewrite to clarify, separate, and make more precise the 
> requirements for
> each protocol.
> 
> Charles,  
> 
> If the security document was intended as a draft of the security
> sections for each protocol, it needs a major rewrite to separate
> the particular language to be dropped into each document from the
> tutorial information.  It then needs to formulate much more
> clearly and formally the language that will be dropped into the
> primary documents.  That would be okay with me, but the draft
> should indicate that the language to be dropped into the
> primary documents is only proposed and that the actual applicable
> standards information is contained in the primary document.
> 
> Bob
> 
> > -----Original Message-----
> > From: Paul Koning [mailto:ni1d@arrl.net]
> > Sent: Thursday, October 18, 2001 7:37 AM
> > To: cmonia@NishanSystems.com
> > Cc: ips@ece.cmu.edu
> > Subject: RE: Question on security document
> > 
> > 
> > Excerpt of message (sent 17 October 2001) by Charles Monia:
> > > Hi:
> > > 
> > > I had assumed that one goal of the document was to set 
> > forth the language
> > > necessary for each spec to pass muster with the IESG in 
> the realm of
> > > security.  If that's correct, I'm concerned that the 
> > suggested change may
> > > compromise that intent.
> > > 
> > > Charles
> > > > -----Original Message-----
> > > > From: Robert Snively [mailto:rsnively@Brocade.COM]
> > > > Sent: Wednesday, October 17, 2001 4:31 PM
> > > > To: 'ips@ece.cmu.edu'
> > > > Subject: Question on security document
> > > > 
> > > > 
> > > > I have a recommendation to the authors of the security 
> > > > document:
> > > > ...
> > 
> > The problem, as Bob is right to point out, is that 
> informational RFCs
> > by definition cannot establish requirements on 
> implementations.  So if
> > you want there to be security requirements that apply to 
> iFCP, iSCSI,
> > and so on, they can only be stated in standards track RFCs, not
> > informational RFCs.  It may be a separate document or part 
> of the IPS
> > document it applies to.
> > 
> > So one answer is for the security draft not to be informational
> > anymore.
> > 
> > 	paul
> > 
> > 
>