|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IPS-ALL: RE: Question on security document
- To: "Charles Monia" <cmonia@NishanSystems.com>, <ips@ece.cmu.edu>
- Subject: IPS-ALL: RE: Question on security document
- From: "Elizabeth Rodriguez" <egrodriguez@lucent.com>
- Date: Thu, 18 Oct 2001 23:47:55 -0400
- Cc: "Allison Mankin (E-mail)" <mankin@ISI.EDU>, "Scott Bradner (E-mail)" <sob@harvard.edu>, "David Black (E-mail)" <black_david@emc.com>
- Content-Class: urn:content-classes:message
- Content-Type: multipart/alternative;boundary="----_=_NextPart_001_01C15850.D61D187F"
- Disposition-Notification-To: "Elizabeth Rodriguez" <Elizabeth.Rodriguez@nc8220exch1.ral.lucent.com>
- Sender: owner-ips@ece.cmu.edu
- Thread-Index: AcFYNuie9xmqZbt7RBih1WKM/3IGZgAFz3hg
- Thread-Topic: Question on security document
Hello
all,
What
Bob Snively and Bill Strahm have stated on this email thread is true -- the
current tone of the security document is prescriptive -- making statements about
conformance and direction for the iSCSI, FCIP and iFCP documents. Per RFC
2026, an informational draft is for general information only, and does not
represent group consensus or recommendation. So, this does not quite fit
what the direction of this document is presently.
As
pointed out by Bob, the current language in the security draft may cause
confusion later, since if a draft (iSCSI, FCIP or iFCP) chooses to not follow a
directive of the security RFC, that would be proper, in that the security RFC
was informational only and cannot make requirements of the standards track
documents.
The
question remains on how to resolve the issue. There have been several
recommendations on this thread, most of which are possible directions that we
can take.
I am
unclear of what is the appropriate direction, and have asked the ADs
for guidance on this issue.
They
have agreed that this is an important issue, and hope to respond
quickly.
Thanks,
Elizabeth Rodriguez
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
|