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