specification inconsistencies
msteenst@bbn.com Fri, 15 May 1992 18:56 UTC
Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa03138;
15 May 92 14:56 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id ab07614;
15 May 92 15:02 EDT
Received: from PIZZA.BBN.COM by NRI.Reston.VA.US id ab07604;
15 May 92 15:02 EDT
Received: from pizza by PIZZA.BBN.COM id aa10171; 15 May 92 13:36 EDT
Received: from ALEXANDER.BBN.COM by PIZZA.BBN.COM id aa10167;
15 May 92 13:34 EDT
To: woody@sparta.com
cc: idpr-wg@bbn.com
Subject: specification inconsistencies
Date: Fri, 15 May 92 13:33:46 -0400
From: msteenst@bbn.com
Message-ID: <9205151502.ab07604@NRI.Reston.VA.US>
Hi Woody,
Thanks for the message.
(1) Location of INT/AUTH value. Yup, entirely my oversight.
Will be fixed.
(2) The INFORM field in the CMTP ACK IS used. That's the way IDPR
protocols send back negative acknowledgements for a message that
looks correct to CMTP but incorrect to an IDPR protocol. For
example, a policy gateway may receive from an adjacent policy
gateway a routing information message that is out-of-date but
that passes all of the CMTP checks. In this case, the recipient
policy gateway returns a CMTP ACK with the INFORM field set
to indicate that the routing information message was out-of-date
according to the recipient. (The "Negative Acknowledgments"
section at the end of each protocol description talks about this
more.)
(3) NAK messages are used to indicate CMTP message check failures.
The reasons for these failures are returned in the "message
specific" field of the NAK. The INFORM field of a CMTP ACK
is used to indicate negative acknowledgements at the IDPR
protocol level, as I mentioned in (2).
(4) Messages types. Thanks, will check these out.
m
- specification inconsistencies msteenst