SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [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
    -----Original Message-----
    From: Charles Monia [mailto:cmonia@NishanSystems.com]
    Sent: Thursday, October 18, 2001 7:22 PM
    To: ips@ece.cmu.edu
    Subject: 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 
    -----Original Message-----
    From: Robert Snively [mailto:rsnively@Brocade.COM]
    Sent: Thursday, October 18, 2001 4:08 PM
    To: 'Franco Travostino'
    Cc: ips@ece.cmu.edu
    Subject: RE: Question on security document

    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
    -----Original Message-----
    From: Franco Travostino [mailto:travos@nortelnetworks.com]
    Sent: Thursday, October 18, 2001 10:06 AM
    To: Robert Snively; 'Paul Koning'; cmonia@NishanSystems.com
    Cc: ips@ece.cmu.edu
    Subject: 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: Fri Oct 19 12:17:37 2001
7297 messages in chronological order