SDLC Frame Check Sequence details
Could someone clarify which scenario is correct


It's the first one you listed:


  
    One engineer says you must decode the NRZI encoding and discard the inserted-zero bits, and then the remaining bits will be pushed through a FCS algorithm.
  


Sequence of events

The SDLC FCS is calculated at the transmitter on the raw contents of the Address, Control &amp; Information fields, before bit-stuffing and NRZI encoding (*) is done. The bit-stuffing and NRZI encoding is done "just before" transmission, after the FCS has been calculated.

At the receiver, the NRZI encoding and bit-stuffing are reversed first. Then the frames (consisting of the Address, Control and Information fields, and the transmitted FCS) are fed into the FCS checker.  That means that the FCS checker (which is later in the processing pipeline) can't even get access to the datastream with the bit-stuffing still in it! That is why the other options you were given cannot be correct.

Confirmation

For confirmation, here is a block diagram of the receive path from the Zilog Z80C30/Z85C30 SCC (Serial Communications Controller) which implements SDLC:



Image source: Zilog Z80C30/Z85C30 SCC (Serial Communications Controller) datasheet

From the RXD input in the bottom-left, you can see that the sequence of processing is NRZI Decode, then Zero Delete (i.e. remove bit-stuffing), and only then, into CRC Checker (i.e. the FCS checker).

Summary

As I explained above, the receiver's FCS checker does not, and cannot, operate on the received bits which are still NRZI encoded or have bit-stuffing - those have already been reversed, before the frames go to the FCS checker. That is why only the one choice which I quoted above from your question, is correct.

(As kindly commented by Peter Smith, the old IBM manual "SDLC Concepts" is available online.)

(*) I have written the text above, assuming that NRZI encoding is being used. Although all the IBM SNA systems which I worked on used NRZI encoding (as far as I can remember - it was a long time ago!), I believe that there can be other encoding types, as long as both ends of a link use the same encoding, of course.