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

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Sep 2007 09:43:06 +0200

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
 
> - Sect 1.4
> 
>       The work will address ...
> 
>       The work will include ...
> 
>   Maybe better: This document addresses ...
>                 This document includes/defines ...

editorial

> - 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

> - 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

> - Should we root this MIB module under snmpModules? 
>   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
> 
> - 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.
 
> - 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.

>   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.

>   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.

/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

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Tue, 11 Sep 2007 10:54:33 +0200

I am OK with suggested resolutions.

Bert Wijnen  

> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Tuesday, September 11, 2007 9: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
> 
> there were suggestions in the discussion to actually be less 
> precise concerning SNMP messages and this seems to solve this issue
> 
> > - top of page 15:
> This needs to be dealt with according the resolution we 
> achieve for the TMS document.
>  
> 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 
> 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.
> 
> /js
> 
> --

---

From: "David Harrington" <[email-masked]>
Date: Thu, 27 Sep 2007 12:48:40 -0400

> From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
> 
>   Further I read:
> 

I changed this paragraph to say (copying from RFC4181):

         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. It is 
         RECOMMENDED that all MIB documents using this textual 
         convention make explicit any limitations on index
         component lengths that management software must observe.  
         This may be done either by including SIZE constraints on 
         the index components or by specifying applicable 
         constraints in the conceptual row DESCRIPTION clause or 
         in the surrounding documentation.

David Harrington
[email-masked]
[email-masked]

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Thu, 27 Sep 2007 23:06:43 +0200

Thanks. That addresses my concern

Bert Wijnen  

> From: David Harrington [mailto:[email-masked]] 
> Sent: Thursday, September 27, 2007 6:49 PM
> To: Wijnen, Bert (Bert); [email-masked]
> Cc: [email-masked]
> Subject: RE: my review of: draft-ietf-isms-secshell-08.txt
> 
>  
>