[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Response to IESG comments on draft-ietf-dhc-isnsoption-08.txt

    Please see responses embedded below.
    > -----Original Message-----
    > From: Thomas Narten []
    > Sent: Friday, August 08, 2003 4:42 AM
    > To:;;
    > Cc:; 'David Black'; Elizabeth G. Rodriguez; Allison
    > Mankin
    > Subject: IESG comments on draft-ietf-dhc-isnsoption-08.txt
    > [apologies for the earlier truncated note]
    > Hi.
    > The IESG discussed this document yesterday, and the following comments
    > came up.
    > Alex Zinin <> writes:
    > > [iSNS] is listed as non-normative. How's that possible if 
    > the opinion
    > > is supposedly specific for iSNS and doesn't make sense 
    > outside of iSNS
    > > context, i.e., iSNS needs to exist for the option to make sense.
    We will change the spec as noted in the comment.
    > "Steven M. Bellovin" <> writes:
    > Is 3118 mandatory-to-implement or not?  I have a hard time 
    > understanding why it should be optional.
    We will revise the spec to make implementation of RFC 3118 mandatory.
    > What are the semantics if both "Main Mode" and "Aggressive Mode" have 
    > the same value?  "Transport Mode" and "Tunnel Mode"?  If IKE/IPsec is 
    > disabled, what security should be used?  Any?  None?
    The following text is proposed for insertion at the end of section 2.4:
    "If IKE/IPSec is disabled, this indicates that the Internet Key Exchange
    (IKE) Protocol is not available to configure IPSec keys for iSNS sessions to
    this iSNS server.  It does not necessarily preclude other key exchange
    methods (e.g., manual keying) from establishing an IPSec security
    association for the iSNS session."
    If IKE/IPsec is enabled, only one of Main Mode or Aggressive Mode SHALL be
    enabled.  Similarly, only one of Transport Mode or Tunnel Mode SHALL be
    > > The IANA Considerations section is inadequate.  First, it 
    > should state 
    > > what registry the option code should be taken from.  
    > Second, it should 
    > > state what what procedure (per 2434) should be used to assign new 
    > > values to the assorted bit fields in this option.
    The following replacement text is proposed for this section:
    "IANA is requested to assign a number for this option is accordance with the
    policy defined in [DHCP].
    "New values for other numeric and bit fields in this document SHALL only be
    defined in an RFC which supercedes this specification."
    -- Charles
    Charles Monia
    Senior Technology Consultant
    Nishan Systems
    voice: (408) 519-3986
    fax:   (408) 435-8385


Last updated: Mon Sep 08 18:19:48 2003
12870 messages in chronological order