Subject: [OPSAWG] Working group last call on "Ethernet in the First Mile Copper (EFMCu) Interfaces MIB"

From: Melinda Shore <[email-masked]>
Date: Mon, 05 Aug 2013 13:42:03 -0800

Reminder:  https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/
is in working group last call, which closes August 7.  Please
have a look at it and post any comments to the opsawg mailing
list.

Melinda

-------- Original Message --------
Subject: Working group last call on "Ethernet in the First Mile Copper
(EFMCu) Interfaces MIB"
Date: Wed, 24 Jul 2013 11:42:13 -0800
From: Melinda Shore <[email-masked]>
To: [email-masked] <[email-masked]>

This is to announce the start of working group last call on:

    Ethernet in the First Mile Copper (EFMCu) Interfaces MIB
    https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/

It is intended for publication as a standards track RFC.

Please give it a careful read and provide any feedback to this
mailing list by August 7, 2013.

Thanks,

opsawg chairs

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 7 Aug 2013 12:45:00 +0000

Hi,

I support this document and I believe that it is almost ready for submission to the IESG. I have a number of editorial comments, their resolution does not require IMO to re-do the WGLC. 

1. In the Abstract: 

OLD: 

   It amends that specification by
   informing the internet community about the transition of the EFM-CU-
   MIB module from the IETF Ethernet Interfaces and Hub MIB Working
   Group to the Institute of Electrical and Electronics Engineers (IEEE)
   802.3 working group.

NEW: 

   It amends that specification by
   informing the community about the transition of the EFM-CU-MIB
   module from the concluded IETF Ethernet Interfaces and Hub MIB Working
   Group to the Institute of Electrical and Electronics Engineers (IEEE)
   802.3 working group.

2. In the Introduction: 

s/the Institute of Electrical and Electronics Engineers (IEEE) [802.3] working group/the Institute of Electrical and Electronics Engineers (IEEE) 802.3 [802.3] working group/

3. Also in the Introduction:

   In 2011 the IEEE developed
   IEEE8023-EFM-CU-MIB module, defined in IEEE Std 802.3.1-2011
   [802.3.1] and based on the EFM-CU-MIB, defined in RFC 5066.

Better drop 'In 2011' - this information is not relevant and is probably not accurate, as 2011 is the year of the publication (obvious from the name), development took longer

4. Also in the Introduction: 

s/The IEEE8023-EFM-CU-MIB and EFM-CU-MIB are both valid MIB modules, which can coexist./ The IEEE8023-EFM-CU-MIB and EFM-CU-MIB MIB modules can coexist./

5. In Section 4: 

OLD: 

   Requests and comments pertaining to EFM Copper Interfaces MIB SHOULD
   be sent to the IEEE 803.3.1 task force mailing list:
   [[email-masked]].

NEW: 

   Requests and comments pertaining to EFM Copper Interfaces MIB SHOULD
   be sent to the IEEE 802.3 Working Group. Currently the IEEE 802.3.1 
   task force (chartered with MIB development) mailing list is 
   [[email-masked]].

6. Also in section 4: 

s/jurisdiction/control/

Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Melinda Shore
> Sent: Tuesday, August 06, 2013 12:42 AM
> To: [email-masked]
> Subject: [OPSAWG] Working group last call on "Ethernet in the First Mile
> Copper (EFMCu) Interfaces MIB"
> 
> is in working group last call, which closes August 7.  Please have a
> look at it and post any comments to the opsawg mailing list.
> 
> Melinda
> 
> 
> Please give it a careful read and provide any feedback to this mailing
> list by August 7, 2013.
> 
> Thanks,
> 
> opsawg chairs
> 
> 
> 
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: t.petch <[email-masked]>
Date: Thu, 8 Aug 2013 10:40:48 +0100

Some more editorial suggestions.

OLD
"  With the conclusion of the [HUBMIB] working group, the responsibility
   for the maintenance and further development of the EFM-CU-MIB module
   has been transfered to the Institute of Electrical and Electronics
   Engineers (IEEE) [802.3] working group."
NEW
"  With the conclusion of the [HUBMIB] working group, the responsibility
   for the maintenance and further development of a MIB module
  for managing 10PASS-TS and
      2BASE-TL Ethernet in the First Mile Copper (EFMCu) interfaces;
   has been transfered to the Institute of Electrical and Electronics
   Engineers (IEEE) [802.3] working group."

[I trust that the IEEE will not be reissuing the IETF MIB module!]

OLD
"   The names of the objects in IEEE8023-EFM-CU-MIB are identical to
   those in EFM-CU-MIB."
NEW
"   The names of the objects in the first version of the
IEEE8023-EFM-CU-MIB are identical to
   those in EFM-CU-MIB."
[Again, remove the implied update of the IETF MIB module}

OLD
becomes the last valid version of that MIB.
NEW
becomes the last valid version of that MIB module.

[It is a MIB module not the MIB - not sure about the valid, I would omit
that ]

Overall, I think that the thrust is right, which I did not say about
version -00.

Tom Petch

----- Original Message -----
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Melinda Shore" <[email-masked]>; <[email-masked]>
Sent: Wednesday, August 07, 2013 1:45 PM

> Hi,
>
> I support this document and I believe that it is almost ready for
submission to the IESG. I have a number of editorial comments, their
resolution does not require IMO to re-do the WGLC.
> s/the Institute of Electrical and Electronics Engineers (IEEE) [802.3]
working group/the Institute of Electrical and Electronics Engineers
(IEEE) 802.3 [802.3] working group/
> Better drop 'In 2011' - this information is not relevant and is
probably not accurate, as 2011 is the year of the publication (obvious
from the name), development took longer
> s/The IEEE8023-EFM-CU-MIB and EFM-CU-MIB are both valid MIB modules,
which can coexist./ The IEEE8023-EFM-CU-MIB and EFM-CU-MIB MIB modules
can coexist./
> > Please give it a careful read and provide any feedback to this
mailing

---

From: David Harrington <[email-masked]>
Date: Thu, 08 Aug 2013 22:33:17 +0200

Hi,

Are they really identically named objects in different modules?
I think that may be illegal per rfc2578 section 3.6.

--
David Harrington
[email-masked]
+1-603-828-1401

---

From: t.petch <[email-masked]>
Date: Fri, 9 Aug 2013 11:53:01 +0100

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: "t.petch" <[email-masked]>; "Romascanu, Dan (Dan)"
<[email-masked]>; "Melinda Shore" <[email-masked]>;
<[email-masked]>
Sent: Thursday, August 08, 2013 9:33 PM

> I think that may be illegal per rfc2578 section 3.6.

Probably.  I cannot get access to the IEEE drafts and so do not know
what they have done.  My NEW text was to remove the implicit updates to
the IETF module - I took the wording about the IEEE module as given in
the I-D.  (Of course, if they had retained the OIDs and changed the
descriptors, as an intermediate step, then that would be fine:-)

There is a weasel words get out in that RFC2578 could be taken as a MUST
only for an IETF MIB module, whereas this will not be such, but rather
an IEEE MIB module, but I would not regard that as very satisfactory.

We need an IEEE liaison/member to give us sight of what has been done;
or else an e-mail to the listserv address given in the I-D.

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 9 Aug 2013 14:35:58 +0200

> an IEEE MIB module, but I would not regard that as very satisfactory.

Back in a day, SNMP tools often could not deal with descriptors that
need to be scoped by a module name. This, of course, is broken. Not
surprising, the rule in RFC 2578 did not encourage tool writers to fix
their tools.

Unless SNMP tools have improved significantly in the last few years, I
would rather suggest to keep descriptors unique if there is a need to
copy things. (In fact, copying definitions just for the sake of having
them registered in a different branch likely fails on the cost/benefit
analysis badly since management applications will have to look for two
possible OIDs now for the next N years to deal with the transition.)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 13 Aug 2013 14:02:20 +0000

Well, copying the IETF MIB modules with all the names 'as-is' excepting the names of the MIB modules and the names of the sub-branches is what the IEEE 802.3 seem to have done, including in the revised IEEE 802.3.1 which was just approved. I asked Howard Frazier for a copy of the MIB modules in the recently approved document for confirmation. 

Section 3.1 of RFC 2578 says: 

>    The set of descriptors defined in all "standard" information modules
     shall be unique.

Allegedly IEEE 802.3 MIB modules are not IETF "standards". From this perspective what they have done is not 'illegal'. They may have thought that they are actually making life of some of the management applications easier in transition, as they will continue to use the same names, just load a different MIB module. 

Question is what we do at this point. The I-D we have just Last Called reflects the reality - good or bad. 

Regards,

Dan

> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Friday, August 09, 2013 3:36 PM
> To: t.petch
> Cc: David Harrington; Romascanu, Dan (Dan); Melinda Shore;
> [email-masked]
> Subject: Re: [OPSAWG] Working group last call on "Ethernet in the First
> Mile Copper (EFMCu) Interfaces MIB"
> 
> > what they have done.  My NEW text was to remove the implicit updates
> > to the IETF module - I took the wording about the IEEE module as given
> > in the I-D.  (Of course, if they had retained the OIDs and changed the
> > There is a weasel words get out in that RFC2578 could be taken as a
> > MUST only for an IETF MIB module, whereas this will not be such, but
> > rather an IEEE MIB module, but I would not regard that as very
> satisfactory.
> >
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 13 Aug 2013 16:27:05 +0200

> Question is what we do at this point. The I-D we have just Last Called reflects the reality - good or bad. 

Well, then this is what they did. Document it - perhaps add a warning
that tools must to be able to deal with prefixed descriptors since
descriptors are for sure not unique anymore if if both old (pre IEEE)
and new MIB modules need to be supported. But then, people will also
figure this out quickly once they try and perhaps tools have generally
improved to deal with this situation better than in the past.

/js