Skip to main content

Dual-Stack Lite (DS-Lite) Management Information Base (MIB) for Address Family Transition Routers (AFTRs)
draft-ietf-softwire-dslite-mib-15

Revision differences

Document history

Date Rev. By Action
2016-06-13
15 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2016-05-18
15 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2016-05-04
15 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2016-05-04
15 (System) RFC Editor state changed to RFC-EDITOR from IANA
2016-05-04
15 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2016-04-29
15 (System) IANA Action state changed to Waiting on Authors from In Progress
2016-04-29
15 (System) IANA Action state changed to In Progress from Waiting on Authors
2016-04-28
15 (System) IANA Action state changed to Waiting on Authors from In Progress
2016-04-28
15 (System) IANA Action state changed to In Progress from Waiting on ADs
2016-03-11
15 (System) RFC Editor state changed to IANA from RFC-EDITOR
2016-03-09
15 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2016-01-15
15 (System) IANA Action state changed to Waiting on ADs from In Progress
2016-01-12
15 (System) RFC Editor state changed to EDIT
2016-01-12
15 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2016-01-12
15 (System) Announcement was received by RFC Editor
2016-01-12
15 (System) IANA Action state changed to In Progress
2016-01-12
15 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup
2016-01-12
15 Amy Vezza IESG has approved the document
2016-01-12
15 Amy Vezza Closed "Approve" ballot
2016-01-12
15 Amy Vezza Ballot approval text was generated
2016-01-03
15 Yu Fu New version available: draft-ietf-softwire-dslite-mib-15.txt
2015-12-22
14 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'No Response'
2015-12-20
14 (System) Sub state has been changed to AD Followup from Revised ID Needed
2015-12-20
14 Yu Fu New version available: draft-ietf-softwire-dslite-mib-14.txt
2015-12-17
13 Cindy Morgan IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation
2015-12-17
13 Benoît Claise
[Ballot comment]
Let me append my COMMENT.
Since the companion MIB document didn't compile (https://datatracker.ietf.org/doc/draft-ietf-softwire-mesh-mib/ballot/#benoit-claise) , I made some extra test with this …
[Ballot comment]
Let me append my COMMENT.
Since the companion MIB document didn't compile (https://datatracker.ietf.org/doc/draft-ietf-softwire-mesh-mib/ballot/#benoit-claise) , I made some extra test with this MIB module.

Thanks for addressing Dave Thaler's recommendations.

The only point that looks under specified to me is:
      dsliteNATBindMappingExtAddressType OBJECT-TYPE
          SYNTAX InetAddressType
          MAX-ACCESS not-accessible
          STATUS current
          DESCRIPTION
            "Address type for the mapping's external address.
            A value other than IPv4(1) would be unexpected."
          ::= { dsliteNATBindEntry 4 }


    dsliteNATBindMappingIntAddressType OBJECT-TYPE
          SYNTAX InetAddressType
          MAX-ACCESS read-only
          STATUS current
          DESCRIPTION
            "Address type of the mapping's internal address.
              A value other than ipv4z(3) would be unexpected."
          ::= { dsliteNATBindEntry 8 }

What does it mean: "other value would be unexpected"?
Is this allowed or not?

timeout 10 smilint -s -e -l 6 -p mibs/NATV2-MIB mibs/DSLite-MIB 2>report.txt

You can access any intermediately created files, the processing report (which might be empty if no errors or warnings have been found), and output files (in case of a conversion request) for reading and download from a temporary server directory for approx. 24 hours.

While processing your request the following errors and/or warnings have been found:

mibs/NATV2-MIB:368: warning: identifier `natv2SubscriberIndex' differs from `Natv2SubscriberIndex' only in case
mibs/NATV2-MIB:109: info: previous definition of `Natv2SubscriberIndex'
mibs/NATV2-MIB:805: warning: identifier `natv2InstanceIndex' differs from `Natv2InstanceIndex' only in case
mibs/NATV2-MIB:135: info: previous definition of `Natv2InstanceIndex'
mibs/NATV2-MIB:1689: warning: identifier `natv2PoolIndex' differs from `Natv2PoolIndex' only in case
mibs/NATV2-MIB:153: info: previous definition of `Natv2PoolIndex'
mibs/NATV2-MIB:2074: warning: `InetAddress' object should have an accompanied preceding `InetAddressType' object
mibs/NATV2-MIB:2087: warning: `InetAddress' object should have an accompanied preceding `InetAddressType' object
mibs/DSLite-MIB:72: [2] {object-identifier-not-prefix} Object identifier element `xxx' name only allowed as first element
mibs/DSLite-MIB:29: [2] {module-identity-registration} illegal module identity registration
mibs/DSLite-MIB:118: [5] {index-exceeds-too-large} warning: index of row `dsliteTunnelEntry' can exceed OID size limit by 392 subidentifier(s)
mibs/DSLite-MIB:198: [5] {index-exceeds-too-large} warning: index of row `dsliteNATBindEntry' can exceed OID size limit by 189 subidentifier(s)
mibs/DSLite-MIB:681: [5] {notification-not-reversible} warning: notification `dsliteTunnelNumAlarm' is not reverse mappable
mibs/DSLite-MIB:692: [5] {notification-not-reversible} warning: notification `dsliteAFTRUserSessionNumAlarm' is not reverse mappable
mibs/DSLite-MIB:712: [5] {notification-not-reversible} warning: notification `dsliteAFTRPortUsageOfSpecificIpAlarm' is not reverse mappable
mibs/DSLite-MIB:5: [5] {import-unused} warning: identifier `Gauge32' imported from module `SNMPv2-SMI' is never used
mibs/DSLite-MIB:5: [5] {import-unused} warning: identifier `TimeTicks' imported from module `SNMPv2-SMI' is never used
mibs/DSLite-MIB:13: [5] {import-unused} warning: identifier `DisplayString' imported from module `SNMPv2-TC' is never used

You could take care of the last 3 warnings.
Also, I inquired about the "notification X  is not reverse mappable" to the MIB-doctors.
Here is Jürgen Schönwälder's answer:
SNMPv1 identifies notifications in a different way that SNMPv2c/SNMPv3
does and SMIv2 notification definitions are reverse mappable if they
are registered OID.0.X and smilint generates this warning if they are
not. This is the reason why the generally suggestion MIB OID layout
has a notifications branch registered with the subidentifier 0.

The MIB module in question has

dsliteNotifications  OBJECT IDENTIFIER
        ::=  { dsliteMIB 0 }

dsliteTraps  OBJECT IDENTIFIER
            ::=  { dsliteNotifications 1  }

and the notification registered below dsliteTraps. I do not think this
serves any purpose - if authors would simply follow RFC 4181 appendix
D the problem would not show up. (And in general, we talk about
notifications not traps in SMIv2.)

See also section 4.7 of RFC 4181.

Authors, please improve your MIB module to be compliant with RFC 4181.

Regards, Benoit
2015-12-17
13 Benoît Claise Ballot comment text updated for Benoit Claise
2015-12-17
13 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2015-12-17
13 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2015-12-17
13 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2015-12-17
13 Benoît Claise
[Ballot comment]
Thanks for addressing Dave Thaler's recommendations.

The only point that looks under specified to me is:
      dsliteNATBindMappingExtAddressType OBJECT-TYPE
    …
[Ballot comment]
Thanks for addressing Dave Thaler's recommendations.

The only point that looks under specified to me is:
      dsliteNATBindMappingExtAddressType OBJECT-TYPE
          SYNTAX InetAddressType
          MAX-ACCESS not-accessible
          STATUS current
          DESCRIPTION
            "Address type for the mapping's external address.
            A value other than IPv4(1) would be unexpected."
          ::= { dsliteNATBindEntry 4 }


    dsliteNATBindMappingIntAddressType OBJECT-TYPE
          SYNTAX InetAddressType
          MAX-ACCESS read-only
          STATUS current
          DESCRIPTION
            "Address type of the mapping's internal address.
              A value other than ipv4z(3) would be unexpected."
          ::= { dsliteNATBindEntry 8 }

What does it mean: "other value would be unexpected"?
Is this allowed or not?

Note: I have recompiled the MIB, I trust you on this point.

Regards, Benoit
2015-12-17
13 Benoît Claise [Ballot Position Update] Position for Benoit Claise has been changed to No Objection from Discuss
2015-12-16
13 Matthew Miller Request for Telechat review by GENART Completed: Ready. Reviewer: Matthew Miller.
2015-12-16
13 Yu Fu New version available: draft-ietf-softwire-dslite-mib-13.txt
2015-12-15
12 Joel Jaeggli [Ballot comment]
mib doctor review will cause a substantial revision.
2015-12-15
12 Joel Jaeggli Ballot comment text updated for Joel Jaeggli
2015-12-14
12 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2015-12-10
12 Jean Mahoney Request for Telechat review by GENART is assigned to Matthew Miller
2015-12-10
12 Jean Mahoney Request for Telechat review by GENART is assigned to Matthew Miller
2015-12-10
12 Tero Kivinen Request for Last Call review by SECDIR Completed: Ready. Reviewer: Derek Atkins.
2015-12-02
12 Terry Manderson Telechat date has been changed to 2015-12-17 from 2015-12-03
2015-12-02
12 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2015-12-02
12 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2015-12-02
12 Cindy Morgan Changed consensus to Yes from Unknown
2015-12-02
12 Benoît Claise
[Ballot discuss]
As mentioned by Dave Thaler in his MIB doctor review:
I was assigned to do the MIB doctor review of this document, since …
[Ballot discuss]
As mentioned by Dave Thaler in his MIB doctor review:
I was assigned to do the MIB doctor review of this document, since I previously
did an early review of -03.  My full comments are in the marked up copy at
http://research.microsoft.com/~dthaler/draft-ietf-softwire-dslite-mib-12.pdf
Below is a summary of the issues called out therein.

Substantive issues:

1)      RFC 4001 requires each InetAddress object to explicitly state
which other InetAddressType object indicates the type.  None of the objects
in this document do so.  RFC 7659 (the NATv2 MIB) does, and can be used as
an example.

2)      dsliteNATBindEntry includes dsliteTunnelStartAddPreLen in the INDEX.
To confirm this was intended: Can you really have 2 entries that have all
other INDEX values the same and differ only in the prefix length?

3)      dsliteNATBindTable states that it extends natv2PortMapTable in RFC 7659,
but rather than reusing the not-accessible objects from that table in its own
INDEX clause, it defines its own.  That’s fine, but it is then not clear whether
each such object in the dsliteNATBindTable INDEX needs to match
a corresponding value in the natv2PortMapTable INDEX,
or whether there can be additional entries that do not
appear in the natv2PortMapTable.  This should be clarified.

4)      Many objects in that table, such as dsliteNATBindMappingIntRealm,
have very terse DESCRIPTIONs, whereas the DESCRIPTION of
the corresponding object in the natv2PortMapTable is quite
detailed.  Hence this draft is far less clear than RFC 7659,
since this draft has no such language.

5)      Objects of type InetAddress incorrectly have a REFERENCE
clause pointing to the definition of the InetAddress TC.
REFERENCE clauses should be used to point to the spec defining
the semantics, rather than the syntax.  For example,
dsliteNATBindMappingIntAddress is incorrect, whereas the
corresponding object in RFC 7659 (natv2AddressMapInternalAddressType)
is correct and points into the DS-Lite RFC (RFC 6333).

6)      I didn’t understand DsliteNATBindEntry at all.  Its
dsliteNATBindMappingMapBehavior object has a value
addressAndPortDependent(2) which “maps to a separate external
address and port combination for each different
destination address and port combination reached
through the same external realm”.  However, the external port
is in the INDEX clause and the destination address does not appear to be
in the table at all.  Since the 0 value for the external port already has a different
special meaning, it can’t be 0 either.  So I don’t understand how this table
can work.

7)      dsliteAFTRAlarmProtocolType is underspecified.  It’s a string,
but the description is very confusing as to what the legal string
values are, making it sound more like an INTEGER was intended.
(“This object indicate the protocol type of alarm,
                0:tcp,1:udp,2:icmp,3:total”)
E.g., does that mean the string is “0:tcp” or “0” or “tcp” or what?

8)      The dsliteStatisticTransmitted object seems to combine sent + received
packets into a single counter with a name that implies only one direction.
This is confusing, especially since most other MIB modules separate sent
vs received into different counters.

9)      dsliteAFTRUserSessionNumAlarm and dsliteAFTRPortUsageOfSpecificIpAlarm
both refer to “the threshold” without stating what threshold that is.
There doesn’t seem to be any such threshold object in this MIB module or
elsewhere that I could find.

10)  dsliteAFTRAlarmScalarGroup is mandatory and requires read-write access.
But a lesson learned from the NAT MIB (and many other MIBs) is that many
people don’t want write support in their MIB modules.  Does the WG really
feel that write support is required in all implementations?  I’d recommend
also having a read-only compliance statement, as is done in many other
MIB modules.

11)  The security considerations section uses the correct boilerplate for
sensitive read-only objects, which includes “These are the tables and
objects and their sensitivity/vulnerability”.  However it then only
lists the tables/objects and contains no discussion of their sensitivity/vulnerability.
This is required in order to comply with MIB review guidelines in RFC 4181.

12)  Per discussion on MIB Doctors, the root OID should probably not be
{ transmission xxx }, since that space usually implies that xxx is an ifType
(not tunnel type) value.
BENOIT: as discussed with the MIB Doctors, it should be under mib-2.

13)  A number of undefined terms are used that I could not find in the DS-Lite
RFC (6333) either, e.g., connection, session, etc.  As such, I couldn’t tell what
was meant, and whether there were issues with the meaning.  At minimum,
REFERENCE clauses should be added to point to a specific section of a document
that defines the terms.
2015-12-02
12 Benoît Claise
[Ballot comment]
Editorial issues:

14)  The title, abstract, MIB module name, etc. all say the MIB module is for
managing DS-Lite, but DS-Lite has two …
[Ballot comment]
Editorial issues:

14)  The title, abstract, MIB module name, etc. all say the MIB module is for
managing DS-Lite, but DS-Lite has two roles: AFTR and B4, and this document
only instruments the AFTR.  Hence I would really recommend putting AFTR
in the title, abstract, and name.

15)  There are a bunch of editorial issues (grammar, typos) that should be
cleaned up before publication.

16)  In a number of places, it seems to refer to some objects in some MIB module,
whether this document or RFC 7659, without stating the name of the object
so it is not clear which object was meant.

17)  The document still refers to draft-perrault-behave-natv2-mib
and should be RFC 7659.

And finally, I don't see the value of this sentence.
  "When these words are not in
  ALL CAPS (such as "should" or "Should"), they have their usual
  English meanings, and are not to be interpreted as [RFC2119] key
  words."
I believe we should favor text consistency across documents.
2015-12-02
12 Benoît Claise [Ballot Position Update] New position, Discuss, has been recorded for Benoit Claise
2015-12-02
12 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2015-12-01
12 Matthew Miller Request for Telechat review by GENART Completed: Ready. Reviewer: Matthew Miller.
2015-12-01
12 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2015-12-01
12 Alissa Cooper
[Ballot comment]
This may be because this is not my area, but it wasn't immediately obvious what is meant by "the number of the current …
[Ballot comment]
This may be because this is not my area, but it wasn't immediately obvious what is meant by "the number of the current IPv4 Session" and "the number of the current IPv6 Session." Is that an internal identifier for statistics-gathering purposes? If you think it's worth clarifying, feel free.
2015-12-01
12 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2015-12-01
12 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2015-11-30
12 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2015-11-30
12 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2015-11-25
12 Jean Mahoney Request for Telechat review by GENART is assigned to Matthew Miller
2015-11-25
12 Jean Mahoney Request for Telechat review by GENART is assigned to Matthew Miller
2015-11-24
12 Yu Fu IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2015-11-24
12 Yu Fu New version available: draft-ietf-softwire-dslite-mib-12.txt
2015-11-20
11 Bernie Volz Request for Telechat review by INTDIR Completed. Reviewer: DENG Hui.
2015-11-20
11 Bernie Volz Request for Telechat review by INTDIR Completed: Ready. Reviewer: Carlos Pignataro.
2015-11-20
11 (System) Requested Telechat review by INTDIR
2015-11-17
11 Terry Manderson Placed on agenda for telechat - 2015-12-03
2015-11-17
11 Terry Manderson IESG state changed to IESG Evaluation from Waiting for Writeup
2015-11-17
11 Terry Manderson Ballot has been issued
2015-11-17
11 Terry Manderson [Ballot Position Update] New position, Yes, has been recorded for Terry Manderson
2015-11-17
11 Terry Manderson Created "Approve" ballot
2015-11-17
11 Terry Manderson Ballot writeup was changed
2015-11-15
11 (System) IESG state changed to Waiting for Writeup from In Last Call
2015-11-12
11 Matthew Miller Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Matthew Miller.
2015-11-12
11 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2015-11-12
11 Michelle Cotton
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-softwire-dslite-mib-11.txt. If any part of this review is inaccurate, please let us know.

IANA …
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-softwire-dslite-mib-11.txt. If any part of this review is inaccurate, please let us know.

IANA has questions about the actions to be completed for this document:

In the SMI Network Management MGMT Codes Internet-standard MIBsubregistry of the Network Management Parameters registry located at:

http://www.iana.org/assignments/smi-numbers

The document requests a new MIB will be registered as follows:

Decimal: [ TBD by IANA at time of registration ]
Name: DSLite-MIB
Description: Dual Stack Lite
References: [ RFC-to-be ]

QUESTION TO AUTHORS:  We want to be absolutely sure where this mib assignment goes.  In the IANA Considerations section of the document, it mentions the IANAtunneltype and also transmission.  We see 2 TBDs in the form of

DSLite-MIB        { transmission XXX }
dsLite ("XX")        -- dslite tunnel

Can you clarify the exact request for assignment and which registry?

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.
2015-11-10
11 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Bert Wijnen
2015-11-10
11 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Bert Wijnen
2015-11-05
11 Jean Mahoney Request for Last Call review by GENART is assigned to Matthew Miller
2015-11-05
11 Jean Mahoney Request for Last Call review by GENART is assigned to Matthew Miller
2015-11-05
11 Tero Kivinen Request for Last Call review by SECDIR is assigned to Derek Atkins
2015-11-05
11 Tero Kivinen Request for Last Call review by SECDIR is assigned to Derek Atkins
2015-11-01
11 Amy Vezza IANA Review state changed to IANA - Review Needed
2015-11-01
11 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-softwire-dslite-mib@ietf.org, softwires@ietf.org, softwire-chairs@ietf.org, cuiyong@tsinghua.edu.cn, terry.manderson@icann.org
Reply-To: ietf@ietf.org …
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-softwire-dslite-mib@ietf.org, softwires@ietf.org, softwire-chairs@ietf.org, cuiyong@tsinghua.edu.cn, terry.manderson@icann.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (DS-Lite Management Information Base (MIB)) to Proposed Standard


The IESG has received a request from the Softwires WG (softwire) to
consider the following document:
- 'DS-Lite Management Information Base (MIB)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-11-15. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This memo defines a portion of the Management Information Base (MIB)
  for using with network management protocols in the Internet
  community.  In particular, it defines managed objects for Dual-Stack
  Lite (DS-Lite).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-mib/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-mib/ballot/


No IPR declarations have been submitted directly on this I-D.


2015-11-01
11 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2015-11-01
11 Terry Manderson Last call was requested
2015-11-01
11 Terry Manderson Ballot approval text was generated
2015-11-01
11 Terry Manderson Ballot writeup was generated
2015-11-01
11 Terry Manderson IESG state changed to Last Call Requested from Expert Review
2015-11-01
11 Terry Manderson Last call announcement was generated
2015-11-01
11 Terry Manderson
Carlos Pignataro performed an INT Area review:

Hi,

I am an assigned INT directorate reviewer for draft-ietf-softwire-dslite-mib-11. These comments were written primarily for the benefit …
Carlos Pignataro performed an INT Area review:

Hi,

I am an assigned INT directorate reviewer for draft-ietf-softwire-dslite-mib-11. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/directorate/intarea.html.

This document defines MIB objects to manage DS-Lite solutions, and targets the Standards Track.

Please find some minor review comments:

5.  Difference from the IP tunnel MIB and NATV2-MIB

  Notes: According to section 5.2 of [RFC6333], DS-Lite only defines
  IPv4 in IPv6 tunnels at this moment, but other types of encapsulation
  could be defined in the future.  So this DS-Lite MIB only supports IP
  in IP encapsulation, if another RFC defined other tunnel types in the
  future, this DS-Lite MIB will be updated then.

CMP: Should the above say that this only supports IPv4-in-IPv6?

  The implementation of the IP Tunnel MIB is required for DS-Lite.  The
  tunnelIfEncapsMethod in the tunnelIfEntry should be set to
  dsLite("xx"), and a corresponding entry in the DS-Lite module will
  exist for every tunnelIfEntry with this tunnelIfEncapsMethod.  The
  tunnelIfRemoteInetAddress must be set to "::”.

CMP: Might be useful to add that this is because the tunnel is not point-to-point.

      dsliteAFTRAlarmConnectNumber OBJECT-TYPE
        SYNTAX Integer32 (60..90)
        MAX-ACCESS read-write

CMP: Has this been checked? https://www.ietf.org/iesg/statement/writable-mib-module.html

9.  Security Considerations

  There are a number of management objects defined in this MIB module
  with a MAX-ACCESS clause of read-write and/or read-create.

CMP: I only saw one read-write and no read-create. Are there “a number of …”?

12.2.  Informative References

  [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              .

CMP: Why is RFC 2119 Informative?

I hope these are useful!

Thanks,

— Carlos.
2015-11-01
11 Terry Manderson
Hui Deng performed a INT area review

Hi,

I am an assigned INT directorate reviewer for draft-ietf-softwire-dslite-mib-11. These comments were written primarily for the benefit …
Hui Deng performed a INT area review

Hi,

I am an assigned INT directorate reviewer for draft-ietf-softwire-dslite-mib-11. These comments were written primarily for the benefit of the Internet Area Directors.

Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other

Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/directorate/intarea.html.

This document defines MIB objects to manage DS-Lite solutions, and targets the Standards Track.

Please find some minor review comments:

1) As the coordination with the NATv2-MIB (the draft has not published), the MIB checker reports several errors in this DS-Lite MIB.

2) In section 6.1.1,  “Because some objects defined in the IP Tunnel MIB are not read-write and read-only, a few new objects are defined in DS- Lite MIB.” What is the “read-write” and “read-only”? If it is a special meaning words in MIB, it need a quotation mark here.

3) In page 8,
“dsliteTunnelAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" This object MUST be set to the value of ipv6(2).
It describes the address type of the IPv4-in-IPv6
tunnel initiator and endpoint."
::= { dsliteTunnelEntry 1 }”

There’s no scenario requiring ipv6z(4)?  It needs a REFERENCE to RFC 4001 in this object definition.


4) In page 10, DsliteNATBindEntry: I think dsliteNATBindMappingExtAddressType and dsliteNATBindMappingIntAddressType should just be dsliteNATBindMappingAddressType and apply to both. If all address objects in the row are of the same type, you only need one type object.

5) In page 11, it needs a REFERENCE to RFC 4001 in the definition of dsliteNATBindMappingExtPort.

6) In page 12, it need some description to describe “endpointIndependent, addressDependent, addressAndPortDependent” in more detail in the DESCRIPTION of dsliteNATBindMappingMapBehavior.
The same comments to the “arbitrary, paired” in dsliteMATBindMappingAddressPooling. A REFERENCE is also needed.

7) In page 14, it needs to define a DEFVAL value for dsliteAFTRAlarmConnectionNumber.

8) Whether dsliteStatisticSubscriberIdex is enough or direct to get subscribers' information?

9) I am not very sure what is dsliteStatisticIpv6Session mean? As for IPv6 traffic, there seems no mapping.

10)Whether there has requirement to support multiple instances in DS-Lite?

Best regards,

DENG Hui
2015-10-14
11 (System) Notify list changed from draft-ietf-softwire-dslite-mib@ietf.org, draft-ietf-softwire-dslite-mib.ad@ietf.org, softwire-chairs@ietf.org, cuiyong@tsinghua.edu.cn, draft-ietf-softwire-dslite-mib.shepherd@ietf.org to (None)
2015-10-07
11 Terry Manderson IESG state changed to Expert Review from Publication Requested
2015-10-02
11 Amy Vezza Notification list changed to draft-ietf-softwire-dslite-mib@ietf.org, draft-ietf-softwire-dslite-mib.ad@ietf.org, softwire-chairs@ietf.org, cuiyong@tsinghua.edu.cn, draft-ietf-softwire-dslite-mib.shepherd@ietf.org from "Yong Cui" <cuiyong@tsinghua.edu.cn>
2015-10-01
11 Yong Cui
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Intended status: Standards Track
This document defines the MIB for DS-Lite.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

Dual-stack Lite (DS-Lite) [RFC6333] is a transition technique that
enable operators to multiplex public IPv4 addresses while
provisioning only IPv6 to users. This document defines the related
the Management Information Base (MIB) for using with network
management protocols in the Internet community.  This MIB module
may be used for configuration and monitoring devices in a Dual-Stack
Lite scenario.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

This document was discussed in depth and well-reviewed,
including MIB doctor review.
The WG achieves the consensus to publish this document.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

I'm not aware of any implementation for the MIB. DS-Lite is an
important protocol for IPv4/IPv6 coexistence, while its MIB
should be the basis to support the management of DS-Lite.
The document has addressed all the concerns raised by the WG
and the MIB Doctor.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?
Softwire co-chair, Yong Cui, is the Document Shepherd.
Terry Manderson is the Responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document is well writen and ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

N/A

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR issue.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The WG consensus is achieved and all of the related active
participants agree on the advancement of this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No errors, flaws or warnings.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

MIB Doctor has reviewed the document and then the document has been
revised accordingly.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

This document needs new IANA-assigned OBJECT IDENTIFIER and new
IANA-assigned tunnelType.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

The automated check shows some issues because some definitions in
this document depend on draft-perrault-behave-natv2-mib-05, which is
now in the RFC Editor Queue. So we can ignore the issues.
2015-10-01
11 Yong Cui Responsible AD changed to Terry Manderson
2015-10-01
11 Yong Cui IETF WG state changed to Submitted to IESG for Publication from WG Document
2015-10-01
11 Yong Cui IESG state changed to Publication Requested
2015-10-01
11 Yong Cui IESG process started in state Publication Requested
2015-10-01
11 Yong Cui Changed document writeup
2015-10-01
11 Yong Cui Notification list changed to "Yong Cui" <cuiyong@tsinghua.edu.cn>
2015-10-01
11 Yong Cui Document shepherd changed to Yong Cui
2015-10-01
11 Yong Cui Tag Awaiting Expert Review/Resolution of Issues Raised cleared.
2015-10-01
11 Yong Cui Intended Status changed to Proposed Standard from None
2015-09-30
11 Yu Fu New version available: draft-ietf-softwire-dslite-mib-11.txt
2015-09-24
10 Yu Fu New version available: draft-ietf-softwire-dslite-mib-10.txt
2015-03-25
09 Yu Fu New version available: draft-ietf-softwire-dslite-mib-09.txt
2015-02-08
08 Yu Fu New version available: draft-ietf-softwire-dslite-mib-08.txt
2014-12-29
07 Yu Fu New version available: draft-ietf-softwire-dslite-mib-07.txt
2014-07-02
06 Yu Fu New version available: draft-ietf-softwire-dslite-mib-06.txt
2014-04-28
05 Sheng Jiang New version available: draft-ietf-softwire-dslite-mib-05.txt
2013-11-04
04 Yu Fu New version available: draft-ietf-softwire-dslite-mib-04.txt
2013-11-02
03 Suresh Krishnan IETF WG state changed to WG Document from In WG Last Call
2013-11-02
03 Suresh Krishnan Annotation tag Awaiting Expert Review/Resolution of Issues Raised set.
2013-08-28
03 Yu Fu New version available: draft-ietf-softwire-dslite-mib-03.txt
2013-05-23
02 Suresh Krishnan IETF WG state changed to In WG Last Call from WG Document
2013-02-25
02 Yu Fu New version available: draft-ietf-softwire-dslite-mib-02.txt
2013-01-10
01 Yu Fu New version available: draft-ietf-softwire-dslite-mib-01.txt
2012-07-16
00 Cindy Morgan New version available: draft-ietf-softwire-dslite-mib-00.txt