In Working Draft 2008-05-11, production 208 references ns-l+block-node, which isn’t defined. Instead production 197 defines s-l+block-node which I think might be what’s intended. I’m not sure what the correct name is, but it looks like a typo in one place or the other.
Also regarding the production naming, I’d suggest it might make sense to distinguish between simple character-class productions (with a c- prefix), from the more complex indicator-based productions (with perhaps a i- prefix). For example, I’d rename c-ns-tag-property to i-tag-property, c-single-quoted to i-single-quoted, c-flow-sequence to i-flow-sequence, etc. This obviously doesn’t impact the validity of the document, but I believe it would improve its understandability.
I’m not sure what motivated the change from V1.1’s c-l-block-sequence to V1.2’s l-block-sequence; whatever the reason, I applaud it! I think reducing the number of productions that start with a comment or non-indent whitespace will make it much easier to map the spec. to practical implementations. Perhaps some simpler Hungarian prefix for block constructs like s-l+block-indented would help. I’m not sure how to put this in parser terminology, but after having struggled with 1.1s productions for quite a while, it seems like a good idea. It would be incredibly useful to be able to express YAML’s syntax with the same sort of railroad track diagrams that JSONs is documented in.