Re: [magma] [Fwd: Additional comments on draft-ietf-magma-mgmd-mib-12.txt]

"Bert Wijnen \(IETF\)" <bertietf@bwijnen.net> Wed, 08 October 2008 14:20 UTC

Return-Path: <magma-bounces@ietf.org>
X-Original-To: magma-archive@megatron.ietf.org
Delivered-To: ietfarch-magma-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDC8A3A6AE7; Wed, 8 Oct 2008 07:20:37 -0700 (PDT)
X-Original-To: magma@core3.amsl.com
Delivered-To: magma@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4146A3A69AC for <magma@core3.amsl.com>; Fri, 3 Oct 2008 09:08:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUjlevE6Y24v for <magma@core3.amsl.com>; Fri, 3 Oct 2008 09:08:27 -0700 (PDT)
Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 6ADBF3A6820 for <magma@ietf.org>; Fri, 3 Oct 2008 09:08:26 -0700 (PDT)
Received: (qmail 46907 invoked from network); 3 Oct 2008 16:08:54 -0000
Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 3 Oct 2008 16:08:54 -0000
Message-ID: <DC0FFF5AD21B495995F59D562AB2C2A8@BertLaptop>
From: "Bert Wijnen (IETF)" <bertietf@bwijnen.net>
To: Julian Chesterfield <julian.chesterfield@eu.citrix.com>
References: <48D7CFCB.4030606@innovationslab.net> <48D8C2DD.7040002@eu.citrix.com>
In-Reply-To: <48D8C2DD.7040002@eu.citrix.com>
Date: Fri, 03 Oct 2008 17:39:21 +0200
Organization: Consultant
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6001.18000
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049
X-Mailman-Approved-At: Wed, 08 Oct 2008 07:20:37 -0700
Cc: magma@ietf.org
Subject: Re: [magma] [Fwd: Additional comments on draft-ietf-magma-mgmd-mib-12.txt]
X-BeenThere: magma@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:magma-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/magma>
List-Post: <mailto:magma@ietf.org>
List-Help: <mailto:magma-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:magma-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: magma-bounces@ietf.org
Errors-To: magma-bounces@ietf.org

I had already suggested to change

mgmdIgmpV1HostReadMIBCompliance MODULE-COMPLIANCE
    STATUS  current
    DESCRIPTION
            "A read-only compliance statement for hosts running IGMPv1
            [RFC 1112] and implementing the MGMD MIB. IGMPv1 hosts must
            support the IPv4 address type."
    MODULE  -- this module
    MANDATORY-GROUPS { mgmdHostBaseMIBGroup }
    GROUP mgmdHostOptMIBGroup
    DESCRIPTION
            "Write access is not required."
    ::= { mgmdMIBCompliance 1 }

into:

mgmdIgmpV1HostReadMIBCompliance MODULE-COMPLIANCE
    STATUS  current
    DESCRIPTION
            "A read-only compliance statement for hosts running IGMPv1
            [RFC 1112] and implementing the MGMD MIB. IGMPv1 hosts must
            support the IPv4 address type. In the index, this means
            for object mgmdHostInterfaceQuerierType

              OBJECT     mgmdHostInterfaceQuerierType
              SYNTAX     InetAddressType {ipv4(1)}
              MIN-ACCESS read-only
            "
    MODULE  -- this module
    MANDATORY-GROUPS { mgmdHostBaseMIBGroup }
    OBJECT mgmdHostInterfaceStatus
    SYNTAX RowStatus {active(1)}
    MIN-ACCESS read-only
    DESCRIPTION "read-write or read-create access is not required
                 and the only value that needs to be supported is
                 'active'"
    GROUP mgmdHostOptMIBGroup
    DESCRIPTION
            "Supporting this optional group can be especially useful
            in an environment with a router which does not support
            the MGMD MIB."
    ::= { mgmdMIBCompliance 1 }

I see that I shoudl have said:

mgmdIgmpV1HostReadMIBCompliance MODULE-COMPLIANCE
    STATUS  current
    DESCRIPTION
            "A read-only compliance statement for hosts running IGMPv1
            [RFC 1112] and implementing the MGMD MIB. IGMPv1 hosts must
            support the IPv4 address type. In the index, this means
            for object mgmdHostInterfaceQuerierType

              OBJECT     mgmdHostInterfaceQuerierType
              SYNTAX     InetAddressType {ipv4(1)}
            "
  ....

That object is an INDEX object (that is why I need to describe it in the 
DESCRIPTION
clause, and so MIN-ACCESS read-only is not relevant. In fact it is incorrect 
for an INDEX
object that has a MAX-ACCESS of not-accesible.
The remainder of my suggested text stays the same.

Bert

----- Original Message ----- 
From: "Julian Chesterfield" <julian.chesterfield@eu.citrix.com>
To: <bertietf@bwijnen.net>
Cc: "Brian Haberman" <brian@innovationslab.net>; <magma@ietf.org>
Sent: Tuesday, September 23, 2008 12:20 PM
Subject: Re: [Fwd: Additional comments on draft-ietf-magma-mgmd-mib-12.txt]


> Thanks Bert,
>
> Comments inline.
>
> Brian Haberman wrote:
>>
>>
>> I now happend to browse through the MIB module some more, and I am 
>> somewhat
>> suprised by the many MODULE-COMPLIANCE staments. But not only suprised. I
>> am also confused.
> The additional Module-compliance statements were added in response to a 
> request to split out the read-only/read-create access requirements for 
> both MLD and IGMP hosts, hence the somewhat large matrix of options.
>>
>> For example, I am  wondering how the following 2 statements differ. I can
>> see in
>> the DESCRIPTION clauses some differences, but none of that is
>> machine-readable.
>>
>>  mgmdIgmpV1HostReadMIBCompliance MODULE-COMPLIANCE
>>     STATUS  current
>>     DESCRIPTION
>>            "A read-only compliance statement for hosts running IGMPv1
>>            [RFC 1112] and implementing the MGMD MIB. IGMPv1 hosts must
>>            support the IPv4 address type."
>>     MODULE  -- this module
>>     MANDATORY-GROUPS { mgmdHostBaseMIBGroup }
>>     GROUP mgmdHostOptMIBGroup
>>     DESCRIPTION
>>            "Write access is not required."
>>     ::= { mgmdMIBCompliance 1 }
>>
>>  mgmdMldV1HostMIBCompliance MODULE-COMPLIANCE
>>     STATUS  current
>>     DESCRIPTION
>>            "A read-only compliance statement for hosts running MLDv1
>>            [RFC 2710] and implementing the MGMD MIB. MLDv1 hosts must
>>            support the IPv6 address type."
>>     MODULE  -- this module
>>     MANDATORY-GROUPS { mgmdHostBaseMIBGroup }
>>     GROUP    mgmdHostOptMIBGroup
>>     DESCRIPTION
>>            "Read-only access required."
>>     ::= { mgmdMIBCompliance 8 }
> The difference is the relevance to hosts utilising the IGMP vs MLD 
> protocol.
>>
>> But even worse, In the two OBJECT GROUPS that play a role here, I see:
>>
>>   mgmdHostBaseMIBGroup OBJECT-GROUP
>>      OBJECTS { mgmdHostInterfaceStatus }
>>      STATUS  current
>>      DESCRIPTION
>>            "The basic collection of objects providing management of
>>            MGMD version 1, 2 or 3 for hosts."
>>      ::= { mgmdMIBGroups 1 }
>>
>>  mgmdHostOptMIBGroup OBJECT-GROUP
>>     OBJECTS { mgmdHostCacheLastReporter, mgmdHostCacheUpTime,
>>                           mgmdHostInterfaceQuerier,
>> mgmdInverseHostCacheAddress }
>>     STATUS  current
>>     DESCRIPTION
>>            "A collection of optional read-only objects for MGMD hosts.
>>            Supporting this group can be especially useful in an
>>            environment with a router which does not support the MGMD
>>            MIB."
>>     ::= { mgmdMIBGroups 6 }
>>
>> First, in principle, you do not specify in the DESCRIPTION clasue of an
>> OBJECT-GROUP
>> if they are "optional or not". They are a GROUP, nothing more. If they 
>> are
>> mandatory
>> or optional, that is specified in the MODULE-COMPLIANCE. They could be
>> optional
>> in one MODULE-COMPLIANCE and MANDATORY in another.
>> I personally would even prefer the "Opt" is not part of the name of the
>> group.
> Ack. No objections.
>>
>> Second,   if they are MAX-ACCESS read-only in the OBJECT definition, then
>> that
>> is what it is. If they have MAX-ACCESS read-write or read-create on the
>> OBJECT
>> definition, then they could be read-only for a module-compliance, but 
>> again,
>> that
>> is specified in the MODULE-COMPLIANCE statement in the OBJECT clause
>> underneath a MANDATORY-GROUPS or GROUP clause in the MODULE-COMPLIANCE.
>> Again, they could be OK in read-only mode in one MODULE-COMPLIACNE and
>> read-write in another.
> Ack.
>>
>> Now... the object in the first group does have a read-create object. To 
>> make
>> a
>> read-only implementation compliant, you would do so by adding a OBJECT
>> clause
>> to the MODULE-COMPLIANCE, see below.
> Thx, the example below looks fine.
>>
>> My third problem is that it is not clear how you want this implemented. 
>> Does
>> it
>> mean that for this MODULE-COMPLIANCE you only have to have the
>> rowstatus object and none of the otehr objects in the table?
> That's correct.
>>
>> The objects in the 2nd group all happen to be read-only objects. So 
>> although
>> the
>> comment about them being read-only objects does not harm, I think I would
>> not
>> state so in the OBJECT-GROUP DESCRIPTION clause. But that is a NIT
>> And there is certainly not a need to state that "write access is not
>> required"
>> in the MODULE-COMPLIANCE. The objects have MAX-ACCESS of read-only. so 
>> !!!
> Good point.
>>
>> You speak about ipv4 or ipv6 support, and such can also be specified
>> in OBJECT clauses (so it become machine readable), see below.
>>
>> I wonder if
>>    mgmdIgmpV1HostReadMIBCompliance MODULE-COMPLIANCE
>>       STATUS  current
>>       DESCRIPTION
>>            "A read-only compliance statement for hosts running IGMPv1
>>            [RFC 1112] and implementing the MGMD MIB. IGMPv1 hosts must
>>            support the IPv4 address type."
>>
>> Means that only IPv4 needs to be supported, or that both IPv4 AND IPv6 
>> must
>> be
>> supported?
> It means that only IPv4 needs to be supported.
>> My understanding from that text would be "only IPv4".
>> You may  want to clarify that. If you look at my module-compliance
>> suggestion below, then you can see that that makes it much clearer
>> (I have stated it how I understood it).
>>
>> Same for
>>   mgmdMldV1HostMIBCompliance MODULE-COMPLIANCE
>>      STATUS  current
>>
>>      DESCRIPTION
>>            "A read-only compliance statement for hosts running MLDv1
>>            [RFC 2710] and implementing the MGMD MIB. MLDv1 hosts must
>>            support the IPv6 address type."
>>
>> Does that mean ONLY IPv6 or both IPv4 and IPv6?
> It means that either may be supported, but at least IPv6 must be 
> supported.
>>
>>
>> So to better document the module compliance, I would do something like:
>>
>> mgmdIgmpV1HostReadMIBCompliance MODULE-COMPLIANCE
>>    STATUS  current
>>    DESCRIPTION
>>            "A read-only compliance statement for hosts running IGMPv1
>>            [RFC 1112] and implementing the MGMD MIB. IGMPv1 hosts must
>>            support only the IPv4 address. In the index, this means
>>            for object mgmdHostInterfaceQuerierType
>>
>>              OBJECT     mgmdHostInterfaceQuerierType
>>              SYNTAX     InetAddressType {ipv4(1)}
>>            "
>>    MODULE  -- this module
>>    MANDATORY-GROUPS { mgmdHostBaseMIBGroup }
>>    OBJECT mgmdHostInterfaceStatus
>>    SYNTAX RowStatus {active(1)}
>>    MIN-ACCESS read-only
>>    DESCRIPTION "read-write or read-create access is not required
>>                 and only the value 'active(1)'  needs to be supported"
>>    GROUP mgmdHostOptMIBGroup
>>    DESCRIPTION
>>            "Supporting this optional group can be especially useful
>>            in an environment with a router which does not support
>>            the MGMD MIB."
>>    ::= { mgmdMIBCompliance 1 }
> This looks fine, thanks for the pointers.
>>
>> Before I go and try to do the other MODULE-COMPLIANCE statements
>> (or help with them),
> Please do, we're keen to get this finished up and everyone in agreement.
>
> Thanks,
> Julian
>
> 


_______________________________________________
magma mailing list
magma@ietf.org
https://www.ietf.org/mailman/listinfo/magma