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

[Charles Monia <cmonia@NishanSystems.com>]

Hi:

Please see responses embedded below.

Charles
> -----Original Message-----
> From: Thomas Narten [mailto:narten@us.ibm.com]
> Sent: Friday, August 08, 2003 4:42 AM
> To: cmonia@nishansystems.com; jtseng@nishansystems.com;
> kgibbons@nishansystems.com
> Cc: dhcwg@ietf.org; '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 <zinin@psg.com> 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" <smb@research.att.com> 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
enabled.

> > 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
email: cmonia@nishansystems.com
voice: (408) 519-3986
fax:   (408) 435-8385