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]>]

On 12/2/2015 8:04 AM, Romascanu, Dan (Dan) wrote:
>
> I like less this option. It seems more complicated from the IANA 
> perspective, it creates a new hierarchy within the transmission tree 
> (a practice we discouraged WGs to follow), and it does not fit well 
> IMO with the recommendations of RFC 4181.
>
I would agree with this.
I believe that mib-2 is the best choice.

Regards, Benoit
>
> Regards,
>
> Dan
>
> *From:*Dave Thaler [mailto:[e-mail]]
> *Sent:* Tuesday, December 01, 2015 10:02 PM
> *To:* Benoit Claise; Romascanu, Dan (Dan)
> *Cc:* MIB Doctors (E-mail); Spencer Dawkins
> *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
>
> Another possibility is that we could define a subtree 
> transmission.131.xxx to hold tunnel subtype values.
>
> E.g., if we define (say) xxx is 3, and a given tunnel subtype is yyy, 
> then the subtree could be transmission.131.3.yyy.
>
> That might be a good way to organize tunneling protocol MIB modules 
> and avoid having this discussion each time
>
> there’s a new tunnel subtype.
>
> Dave
>
> *From:*Benoit Claise [mailto:[e-mail]]
> *Sent:* Tuesday, December 1, 2015 2:30 AM
> *To:* Dave Thaler <[e-mail] 
> <mailto:[e-mail]>>; Romascanu, Dan (Dan) 
> <[e-mail] <mailto:[e-mail]>>
> *Cc:* MIB Doctors (E-mail) <[e-mail] 
> <mailto:[e-mail]>>; Spencer Dawkins 
> <[e-mail] <mailto:[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
>
> 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
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttp-253a-252f-252fwww.iana.org-252fassignments-252fianaiftype-2Dmib-252fianaiftype-2Dmib-26data-3D01-257c01-257cdthaler-2540microsoft.com-257c8c90b6eddef0413f302908d2fa3a5e1f-257c72f988bf86f141af91ab2d7cd011db47-257c1-26sdata-3DQ9ajUpNPgbOhs8DkSlx3bUBv2ySL-252f3WlRSh7ndycN2k-253d&d=BQMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=rRgXNtv8nlhF9zyqO_W5Er2oaxexNyRD_11402W29OQ&s=ud0a_seLHDWwaBUNf7Pbv7Y6Fq3VFQaMSB3Bb-VOzJo&e=>
>     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
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttp-253a-252f-252ftools.ietf.org-252fhtml-252frfc2578-26data-3D01-257c01-257cdthaler-2540microsoft.com-257c8c90b6eddef0413f302908d2fa3a5e1f-257c72f988bf86f141af91ab2d7cd011db47-257c1-26sdata-3DgUgpJhJ2NP5p8cvZcB7yOBT1ar6-252bdKtupKa1lbItCQA-253d&d=BQMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=rRgXNtv8nlhF9zyqO_W5Er2oaxexNyRD_11402W29OQ&s=ws-Xmojtcxz4KfGYOmSJgqalNqvRCxGGdxYOR8g8lb4&e=>]. 
>     Most often it will be an IANA-assigned
>
>          value directly under mib-2 [RFC2578
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttp-253a-252f-252ftools.ietf.org-252fhtml-252frfc2578-26data-3D01-257c01-257cdthaler-2540microsoft.com-257c8c90b6eddef0413f302908d2fa3a5e1f-257c72f988bf86f141af91ab2d7cd011db47-257c1-26sdata-3DgUgpJhJ2NP5p8cvZcB7yOBT1ar6-252bdKtupKa1lbItCQA-253d&d=BQMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=rRgXNtv8nlhF9zyqO_W5Er2oaxexNyRD_11402W29OQ&s=ws-Xmojtcxz4KfGYOmSJgqalNqvRCxGGdxYOR8g8lb4&e=>],
>     although for media-specific
>
>          MIB modules that extend the IF-MIB [RFC2863
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttp-253a-252f-252ftools.ietf.org-252fhtml-252frfc2863-26data-3D01-257c01-257cdthaler-2540microsoft.com-257c8c90b6eddef0413f302908d2fa3a5e1f-257c72f988bf86f141af91ab2d7cd011db47-257c1-26sdata-3DZveZj0pM3fX7i5RJh0umoLyLn7rFVVIjWirotRe9-252fkA-253d&d=BQMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=rRgXNtv8nlhF9zyqO_W5Er2oaxexNyRD_11402W29OQ&s=_22mQiqJPfzfvpfd6xTfxSsGydE-I9-FYj9NY9uqBkg&e=>]
>     it is customary to use
>
>          an IANA-assigned value under transmission [RFC2578
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttp-253a-252f-252ftools.ietf.org-252fhtml-252frfc2578-26data-3D01-257c01-257cdthaler-2540microsoft.com-257c8c90b6eddef0413f302908d2fa3a5e1f-257c72f988bf86f141af91ab2d7cd011db47-257c1-26sdata-3DgUgpJhJ2NP5p8cvZcB7yOBT1ar6-252bdKtupKa1lbItCQA-253d&d=BQMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=rRgXNtv8nlhF9zyqO_W5Er2oaxexNyRD_11402W29OQ&s=ws-Xmojtcxz4KfGYOmSJgqalNqvRCxGGdxYOR8g8lb4&e=>]. 
>     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]>
>     <mailto:[e-mail]>; Dave Thaler <[e-mail]>
>     <mailto:[e-mail]>
>     *Cc:* MIB Doctors (E-mail) <[e-mail]>
>     <mailto:[e-mail]>; Spencer Dawkins
>     <[e-mail]> <mailto:[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://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttp-253a-252f-252ftrac.tools.ietf.org-252farea-252fops-252ftrac-252fwiki-252fmib-2Ddoctors-2Dreview-2Dhistory-26data-3D01-257c01-257cdthaler-2540microsoft.com-257c8c90b6eddef0413f302908d2fa3a5e1f-257c72f988bf86f141af91ab2d7cd011db47-257c1-26sdata-3DZNY6Ix2dgaZpkb-252b4bZgaO6ED2nHF7baVEM-252byxwKa1fg-253d&d=BQMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=rRgXNtv8nlhF9zyqO_W5Er2oaxexNyRD_11402W29OQ&s=lyXBhSLk8eHfPNghBulPeOUEwIcNztsjQXWhm-hym-0&e=>
>
>         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://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253a-252f-252furldefense.proofpoint.com-252fv2-252furl-253fu-253dhttp-2D3A-5F-5Fresearch.microsoft.com-5F-2D257Edthaler-5Fdraft-2D2Dietf-2D2Dsoftwire-2D2Dmesh-2D2Dmib-2D2D04.pdf-2526d-253dBQMDaQ-2526c-253dBFpWQw8bsuKpl1SgiZH64Q-2526r-253dI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA-2526m-253dEmyVUD-5FiyiDij-5Fd-2DDdLNVFK2XWSeKZ1aF6FTt-2DD5224-2526s-253dHo63Okm-2Dfo9bjIZHdCzzwvZRa87Ac4z9r3-5Fvn7Sy8-2Ds-2526e-253d-26data-3D01-257c01-257cdthaler-2540microsoft.com-257c5c2e1408e814474cd23e08d2f99d7591-257c72f988bf86f141af91ab2d7cd011db47-257c1-26sdata-3D6ttADpfOT8BqneSYvSroaDY4faoSF7SiQjpdX6aB2mE-253d&d=BQMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=rRgXNtv8nlhF9zyqO_W5Er2oaxexNyRD_11402W29OQ&s=4btjBeHBhFaSEhRFwHNRzMXIXugU58L4RMlQTv9im6w&e=>
>
>
>             (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://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253a-252f-252furldefense.proofpoint.com-252fv2-252furl-253fu-253dhttp-2D3A-5F-5Fwww.ibr.cs.tu-2D2Dbs.de-5Fbin-5Fsmitools.cgi-2526d-253dBQMDaQ-2526c-253dBFpWQw8bsuKpl1SgiZH64Q-2526r-253dI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA-2526m-253dEmyVUD-5FiyiDij-5Fd-2DDdLNVFK2XWSeKZ1aF6FTt-2DD5224-2526s-253dvSO3FAc4-2DxOytETyJWMkVWpuGL92s1VT1LJllaK0tf0-2526e-253d-26data-3D01-257c01-257cdthaler-2540microsoft.com-257c5c2e1408e814474cd23e08d2f99d7591-257c72f988bf86f141af91ab2d7cd011db47-257c1-26sdata-3Dqixmtt-252bKMxCYecCaCiJDHq4ol2aivAxnInq-252fELTxuUk-253d&d=BQMGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=rRgXNtv8nlhF9zyqO_W5Er2oaxexNyRD_11402W29OQ&s=xvJS1_gSlaJS3A-sN6Kz56O4TaDQt9L1mbbN4pwD9Ss&e=>)
>
>             -Dave
>