|
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Question on security document
Hi
Folks:
I hope
we do not delay closure on the technical content in order to correct what seem
to be editorial issues.
Charles
Franco,
The
problem is that the format of the document does not differentiate
between
the
tutorial information and the language that is to go into the Standard
RFCs.
I
would expect that we should have a formal clause for each document
saying
something to the effect:
"and
because of the knowledge carried in the above tutorial, the [FCIP, iSCSI,
iFCP]
document should contain the following text to
properly describe the expected
behavior. For the actual standard requirements,
see [FCIP, iSCSI, iFCP]."
This
clearly separates the result of the discussion (text to be shoved into
a
Standard RFC which has no authority in this document,
but will have authority when it is
shoved into the Standard RFC, perhaps with editorial
or technical modifications)
and
the tutorial discussion itself (which explains
without any capitalized requirements why it is nice
to do each of the things
proposed in the text to be included in the Standard
RFC).
Bob
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: Fri Oct 19 12:17:37 2001
7297 messages in chronological order
|
