Subject: RE: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 docu ments

From: "C. M. Heard" <[email-masked]>
Date: Mon, 1 Sep 2003 10:53:53 -0700 (PDT)

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

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 1 Sep 2003 20:20:51 +0200

> This same comment applies also for RFCs 2011, 2012, and 2096.
Yep I saw that later. And indeed your remarks make sense now.
Thanks for clarifying and elaborating. So you can ignore those
hints to add ptrs about work-in-progress and such in sect 5.
And same for some other similar comments from my side.

Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 5 Sep 2003 00:37:49 +0200

Mmm... I wanted to chime in earlier but was (too) busy with 
other (mainly IETF/IESG related) work.

I believe I see people converging which is good.

But I do want to state my support for trying to get the
doc accurate and clean and to not have it list issues
with now obsoleted or historic documents. That seems to
me to be "editorial" changes, so should be easy.

Of course I would also like to see thing fixed/corrected where
the statement were not correct (I am not blaming the author(s),
after all not everyone is a MIB expert). That is why I asked
MIB doctors to take a look at it. Thanks to Mike!

Thanks,
Bert 

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]]
> Sent: donderdag 4 september 2003 22:06
> To: C. M. Heard
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01
> documents
> 
> 
> Hi,
> 
> First of all, let me give a conclusion reached during an 
> off-list thread 
> with you and the document editors.
> 
> We seem to be in agreement that the Historic documents should 
> be removed,
> and those documents which have been obsoleted (should be only 
> those which
> have been done after RFC3200 or so) be updated to point to 
> the most recent
> versions.
> 
> I'll respond to other points inline (which don't seem more or less
> trivial); I'll remove those which are moot with this agreement.
> 
> Andreas, if you have time, please try to edit the ops 
> document to address
> the concerns and text updates soon and pass it over by Mike 
> when done or
> when trying to figure out what kind of wording to put in 
> there.  That way
> we can (hopefully) get the loop closed pretty fast, and 
> minimize the risk
> of having comments fall through the cracks.
> 
> I think we can go off-list for further issues, and come back to 
> ops-area/v6ops after we have a new shiny revision of the 
> document ready 
> :-)
> 
> Thanks for the work, everybody, especially the MIB folks.
> 
> (Mike, if you'd like, I think it would be fair to add you as 
> a co-editor
> of the document due to the huge amount of effort you've 
> poured into it,
> but it's as you prefer.)
> 
> On Wed, 3 Sep 2003, C. M. Heard wrote:
> > >  2) protocol/specification.  I totally agree that we 
> should refer the
> > > RFC's by "specification" because that's generic enough to 
> cover any RFC.
> > > 
> > >  3) MIB acronyms like TRANS-MIB in:
> > > 
> > >  3.9 RFC 3417 Transport Mappings for Version 2 of the 
> Simple Network
> > >       Management Protocol (SNMPv2) (TRANS-MIB)
> > > 
> > >  .. these do not appear in the original RFC's, but are invented by
> > > RFC-editor for some RFC indexes.  My opinion is that we should get
> > > rid of these bogus abbreviations completely, but I would also be
> > > OK with it if they're changed to be correct.  Whatever works for
> > > you..
> > 
> > Getting rid of the acronyms and relying on RFC title and number
> > alone would suit me just fine.  But if they remain the acronyms must
> > be the right ones (MIB module names in the case of MIB modules).
> > Note that in some cases an acronym appears twice, once in the
> > original title, and the once again and the MIB or protocol name;
> > in those cases remove only the second occurrence.
> 
> Agreed, in all counts.  Let's remove the RFC-editor's 
> "invented" names 
> entirely.
>  
> > > But I think we can address this situation in practical 
> terms.  Where
> > > applicable, add notions about these documents in the 
> "analysis", section
> > > 7, like:
> > > 
> > >   7.3.18  Coexistence of SNMP v1, v2, & v3 (RFC 2576)
> > > 
> > >     There are no real issues that can be resolved.
> > > 
> > >   ==> add a sentence like:
> > > 
> > >     The document is obsoleted by RFC 3584.
> > > 
> > >  (or something else, if RFC3584 addresses the concerns)
> > > 
> > > .. that way, we could have somekind of a "forward pointer" even to
> > > informational/BCP documents which may be relevant.
> > > 
> > > Would this satisfy your concern?  If so, could you submit 
> some wording
> > > that would be appropriate for these cases?
> > 
> > I'm not too keen on the specific suggestion above.  But, given your
> > lack of resources, I can accept that you would only address the
> > specific documents mentioned above (namely RFCs 1212, 1215, and
> > 3584).  I can also accept the following editorial strategy:
> > mention RFC 1215 in conjunction with 1155 and 1212 (since together
> > they form a package, and really are part of the same de-facto
> > standard), replace all mentions of RFC 2576 with RFC 3584, move RFC
> > 3584 to Section 3, and re-title Section 3 as follows:
> > 
> >       3.0 Full Standards and BCPs
> > 
> > That would entail an addition to the lead-in text of that section:
> > 
> > > > | Full Internet Standards (most commonly simply referred to as
> > > > | "Standards") are fully mature protocol specification 
> that are widely
> > > > | implemented and used throughout the Internet.
> > 
> >       The OPS area has one technical specification (RFC 
> 3584) which is
> >       classified as a Best Current Practice, or BCP.  That 
> is another
> >       "terminal" classification.  It  was used for this specfication
> >       because it was deemed mature and unlikely to see 
> further evolution,
> >       but did not meet the formal requirements for Full Standard.
> 
> s/specfication/specification/
> 
> > Suggested text for the other stuff will appear below.
> 
> This would be a special case for including BCP's (other areas don't
> include them because analyzing them would be more work..), but you
> strongly prefer having it in here, I guess we can agree to 
> that, as long
> as you provide the text :-)
> 
> Personally I'd just like to handwave it away (somehow), for 
> consistency 
> reasons, but I understand if you'd like to have it included 
> explicitly.
> 
> > > > | 3.1 RFC 1157 Simple Network Management Protocol
> > > > | 
> > > > | Beginning in Section 3.2.6.3.2 atTable Object Type 
> Names thru the rest
> > > > | of Section 3 there are numerous references to the use 
> of IPv4 addresses
> > > > | as part of OIDs.
> > 
> > OK, if we want to keep this one (which would be justified 
> because of its
> > wide deployment) then make this fix:
> > 
> > s/as part of OIDs/for identification of object instances/
> > 
> > Technically, the use of the term "OIDs" is correct here, but I much
> > prefer the more precise language.
> 
> It's historic, and could be removed due to the policy.. but if you'd 
> prefer to have it enabled, we could reword the text (and 
> resolution in 
> section 7) to your liking.
> 
> > > > | 5.058 RFC 2493 Textual Conventions for MIB Modules Using
> > > > |       Performance History Based on 15 Minute Intervals
> > > > | 
> > > > | There are no IPv4 dependencies in this specification.
> > > > 
> > > > Note:  this document is due to be replaced by RFC 3593,
> > > > which will be a Draft Standard and will have the same title.
> > 
> > That has now happened:  the announcement has just been sent to the
> > IETF-Announce list, and RFC 3593 is now available in the on-line
> > repositories since yesterday.  So, please change the RFC number from
> > 2493 to 3593 and move this sub-section from the PS part to the DS
> > part.  Yes, I know this contradicts your minimal change doctrine but
> > I don't agree with that doctrine.
> 
> Good.. because now we have agreed to a close-to-minimal 
> change doctrine 
> :-), which should be sufficiently low-overhead for us, while 
> enhancing the 
> reader's usability of the document.
> 
> > > > | 5.068 RFC 2562 Definitions of Protocol and Managed Objects for
> > > > |       TN3270E Response Time Collection Using SMIv2 
> (TN3270E-RT-MIB)
> > > > |       (TN2370E-RT)
> > > > 
> > > > remove "(TN3270E-RT)" at the end
> > > 
> > > remove both ? :-)
> > 
> > No, "(TN3270E-RT-MIB)" is actually part of the official title.
> 
> ok.
> 
> > > > | 5.092 RFC 2726 PGP Authentication for RIPE Database Updates
> > > > | 
> > > > Is this actually an OPS Area specification?
> > > 
> > > this could be moved to security, that's true.  however, 
> we felt that RPSL
> > > was so strongly OPS stuff, so this could logically belong here too
> > > (doesn't really matter as there are no dependencies).
> > 
> > I was just asking.  If you think it's in the right place leave it
> > (RPSL evidently is, according to Bert Wijnen).
> 
> Ok.
> 
> > > > | 5.113 RFC 2959 Real-Time Transport Protocol Management
> > > > |       Information Base
> > > > | 
> > > > | There are numerous uses of the included TAddress 
> Syntax which is
> > > > | IPv4 dependent as noted above.
> > > > | 
> > > > | For example:
> > ...
> > > > | There are a total of 8 instances of this.
> > > > 
> > > > As explained above under 5.093, this does not 
> necessarily mean that
> > > > there is an IPv4 dependency.  Please re-evaluate this 
> MIB module and
> > > > update this section accordingly.  I'd bet that this 
> spec doesn't really
> > > > have any IPv4 dependencies after all.
> > > 
> > > we don't have resources for re-evaluation, unfortunately. 
>  unless someone
> > > more knowledgeable does it, we'll have to keep it as is.
> > 
> > OK, I just had a quick look at this RFC and it looks OK to 
> me ... the
> > object rtpSessionDomain, which is of type TDomain, allows 
> IPv6 transport
> > to be represented by all the TAddress objects.  So here's 
> the rewrite:
> > 
> >       5.113 RFC 2959 Real-Time Transport Protocol Management
> >             Information Base
> > 
> >       There are no IPv4 dependencies in this specification.
> > 
> > (modulo a probable sub-section number change).
> 
> nice.
> 
> > > > I agree with the 2nd sentence, except
> > > > that the draft is now draft-ietf-rip-mib-01.txt;  it 
> stands alone
> > > > quite nicely.
> > > 
> > > the draft name you mentioned is the same as listed, 
> perhaps you meant
> > > something else? (btw, the draft has expired in the meantime)
> > 
> > I think I meant to say draft-ietf-rip-mib-02.txt but as you 
> say that's
> > only a note saying that the draft has expired and the WG 
> has concluded.
> > So how about this:
> > 
> >       7.2.3 RIPv2 MIB (RFC 1724)
> > 
> >       There is no updated MIB module to cover the problems 
> outlined.  A
> >       new MIB module should be defined.
> 
> ok
> 
> > Thank you for yout detailed reply.  I hope that I have strong-armed
> > you into making a few more changes than your "minimum update" policy
> > would mandate, maybe with the help of the carrot of providing some
> > actual text :-)
> 
> Right.  Thanks for your persistence, perhaps it is for the best :-)
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> 
> 
> 
> 
> 
>