Subject: Re: [Isms] barely a review: secshell-08

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Sep 2007 10:24:59 +0200

On Fri, Aug 10, 2007 at 10:24:38PM -0700, Wes Hardaker wrote:
> 
> I didn't get as far into it as I had hoped, but I do support the
> document based on what I've read so far and think it's important work.
> 
> misc points:
> 
> introduction:
>   Secure Shell Protocol => Secure Shell Protocol (SSH) [RFC4251?]

editorial
 
> 1.2:
>   acting as either manager or agent or both =>
>   acting in either manager or agent or both roles
> 
>   SNMP applications included in the engine =>
>   SNMP application types being implemented
> 
>        (the SNMP applications don't sit in the engine, so the original
>        wording doesn't meet the SNMP architecture).
> 
>   USM => User-Based Security Model (USM) [RFC3414]
> 
>   delete the last paragraph (todo markings)

editorial
 
> 1.3:
>   design decision*s* => design decision
> 
>   These MIB objects SHOULD NOT be referenced in other documents
> 
>      That one kind of bothers me.  Generally in the IETF, we encourage
>      cross-reuse among MIB modules and here you're specifically saying
>      pretend this one doesn't exist if you're working on something else.
>      I'm not really fond of that notion.  I do understand the rational
>      for wanting to do it, but I don't think you gain anything in the
>      end and you certainly loose the ability to do some possible future
>      reuse.

I think this can be solved by simply deleting all text except the
first sentence:

   In keeping with the RFC 3411 design decisions to use self-contained
   documents, this memo includes the elements of procedure plus
   associated MIB objects which are needed for processing the Secure
   Shell Transport Model for SNMP.

The rest of the paragraph is trying to explain the motivation for the
RFC 3411 design decision but it may not really be needed to repeat
this in every SNMP document since section 1.5 of RFC 3411 explains
this well enough.

> 1.4:
>   USM typically utilizes => USM utilizes
> 
>   not deploying SNMPv3 at this point in time =>
>   not deploying SNMPv3
> 
>   to minimize the time until deployment is possible =>
>   to minimize deployment time
> 
>   4th paragarph, 1st sentence: does the work properly allow for future
>   SSH extensions to add authentication capabilities (I believe it is
>   supposed to).  If so, that should probably be noted in this sentence.

editorial

/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: "David Harrington" <[email-masked]>
Date: Thu, 27 Sep 2007 13:13:51 -0400

> -----Original Message-----
> From: Wes Hardaker [mailto:[email-masked]] 
> Sent: Saturday, August 11, 2007 1:25 AM
> To: [email-masked]
> Subject: [Isms] barely a review: secshell-08
> 

>      That one kind of bothers me.  

Is this better:
                     In keeping with the RFC 3411 design decision 
                     to use self-contained documents, this document 
                     defines the elements of procedure and associated 
                     MIB module objects needed for processing the 
                     Secure Shell Transport Model for SNMP. The MIB 
                     objects defined in this document SHOULD NOT be 
                     modified except by the elements of procedure 
                     defined in this document. This allows the Secure 
                     Shell Transport Model for SNMP to be designed and

                     documented as independent and self-contained, 
                     having no direct impact on other modules, and 
                     this allows this module to be upgraded and 
                     supplemented as the need arises, and to move 
                     along the standards track on different time-lines

                     from other modules.

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

---

From: "David Harrington" <[email-masked]>
Date: Thu, 27 Sep 2007 13:32:07 -0400

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Tuesday, September 11, 2007 4:25 AM
> To: Wes Hardaker
> Cc: [email-masked]
> Subject: Re: [Isms] barely a review: secshell-08
> 

I agree the sentence in the "modularity" Introduction can be
shortened. But the same paragraph in the MIB module itself tries to
constrain future implementers from violating the modularity of this
MIB module, and they may get the MIB module stripped of the
surrounding text.

I'm not quite satisfied with the wordings either. This particular MIB
module has no writable objects, so at least we are not saying that a
manager application should not change any values, but we are more or
less constraining implementations, and I'm not sure we want to do that
either. I guess the constraint is really for future protocol designs.

So I guess we should simply remove the paragraph from the MIB module,
and leave the first sentence only in the introduction. Does that sound
reasonable?