editorial comments to routing document

[Allan Cargille <[e-mail]>]

Hi, I would like to give some comments on the routdir document, ID
version 04.  For ease of editing I am using the text version.  When I
list page numbers, they refer to the text version.

In some cases, the formatting of the document needs to be modified
somewhat because by RFC document rules, the text version is the
standard and must be the reference document.

I embed my comments in the text with the marker >>>.  I have also
listed some typos and possible typos at the bottom of the document.

Cheers,

allan

======================================================================

....
 o  Delay between message submission and delivery should be minimised.
    Table 1 indicates the sort of target which might be aimed for.
    The figures are illustrative of the sort of target which might be
    set.  They are better than achieved in most current Research
    Networks.  The long tail-offs on Normal and Low priority recognise
    the fact that some end systems will not get 24 hour operator
    coverage (whereas any MTAs providing ADMD service should).  In the
    case of a high priority message, a non-delivery notification
             ^^^^^^^^^^^^^^^^^^^^^

>>> I think we should add normal priority messages to this as well.
Normal priority is probably the general case default for a user to
user message, and performance should be good for this case.  I agree
with low performance standards for "low" priority messages, because
these are most likely mailing list messages.

....

 o  Interact sensibly with ADMD services provided by PTTs or RPOAs.

>>> expand RPOA to "RPOAs (Recognized Private Operating Agencies, ie,
carriers)"

....

 o  Routing strategy should deal with a scale of order of magnitude
    106 -- 108 MTAs.
    ^^^^^^^^^^^^^^^
 o  Routing strategy should deal with of order 106 -- 108
    Organisations.                             ^^^^^^^^^^

>>> This did not come out like one would want in the text version --
suggest 10^6 or 10**6 or "one million to 100 million"

....

Bilateral Agreements An agreement between a pair of MTAs to route
    certain types of traffic.  This MTA pair agreement usually
    reflects a higher level agreement.  It is an important special
    case of the first, as bilateral information must be held for the
    link at both ends.  In some cases, this information must be
    private.

>>> "special case of the first"?  Please clarify.

....

They might choose to label a routing tree root ``UCL Routing  Tree'',
which would lead to a routing tree root of:


 CN=Zydeco Routing Tree, O=Zydeco Services, C=GB

>>> Typo?  Change "UCL Routing Tree" to "Zydeco Services"?

....

Routing trees are defined in the previous section, and are used as a
framework to hold routing information.  Each node, other than a
skeletal one, in a routing tree has information associated with it,
which is defined by the object class routingInformation in Figure 3.
This structure is fundamental to the operation of this specification,
and_should_be_studies_with_care._______________________________________
              ^^^^^^^
>>> typo - studied

....

routingFailureAction An action to be taken if none of the MTAs can be
    used directly (or if there are no MTAs present) is defined by the
    routingFailureAction attribute.  Use of this attribute an multiple
    routing trees is described in Section 10.1.

>>> typo "and multiple"

....

ae-qualifier A printable string (e.g.  ``x400-88''), which is the e
    the value of the common name of the relative distinguished name of

>>> typo "the e the value"

....

Attributes present in an MTA Entry are defined in

>>> Defined where?
                                                ^^^^^^^^^^^^^^^^^^
....

weight This gives the weight of the filter, which is encoded as a
    Route Weight.  If multiple filters match, the weight of each
    matched filter is used to select between them.  If the weight is
    the same, then a random choice should be made.

>>> Need to specify that lower weight means higher priority.  This was
clarified for Route Weight but not for filters.

>>> This also illustrates another problem with the text version - in
the postscript the "tag" (weight, above) is in bold and can be
distinguished from the explanatory text.  In the ascii version this
cannot be distinguished.  One way to distinguish them would be to
suffix all the tags with a colon (yielding "weight: This ...").
This is a general problem seen through the ascii version of the document.

....

10.4  Indirect Connectivity


In some cases a part of the O/R Address space will be accessed
indirectly.  For example, an ADMD without access from the open
community might have an agreement with another MD to provide this
access.  This is achieved by use of the accessMD attribute defined in
Figure 4.  If this attribute is found, the routing algorithm should
read the entry pointed to by this distinguished name and route
according to the information retrieved, in order to route to this
access MD.
The attribute is called an MD, as this is descriptive of its normal
use.  It might point to a more closely defined part of the O/R Address
space.
It is possible for both access MD and MTAs to be specified.  This
might be done if the MTAs only support access over a restricted set of
transport stacks.  In this case, the access MD should only be routed
to if it is not possible to route to any of the MTAs.

This structure can also be used as an optimisation, where a set of
MTAs provides access to several parts of the O/R Address space.
Rather than repeat the MTA information, a single access MD is used as
a means of grouping the MTAs.  The value of the Distinguished Name of
the access MD will probably not be meaningful in this case.

>>> Is this formatted right?  Text is not filled; whitespace would be
good if these are separate paragraphs.  (Sentences starting "The
attribute is called" and "It is possible"...)

>>> Could you please give an example of the optimisation discussed
in the last paragraph?

>>> Could you please clarify what should occur in the routing
algorithm if the directory access to the accessMD is denied due to
lack of permissions?  Kevin thought it should continue in the ORIGINAL
tree (not switch to the accessMD location in the tree).

....

supportingMTA The MTAs which support a UA directly are noted in the
    SupportingMTA attribute, which may be multi-valued.  X.400 models
    that only one MTA is associated with a UA. In practice, it is
    possible and useful for several MTAs to be able to deliver to a
    single UA. This attribute is a subtype of MTAinfo, as it is
    possible for an MTA to be registered to route to a UA, without it
    actually being able to deliver messages to it.
    This attribute must be present, unless the address is being
    non-delivered or redirected.

>>> Formatted right?  Not filled - "This attribute ... "

>>> "X.400 models that ..." - maybe this is an American/English
grammer thing, but that sounds funny in American english.  Better
would be "In the X.400 model, ..."

....

The routing algorithm selects a single MTA to be routed to.  It could
be extended to find alternate routes to a single MTA with possibly
different weights.  How far this is done should be a local
configuration choice.  Provision of backup routing is desirable, and
leads to robust service, but excessive use of alternate routing is not
usually beneficial.  It will often force messages onto convoluted
paths, when there was only a short outage on the preferred path.
It is important to note that this strategy will lead to picking the
first acceptable route.  It is important to configure the routing
trees, so that the first route identified will also be the best route.
^^^^^^

>>>> no comma

....


Handle MTA Info Information from the node should be examined.  If
    suitable information is found, one of the following is done:

>>> This is a good example where the "tag" and the explanatory text are not 
distinct.

....

Bad Address

>>> The lack of bold/normal type makes it appear like the explanatory
text was just forgotten in this point.  Maybe want to add four words
"The address is invalid." or something like that.  The colon I
suggested earlier would also help fix this anyway, but I would add a
little text anyway for symmetry.

....

MTAs need to be named in the DIT, but the name does not have routing
significance, it is simply a unique key.  Attributes associated with
naming MTAs are given in Figure 6.  This figure also gives a list of
attributes, which may be present in the MTA entry.  The use of most of
these is explained in subsequent sections.  The mTAName and
globalDomainID attributes are needed to define the information that an
MTA places in trace information.  As noted previously, and MTA is
                                                        ^^^^^^^
represented as an Application Process, with one or more Application
Entities.______________________________________________________________

>>> typo "an MTA"

....

Editor's Note: Need to add in control for various ghastly things such
    as trace stripping and originator munging.  Whilst this is needed,
    it is perhaps best swept under the carpet and left to
    implementation specific extensions.

>>> Agree.  Delete note, or note that such topics are left up to the
implementations.

....

A key issue for authentication is for the called MTA to find the name
of the calling MTA. This is needed for it to be able to look up
information on a bilateral agreement.
Where X.400(88) is used, the name is available as a distinguished name
from the AE-Title provided in the A-Associate.  For X.400(84), it will
not be possible to derive a global name from the bind.  The MTA Name
exchanged in the RTS Bind will provide a key into the private
bilateral agreement table.  Thus for X.400(1984) it will only be
possible to have bilateral inbound links or no authentication of the
calling MTA.

>>> Support for Multilateral agreements has been added, so this text
should be rewritten in light of the new feature.

Editor's Note CDC use a search here, as a mechanism to use a single
    table and an 88/84 independent access.  This should be considered
    for general adoption.  It appears to make the data model cleaner,
    possibly at the expense of some performance.

>>> Is this note still relevant after introducing the Multilateral
agreement?  Note that implementations are still free to search whatever
they want to identify incoming connections, such a thing does not need
to be standardized...

....

21.1  Simple MTA Policy

The routing trees will generally be configured in order to identify
MTAs which will route to the destination.  A simple means is
identified to specify an MTA's policy.  This is defined in Figure 14.
The multi-valued attribute gives a set of policies which the MTA will
route.  O/R Addresses are represented by a prefix, which identifies a
subtree.  A distinguished name encoding of O/R Address is used.  There
are three components:

from This gives a set of O/R addresses which are granted permission
    by this attribute value.  If omitted, ``all'' is implied.

to This gives the set of acceptable destinations.  If omitted,
    ``all'' is implied.

from-excludes This defines (by prefix) subtrees of the O/R address
    tree which are explicitly excluded from the ``from'' definition.
    If omitted, there are no exclusions.

to-excludes This defines (by prefix) subtrees of the O/R address tree
    which are explicitly excluded from the ``to'' definition.  If
    omitted, there are no exclusions.

This simple policy should suffice for most cases.  In particular, it
gives sufficient information for most real situations where a policy
choice is forced.
This simple prefixing approach does not deal explicitly with alias
dereferencing.  The prefixes refer to O/R addresses where aliases have
been dereferenced.  To match against these prefixes, O/R addresses
being matched need to be ``normalised'' by being looked up in the
directory to resolve alias values.  If the lookup fails, it should be
assumed that the provided address is already normalised.  This means
that policy may be misinterpreted for parts of the DIT not referenced
in the directory.
The originator refers to the MTS originator, and the recipient to the
MTS recipient, following any list expansion or redirect.

>>> Is this formatted right?  Paragraphs should be separated by
whitespace or filled.

>>> Could you please clarify the default permissions?

>>> It would be helpful to include an example here -- I think a good one
would be a PRMD that participates in the open tree, but will only allow
it's internal users to send mail to an ADMD, ADMD=costly.  I think this
would be done with two rules:
    from = C=xx/ADMD=yy/PRMD=private/ and to = /C=xx/ADMD=costly/
and
    to-excludes = /C=xx/ADMD=costly/  (and default is "all"?)


21.2  Complex MTA Policy

MTAs will generally have a much more complex policy mechanism, such as
that provided by PP [17].  Representing this as a part of the routing
decision does not seem worthwhile at present.  Some of the issues
which need to be tackled are:

>>> I would change the paragraph above to note that these issues are not
addressed in this document, may be implemented by implementations, and
are for future study.

 o  Use of charging and non-charging nets

 o  Policy dependent on message size

 o  Different policy for delivery reports.

 o  Policy dependent on attributes of the originator or
    recipient(e.g., mail from students)

 o  Content type and encoded information types

 o  The path which the message has traversed to reach the MTA

 o  MTA bilateral agreements

 o  Pulling messages

 o  Costs.  This sort of policy information may also be for
    information only.


Policies relating to submission do not need to be public.  They can be
private to the MTA.

>>> Agree.


22  Delivery

22.1  Redirects


There is a need to specify redirects in the Directory.  This will be
done at the O/R Address level (i.e., in a routing tree).  This will be
useful for alternate names where an equivalent name (synonym) defined
by an alias is not natural.  An example where this might be
appropriate is to redirect mail to a new O/R address where a user had
changed organisation.  The definitions are given in Figure 15.
Mandatory redirects are specified by the mandatoryRedirect attribute.
A filtered redirect is provided, to allow small messages, large
messages, or messages containing specific EITs or content to be
redirected.  Message size is measured in kBytes.  Where multiple
elements are contained in the FilteredRedirect structure, they are
treated as having a ``logical or'' relationship.
When a delivery report is sent to an address which would be
redirected, X.400 would ignore the redirect.  This means that every
O/R address would need to have a valid means of delivery.  This would
seem to be awkward to manage.  Therefore, the redirect should be
followed, and the delivery report delivered to the redirected address.

These reidrects are handled directly by the MTA. Redirects can also be
initiated by the UA, for example in the context of a P7 interaction.

>>> I agree with this logical way to handle this situation, but are
there concerns here about building compliant implementations?
Shouldn't this be pursued as a defect report to X.400?


22.2  Underspecified O/R Addresses

X.400 requires that some underspecified O/R Addresses are handled in a
given way.  Where an underspecified O/R Address should be treated as
if it were another O/R Address, an alias should be used.  If the O/R
Address should be rejected as ambiguous, and entry should be created
in the DIT, and forced non-delivery specified for this reason.

>>> Let's give an example of an underspecified address, such as one with
one or more OUs left out.

>>> You say that this approach "should" be used.  I disagree.  There is
no need to standardize this.  The document is worded like compliant
implementations should take this approach.  I think we should note that
other approaches are possible -- for example, CDC does a search.  Is this a
local delivery issue?  In that case it is no problem.  Or would the 
search be initiated when a remote MTA tries a directory read?  Perhaps
we could say that this is one possible solution, instead of "the
correct solution".

....

22.4  Bad Addresses

If there is a bad address, it is desirable to do a directory search to
find alternatives.  This is a helpful user service and should be
provided.  This function is invoked after address checking has failed,
^^^^^^^^
>>> change to "supported" ?

and where this is no user supplied alternate recipient.  This function
would be an MTA-chosen alternative to administratively assigned
alternate recipient.
Attributes to support handling of bad addresses are defined in
Figure 17.  The attributes are:

>>> Looks like the text should be filled or broken, above "Attributes..."

....

Searches are always single level, and always use approximate match.
If a small number of matches are made, this is returned to the
originator by use of the per recipient AlternativeAddresssInformation
in the delivery report (DR). This should be marked non-critical, so
that it will not cause the DR to be discarded.  This attribute allows
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> Explain that this would occur in 88 to 84 downgrading (the possible
discarding).

the Distinguished Name and O/R Address of possible alternate
recipients to be returned with the delivery report.  There is also the
possibility to attach extra information in the form of directory
attributes.  Typically this might be used to return attributes of the
entry which were matched in the search.  A summary of the information
should also be returned using the delivery report supplementary
information filed (e.g., ``your message could not be delivered to
smith, try J. Smith or P. Smith''), so that the information is
available to user agents not supporting this extension.  Note the
length restriction of this field is 256
(ub-supplementary-info-length).    ^^^^^

>>> Kevin said this is 128 bytes in the 84 standard.  Also note that
this info is retained in 88 to 84 downgrading (assuming length matches).
What happens if the field is > 128 and is downgraded?  Is it truncated?

If the directory search fails, or there are no matches returned, a
delivery report should be returned as if this extra check had not been
made.

Editor's Note: It might be useful to allow control of search type,
    and also single level vs subtree in future versions.

>>> Change this note instead to a brief paragraph noting that this is
for future consideration.

....

24  Access Units

Attributes needed for support of Access Units are defined in
Figure 18.
The attributes defined are:

>>> Looks like these sentences should be filled or separated.

>>> You might note that access units are defined in '88.

....

Editor's Note 1: This mechanism might be used to replace the
    routefilter mechanism of the MTS routing.  Comments are solicited.

Editor's Note 2: It has been proposed to add a more powerful filter
    mechanism.  Comments are solicited.

Editor's Note 3: The utility of this specification as a mechanims to
    route faxes and other non MHS messages has been noted, but not
    explored.  Comments as to how and if this should be developed are
    solicited.

>>> Let's keep the spec as is, and either delete these notes or note
that these issues are for future study.

25  The Overall Routing Algorithm

Having provided all the pieces, a summary of how routing works can be
given.

} The very top level of the routing algorithm is:
} 
} 1.  Route the message according to the protocol by which it arrives
}     (RFC 822 or X.400).  In the case of RFC 822, this should follow
}     [12].
} 
} 2.  If this fails, and gatewaying is supported, map the address and
}     attempt to route according to the other protocol using [16].

>>> I would delete this text marked with "}", and others at the IETF
agreed.  This document should assume that routing via X.400 has been
selected for some reason.  This could be for a policy reason, ie, the
organization chooses to force X.400 when possible.  Instead, you might
wish to note that routing by the same protocol, when possible, is the
most efficient routing choice.


25.1  X.400 Routing


The core of the X.400 routing is described in Section 10.  A sequence
of routing trees are followed.  As nodes of the routing tree are
matched, a set of MTAs will be passed upwards for evaluation.  If all
                               ^^^^^^^^^^^^^^
>>> I know what you mean, but I wonder if we could find a more clear
way to explain this.

of these are rejected, the trees are followed further2.  A set of MTAs
>>> not formatted well in ascii:              ^^^^^^^^
is evaluated on the following criteria:

....

This work was part funded by the COSINE Paradise project.
              ^^^^^^^^^^^

>>> This sounds incorrect in American english.  You might say "partly
funded" or "funded in part".

....


 [5] U. Eppenberger. Routing coordination for an X.400 MHS service
     within a multi protocol environment, October 1991. Version 1.0,
     RARE WG1 Document.
>>> Update version, and it is now RFC1465.

....

    This regular expression notation, whipch can be used in a line address
    to specify lines by con- tent. A regular expression (RE) specifies a
>>>                     ^^^^^^^^^ content

    set of character strings to match against - such as ``any string
    containing digits 5 through 9''.  A member of this set of strings is
    said to be matched by the regular expression.  Regular expressions or
    patterns are used to address lines in the buffer (see Addresses ,
>>> space before comma at end of line

    above), and also for selecting strings to be replaced using the s
    (substitute) command.

>>> Right margin too long in above paragraph on REs, text also not
adjusted (uneven right-hand margin).

....

======================================================================

I also used spell to identify typos and possibly different variations of
what are intended to be the same word/phrase.  Groups of words I had
questions about are listed on consecutive lines, where one or more of
them may be a typo.  Then again, they might be right.  Page numbers
refer to the ascii text.  This is for internet draft v04 of the document.

ACSNET
ACSNet - both are used -- might want to be consistent, choose one

DistinguishedNameTableEntry - typo in text p 41?
distinguishedNameTableEntry 

GlobalDomainID - typo p 39?
globalDomainID
GlobalDomainIdentifier

MTAInfo
MTAinfo - typo when used? should be MTAInfo?
mTAInfo
mtaInfo - typo when used? should be MTAInfo?

MTAName - is the use of both of these correct?  It appears to be.
mTAName - 

RouteWeight - Is this correct?  I think so.

routingActionFailure - should be r/RoutingFailureAction? p 27

RoutingTreeRoot - is one of these a typo?
routingTreeRoot

typo's listed by page/word:
61 whipch
49 reidrects
31 regulear	
52 mechanims
33 followin
28 effectivelyu
54 australian - capitalize in title?

citations - these are poorly formatted in the the ascii
13 mtas1
52 further2
53 supports3