Re: editorial comments to routing document

Steve Kille <S.Kille@isode.com> Mon, 04 July 1994 12:11 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01250; 4 Jul 94 8:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01246; 4 Jul 94 8:11 EDT
Received: from mercury91.udev.cdc.com by CNRI.Reston.VA.US id aa03728; 4 Jul 94 8:11 EDT
Received: by mercury.udev.cdc.com; Mon, 4 Jul 94 06:56:10 -0500
X-From: S.Kille@isode.com Mon Jul 4 06:56 CDT 1994
Received: from zeus.cdc.com by mercury.udev.cdc.com; Mon, 4 Jul 94 06:56:09 -0500
Received: from glengoyne.isode.com by zeus.cdc.com; Mon, 4 Jul 94 06:56:05 -0500
To: Allan Cargille <cargille@cs.wisc.edu>
cc: mhs-ds@mercury.udev.cdc.com
Subject: Re: editorial comments to routing document
Phone: +44-81-332-9091
In-reply-to: Your message of Thu, 07 Apr 1994 11:56:50 -0500. <9404071656.AA20097@calypso.cs.wisc.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8424.773322972.1@glengoyne.isode.com>
Date: Mon, 04 Jul 1994 12:56:24 +0100
Message-ID: <8427.773322984@glengoyne.isode.com>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Steve Kille <S.Kille@isode.com>

Allan,

I'd like to thank you for this comprehensive input.   The document
will benefit greatly from your efforts.

I have been able to handle most of your input directly, but there are
a couple of points that I'd like to share with the list.


22.1 - you agree that this is useful, but note that it goes beyond
X.400, and may be argued to be non-conformant.  I view that we should
gain experience with this function.  If it is found the be useful, and
this utility cannot be handled within X.400, then we should raise
detailed issues with the X.400 standards people.  I think that
submitting a defect report is premature.


22.2 - underspecified O/R addresses.   I have mandated an approach to
be followed, IN THE CONTEXT OF X.400, whereas you suggest that it
should be optional.   I have tightened the text in this area, and
invite you to review it.   I do not believe that this sort of thing
should be left to implementor choice.


Supplementary info bounds.   This is set to 256.   You say that Kevin
says that it is 128 in 84.   While 84 does not specify lengths, a
number of profiles do.   Is there an issue which needs to be addressed
in this document (as opposed to a downgrading spec?)



Steve