Subject: [MIB-DOCTORS] review of draft-mcwalter-langtag-mib-01.txt

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 8 Feb 2007 17:30:06 +0100

Hi,

I have reviewed <draft-mcwalter-langtag-mib-01.txt> following RFC 4181
and here are my comments:

a) Boilerplate is OK and idnits 1.122 pass fine. The MIB modules
   compiles fine with smilint 0.4.1.

b) The abstract contains a reference, which is not allowed according
   to the guidelines.

c) The introduction says that this module was written because RFC 2932
   is being obsoleted, but it does not give further guidelines whether
   other modules should be updated or whether there is a forward path.

   I note that the LanguageTag in RFC 2932 is 100 octets long while
   the new LanguageTag is 60 octets - so an update (in general not
   legal) is technically not possible. Furthermore, MIB modules may
   end up using different TCs with different sizes. This might
   practically not be an issue - but since the document talks about
   obsoleting IPMROUTE-STD-MIB, I would have expected some more
   discussion about this. Note that RFC 2932 LanguageTag is used by
   the MALLOC-MIB (RFC 3559) (and it is subtyped to 94 octets there,
   probably because it is used in an INDEX).

d) Section 4 talks about "several" TCs but there is only one.

e) It is not really clear whether the RFC note (section 6) is supposed
   to stay are whether the RFC editor should remove it before
   publication.

f) Some RFC references list in addition an ID name as work in progress
   and an additional status; both I think should be removed. I am
   talking about [RFC4646], [RFC3414], [RFC 3415]

g) RFC 4181 suggest a MIB name like LANGTAG-TC-MIB in appendix C but I
   leave it to the author to pick up this suggestion or not. (I just
   wanted to mention it.)

/js

-- 
Juergen Schoenwaelder		 Jacobs University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mib-doctors

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Fri, 9 Feb 2007 16:48:15 +0100

I did a very quick scan.
I see

langTagMIB MODULE-IDENTITY
    LAST-UPDATED "200611210000Z" -- 21 November 2006
    ORGANIZATION "IETF Operations and Management Area"
    CONTACT-INFO "EMail: [email-masked]"
    DESCRIPTION

            "This MIB module defines a textual conventions for
            representing BCP 47 language tags."
    REVISION     "200611210000Z" -- 21 November 2006
    DESCRIPTION
           "Initial revision, published as RFC yyyy.

            Copyright (C) The IETF Trust (2006).  The initial version of
            this MIB module was published in RFC yyyy; for full legal
            notices see the RFC itself.  Supplementary information may
            be available at:
            http://www.ietf.org/copyrights/ianamib.html."

IF this is an IANA maintained MIB module, then I would advise to name
it IANA-LANGTAG-TC-MIB and ianaLangTagTcMIB.

But I think it is not an IANA maintained MIB module, and so I think that
the text about ianamib copyright stuff should be removed.

I also wonder if a length of zero means something or not?
I.e. what is a zero-length OCTCT string in terms of a LangTag?

Further, the DESCRIPTION clause states:

            Values MUST be well-formed language tags, in conformance
            with the definition of well-formed tags in BCP 47.  An
            implementation MAY further limit the values it accepts to
            those permitted by a 'validating' processor, as defined in
            BCP 47.

What is "an implementation" of a TC?
I guess that if the TC is used in another MIB module that the
DESCRUPTION clause of an object that uses this TC for its SYNTAX,
that such DESCRIPTION clause may limit it?

I think that    [I-D.ietf-mboned-ip-mcast-mib] should NOT be a
reference/citation
at all. Certainly not in the final RFC. The dependency of that mcast-mib
on this document MUST/SHOULD be documented with a normative ref in the
mcast-mib document to this ID. but not from here to there.
I think this means that the complete section 6 can be removed (at least
in the resulting RFC).

Item c in Juergens review is important.
I think it is incorrect to use the same name for this TC while changing
the
SIZE (1..100) into SIZE (0..60)

W.r.t. the Security Considerations section, I am niot saying that what
it 
states is invalid or incorrect. But I doubt that this is very relevant
to
a TC MIB module. I would replace the whole section with:

   This MIB module does not define any management objects.  Instead, it
   defines a textual convention that may be imported by other MIB
   modules and used for object definitions.

   Meaningful security considerations can only be written in the MIB
   modules that define management objects.  This document has therefore
   no impact on the security of the Internet.

The refences to RFC3414 and RFC3415 can then be removed.

Bert 

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> Sent: donderdag 8 februari 2007 17:30
> To: Dan Romascanu; [email-masked]
> Cc: [email-masked]
> Subject: [MIB-DOCTORS] review of draft-mcwalter-langtag-mib-01.txt
> 
> Hi,
> 
> I have reviewed <draft-mcwalter-langtag-mib-01.txt> following 
> RFC 4181 and here are my comments:
>