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

[Benoit Claise <[e-mail]>]

Thanks Dave.

Dan, do you agree?
Shall we ask draft-ietf-softwire-mesh-mib-04 and 
draft-ietf-softwire-dslite-mib to be moved under mib-2?

Regards, Benoit
>
> 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
>