A MIB Textual Convention for Language Tags
draft-mcwalter-langtag-mib-03

Moving to IESG Evaluation::Revised ID Needed to reflect the result of the telechat.  Hopefully we can get the Revised ID during IETF week so this can be approved then.

[Ballot discuss]
Last Call comments to address:

- Heard: title change

- Whitehead (& Dan's COMMENT): "This"

- Also consider Dan's comment about Juergen's MIB Dr. Review

[Ballot comment]
The document currently says:

          Only lowercase characters are allowed.  The purpose of this
            restriction is to provide unique language tags for use as
            indexes.  BCP 47 recommends case conventions for user
            interfaces, but objects using this textual convention MUST
            use only lowercase.

Mandating lower case is clearly a good idea here, but I believe
that this doesn't achieve the intended goal without also being
combined with canonicalization (see Section 4.7 of 4646).  That
is already a SHOULD-level requirment; would it make sense to
strengthen it to MUST for this use?

[Ballot comment]
1. Based on a LC comment from CE Whitehead, I suggest to replace in the DESCRIPTION clause of the LangTag TC 'This language tag' by 'The language tag described in this TC'.

2. I believe that the following comment from the MIB Doctor review of Juergen Schoenwaelder was not completly addressed:

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

Although now the text about RFC 2932 moved to Section 6, there is no text that warns the reader that some other documents may still use the LanguageTag TC defined in 2932.

IANA Last Call Comments:

Upon approval of this document, the IANA will assign a mib-2
number for LANGTAG-MIB in the Prefix: iso.org.dod.internet.mgmt.mib-2
(1.3.6.1.2.1) at the following location:

http://www.iana.org/assignments/smi-numbers

We understand this to be the only IANA Action for this document.

Juergen Schoenwaelder provided a MIB Dr. Review.  Let's consider the changes required during the IETF Last Call and submit a revised version for the IESG telechat.

Hi,

I have reviewed  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
  P.O. Box 750 561, 28725 Bremen, Germany