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

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

> > > | 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.
> 
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