Re: [MIB-DOCTORS] On this week IESG telechat. : Early MIB doctor review of draft-ietf-softwire-mesh-mib-04 and draft-ietf-softwire-dslite-mib

[Dave Thaler <[e-mail]>]

Good point, and indeed in my MIB doctor review of -04, I see that I had annotated that proposed assignment with a
“TODO: check this”

I believe it was intended to be the case (per the original ifmib WG) that “transmission xxx” means “xxx” is an ifType value.
Keith McCloghrie would be able to say for sure, but that’s my recollection.

For tunnels (of which this is one), RFC 4087 uses “transmission 131” because the ifType is 131.
It then defines tunnel subtypes as a separate numbering space, and does not specify where in the OID
hierarchy tunnel subtype MIBs should go.


From http://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib the current set of subtype values is:
    SYNTAX     INTEGER {
                   other(1),        -- none of the following
                   direct(2),       -- no intermediate header
                   gre(3),          -- GRE encapsulation
                   minimal(4),      -- Minimal encapsulation
                   l2tp(5),         -- L2TP encapsulation
                   pptp(6),         -- PPTP encapsulation
                   l2f(7),          -- L2F encapsulation
                   udp(8),          -- UDP encapsulation
                   atmp(9),         -- ATMP encapsulation
                   msdp(10),        -- MSDP encapsulation
                   sixToFour(11),   -- 6to4 encapsulation
                   sixOverFour(12), -- 6over4 encapsulation
                   isatap(13),      -- ISATAP encapsulation
                   teredo(14),      -- Teredo encapsulation
                   ipHttps(15)      -- IPHTTPS
               }

Checking some other docs, since each subtype need not have its own MIB, only a few do:

Protocol               Subtype                               MIB OID                               MIB Reference
L2TP                       l2tp(5)                   ::= { transmission 95 }     [RFC3371]
MSDP                    msdp(10)             ::= { experimental 92 }   [RFC4624]

Note that IANA ifType for 95 is
                  radsl(95),          -- Rate-Adapt. Digital Subscriber Loop
which is NOT L2TP, so the L2TP assignment is an anomaly.

So I would say it should probably not go under transmission, since it is not asking for an ifType value.
What RFC 4181 actually says is:

   - The value assigned to the MODULE-IDENTITY descriptor MUST be unique
     and (for IETF standards-track MIB modules) SHOULD reside under the
     mgmt subtree [RFC2578<http://tools.ietf.org/html/rfc2578>].  Most often it will be an IANA-assigned
     value directly under mib-2 [RFC2578<http://tools.ietf.org/html/rfc2578>], although for media-specific
     MIB modules that extend the IF-MIB [RFC2863<http://tools.ietf.org/html/rfc2863>] it is customary to use
     an IANA-assigned value under transmission [RFC2578<http://tools.ietf.org/html/rfc2578>].  In the past,
     some IETF working groups have made their own assignments from
     subtrees delegated to them by IANA, but that practice has proven
     problematic and is NOT RECOMMENDED.

The key phrase is “that extend the IF-MIB”.   This MIB does not, it extends the IP Tunnel MIB.
(The IP Tunnel MIB extends the IF-MIB and so the IF Tunnel MIB does use transmission.)

So it would not be illegal to use transmission, since it is about transmission and does indirectly
(via IP Tunnel MIB) extend IF-MIB, but not directly and does not need an ifType value.

Dave

From: Romascanu, Dan (Dan) [mailto:[e-mail]]
Sent: Monday, November 30, 2015 7:46 AM
To: Benoit Claise <[e-mail]>; Dave Thaler <[e-mail]>
Cc: MIB Doctors (E-mail) <[e-mail]>; Spencer Dawkins <[e-mail]>
Subject: RE: [MIB-DOCTORS] On this week IESG telechat. : Early MIB doctor review of draft-ietf-softwire-mesh-mib-04 and draft-ietf-softwire-dslite-mib

These two documents also came on my plate at the request of IANA. The reason for locating these under the transmission subtree is not clear. RFC 4181 requires to do this for media-specific MIB modules – is softwire considered ‘media-specific’ work?

Regards,

Dan


From: MIB-DOCTORS [mailto:[e-mail]] On Behalf Of Benoit Claise
Sent: Monday, November 30, 2015 5:35 PM
To: Dave Thaler
Cc: MIB Doctors (E-mail); Spencer Dawkins
Subject: [MIB-DOCTORS] On this week IESG telechat. : Early MIB doctor review of draft-ietf-softwire-mesh-mib-04 and draft-ietf-softwire-dslite-mib

Hi Dave,

Those two MIB modules are on the telechat this week, and I would like to get your green light.
Please let us know.

Regards, Benoit
Hi Dave,

We are now at version 7 and 6, respectively.
Are you happy with the MIB modules now?
And may I flag this one as done at http://trac.tools.ietf.org/area/ops/trac/wiki/mib-doctors-review-history<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2furldefense.proofpoint.com%2fv2%2furl%3fu%3dhttp-3A__trac.tools.ietf.org_area_ops_trac_wiki_mib-2Ddoctors-2Dreview-2Dhistory%26d%3dBQMDaQ%26c%3dBFpWQw8bsuKpl1SgiZH64Q%26r%3dI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA%26m%3dEmyVUD_iyiDij_d-DdLNVFK2XWSeKZ1aF6FTt-D5224%26s%3dpT3kgKSva5ALjadCooEr-iafVt-72eDM0plEFfsnCN8%26e%3d&data=01%7c01%7cdthaler%40microsoft.com%7c5c2e1408e814474cd23e08d2f99d7591%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=f4WZJqbumHm1ZGnM48tgMSuP4tA2VLbcUBfydJoJVP4%3d>

Regards, Benoit

Benoit asked me to do an early MIB doctor review of this document.  My

full comments are in the marked up copy at

http://research.microsoft.com/~dthaler/draft-ietf-softwire-mesh-mib-04.pdf<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2furldefense.proofpoint.com%2fv2%2furl%3fu%3dhttp-3A__research.microsoft.com_-257Edthaler_draft-2Dietf-2Dsoftwire-2Dmesh-2Dmib-2D04.pdf%26d%3dBQMDaQ%26c%3dBFpWQw8bsuKpl1SgiZH64Q%26r%3dI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA%26m%3dEmyVUD_iyiDij_d-DdLNVFK2XWSeKZ1aF6FTt-D5224%26s%3dHo63Okm-fo9bjIZHdCzzwvZRa87Ac4z9r3_vn7Sy8-s%26e%3d&data=01%7c01%7cdthaler%40microsoft.com%7c5c2e1408e814474cd23e08d2f99d7591%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6ttADpfOT8BqneSYvSroaDY4faoSF7SiQjpdX6aB2mE%3d>

(there’s also a .docx version if you replace the .pdf extension with .docx)



The doc is in a much better state than draft-ietf-softwire-dslite-mib is, and

so this was fairly easy to review (and my thanks to the authors for that).

Nevertheless, I did find a few issues, a short summary of which is:

1)      It does not yet meet all the requirements for MIBs in RFC 4181, mostly around

missing boilerplate

2)      The security considerations section needs (per RFC 4181) a brief discussion of

what objects, if any, might be considered sensitive.  For example, one might

argue the swmEncapsTable might reveal things about the internal network

topology.

3)      the smilint MIB checker reports several errors.  I’ve noted in my comments

how to fix them.  (I used http://www.ibr.cs.tu-bs.de/bin/smitools.cgi<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2furldefense.proofpoint.com%2fv2%2furl%3fu%3dhttp-3A__www.ibr.cs.tu-2Dbs.de_bin_smitools.cgi%26d%3dBQMDaQ%26c%3dBFpWQw8bsuKpl1SgiZH64Q%26r%3dI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA%26m%3dEmyVUD_iyiDij_d-DdLNVFK2XWSeKZ1aF6FTt-D5224%26s%3dvSO3FAc4-xOytETyJWMkVWpuGL92s1VT1LJllaK0tf0%26e%3d&data=01%7c01%7cdthaler%40microsoft.com%7c5c2e1408e814474cd23e08d2f99d7591%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=qixmtt%2bKMxCYecCaCiJDHq4ol2aivAxnInq%2fELTxuUk%3d>)



-Dave