|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Question on security document
We have routinely taken our text into the security draft, and we had it
reviewed and scrubbed off there by a good group of security experts. We
routinely took selected things back into the authoritative document (iFCP
in our case, but it could have been any one the three protocols). The use
of the very same textual conventions is key to this high-bandwidth
interaction, as well as to keeping the documents in sync as we repeat the
cycle over and over.
The security draft also serves the purpose of keeper of the knowledge,
hence it does not fit the normative text role. Rationale text
and data (e.g., the speed/cycles figures) will hopefully be a good
companion text to many Standard RFC's readers. As well as new RFC writers
(good data outlives bad theory :-).
I don't see a conflict between MUST words and Informational RFC, the
latter clearly and unambiguously dominates over the former.
-franco
At 11:35 AM 10/18/2001, Robert Snively wrote:
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
>
>
Franco Travostino, Director Content Internetworking Lab
Advanced Technology Investments
Nortel Networks, Inc.
600 Technology Park
Billerica, MA 01821 USA
Tel: 978 288 7708 Fax: 978 288 4690
email: travos@nortelnetworks.com
Home
Last updated: Thu Oct 18 14:17:32 2001
7284 messages in chronological order
|