Subject: Draft-ietf-nasreq-ext-radiuspract-02.txt

From: "David Mitton" <[email-masked]>
Date: Thu, 17 Feb 2000 14:43:15 -0500

Changes To ietf-draft-nasreq-ext-radpract-01.txt
------

At the last WG meeting (Nov 99, DC), there were comments
from the floor requesting changes in this draft.

The primary complaints were;
- It should not name vendor's names,
- It does not adequately represent the vendor's products as
they update,
- It contains significantly out-dated references,

1) The AD asked if the vendor's names added value, and my
response was yes.  Anytime I discuss this topic with anyone,
they always wanted to know whom did what.  This is always
important to people, as they attempt to judge the impact of
such functions on their environment.  And it provides a way
to find out more about the feature from the vendor's own
documentation.  Coincidentally, I just before the meeting I
had received an email request from my co-chair asking about
one of the features in the prior version where I had _not_
identified the implementing vendor.

      In any case, I have removed almost all mentions of
vendors with respect to functions.

2) I am really baffled as to how it would be possible for
any IETF document to continually stay current with
implementations after it's been published.  The whole point
of naming versions is to lock the description to a given
time in the past.  Future readers will be able to refer to
the publication date and the version number in order to
figure out when the information was reviewed by the group.
I would like an example of any BCP type RFC which has been
updated past it's issuance date and if that is even relevant
to this case.

      In any case, I have removed all mention of specific
version numbers.  The several existing disclaimers of being a
reference document have been wordsmithed some more.

3) Looking through what I've actually written in the draft,
I actually find very few of the references called out.   I
mostly just tacked a list of my favorite IETF documents on
the end.  Certainly none of them is "normative" to this
document, as it's an informational work about non-standard
practices.

Looking over the list of documents in the reference section,
I could only find two that were not available.
So I have removed these, as there are other ways to
communicate that information.

      [16] G. Zorn, "Yet Another Authentication Protocol
      (YAAP)", draft-zorn-yaap-01.txt, 30 June 1996
      Is now acknowledged more properly in the draft-ietf-
      nasreq-criteria-03.txt document which is more
      appropriate to it's subject.

      And, [17] N. Greene, "Best Current Practice for Modem
      Outsourcing", draft-greene-nasreq-00.txt, March 1998,
      in which the concept was relevant, but the approach had
      nothing to do with RADIUS.

I have also removed other various document listings, as I
realized they were not particularly supporting to this
document as well.

If there are any other errors or updates to the references
of this documents, or any other work item with this group,
please send me email.  I would like to move this document to
Working Group Last Call.

Thanks,
      Dave.

---------------------------------------------------------------
David Mitton                                  ESN: 248-4570
Advisor, Nortel Networks                      978-288-4570 Direct
Carrier Packet Solutions, Preside             978-288-3030 FAX
Billerica, MA 01821                    [email-masked]