Subject: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 3 Jan 2013 15:58:46 +0000

Thanks to Ed Beili for undertaking this work. 

A few comments: 

1. In the Abstract you are making the statement that this specification moves the EFM-CU-MIB module to an IEEE document. In fact the IETF does not have the rights to do such a move alone, this document should rather just recognize this move.

Suggested change: 

OLD: 

   It amends that specification by moving the entire EFM-CU-
   MIB module along with the relevant descriptive text, to a separate
   document, maintained by the Institute of Electrical and Electronics
   Engineers (IEEE) 802.3.1 working group. 

NEW: 

   It amends that specification by taking out the entire EFM-CU-
   MIB module along with the relevant descriptive text. That MIB module 
   will be part of a separate document, maintained by the Institute of 
   Electrical and Electronics Engineers (IEEE) 802.3 working group.

Also in Section 1: 

OLD: 

   This
   version moves the entire EFM-CU-MIB module along with the relevant
   descriptive text, to a separate document, maintained by the Institute
   of Electrical and Electronics Engineers (IEEE) 802.3.1 working group.

NEW: 

   This version 
   removes the entire EFM-CU-MIB module along with the relevant descriptive 
   text. That MIB module will be part of a separate document, maintained by 
   the Institute of Electrical and Electronics Engineers (IEEE) 802.3.
   working group.
   
2. In Section 3.1: 

   The EFM-CU-MIB module defined in the previous version of this
   document, along with the relevant descriptive text, is now moved to a
   separate, IEEE maintained document, IEEE Std 802.3.1-2011 [802.3.1],
   which also renamed the EFM-CU-MIB to IEEE8023-EFM-CU-MIB.

- Instead of 'the previous version of this document' we should just say [RFC5066].
- We should provide a more updated version of the IEEE standard which contains the IEEE-EFM-CU-MIB - the document now in Sponsor Ballot would be fine, but the access is restricted. I suggest to ask advice from Howard Frazier. 

3. I suggest that Section 7 mentions that no (new) IANA actions are required because it's the same root already allocated in RFC 5066.

OLD: 

   Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have been
   allocated by IANA in the MIB-2 sub-tree.

NEW: 

   New action is required from IANA as the OID for ifCapStackMIB MODULE-IDENTITY
   was already allocated in [RFC5066].

Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 3 Jan 2013 18:00:18 +0000

Hi Ed,

> 3. You probably meant "No action is required from IANA ..."

Of course, thanks for catching this. 

> 4. Shall I wait for other comments or should I just issue the next
> version of the draft?
>

Let us wait for a couple of days. Hopefully we will get an answer from Howard concerning a better reference for the IEEE 802.3.1a Rev 2 draft, and maybe other comments from the OPSAWG or the IEEE folks. 

Please issue a revised version by the start of the next week, as I plan to enter my Sponsor Ballot comment on the IEEE document, and I need a reference to the best IETF I-D available at that moment. 

Thanks and Regards,

Dan

> -----Original Message-----
> From: Edward Beili [mailto:[email-masked]]
> Sent: Thursday, January 03, 2013 7:55 PM
> To: Romascanu, Dan (Dan); [email-masked]
> Cc: [email-masked]
> Subject: RE: comments on draft-ietf-opsawg-rfc5066bis-00.txt
> 
> Dan,
> Thank you for the comments, I agree with everything, except for the
> following:
> 
> 2. I will leave the IEEE 803.2.1-2011 reference for now, until IEEE
> 802.3 would provide a publically accessible link.
> 
> 3. You probably meant "No action is required from IANA ..." instead of
> "New action is required form IANA ...", i.e. the correct paragraph would
> be:
> 
> OLD:
> 
>    No action is required from IANA as the OID for ifCapStackMIB MODULE-
> IDENTITY
> 4. Shall I wait for other comments or should I just issue the next
> version of the draft?
> 
> Regards,
> -E.
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Romascanu, Dan (Dan)
> Sent: Thursday, January 03, 2013 17:59
> To: [email-masked]
> Cc: [email-masked]
> Subject: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt
> 
> 
> 1. In the Abstract you are making the statement that this specification
> moves the EFM-CU-MIB module to an IEEE document. In fact the IETF does
> not have the rights to do such a move alone, this document should rather
> just recognize this move.
> 
> Suggested change:
> 
> OLD:
> 
> - We should provide a more updated version of the IEEE standard which
> contains the IEEE-EFM-CU-MIB - the document now in Sponsor Ballot would
> be fine, but the access is restricted. I suggest to ask advice from
> Howard Frazier.
> 
> 3. I suggest that Section 7 mentions that no (new) IANA actions are
> required because it's the same root already allocated in RFC 5066.
> 
> OLD:
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Edward Beili <[email-masked]>
Date: Thu, 3 Jan 2013 19:55:05 +0200

Dan,
Thank you for the comments, I agree with everything, except for the following:

2. I will leave the IEEE 803.2.1-2011 reference for now, until IEEE 802.3 would provide a publically accessible link.

3. You probably meant "No action is required from IANA ..." instead of "New action is required form IANA ...", i.e. the correct paragraph would be:

OLD: 

NEW: 

   No action is required from IANA as the OID for ifCapStackMIB MODULE-IDENTITY
   was already allocated in [RFC5066].

4. Shall I wait for other comments or should I just issue the next version of the draft?

Regards,
-E.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, January 03, 2013 17:59
To: [email-masked]
Cc: [email-masked]
Subject: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt

A few comments: 

Suggested change: 

OLD: 

NEW: 

Also in Section 1: 

OLD: 

   This

NEW: 

   This version 
   
2. In Section 3.1: 

OLD: 

NEW: 

Regards,

Dan

---

From: t.petch <[email-masked]>
Date: Sat, 5 Jan 2013 12:45:23 +0000

I wonder if this I-D should really supersede RFC5066.  I would rather
see RFC5066 become Historic with this as an Updates.

Should the Copyright carry the caveat about old material for which the
current rules may not apply?  Since this MIB Module is going to see
extensive use by another SDO, this seems particularly relevant.

Tom Petch

----- Original Message -----
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Edward Beili" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, January 03, 2013 6:00 PM

> Let us wait for a couple of days. Hopefully we will get an answer from
Howard concerning a better reference for the IEEE 802.3.1a Rev 2 draft,
and maybe other comments from the OPSAWG or the IEEE folks.
>
> Please issue a revised version by the start of the next week, as I
plan to enter my Sponsor Ballot comment on the IEEE document, and I need
a reference to the best IETF I-D available at that moment.
> >    text. That MIB module will be part of a separate document,
maintained
> > by
> > - Instead of 'the previous version of this document' we should just
say
> > [RFC5066].
> >    New action is required from IANA as the OID for ifCapStackMIB
MODULE-

---

From: Scott O Bradner <[email-masked]>
Date: Sat, 5 Jan 2013 09:25:56 -0500

> see RFC5066 become Historic with this as an Updates.

a historic document does not exist (standards track wise) so there would be nothing to 
update - 

also- an update would not be a complete replacement (i.e. some of the 
old document would still be in force) - is that the case here (i.e.
do you think that this is not a full replacement?)

> extensive use by another SDO, this seems particularly relevant.

the author of the old doc is the author of the new doc and is submitting the 
new doc under the current rules (and gave himself permission to do that)

Scott

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 7 Jan 2013 15:23:20 +0000

Hi Ed,

Please issue the next version of the draft - I would like to enter my Sponsor Ballot comment in the next couple of days. 

Thanks and Regards,

Dan

> Sent: Thursday, January 03, 2013 8:00 PM
> To: Edward Beili; [email-masked]
> Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt
> 
> Hi Ed,
> 
> Please issue a revised version by the start of the next week, as I plan
> to enter my Sponsor Ballot comment on the IEEE document, and I need a
> reference to the best IETF I-D available at that moment.
> 
> Thanks and Regards,
> 
> Dan
> 
> 
> 
> >    No action is required from IANA as the OID for ifCapStackMIB
> > MODULE- IDENTITY
> > 1. In the Abstract you are making the statement that this
> > specification moves the EFM-CU-MIB module to an IEEE document. In fact
> > the IETF does not have the rights to do such a move alone, this
> > document should rather just recognize this move.
> >
> > Suggested change:
> >
> > OLD:
> >
> > maintained by
> > say [RFC5066].
> > contains the IEEE-EFM-CU-MIB - the document now in Sponsor Ballot
> > would be fine, but the access is restricted. I suggest to ask advice
> > from Howard Frazier.
> >
> > MODULE- IDENTITY

---

From: Scott O Bradner <[email-masked]>
Date: Mon, 7 Jan 2013 10:40:25 -0500

please revive the unused references while you are at it

Scott

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 7 Jan 2013 15:57:54 +0000

Hi Scott, 

Running idnits does not result in any unused references. We have a problem with [802.3.1] which should be IMO the more recent updated draft document, but this one is now in IEEE ballot and restricted access. We are expecting an answer from Howard Frazier on this matter, but IMO we should not delay the submission for this, we can improve this reference later. 

Regards,

Dan

> From: Scott O Bradner [mailto:[email-masked]]
> Sent: Monday, January 07, 2013 5:40 PM
> To: Romascanu, Dan (Dan)
> Cc: Edward Beili; [email-masked]; [email-masked]
> > Please issue the next version of the draft - I would like to enter my
> Sponsor Ballot comment in the next couple of days.
> >
> > Thanks and Regards,
> >
> > Dan
> >
> >
> >
> >
> >> Let us wait for a couple of days. Hopefully we will get an answer
> >> from Howard concerning a better reference for the IEEE 802.3.1a Rev 2
> >> draft, and maybe other comments from the OPSAWG or the IEEE folks.
> >>
> >> plan to enter my Sponsor Ballot comment on the IEEE document, and I
> >> need a reference to the best IETF I-D available at that moment.
> >>
> >> Thanks and Regards,
> >>
> >> Dan
> >>
> >>
> >>
> >>> 3. You probably meant "No action is required from IANA ..." instead
> >>> of "New action is required form IANA ...", i.e. the correct
> >>> paragraph would
> >>> be:
> >>>
> >>> OLD:
> >>>
> >>> specification moves the EFM-CU-MIB module to an IEEE document. In
> >>> fact the IETF does not have the rights to do such a move alone, this
> >>>   document, along with the relevant descriptive text, is now moved
> >>> to
> >> a
> >>> - We should provide a more updated version of the IEEE standard
> >>> which contains the IEEE-EFM-CU-MIB - the document now in Sponsor
> >>> Ballot would be fine, but the access is restricted. I suggest to ask
> >>> advice from Howard Frazier.
> >>>

---

From: t.petch <[email-masked]>
Date: Tue, 8 Jan 2013 10:17:58 +0000

---- Original Message -----
From: "Scott O Bradner" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Romascanu, Dan (Dan)" <[email-masked]>; "Edward Beili"
<[email-masked]>; <[email-masked]>
Sent: Saturday, January 05, 2013 2:25 PM

> see RFC5066 become Historic with this as an Updates.

a historic document does not exist (standards track wise) so there would
be nothing to
update -

Scott

As Dan said,
"RFC 5066 defines two MIB modules. One (this one) continues to be
maintained by the IETF. There is no need for a change. The other
(EFM-CU-MIB) goes to the IEEE, and will be relocated with new names
under the IEEE802 subtree. That document is now in Sponsor Ballot by the
IEEE-SA."

so the vast majority of RFC5066 vanishes into IEEE and is transformed
therein.

The bit that is left, ifCapStackMIB, is unaltered from RFC5066 (hence
the reuse of the number in the mib tree).

I do not know what the best way to describe this in our documentation
is!

As to Copyright, RFC5066 has one editor but the work was
"greatly advanced by the contributions of the following people"
which lists eight such people, so no, I do not think that the editor
of RFC5066bis can make the necessary grant.

RFC5066 predates the change of rules, increasing the grants, by a year.

Tom Petch

> extensive use by another SDO, this seems particularly relevant.

the author of the old doc is the author of the new doc and is submitting
the
new doc under the current rules (and gave himself permission to do that)

Scott

>> Let us wait for a couple of days. Hopefully we will get an answer
from
> plan to enter my Sponsor Ballot comment on the IEEE document, and I
need
> of
> specification
> to a
> which
> would

---

From: "ietfdbh" <[email-masked]>
Date: Tue, 8 Jan 2013 17:07:44 -0500

Hi,

I would be careful with assumptions about the existing IETF standards-track
MIB vanishing, even if IEEE is going to maintain comparable definitions
under an IEEE subtree going forward.

Existing devices and managers might support the RFC5066 EFM-CU-MIB, and
those devices may never be updated to the new IEEE version.
The IETF standards-track EFM-CU-MIB should still be considered a valid MIB
module; it just should not be modified going forward.
The IEEE version should replace it for new implementations, and the IEEE
version could supplement the IETF EFM-CU-MIB in new and updated
implementations, to support continued interoperability.

David Harrington
[email-masked]
+1-603-828-1401
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
t.petch
Sent: Tuesday, January 08, 2013 5:18 AM
To: Scott O Bradner
Cc: [email-masked]; Edward Beili
Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt

---- Original Message -----
From: "Scott O Bradner" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Romascanu, Dan (Dan)" <[email-masked]>; "Edward Beili"

> see RFC5066 become Historic with this as an Updates.

a historic document does not exist (standards track wise) so there would be
nothing to update -

also- an update would not be a complete replacement (i.e. some of the old
document would still be in force) - is that the case here (i.e.
do you think that this is not a full replacement?)

Scott

As Dan said,
"RFC 5066 defines two MIB modules. One (this one) continues to be maintained
by the IETF. There is no need for a change. The other
(EFM-CU-MIB) goes to the IEEE, and will be relocated with new names under
the IEEE802 subtree. That document is now in Sponsor Ballot by the IEEE-SA."

The bit that is left, ifCapStackMIB, is unaltered from RFC5066 (hence the
reuse of the number in the mib tree).

I do not know what the best way to describe this in our documentation is!

As to Copyright, RFC5066 has one editor but the work was "greatly advanced
by the contributions of the following people"
which lists eight such people, so no, I do not think that the editor of
RFC5066bis can make the necessary grant.

Tom Petch

Scott

from
need

---

From: t.petch <[email-masked]>
Date: Thu, 10 Jan 2013 10:18:40 +0000

---- Original Message -----
From: "ietfdbh" <[email-masked]>
To: "'t.petch'" <[email-masked]>; "'Scott O Bradner'"
<[email-masked]>
Cc: <[email-masked]>; "'Edward Beili'" <[email-masked]>
Sent: Tuesday, January 08, 2013 10:07 PM

> implementations, to support continued interoperability.

David

So in practical terms, what would you do?  Currently the I-D has an
'Obsoletes 5066' which I think wrong, since the new I-D omits the vast
mass of 5066; and, as you rightly point out, the EFM-CU-MIB module could
well be with us for a long time (and we have no change control over the
IEEE module that one day may replace it).

Leave 5066 as Standards Track with this as an Updates (which it isn't,
its a reproduce a small part thereof unchanged as far as I can see)?

I will go on objecting to Obsoletes even if I cannot see what the
alternative should be:-)

Tom Petch

> [email-masked]
old
maintained
> (EFM-CU-MIB) goes to the IEEE, and will be relocated with new names
under
the
is!
of
> >>> 3. You probably meant "No action is required from IANA ..."
instead

---

From: "ietfdbh" <[email-masked]>
Date: Thu, 10 Jan 2013 15:13:22 -0500

Hi,

I agree Obsoletes is not accurate.
I think Updates might be accurate. 

However, I think the text is inaccurate:
"That MIB module will be part of a separate
   document, maintained by the Institute of Electrical and Electronics
   Engineers (IEEE) 802.3 working group."
I disagree with this statement.

The EFM-CU-MIB is being frozen as is, and a NEW MIB module is being created,
called IEEE8023-EFM-CU-MIB.
RFC2578 does not allow renaming of a MIB module:
" Note that any definition contained in an information module is
   available to be IMPORT-ed by any other information module, and is
   referenced in an IMPORTS clause via the module name.  Thus, a module
   name should not be changed.  Specifically, the module name (e.g.,
   "FIZBIN-MIB" in the example of Section 5.7) should not be changed
   when revising an information module (except to correct typographical
   errors), and definitions should not be moved from one information
   module to another.

   Also note that obsolete definitions must not be removed from MIB
   modules since their descriptors may still be referenced by other
   information modules, and the OBJECT IDENTIFIERs used to name them
   must never be re-assigned."

So claiming that the EFM-CU-MIB is being renamed is inaccurate because that
would violate SMIv2 rules.
All the object definitions in EFM-CU-MIB will also need to be renamed and
duplicated under IEEE8023-EFM-CU-MIB.
Otherwise NMS applications that import EFM-CU-MIB and IEEE8023-EFM-CU-MIB
would not be able to easily distinguish which OID is appropriate.

Since EFM-CU-MIB cannot be legally "moved" to IEEE8023-EFM-CU-MIB, and
existing devices and applications may continue to support it, I recommend
the existing MIB module should retain its current status.
If we want to recommend that people utilize IEEE8023-EFM-CU-MIB, we can
provide an Updates clause to update the RFC5066 status, but since it
contains an active MIB it really should not be Obsoleted. 
If we want to deprecate the EFM-CU-MIB and recommend IEEE8023-EFM-CU-MIB,
then I think the EFM-CU-MIB MIB module would need to be published again with
an SMIv2 deprecated status (and all the objects would presumably need to be
deprecated as well).
If we deprecate the EFM-CU-MIB module and its objects, the "relationship to
other MIB modules" would need some serious updating to discuss the impact of
the deprecation on other modules (including proprietary MIB modules) that
depend on EFM-CU-MIB.

David Harrington
[email-masked]
+1-603-828-1401
-----Original Message-----
From: t.petch [mailto:[email-masked]] 
Sent: Thursday, January 10, 2013 5:19 AM
To: ietfdbh; 'Scott O Bradner'
Cc: [email-masked]; 'Edward Beili'
Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt

---- Original Message -----
From: "ietfdbh" <[email-masked]>
To: "'t.petch'" <[email-masked]>; "'Scott O Bradner'"
<[email-masked]>

David

So in practical terms, what would you do?  Currently the I-D has an
'Obsoletes 5066' which I think wrong, since the new I-D omits the vast mass
of 5066; and, as you rightly point out, the EFM-CU-MIB module could well be
with us for a long time (and we have no change control over the IEEE module
that one day may replace it).

Leave 5066 as Standards Track with this as an Updates (which it isn't, its a
reproduce a small part thereof unchanged as far as I can see)?

Tom Petch

old
maintained
under
the
is!
of
instead