Ftp-WG: Re: draft-ietf-ftpext-mlst (fwd)

    Date:        Wed, 17 Jul 2002 16:44:01 +0900
    From:        Patrik Fältström <[email protected]>
    Message-ID:  <2276674.1026924241@localhost>

  | Finally I manage to get all information from IESG members _and_ time to
  | summaarize them.

OK, thanks, and I will just ignore the old repeated comments as
requested in your later message.   Please forward this to whatever
other parts of the IESG are relevant.

  | (A) 
  | 
  | Section 3 talks about comparing the server's file modification time to the
  | client's. But 2.3 says that the times aren't synchronized.
  | 
  | I asked what the issue was and got the following dialogue:
  | 
  | >> The key sentence is in 2.3 before the one talking about time not being
  | >> synchronized:
  | >> 
  | >>     A server-FTP process should always use the same
  | >>     time reference, so the times it returns will be consistent.
  | > 
  | > Right.  But it's easy to read "file modification time" as "local file 
  | > modification time".  I think the document should suggest asking for the 
  | > modification time before a transfer, so that that can be compared with
  | > the modification time retrieved before a restart.

OK, that seems simple enough, if no-one objects, I can do that
(text that will be included will appear soon).

  | >> 
  | >>> Servers should ensure that the unique identifier fact is not security 
  | >>> sensitive, e.g., it should not be the NFS handle for the file.
  | >> 
  | >> Is this something you want to the Security Considerations Section?
  | >> 
  | > It probably should be there.

Yes, that's reasonable too, will add text about that, again assuming no
WG objection (take that caveat as a given in all below).

  | (B)
  | 
  | Should this doc say that it updates STD 9, see sec 8?

I have previously been told that I-D's aren't supposed to claim to
update RFCs (and particularly standards).   When this is published
then yes, it will say exactly that - though whether it counts as an
"Updates" or a "See Also" seems to depend upon what the rfc editor
had for breakfast that day...   See rfc2389, which has "See Also"
for what I would have considered (and earlier considered) an "Updates".

In any case, something about this will appear in the RFC.   If the IESG
want I can add it to the I-D as well.

  | (J)
  | 
  | 7 says that all 256 octet values are permitted. Must telnet NVT characters
  | be escaped here? Or, should it be said that all 256 octet values are
  | allowed after NVT processing? Clarify.

NVT processing is always done on the control connection in FTP.
That's not news is it?  So, all 256 after NVT processing, obviously.
Section 2.2 already indicates that NVT applies, and that IAC needs
to be escaped.   Does it really need to be repeated in section 7?

  | (K)
  | 
  | Servers should ensure that the unique identifier fact is not security
  | sensitive, e.g., it should not be the NFS handle for the file.
  | 
  | This can be handled by explicit sentence in Security Consideration Section.

This is a repeat of the 2nd half of (A) above.  Will fix.

kre