[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 docu ments
On Mon, 1 Sep 2003, Wijnen, Bert (Bert) wrote:
> Mike, thanks for your detailed review.
> I have a few additional comments inline.
I have some clarifications to add for a few of those items.
> > | 3.2 RFC 1155 Structure of Management Information
...
> > There should also be a subsection for RFC 1212, and perhaps also RFC
> > 1215, since RFCs 1155 and 1212 form STD 16, and together with RFC
> > 1215 define SMIv1.
> >
> It might also be good/wise to mention that SMIv1 is currently still at
> STD level because some other documents at STD or DRAFT STD level still
> depend on it. But there is NO new work being done based on the SMIv1
> STD, and (at least all IETF standards track) work is now using the
> new SMIv2 document set.
I agree with that suggestion. Note that the text I proposed for the
analysis section 7.1.1 makes reference to the "NO new work" part, as
it states that "the limitations identified in this Internet Standard
do not require any action."
As an aside, I'll mention that part of the reasoning applies also to
RFC 1213 (MIB-II): a number of STD or DRAFT STD level still depend
on it, too, so it will probably never be retired, either. But that
probably doesn't need to be mentioned in the survey doc since there
is at present a stronger reason: we don't yet have replacements for
the IP group, the ICMP group, the TCP group, and the UDP group,
although that is being worked on.
> > | 3.8 RFC 3416 Protocol Operations for Version 2 of the Simple Network
> > | Management Protocol (SNMPv2) (OPS-MIB)
> >
> > Remove "(OPS-MIB)" ... the mnemonic is misleading, as this document
> > does not contain a MIB module. See also the note below.
> >
...
> >
> > | 3.9 RFC 3417 Transport Mappings for Version 2 of the Simple Network
> > | Management Protocol (SNMPv2) (TRANS-MIB)
> >
> > NOTE: I would like to suggest that it is more useful in the case
> > of standards that contain a single MIB module to use the MIB module
> > names instead of the sometimes strange and seldom-used mnemonics
> > that are listed in STD 1, Official Internet Protocol Standards.
> > I will be making this suggestion for each spec that contains a
> > single MIB module; in the present case the change would be:
> >
> > s/TRANS-MIB/SNMPv2-TM/
> >
> I agree with Mike.
> Please do NOT invent your own "MIB-XXX" names that do not exist.
In fairness to the authors, it seems that it was this practice
originated in STD 1, Official Internet Protocol Standards --
currently RFC 3300 -- where the RFC Editor staff appear to have
made up the acronyms and was carried forward into this document.
For instance, it says in RFC 3300:
3.3. Draft Standard Protocols
Mnemonic Title RFC#
------------------------------------------------------------------------
[ ... ]
INTERGRMIB The Interfaces Group MIB 2863
-------- Host Resources MIB 2790
SNMP Definitions of Managed Objects for Extensible 2742*
SNMP Agents
-------- Agent Extensibility (AgentX) Protocol Version 1 2741*
[ ... ]
VACM-SNMP View-based Access Control Model (VACM) for 2575
the Simple Network Management Protocol (SNMP)
USM-SNMPV3 User-based Security Model (USM) for version 2574
3 of the Simple Network Management Protocol (SNMPv3)
SNMP-APP SNMP Applications 2573
MPD-SNMP Message Processing and Dispatching for the 2572
Simple Network Management Protocol (SNMP)
ARCH-SNMP An Architecture for Describing SNMP Management 2571
Frameworks
[ ... ]
SNMPv2-MIB Management Information Base for Version 2 1907
of the Simple Network Management Protocol (SNMPv2)
TRANS-MIB Transport Mappings for Version 2 of the Simple 1906
Network Management Protocol (SNMPv2)
OPS-MIB Protocol Operations for Version 2 of the Simple 1905
Network Management Protocol (SNMPv2)
I squawked about using INTERGRMIB instead of IF-MIB for RFC 2863,
about using SNMP for any MIB module, about using OPS-MIB for RFC
1905 (now 3416), about using TRANS-MIB instead of SNMPv2-TM, and
about many other such things. I didn't squawk about VACM-SNMP,
USM-SNMPV3, SNMP-APP, MPD-SNMP, ARCH-SNMP, or any acronym for a
non-MIB document unless it was clearly wrong, like OPS-MIB.
I'm not sure if it would pay to pick a fight with the RFC Editor
about this practice, but I also don't think it's a good idea to
follow the practoce in the case of MIB modules because no-one in the
MIB community does so. I know quite well that IF-MIB means the MIB
module in RFC 2863, but I'd have had no clue what INTERGRMIB meant
if I hadn't seen it in RFC 3300. That's why I raised this issue.
> > | 5.033 RFC 2013 SNMPv2 Management Information Base for the User
> > | Datagram Protocol using SMIv2 (MIB-UDP)
> >
> > s/MIB-UDP/UDP-MIB/
> >
> > | A number of OIDs in this MIB assumes IPv4 addresses, as is noted in
> > | the note reproduced below:
> >
> > s/OIDs/object definitions/
> >
> > | IESG Note:
> > |
> > | The IP, UDP, and TCP MIB modules currently support only IPv4. These
> > | three modules use the IpAddress type defined as an OCTET STRING of
> > | length 4 to represent the IPv4 32-bit internet addresses. (See RFC
> > | 1902, SMI for SNMPv2.) They do not support the new 128-bit IPv6
> > | internet addresses.
> > |
> Might want to add another editors note that RFC1902 has been obsoleted
> by RFC2578 (STD 58) in the meantime.
>
> Would it make sense to mention that IPv6 WG is working on this?
> (In fact they are getting close to deliver a replacement document
> I believe).
Hmm, I think that might be a distraction here. My understanding is
that the authors intended for this section only to report the "raw
data" ... all the analysis is in Section 7. And the text in that
section (with the proposed edits) does address both of those points.
This same comment applies also for RFCs 2011, 2012, and 2096.
> > | radiusAuthServerAddress OBJECT-TYPE
> > | SYNTAX IpAddress
> > | MAX-ACCESS read-only
> > | STATUS current
> > | DESCRIPTION
> > | "The IP address of the RADIUS authentication server
> > | referred to in this table entry."
> > | ::= { radiusAuthServerEntry 2 }
> > |
> > | There needs to be an update to allow an IPv6 based OID for this
> > | value.
> > |
> s/OID/object/
>
> Mike... you seem to have forgotten/missed this one?
> Or Mike would probably say:
>
> Reword with:
> This object needs to be deprecated and replaced by one that
> supports both IPv4 and IPv6 addresses.
>
> And I agree.
Yep, I missed that.
> > | 5.086 RFC 2669 DOCSIS Cable Device MIB Cable Device Management
> > | Information Base for DOCSIS compliant Cable Modems and
> > | Cable Modem Termination Systems
> > |
> > | This document states:
> > |
> > | Please note that the DOCSIS 1.0 standard only requires Cable
> > | Modems to implement SNMPv1 and to process IPv4 customer traffic.
> > | Design choices in this MIB reflect those requirements. Future
> > | versions of the DOCSIS standard are expected to require support
> > | for SNMPv3 and IPv6 as well.
> > |
> And in fact a new revision is being worked on by IPCDN as we speak.
Section 7.3.23 mentions that fact.
> > | 5.097 RFC 2749 COPS usage for RSVP
> > |
> > | There are no IPv4 dependencies in this protocol.
> > |
> > | 5.098 RFC 2769 Routing Policy System Replication (RPSL)
> >
> > remove "(RPSL)"
> >
> > | There are no IPv4 dependencies in this protocol.
> >
> > Is this an OPS Area spec? It looks like a routine area
> > spec to me.
> >
> Routine Area? Or Routing area?
That's an amusing typo :-)
> In any event, the document was done in a WG that used to be in
> the OPS Area... Oh well.
OK, then it's probably listed in the right place. I was just asking
because I wasn't sure.
> > | 5.107 RFC 2925 Definitions of Managed Objects for Remote
> > | Ping, Traceroute, and Lookup Operations
...
> > | pingCtlDataSize OBJECT-TYPE
> > | SYNTAX Unsigned32 (0..65507)
> > | UNITS "octets"
> > | MAX-ACCESS read-create
> > | STATUS current
> > | DESCRIPTION
> > | "Specifies the size of the data portion to be
> > | transmitted in a ping operation in octets. A ping
> > | request is usually an ICMP message encoded
> > | into an IP packet. An IP packet has a maximum size
> > | of 65535 octets. Subtracting the size of the ICMP
> > | or UDP header (both 8 octets) and the size of the IP
> > | header (20 octets) yields a maximum size of 65507
> > | octets."
> > | DEFVAL { 0 }
> > | ::= { pingCtlEntry 5 }
> > |
> > |
> > | traceRouteCtlDataSize OBJECT-TYPE
> > | SYNTAX Unsigned32 (0..65507)
> > | UNITS "octets"
> > | MAX-ACCESS read-create
> > | STATUS current
> > | DESCRIPTION
> > | "Specifies the size of the data portion of a traceroute
> > | request in octets. A traceroute request is essentially
> > | transmitted by encoding a UDP datagram into a
> > | IP packet. So subtracting the size of a UDP header
> > | (8 octets) and the size of a IP header (20 octets)
> > | yields a maximum of 65507 octets."
> > | DEFVAL { 0 }
> > | ::= { traceRouteCtlEntry 6 }
> > |
> > | There is clearly an assumption of IPv4 header sizes.
> >
> > Please rewrite this last sentence:
> >
> > The DESCRIPTION clauses need to be updated to remove the
> > IPv4 dependencies.
> >
> > Note that there is nothing wrong with the objects themselves.
I guess that's true ... and the only change that's needed is:
s/size of a IP header/minimum size of a IP header/
since the minimum size of any IP header (v4 or v6) is 20 octets
(the smalled IPv6 header is 40 octets). But that detail probably
doesn't need to go into the survey document.
Once again, let me say that despite all the criticism we owe the
authors of this draft a big debt of gratitude for all the hard
work in collecting this valuable information. I hope that our
comments will serve to make the work better.
Thanks,
Mike Heard