rfc1207.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

User Services Working Group                                     [Page 5]

RFC 1207        FYI Q/A - for Experienced Internet Users   February 1991


      These problems have been related to TCP connections, NS RRs with
      small TTLs, and several other causes.  Experience suggests that
      the style of bug fixing has often been that of reducing the
      problem by 90% rather than eliminating it.

      IBM's support for the DNS (outside of UNIX systems) is interesting
      in its techniques, encouraging in its improvement, but still
      somewhat depressing when compared to most other DNS software.  IBM
      also uses terminology that varies somewhat from the usual DNS
      usage and preserves some archaic syntax, e.g., "..".

      The combination of an old BIND and an old IBM server is just plain
      unpleasant.

   6.3. Is the model used by the domain name system for host names
        that the owner of a name gets to choose its case?

      The model used by the DNS is that you get to control at a specific
      point in the name space, and are hence free to select case as you
      choose, until points where you in turn give away control.  As a
      practical matter, there are several implementations that don't do
      the right thing.  IBM implementations often map everything into a
      single case.

   6.4. According to RFC 1034 [2], section 4.2.1, one should not have
        to code glue RR's for name server's names unless they are below
        the cut.  When I don't put glue RR's in, and do a query for
        NS records, the "additional" field is left blank.  As far as I
        can tell, all other zones I query for NS records have this
        filled with the IP addresses of the NS hosts.  Is this required
        or should I not be concerned that the additional field is empty?

      The protocol says that an empty additional field is not a problem
      when the name server's name is not "below" the cut.

      In practice, putting in the glue where it is not required can
      cause problems if the servers named in the glue are used for
      several zones.  This is broken behavior in BIND.  Not putting in
      glue can cause other problems in BIND, usually when the server
      name is difficult to resolve.  So, the bottom line is to put glue
      in only when required, and don't use aliases or anything else
      tricky when it comes to identifying name servers.









User Services Working Group                                     [Page 6]

RFC 1207        FYI Q/A - for Experienced Internet Users   February 1991


7. Questions About Network Management Implementations

   7.1. In reading the SNMP RFCs [3,4,5,6] I find mention of
        authentication of PDUs.  Are there any standards for
        authentication mechanisms?

      There is a working group of the IETF that is working on this
      problem.  They are close to a solution, but nothing has yet
      reached RFC publication yet.  Expect something solid and
      implementable by October of 1991.

   7.2. Can vendors make their enterprise-specific variables available
        to users through a standard distribution mechanism?

      Yes.  But before someone submits a MIB, they should check it out
      themselves.

      On uu.psi.com in pilot/snmp-wg/, there are two files

              mosy-sparc-4.0.3.c

              mosy-sun3-3.5

      The first will run on a Sun-Sparc, the second will run on a Sun-3.
      After retrieving one of these files in BINARY mode via anonymous FTP,
      the submittor can run their MIB through it, e.g.,

              % mosy mymib.my

      Once your MIB passes, send it to:

              [e-mail]

      If everything is OK, the mib-checker will arrange to have it
      installed in the /share/ftp/mib directory on venera.isi.edu.

      Note: This processing does not offer an official endorsement.  The
      documents submitted must not be marked proprietary, confidential,
      or the like.

   7.3. I have a question regarding those pesky octet strings again.
        I use the variable-type field of the Response pdu to determine
        how the result should be displayed to the user.  For example,
        I convert NetworkAddresses to their dotted decimal format
        ("132.243.50.4").  I convert Object Identifiers into strings
        ("1.3.6.1.2....").

        I would LIKE to just print Octet Strings as strings.  But,



User Services Working Group                                     [Page 7]

RFC 1207        FYI Q/A - for Experienced Internet Users   February 1991


        this causes a problem in such cases as atPhysAddress in
        which the Octet string contains the 6 byte address instead
        of a printable ASCII string.  In this case, I would want to
        display the 6 bytes instead of just trying to print the
        string.

        MY QUESTION IS: Does anyone have a suggestion as to how I
        can determine whether I can just print the string or whether
        I should display the octet bytes.  * Remember: I want to
        support enterprise specific variables too.

      In general, there is no way that you can tell what is inside an
      OCTET STRING without knowing something about the object that the
      OCTET STRING comes from.  In MIB-II [6], some objects are marked
      as DisplayString which has the syntax of OCTET STRING but is
      restricted to characters from the NVT ASCII character set (see the
      TELNET Specification, RFC 854 [7], for further information).
      These objects are:

         sysDescr
         sysContact
         sysName
         sysLocation
         ifDescr

      If you want to be able to arbitrarily decide how to display the
      strings, without knowing anything about the object, then you can
      scan the octets, looking for any octet which is not printable
      ASCII.  If you find at least one, you can print the entire string,
      octet by octet, in "%02x:" notation.  If all of the octets are
      printable ASCII, then you can just printf the string.

   7.4. If archived MIBs must be 1155-compatible [3], it would be nice
        if those who submit them check them first.  Where are these
        MIB tools available for public FTP?  Ideally, a simple
        syntax checker (that didn't actually generate code) would be
        nice.

      In the ISODE 6.0 release there is a tool called MOSY which
      recognizes the 1155 syntax and produces a flat ASCII file.  If you
      can run it through MOSY without problems then you are OK.

   7.5. Suppose I want to create a private MIB object for causing
        some action to happen, say, do a reset.  Should the syntax
        or this object specify a value such as:






User Services Working Group                                     [Page 8]

RFC 1207        FYI Q/A - for Experienced Internet Users   February 1991


         Syntax:
            INTEGER {
               perform reset (1),
            }

        even though there is only a single value?  Or, is it ok to
        just allow a Set on this object with any value to perform
        the desired action?  If the later, how is this specified?

      For our SNMP manageable gizmos and doohickies with similar
      "action" type MIB variables, I've defined two values

            Syntax:
               INTEGER {
                  reset(1)
                  not-reset(2)
               }

      And defined behavior so that the only valid value that the
      variable may be set to is "reset" (which is returned in the get
      response PDU) and at all other times a get/getnext will respond
      with "not-reset".

8. Questions about Serial Line Internet Protocol (SLIP) and
   Point-to-Point Protocol (PPP) Implementations

   8.1. I seem to recall hearing that SLIP [8] will only run on
        synchronous serial lines.  Is this true?  ... is there
        something about SLIP which precludes it's being implemented
        over async lines?

      Other way around:  SLIP is designed for async lines and is not a
      good fit on sync lines.  PPP [9, 10] works on either, and is what
      you should be implementing if you're implementing something.

   8.2. Since we are very interested in standards in this area,
        could someone tell me were I can find more information on PPP?

        Also, can this protocol be used in other fields than for the
        Internet (i.e., telecontrol, telemetering) where we see a
        profusion of proprietary incompatible and hard to maintain
        Point-to-Point Protocols?

      PPP was designed to be useful for many protocols besides just IP.
      Whether it would be useful for your particular application should
      probably be discussed with the IETF's Point-to-Point Protocol
      Working Group discussion list.  For general discussion: ietf-
      [e-mail].  To subscribe: [e-mail]



User Services Working Group                                     [Page 9]

RFC 1207        FYI Q/A - for Experienced Internet Users   February 1991


      The PPP specification is available as RFC 1171 [9], and a PPP
      options specification is available as RFC 1172 [10].

      In UnixWorld of April 1990 (Vol. VII, No. 4, Pg. 85), Howard
      Baldwin writes:

         "Point-to-Point Protocol (PPP) has just been submitted to the
         CCITT from the Internet Engineering Task Force.  It specifies a
         standard for encapsulating Internet Protocol data and other
         network layer (level three on ISO's OSI Model) protocol
         information over point-to-point links; it also provides ways to
         test and configure lines and the upper level protocols on the
         OSI Model.  The only requirement is a provision of a duplex
         circuit either dedicated or switched, that can operate in
         either an asynchronous or synchronous mode, transparent to the
         data-linklayer frame.

         "According to Michael Ballard, director of network systems for
         Telebit, PPP is a direct improvement upon Serial Line Internet
         Protocol (SLIP), which had neither error correction nor a way
         to exchange network address."

   8.3. Does anyone know if there is a way to run a SLIP program on
        a IBM computer running SCO Xenix/Unix, with a multi-port
        serial board?

      SCO TCP/IP for Xenix supports SLIP.  It works.  However, be
      warned: SCO SLIP works *only* with SCO serial drivers, so it will
      *not* work with intelligent boards that come with their own
      drivers.  If you want lots of SLIP ports, you'll need lots of dumb
      ports, perhaps with a multi-dumb-port board.

      Here's the setup -- SunOS 3.5, with the 4.3BSD TCP, IP & SLIP
      distributions installed.  Slip is running between the "ttya" ports
      of two Sun 3/60's.  "ping", "rlogin", etc., works fine, but a NFS
      mount results in "server not responding: RPC Timed Out".

      SunOS 3.5 turns the UDP checksum off, which is legal and works
      okay over interfaces such as ethernet which has link- level
      checksumming.  On the other hand, SLIP doesn't perform checksums
      thus running NFS over SLIP requires you to turn the UDP checksum
      on.  Otherwise, you'll experience erratic behavior such as the one
      described above.








User Services Working Group                                    [Page 10]