OSPF Topology-Transparent Zone
draft-ietf-ospf-ttz-06

Thanks for addressing my concern.

Questions on IANA section (not an OSPF expert, so please excuse me if I misunderstood something):
- Don't you have to register both LS types 9 and 10 somehow?
- And do the "Types for new TLVs in the new TTZ LSA" create a new registry or is this an existing one?

Other minor comments:
- What's a DR? Please spell this out!
- There is only little normative language used in this doc. Potentially some more normative language could make things clearer. However I don't have concrete proposals what to change and I believe the most important parts are in normative language. So there is no urgent need to change anything but maybe another check would be good to make sure normative language is used where needed.

I had some high-level context that took a while to build, but after I got through the following comments, I found the document clear to read for a non-OSPF guy. Thank you for that.

The Introduction gives a fairly clear idea of what a TTZ is useful for, but the Abstract doesn't say anything about that. If we still think that people read Abstracts separately from RFCs, it would be useful to add a one-sentence summary naming the use cases that you've already identified for the Introduction.

Perhaps something like "Topology Transparent Zones" allow network operators to restructure the areas in their network, and provide services while the reorganization is taking place, with fewer disruptions." But you folks would know best.

I'm curious why 

   A TTZ ID is a 32-bit number that is unique for identifying a TTZ.
   The TTZ ID SHOULD NOT be 0. 

is not a MUST. Could you give an example of why that would be a good idea?

I found 

   A TTZ hides the internal topology of the TTZ from the outside.  It
   does not directly advertise any internal information about the TTZ to
   a router outside of the TTZ.

very helpful, but it doesn't appear until the top of page 7. Perhaps it would be useful to put this into the Introduction (and, maybe even the Abstract). I had been wondering whether that was true from the beginning of the document, so it seems useful to say so much earlier.

- section 13: I don't agree that there are no new
security considerations, and in fact you seem to raise
one so I'd suggest dropping the "nothing to see here"
pseudo-boilerplate;-)

- section 13: If a router inside a TTZ is borked, then
mechanisms that detect borked routers won't work as
well from outside the TTZ I guess (e.g. they might
identify the wrong router as the borked one). And
contrary-wise, hiding topology may help in that it may
make it harder for an attacker to find a desirable
target. Did anyone think about this? (This is not a
discuss only because I'm not familiar enough with ospf
but I bet a beer that hiding topology will create more
new security issues that are not described here;-)

- 8.1: Did I miss where "Z flag" was described?

- nit: six authors again, plus 2 contributors plus 4
"other authors." I really don't get why it's not
possible to reduce to 5 in cases like this.