Extensions Part sent in negative reply?

gardo@vnet.ibm.com Tue, 07 November 1995 20:22 UTC

Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: gardo@vnet.ibm.com
Message-Id: <199511071956.OAA06795@nexen.nexen.com>
Date: Tue, 7 Nov 95 14:49:58 EST
To: bcole@cisco.com
cc: rolc@nexen.com
Subject: Extensions Part sent in negative reply?
Precedence: bulk
Ref: Your note of Tue, 31 Oct 1995 18:19:52 -0800

Should the "extensions part" be included in negative replies?
I assume it must be included since I cannot find anything that
indicates otherwise.

>To: asmith@Baynetworks.COM (Andrew Smith)
>Cc: bcole@cisco.com, rolc@nexen.com
>Subject: Re: nhrp-05 ?????
>In-Reply-To: Your message of "Tue, 31 Oct 1995 16:29:31 PST."
>             <9511010029.AA28955@milliways-le0.engwest>
>Date: Tue, 31 Oct 1995 18:19:52 -0800
>From: Bruce Cole <bcole@cisco.com>
[...]
>> Do we know when to expect a new draft of NHRP? It would be good if
>> we could see it a couple of weeks before the December IETF and
>> ATM Forum meetings.
[...]
>Hopefully we can at least use the following as the basis for any
>further discussion of NHRP.  I personally hope to see items 4-9 from
>the ROLC list settled here before the next IETF session, so that we
>can be done with changes to NHRP which are preventing any possible
>interroperabilty.
[...]
>For negative replies, the Holding Time field is relevant; however, the
>preference, Address Type, and NBMA length fields MUST be zero, and the
>NBMA Address SHALL NOT be present.
[...]
>The Discretionary bit provides for a means to add to the extension
>set.  If the bit is clear, the NHRP request cannot be satisfied
>unless the extension is processed, so the responder MUST return an
>Error Indication of type Unrecognized Extension.  If the bit is set,
>the extension can be safely ignored, though unrecognized extensions
>so ignored that were received in an NHRP Request packet MUST be
>returned unchanged in the corresponding NHRP Reply.

-- Russell

Extensions Part sent in negative reply? gardo