Subject: [ipcdn] quick review of draft-ietf-ipcdn-qos-mib-07.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 13 Feb 2003 16:59:42 +0100

I did a very quick check of:

http://www.ipcdn.org/drafts/draft-ietf-ipcdn-qos-mib-07.txt

- first para of sect 1 is redundant
- This is the first RFC-tobe. So we do not want to see
  longs list of REVISION clauses with pre-RFC changes
- IfDirection, probably betternamed DocsRFMacIfDirection
  it is not generic TC.
  In any event, it conflicts with IfDirection in RFC3289
  (which I guess should have had another name too).
- In general, I'd like your TCs to start with DocsXxxx
- We prefer interger-based INDEX objects to be Unsigned32
  (with a range that excludes zero)
- You seem to have used RFC2851 when understanding InetAddresType
  and InetAddress. Pls see the newer RFC3291, which also explains
  that you can use one AddressType to specify the type of
  multople Addresses. That will reduce the size of the mIB module
  somewhat I expect. The xxxMask objects probably should be
  InetAddressPrefixLength TC
- RFC3291 also has InetPort as a TC that you probably should use
- I am not happy with 
  diffServMultiFieldClfrProtocol OBJECT-TYPE
    SYNTAX         Unsigned32 (0..255)
  See RFC3289
   diffServMultiFieldClfrProtocol OBJECT-TYPE
    SYNTAX         Unsigned32 (0..255)
  And you will hopefully understand why
- When I see things like:
  docsQosPktClassState OBJECT-TYPE
    SYNTAX          INTEGER {
                      active(1),
                      inactive(2)
                    }
  I always wonder if a TruthValue is bot better
- Have you checked your use of VLANID with other MIB modules
  where they use it?
- docsQosParamSetServiceClassName OBJECT-TYPE
    SYNTAX          DisplayString
  Is this intended for human consumption? Then RFC2277 says it 
  must allow for internatioalization, so an SnmpAdminString or
  some other UTF-8 based TC seems better
- For Counter (both 32 or 64) you must specify a discontinuity
  object (often a timer). See the Counter32 and Counter64 specs
  in RFC2578
- docsQosServiceFlowTimeActive OBJECT-TYPE
    SYNTAX          Counter32
    UNITS           "seconds"
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "The total time that service flow has been active."
  I would say' "The number of seconds that the flow has been active."  
  That way I can see it has Counter32 semantics, otherwise that is hard
  to see.

- docsQosServiceClassTable 
  Can you pls add a StorageType object or specify the persistency
  behaviour of entries in this table?

-       OBJECT  docsQosPktClassInetSourceAddrType
        -- SYNTAX InetAddressType { ipv4(1) }
  Remove the two dashed. This is a valid statement. SMICng
  needs fixing      

As I said... it was just a quick check. So I do not claim
my comments are complete. I also di not do a SYNATX compile check
yet.

Thanks,
Bert 
_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 13 Feb 2003 19:07:36 +0100

>     SYNTAX         Unsigned32 (0..255)
Oops. I meant to say:
    docsQosPktClassIpProtocol OBJECT-TYPE
      SYNTAX          Integer32 (0..258)
> see RFC3289 which says

Bert

---

From: "Eduardo Cardona" <[email-masked]>
Date: Thu, 13 Feb 2003 11:17:38 -0700

FYI 
Could be in other places but a starting point. 

draft-ietf-bridge-bridgemib-01.txt

VlanId ::= TEXTUAL-CONVENTION
       STATUS      current
       DESCRIPTION
           "The 12-bit VLAN ID used in the VLAN Tag header."
       SYNTAX      INTEGER (1..4094)

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent: Thursday, February 13, 2003 9:00 AM
To: Ipcdn (E-mail)
Subject: [ipcdn] quick review of draft-ietf-ipcdn-qos-mib-07.txt

As I said... it was just a quick check. So I do not claim
my comments are complete. I also di not do a SYNATX compile check yet.

Thanks,
Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 13 Feb 2003 19:44:21 +0100

>            "The 12-bit VLAN ID used in the VLAN Tag header."
And so... why does yours differ
docsQosPktClassVlanId OBJECT-TYPE
    SYNTAX          Integer32 (0..4095)
    MAX-ACCESS      read-only
    STATUS          current

I am not claiming that one is better than the other.
But I always wonder why they are different.
Best to try and get in touch with the bridgemib people

Bert

---

From: "Greg White" <[email-masked]>
Date: Thu, 13 Feb 2003 12:06:45 -0700

It is important that the range for docsQosPktClassVlanId include the
value 0:

                    If the referenced parameter is not present in the
                    classifier, the value of this object is reported
                    as 0.

-Greg

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent: Thursday, February 13, 2003 11:44 AM
To: Eduardo Cardona; Wijnen, Bert (Bert); Ipcdn (E-mail)
Subject: RE: [ipcdn] quick review of draft-ietf-ipcdn-qos-mib-07.txt

Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 13 Feb 2003 21:36:33 +0100

Inline
> From: Greg White [mailto:[email-masked]]
> Sent: donderdag 13 februari 2003 20:07
> To: Wijnen, Bert (Bert); Eduardo Cardona; Ipcdn (E-mail)
Well, yours also goes up to (and inclusive) 4095 while
bridgemib only goes up to (and inclusive 4094).

If zero is not a valid VLAN ID and you want to niclude it as
not present, then maybe yours should be renamed to
  docsQosPktClassVlanIdOrNone
or some such

Bert