[rfc-i] on tooling

Fred Baker fred at cisco.com
Tue Mar 27 23:55:46 PDT 2012


In yesterday's BOF, as one might expect, there was a great deal of discussion on tools. Henrik closed with a comment to the effect that much of what we discussed was about the output format, and the output format was something that could be managed with tools. I agree and disagree; tools, yes, but I'm not sure there was a universal concord on the output format. 

I appreciated John Levine's comments on "what do we want to do with the document when we see them". We all said that we grepped documents; I have a personal tool that I find useful that can be thought of as a grep for a paragraph as opposed to a line, on which I build other tools. For example, I have a tool that I use to find a reference to an RFC or internet draft that starts from an index and tells me the citation. Here are some examples:

-----------------------------------------------------------------------------------
[Freds-Computer:~/draft] fred% rfc 'dual-stack li'
https://tools.ietf.org/html/rfc6333
6333 Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion.
     A. Durand, R. Droms, J. Woodyatt, Y. Lee. August 2011. (Format:
     TXT=65622 bytes) (Status: PROPOSED STANDARD)

https://tools.ietf.org/html/rfc6334
6334 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for
     Dual-Stack Lite. D. Hankins, T. Mrugalski. August 2011. (Format:
     TXT=14362 bytes) (Status: PROPOSED STANDARD)

https://tools.ietf.org/html/rfc6519
6519 RADIUS Extensions for Dual-Stack Lite. R. Maglione, A. Durand.
     February 2012. (Format: TXT=22574 bytes) (Status: PROPOSED STANDARD)
-----------------------------------------------------------------------------------
[Freds-Computer:~/draft] fred% ietf *behr*lla* passive-ip
http://datatracker.ietf.org/doc/draft-baker-opsec-passive-ip-address
http://tools.ietf.org/html/draft-baker-opsec-passive-ip-address
  "Passive IP Addresses", Fred Baker, Gunter Van de Velde, 3-Mar-12

http://datatracker.ietf.org/doc/draft-behringer-lla-only
http://tools.ietf.org/html/draft-behringer-lla-only
  "Using Only Link-Local Address in Network Core", Michael Behringer, Eric
  Vyncke, 5-Mar-12

[Freds-Computer:~/rfc] fred% get-refs rfc6296.txt stateless
   This document describes a stateless, transport-agnostic IPv6-to-IPv6
   Network Prefix Translation (NPTv6) function that provides the
   address-independence benefit associated with IPv4-to-IPv4 NAT
   (NAPT44) and provides a 1:1 relationship between addresses in the
   "inside" and "outside" prefixes, preserving end-to-end reachability
   at the network layer.

   This document describes a stateless IPv6-to-IPv6 Network Prefix
   Translation (NPTv6) function, designed to provide address
   independence to the edge network.  It is transport-agnostic with
   respect to transports that do not checksum the IP header, such as
   SCTP, and to transports that use the TCP/UDP/DCCP (Datagram
   Congestion Control Protocol) pseudo-header and checksum [RFC1071].

   The stateless approach described in this document has several
   ramifications:

   NPTv6 Translation does not create several of the problems known to
   exist with other kinds of NATs as discussed in [RFC2993].  In
   particular, NPTv6 Translation is stateless, so a "reset" or brief
   outage of an NPTv6 Translator does not break connections that
   traverse the translation function, and if multiple NPTv6 Translators
   exist between the same two networks, the load can shift or be
   dynamically load shared among them.  Also, an NPTv6 Translator does
   not aggregate traffic for several hosts/interfaces behind a fewer
   number of external addresses, so there is no inherent expectation for
   an NPTv6 Translator to block new inbound flows from external hosts
   and no issue with a filter or blacklist associated with one prefix
   within the domain affecting another.  A firewall can, of course, be
   used in conjunction with an NPTv6 Translator; this would allow the
   network administrator more flexibility to specify security policy
   than would be possible with a traditional NAT.

   The GSE model, by statelessly translating the prefix between an edge
   network and its upstream transit network, accomplishes that with a
   minimum of fuss and bother.  Stated in the simplest terms, it enables
   the edge network to behave as if it has a provider-independent prefix
   from a multihoming and renumbering perspective without the overhead
   of RIR membership or maintenance of BGP connectivity, and it enables
-----------------------------------------------------------------------------------

You can imagine I find these things useful. As I read about UTF-8, I wonder what the impact is. My general comment is that I find tools like these that can analyze internet drafts and RFCs useful, and I'm not sure they exist, in at least this form, for formats like PDF or .doc. At least I'm not sure how to build them.

Something else I would like to facilitate, in whatever form we wind up working, is the improvement of grammar checking. One of the nice things about Word is that it has a grammar checker; there are other tools for basic ASCII text. Whatever input form we use, it would be really nice to have a high quality grammar checker that can not only detect actual grammatical errors ("please don't 'think different', 'think differently'"), but unusual word choices that may have semantic impact (use of "there", "their", and "they're" for example, or more generally catching things like "this feature should not be used in this scoped", where the author mistyped and as a result selected a valid word that was incorrect in context). I suspect that such tools could be helpful not only for English-as-a-Second-Language people, but folks like me that think more quickly than they type.

More generally, I'd like both our input and output formats to facilitate the use of other related tools - rfcdiff and idnits, and language editing and analysis tools.





More information about the rfc-interest mailing list