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

From: Benoit Claise <[email-masked]>
Date: Tue, 1 Dec 2015 11:29:54 +0100

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:[email-masked]]
> *Sent:* Monday, November 30, 2015 7:46 AM
> *To:* Benoit Claise <[email-masked]>; Dave Thaler 
> <[email-masked]>
> *Cc:* MIB Doctors (E-mail) <[email-masked]>; Spencer Dawkins 
> <[email-masked]>
> *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:[email-masked]] *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
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 1 Dec 2015 10:36:36 +0000

Yes. This will be also my recommendation to IANA. I am still waiting for an answer from the authors, but I do not believe that this will change my advice.

Regards,

Dan

From: Benoit Claise [mailto:[email-masked]]
Sent: Tuesday, December 01, 2015 12:30 PM
To: Dave Thaler; 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

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=http-3A__www.iana.org_assignments_ianaiftype-2Dmib_ianaiftype-2Dmib&d=BQMDaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=apWivDgmmySr4TorCMhSops-jzChuycRHJexJE36XrM&s=XBsUedsNadCNrCe2YA3HADlYxTQ1Wlanz4laqZF0q3U&e=> the current set of subtype values is:

    SYNTAX     INTEGER {

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]

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=http-3A__tools.ietf.org_html_rfc2578&d=BQMDaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=apWivDgmmySr4TorCMhSops-jzChuycRHJexJE36XrM&s=zaxDkYYAKS7UiJnUhxVe4l0AoqDBCl_PfA4Lnrh7jJU&e=>].  Most often it will be an IANA-assigned
     value directly under mib-2 [RFC2578<https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org_html_rfc2578&d=BQMDaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=apWivDgmmySr4TorCMhSops-jzChuycRHJexJE36XrM&s=zaxDkYYAKS7UiJnUhxVe4l0AoqDBCl_PfA4Lnrh7jJU&e=>], although for media-specific
     MIB modules that extend the IF-MIB [RFC2863<https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org_html_rfc2863&d=BQMDaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=apWivDgmmySr4TorCMhSops-jzChuycRHJexJE36XrM&s=uzdJnvO6dYI9gDHb3jYAYAb8nYrg_LA3xAYwjrimxMY&e=>] it is customary to use
     an IANA-assigned value under transmission [RFC2578<https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org_html_rfc2578&d=BQMDaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=apWivDgmmySr4TorCMhSops-jzChuycRHJexJE36XrM&s=zaxDkYYAKS7UiJnUhxVe4l0AoqDBCl_PfA4Lnrh7jJU&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:[email-masked]]
Sent: Monday, November 30, 2015 7:46 AM
To: Benoit Claise <[email-masked]><mailto:[email-masked]>; Dave Thaler <[email-masked]><mailto:[email-masked]>
Cc: MIB Doctors (E-mail) <[email-masked]><mailto:[email-masked]>; Spencer Dawkins <[email-masked]><mailto:[email-masked]>
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:[email-masked]] 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=http-3A__trac.tools.ietf.org_area_ops_trac_wiki_mib-2Ddoctors-2Dreview-2Dhistory&d=BQMDaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=apWivDgmmySr4TorCMhSops-jzChuycRHJexJE36XrM&s=h8Ypb2i29O78NQwTx2Z_aQ9u0iBY9Z5ZuAOLG-Cwbeg&e=>

Regards, Benoit

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

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=BQMDaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=apWivDgmmySr4TorCMhSops-jzChuycRHJexJE36XrM&s=8YUQEj3cMo2G06STpEWi5fBQqEJXlfGaSYVpmi7iGqM&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=BQMDaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=apWivDgmmySr4TorCMhSops-jzChuycRHJexJE36XrM&s=-QrZxV-GZFFkeQEWxqB1kqbwP1AsAd602rAfr_1OZ3M&e=>)

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Tue, 1 Dec 2015 20:02:25 +0000

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:[email-masked]]
Sent: Tuesday, December 1, 2015 2:30 AM
To: Dave Thaler <[email-masked]>; Romascanu, Dan (Dan) <[email-masked]>
Cc: MIB Doctors (E-mail) <[email-masked]>; Spencer Dawkins <[email-masked]>
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?

Regards, Benoit

From http://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.iana.org%2fassignments%2fianaiftype-mib%2fianaiftype-mib&data=01%7c01%7cdthaler%40microsoft.com%7c8c90b6eddef0413f302908d2fa3a5e1f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Q9ajUpNPgbOhs8DkSlx3bUBv2ySL%2f3WlRSh7ndycN2k%3d> the current set of subtype values is:

    SYNTAX     INTEGER {

   - 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://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftools.ietf.org%2fhtml%2frfc2578&data=01%7c01%7cdthaler%40microsoft.com%7c8c90b6eddef0413f302908d2fa3a5e1f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=gUgpJhJ2NP5p8cvZcB7yOBT1ar6%2bdKtupKa1lbItCQA%3d>].  Most often it will be an IANA-assigned
     value directly under mib-2 [RFC2578<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftools.ietf.org%2fhtml%2frfc2578&data=01%7c01%7cdthaler%40microsoft.com%7c8c90b6eddef0413f302908d2fa3a5e1f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=gUgpJhJ2NP5p8cvZcB7yOBT1ar6%2bdKtupKa1lbItCQA%3d>], although for media-specific
     MIB modules that extend the IF-MIB [RFC2863<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftools.ietf.org%2fhtml%2frfc2863&data=01%7c01%7cdthaler%40microsoft.com%7c8c90b6eddef0413f302908d2fa3a5e1f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ZveZj0pM3fX7i5RJh0umoLyLn7rFVVIjWirotRe9%2fkA%3d>] it is customary to use
     an IANA-assigned value under transmission [RFC2578<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftools.ietf.org%2fhtml%2frfc2578&data=01%7c01%7cdthaler%40microsoft.com%7c8c90b6eddef0413f302908d2fa3a5e1f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=gUgpJhJ2NP5p8cvZcB7yOBT1ar6%2bdKtupKa1lbItCQA%3d>].  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.

Dave

Regards,

Dan

Hi Dave,

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=http%3a%2f%2ftrac.tools.ietf.org%2farea%2fops%2ftrac%2fwiki%2fmib-doctors-review-history&data=01%7c01%7cdthaler%40microsoft.com%7c8c90b6eddef0413f302908d2fa3a5e1f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ZNY6Ix2dgaZpkb%2b4bZgaO6ED2nHF7baVEM%2byxwKa1fg%3d>

Regards, Benoit

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>

missing boilerplate

topology.

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 2 Dec 2015 07:04:07 +0000

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.

Regards,

Dan

From: Dave Thaler [mailto:[email-masked]]
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

Dave

From: Benoit Claise [mailto:[email-masked]]
Sent: Tuesday, December 1, 2015 2:30 AM
To: Dave Thaler <[email-masked]<mailto:[email-masked]>>; Romascanu, Dan (Dan) <[email-masked]<mailto:[email-masked]>>
Cc: MIB Doctors (E-mail) <[email-masked]<mailto:[email-masked]>>; Spencer Dawkins <[email-masked]<mailto:[email-masked]>>
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?

Regards, Benoit

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 {

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

Dave

Regards,

Dan

Hi Dave,

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

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

missing boilerplate

topology.

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

---

From: Benoit Claise <[email-masked]>
Date: Wed, 2 Dec 2015 21:36:03 +0100

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:[email-masked]]
> *Sent:* Tuesday, December 01, 2015 10:02 PM
> *To:* Benoit Claise; Romascanu, Dan (Dan)
> 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
>
> *From:*Benoit Claise [mailto:[email-masked]]
> *Sent:* Tuesday, December 1, 2015 2:30 AM
> *To:* Dave Thaler <[email-masked] 
> <mailto:[email-masked]>>; Romascanu, Dan (Dan) 
> <[email-masked] <mailto:[email-masked]>>
> *Cc:* MIB Doctors (E-mail) <[email-masked] 
> <mailto:[email-masked]>>; Spencer Dawkins 
> <[email-masked] <mailto:[email-masked]>>
> *Subject:* Re: [MIB-DOCTORS] On this week IESG telechat. : Early MIB 
>     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.
>
>     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 {
>
>          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=>]. 
>     <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
>
>     <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
>
>     <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,
>
>     *To:* Benoit Claise <[email-masked]>
>     <mailto:[email-masked]>; Dave Thaler <[email-masked]>
>     <mailto:[email-masked]>
>     *Cc:* MIB Doctors (E-mail) <[email-masked]>
>     <mailto:[email-masked]>; Spencer Dawkins
>     <[email-masked]> <mailto:[email-masked]>
>     *Subject:* RE: [MIB-DOCTORS] On this week IESG telechat. : Early
>     MIB doctor review of draft-ietf-softwire-mesh-mib-04 and
>     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:[email-masked]] *On
>     Behalf Of *Benoit Claise
>         <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
>
>             <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=>
>
>
>             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
>
>             3)the smilint MIB checker reports several errors.  I’ve
>             noted in my comments
>
>             how to fix them.  (I used
>             <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
>

---

From: Dave Thaler <[email-masked]>
Date: Wed, 2 Dec 2015 20:40:09 +0000

Sounds fine to me.

From: Benoit Claise [mailto:[email-masked]]
Sent: Wednesday, December 2, 2015 12:36 PM
To: Romascanu, Dan (Dan) <[email-masked]>; Dave Thaler <[email-masked]>
Cc: MIB Doctors (E-mail) <[email-masked]>; Spencer Dawkins <[email-masked]>; Terry Manderson <[email-masked]>
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

Regards, Benoit

Regards,

Dan

Dave

Thanks Dave.

Dan, do you agree?

Regards, Benoit

From http://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2furldefense.proofpoint.com%2fv2%2furl%3fu%3dhttps-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%26d%3dBQMGaQ%26c%3dBFpWQw8bsuKpl1SgiZH64Q%26r%3dI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA%26m%3drRgXNtv8nlhF9zyqO_W5Er2oaxexNyRD_11402W29OQ%26s%3dud0a_seLHDWwaBUNf7Pbv7Y6Fq3VFQaMSB3Bb-VOzJo%26e%3d&data=01%7c01%7cdthaler%40microsoft.com%7c45410c6d958547fedb0208d2fb5834e1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=m2xk0nSb7HojOPNexANC6OsfOfAaPXNvi1pl4Rea1uM%3d> the current set of subtype values is:

    SYNTAX     INTEGER {

   - 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://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2furldefense.proofpoint.com%2fv2%2furl%3fu%3dhttps-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%26d%3dBQMGaQ%26c%3dBFpWQw8bsuKpl1SgiZH64Q%26r%3dI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA%26m%3drRgXNtv8nlhF9zyqO_W5Er2oaxexNyRD_11402W29OQ%26s%3dws-Xmojtcxz4KfGYOmSJgqalNqvRCxGGdxYOR8g8lb4%26e%3d&data=01%7c01%7cdthaler%40microsoft.com%7c45410c6d958547fedb0208d2fb5834e1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=E2MLBLCi%2bSjECuMellyxJg7SUt97MnNDbSubANVqlts%3d>].  Most often it will be an IANA-assigned
     value directly under mib-2 [RFC2578<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2furldefense.proofpoint.com%2fv2%2furl%3fu%3dhttps-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%26d%3dBQMGaQ%26c%3dBFpWQw8bsuKpl1SgiZH64Q%26r%3dI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA%26m%3drRgXNtv8nlhF9zyqO_W5Er2oaxexNyRD_11402W29OQ%26s%3dws-Xmojtcxz4KfGYOmSJgqalNqvRCxGGdxYOR8g8lb4%26e%3d&data=01%7c01%7cdthaler%40microsoft.com%7c45410c6d958547fedb0208d2fb5834e1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=E2MLBLCi%2bSjECuMellyxJg7SUt97MnNDbSubANVqlts%3d>], although for media-specific
     MIB modules that extend the IF-MIB [RFC2863<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2furldefense.proofpoint.com%2fv2%2furl%3fu%3dhttps-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%26d%3dBQMGaQ%26c%3dBFpWQw8bsuKpl1SgiZH64Q%26r%3dI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA%26m%3drRgXNtv8nlhF9zyqO_W5Er2oaxexNyRD_11402W29OQ%26s%3d_22mQiqJPfzfvpfd6xTfxSsGydE-I9-FYj9NY9uqBkg%26e%3d&data=01%7c01%7cdthaler%40microsoft.com%7c45410c6d958547fedb0208d2fb5834e1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=w4Kq%2bOalnjY5NsafDaKhKKqlRgEMHFyJ1xoJSGAtoII%3d>] it is customary to use
     an IANA-assigned value under transmission [RFC2578<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2furldefense.proofpoint.com%2fv2%2furl%3fu%3dhttps-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%26d%3dBQMGaQ%26c%3dBFpWQw8bsuKpl1SgiZH64Q%26r%3dI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA%26m%3drRgXNtv8nlhF9zyqO_W5Er2oaxexNyRD_11402W29OQ%26s%3dws-Xmojtcxz4KfGYOmSJgqalNqvRCxGGdxYOR8g8lb4%26e%3d&data=01%7c01%7cdthaler%40microsoft.com%7c45410c6d958547fedb0208d2fb5834e1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=E2MLBLCi%2bSjECuMellyxJg7SUt97MnNDbSubANVqlts%3d>].  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.

Dave

Regards,

Dan

Hi Dave,

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=http%3a%2f%2ftrac.tools.ietf.org%2farea%2fops%2ftrac%2fwiki%2fmib-doctors-review-history&data=01%7c01%7cdthaler%40microsoft.com%7c45410c6d958547fedb0208d2fb5834e1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Tbc7Pvyc3Sl4E9whZZ7g2j2WeQssqZtiw7Z76z7%2bSHM%3d>

Regards, Benoit

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%3dhttps-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%26d%3dBQMGaQ%26c%3dBFpWQw8bsuKpl1SgiZH64Q%26r%3dI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA%26m%3drRgXNtv8nlhF9zyqO_W5Er2oaxexNyRD_11402W29OQ%26s%3d4btjBeHBhFaSEhRFwHNRzMXIXugU58L4RMlQTv9im6w%26e%3d&data=01%7c01%7cdthaler%40microsoft.com%7c45410c6d958547fedb0208d2fb5834e1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=8A3G3Ch5nLsJ0C%2bajrmiJywWuyz4GqYLx2RR8KNiCEU%3d>

missing boilerplate

topology.

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%3dhttps-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%26d%3dBQMGaQ%26c%3dBFpWQw8bsuKpl1SgiZH64Q%26r%3dI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA%26m%3drRgXNtv8nlhF9zyqO_W5Er2oaxexNyRD_11402W29OQ%26s%3dxvJS1_gSlaJS3A-sN6Kz56O4TaDQt9L1mbbN4pwD9Ss%26e%3d&data=01%7c01%7cdthaler%40microsoft.com%7c45410c6d958547fedb0208d2fb5834e1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=XUh9c9Nb%2bvu4hz6KenG51Rn28otT0iBidPvBadEaj0Y%3d>)

-Dave