Subject: RE: [Isms] my review of: draft-ietf-isms-secshell-08.txt

From: "David Harrington" <[email-masked]>
Date: Thu, 8 Nov 2007 16:48:08 -0500

> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Tuesday, September 11, 2007 3:43 AM
> To: Wijnen, Bert (Bert)
> Cc: David Harrington; [email-masked]; [email-masked]
> Subject: Re: [Isms] my review of: draft-ietf-isms-secshell-08.txt
> 
> On Thu, Aug 09, 2007 at 12:17:13PM +0200, Wijnen, Bert (Bert) wrote:
> > 
> > Some of these are NITs, I know that.
> > 
> > - I think the abstract should also mention that there is a 
> MIB module
> >   defined in this document.
> > 
> > - I think the last para of sect 1.2 can/should be removed, 
> or at least
> > the
> >   RFC-Editor should be instructed to do so.
> 
> editorial

done.

>  
> > - Sect 1.4
> > 
> >       The work will address ...
> > 
> >       The work will include ...
> > 
> >   Maybe better: This document addresses ...
> >                 This document includes/defines ...
> 
> editorial

done.
> 
> > - sect 5.1 and 5.1
> >   I assume that SSH_MSG_USERAUTH_REQUEST and SSH_MSG_CHANNEL_DATA
> >   are specified somewhere in the SSH RFC(s)? Maybe a citation to
> >   such RFC(s) is useful at these points.
> 
> there were suggestions in the discussion to actually be less precise
> concerning SNMP messages and this seems to solve this issue

removed references to CHANNEL_DATA. 
I tried to make it clear that how one gets username from the SSH
environment is implementation-dependent.

> 
> > - top of page 15:
> >       45 Extract any implementation-specific parameters from the
LCD
> >       6) Pass the wholeMessage to SSH for encapsulation in an
> >       SSH_MSG_CHANNEL_DATA message.
> > 
> >   what is "45"? Should that be "5)"
> >   But the whole first sentence seems to not belong here?
> 
> editorial

It should be 5).

bullet 4 is conditional; bullet 5 is not. It belongs here so info is
extracted from the LCD whether bullet 4 is triggered or not.
Implementatins are free to optimize this.

> 
> > - Should we root this MIB module under snmpModules? 

rooted under mib-2

> >   see my arguments in my review of the MIB module in
> >   draft-ietf-isms-transport-security-model-05.txt
> > 
> >   If we do keep it under snmpModules, then 
> >     sshtmMIB MODULE-IDENTITY
> >   possibly would be better
> >     snmpSshtmMIB MODULE-IDENTITY
> >   to be consistent with the other MIB modules under snmpModules.
> >
> > - Copyright in MIB module should be IETF Trust, not ISOC

fixeed.

> > 
> > - I see:
> >   sshtmGroups OBJECT IDENTIFIER ::= { sshtmConformance 1 }
> >   sshtmCompliances OBJECT IDENTIFIER ::= { sshtmConformance 2 }
> > 
> >   while RFC4181 suggests:
> > 
> >      xxxMIB
> >      |
> >      +-- xxxNotifications(0)
> >      +-- xxxObjects(1)
> >      +-- xxxConformance(2)
> >          |
> >          +-- xxxCompliances(1)
> >          +-- xxxGroups(2)
> > 
> >   i.e. first compliances, then groups.
> 
> This needs to be dealt with according the resolution we achieve for
> the TMS document.

fixed. consistently.

>  
> > - For SnmpSSHAddress ::= TEXTUAL-CONVENTION I read:
> > 
> >         "Represents either a hostname encoded in ASCII
> >         using the IDNA protocol, as specified in RFC3490, 
> followed by
> >         a colon ':' (ASCII character 0x3A) and a decimal port
number
> >         in ASCII, or an IP address followed by a colon ':'
> >         (ASCII character 0x3A) and a decimal port number in ASCII.
> >          The name SHOULD be fully qualified whenever possible.
> > 
> >   I am not well versed/experienced in IDNA. But is IDNA a
protocol?
> >   The title of 3490 reads
> >       Internationalizing Domain Names in Applications (IDNA)
> >   And are we indeed speaking of a hostname, or of a domain name,
or
> >   of both? I can't quickly determine that. So I wonder if/hope
that
> >   we can be clearer here.
> 
> Seems to have been resolved in the discussion.

text will hopefully respresent conensus.

> 
> >   I also assume (although this is not explicitly stated) that if
we
> >   speak about an IP address, that it is a dotted decimal for
> >   IPv4 and and a colon separated IPv6 address in ASCII? Yes/no?
> > 
> >   I am concerned that for 
> >      SnmpUDPAddress ::= TEXTUAL-CONVENTION
> >          DISPLAY-HINT "1d.1d.1d.1d/2d"
> >   we use a / sign to separate the port from the IPv4 address
> >   and here we use a colon (:).
> >   I must admit that (RFC3419) also uses :
> >       TransportAddressIPv4 ::= TEXTUAL-CONVENTION
> >           DISPLAY-HINT "1d.1d.1d.1d:2d"
> > 
> >   And what do we use for IPv6 addresses/ports?
> 
> The SnmpUDPAddress notation goes back to the old days where a common
> notation for transport endpoints did not exist yet. Nowadays, it is
> common to read a.b.c.d/e as a prefix and a.b.c.d:e as an IPv4
> transport endpoint and [::]:e as an IPv6 transport endpoint. There
is
> an RFC specifying this IPv6 notion and we might just refer to it; I
> think the latest document is RFC 3986 which obsoletes RFC 2732. Note
> that also RFC 3419 uses the now more common notation and breaks with
> the old SnmpUDPAddress notation.

fixed. included a REFERENCE clause for RFC3986

> 
> >   Further I read:
> > 
> >          When this textual convention is used as a syntax of an
> >          index object, there may be issues with the limit of 128
> >          sub-identifiers specified in SMIv2, STD 58. In this case,
> >          the OBJECT-TYPE declaration MUST include a 'SIZE' clause
> >          to limit the number of potential instance
sub-identifiers."
> > 
> >   Mmm.. we do not normally enforce (i.e. MUST language) that a
SIZE
> >   clause must be used. We allo the DESCIRPTION clause to explain
> >   that implementers must be aware and cater for OID limitations.
> >   So do we really want that MUST language here?
> 
> I think this text was copied from RFC 3419 which actually has MUST
> language. RFC 4181 only RECOMMENDS to MIB documents are explicit by
> either including SIZE constraints or specifying things in the row
> DESCRIPTION clause. Since RFC 4181 is newer than RFC 3419, I suggest
> that we adopt RFC 4181 language here.

fixed.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> 

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms