[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



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:pekkas@netcore.fi]
> Sent: donderdag 4 september 2003 22:06
> To: C. M. Heard
> Cc: v6ops@ops.ietf.org; ops-area@ops.ietf.org; 
> andreas.bergstrom@hiof.no
> 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
> > > > | 
> > > > | There are no IPv4 dependencies in this protocol.
> > > > 
> > > > 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
> 
> 
> 
> 
> 
> 
>