editorial comments on routing document

Allan Cargille <cargille@cs.wisc.edu> Tue, 23 August 1994 00:14 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10879; 22 Aug 94 20:14 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10875; 22 Aug 94 20:14 EDT
Received: from mercury91.udev.cdc.com by CNRI.Reston.VA.US id aa19490; 22 Aug 94 20:14 EDT
Received: by mercury.udev.cdc.com; Mon, 22 Aug 94 18:59:26 -0500
X-From: cargille@cs.wisc.edu Mon Aug 22 18:59 CDT 1994
Received: from cdsmail.cdc.com by mercury.udev.cdc.com; Mon, 22 Aug 94 18:59:25 -0500
Received: from calypso.cs.wisc.edu by cdsmail.cdc.com; Mon, 22 Aug 94 18:59:22 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Allan Cargille <cargille@cs.wisc.edu>
Message-Id: <9408222359.AA18039@calypso.cs.wisc.edu>
Received: by calypso.cs.wisc.edu; Mon, 22 Aug 94 18:59:01 -0500
Subject: editorial comments on routing document
To: Steve Kille <s.kille@isode.com>
Date: Mon, 22 Aug 1994 18:59:00 -0500 (CDT)
Cc: mhs-ds@mercury.udev.cdc.com
Organization: University of Wisconsin - Madison
Address: Comp Sci Dept, 1210 W. Dayton St, Madison, WI 53706, USA
Phone: +1 (608) 262-5084
Fax: +1 (608) 262-9777
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 5123

Hi Steve,

Welcome back from your vacation.

Here's my comments on the routing document.  I gave you some of these
in the meeting, but not all.

Good luck wrapping them up!



The following comments are based on the postscript version of

bottom of page 17 - section 9.2.4  "This is an important structure
... MX records)."  We discussed this in the meeting and it was decided
to strike this, since this is known technology now.

bottom of page 21 - badAddressSearchPoint runs off the right margin.

bottom p 21 - last sentence - "Issues relating to use of X.500" -
should be "to the use of".  Also "Section14" should be "Section 14".

top p 22 - "It is possible, that further"  - delete comma

top p 22 - first sentence - cross-reference to where "ae-info
structure" is defined.

middle p 25 - "all of the attribute that may be" - should be

middle p 31 - There is an Editor's Note there about diagnostic codes
and failed lookups - this should be handled or deleted

middle p 31 - "SecurityErrror" - should be "Error"

middle p 31 - first sentence Section 15 - run-on sentence.  Change to
... significance -- it is ..." ?

middle p 35 - distinguishedNameTableEntry runs off Right margin

top p 36 - Editor's note about trace stripping, etc.  I believe this
should be left in the document but that it should be modified, and
perhaps renamed as a "Note"

top p 38 - last sentence section 18.4 - should be "settings in the

Suggestion - 
bottom p 38 - "a key into the private bilaterl agreement table (or
tables)."  Change to "table (or tables), where the connection
information can be verified."  I know this is technically unnecessary
but find it more clear.

middle p 41 - aet-present - add period 

middle p 41 - strong-authentication - is this defined?

bottom p 41 - bilateral-agreement-needed - was this changed to
"multilateral" ?  Should it be?

middle p 42 - "If an MTA/Password pair is .... zero length OCTET
STRING."  change to "If an MTA/Password pair is omitted, the MTA shall
default to the local MTA Name, and the password shall default to a
zero-length OCTET STRING."

middle p 42 - editorial note in text - delete?

bottom p 44 - Editor's note re: examples of MTA policy - I believe it
is important to include such examples, because when we discussed them
at the March IETF meeting there was not a clear interpretation of the
standard.  I'd like to see an example of how a community could allow
the use of a fax gateway by some organizations, but not others.

middle p 45 - "it is highly undesirable that they lead to non-routability of
messages" - rephrase - how about "MTAs may apply more complex routing
policies.  However, this must not lead to the rejection of messages
which are valid based on the published policy information."

bottom p 46 - section 22.2 - "ambiguous, and entry" - should be "an".
Also same sentence "DIT, and" - delete comma?

bottom p 47 - "restriction of this field is 256" - identify whether
this is in 92, 88, or 84.

bottom p 47 - editor's note - leave in?  Delete?

bottom page 49 - three editors notes - edit or delete - do not include
text that "comments are solicited".

bottom page 50 - "has beed designed" - change to "been"

top/middle page 52- references 10-16 - delete 15 - Update others to
relevant RFC or internet draft.

top page 53 - include fax number?

page 69 - section E.1 - delete - if you include it, change to appendix
F instead of E.1 .


The following comments apply to the text version:

you can search for these keys:

support3 - the superscript is appended to the word it follows, which
is poor.  I'd recommend including it in parentheseis.  Perhaps this
should be done manually to the final version, if there's not an easy
way to do this.
further2 - ditto
MTAs1 - ditto

at214 - should be at 214  looks funny: 4{at214}0
at325 - should be at 325  This looks funny: =4{at325}0

CONS10 - should be CONS ?  Is this the superscript problem?

AlternativeAddresssInformation - should be "Address" 

    - these do not follow the general pattern of having the strings
    exactly the same except for the first character.  I don't know if
    that's important or not.

MTAinfo  <-- this one is a typo
mtaInfo  <-- this one may be a typo

repsonderPullingAuthenticationRequirements - typo, should be

routablity - I don't think this is a word.  I have proposed alternate

SecurityErrror - should be Error

    - these do not follow the convention of only differing by the
    first character.

    - I believe these are correct but you might want to doublecheck

supportingMTA The MTAs which support a UA directly are noted in the
    SupportingMTA attribute, which may be multi-valued.  In the X.400
from p 33 - should be supportingMTA