Re: [OSPF] Spencer Dawkins' No Objection on draft-ietf-ospf-ttz-05: (with COMMENT)

[Huaimo Chen <[e-mail]>]

Hi Spencer,

    Thanks for your quick response.

Best Regards,
Huaimo
-----Original Message-----
From: Spencer [mailto:[e-mail]] 
Sent: Thursday, January 05, 2017 4:22 AM
To: Huaimo Chen; The IESG
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: Spencer Dawkins' No Objection on draft-ietf-ospf-ttz-05: (with COMMENT)

Hi, Huaimo,

On 1/4/2017 10:00 PM, Huaimo Chen wrote:
> Hi Spencer,
>
>      Thank you very much for your time and valuable comments.
>      Your comments are addressed inline below with prefix [HC].
>
> Best Regards,
> Huaimo
> -----Original Message-----
> From: Spencer Dawkins [mailto:[e-mail]]
> Sent: Wednesday, January 04, 2017 5:27 PM
> To: The IESG
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: Spencer Dawkins' No Objection on draft-ietf-ospf-ttz-05: (with COMMENT)
>
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-ospf-ttz-05: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ospf-ttz/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 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.
> [HC]: We will put it into the Abstract as you suggested.
>
> 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?
> [HC]: A different number is used to identify a different TTZ. In general, this number is not zero. For example, we use number 100 for a TTZ, and number 200 for another TTZ. Number 0 is special. A TTZ (Topology Transparent Zone) can be considered as an improved Area in OSPF. A different number is used to identify a different Area. Number 0 is used to identify a backbone Area. From this, MUST is not used.

So, would it be correct to say

    A TTZ ID is a 32-bit number that is unique for identifying a TTZ.
    The TTZ ID SHOULD NOT be 0, to avoid confusion with Area 0, used to identify a backbone Area.

?
[HC]: OK

What I was asking about, was why someone would need to use 0 as a TTZ 
ID. From your explanation, I'm understanding that this isn't a MUST NOT 
because TTZ ID 0 would work just fine in OSPF, but would be more likely 
to cause confusion. Is that true?
[HC]: Yes.

If so, I'd be happier with SHOULD NOT, if the document hinted at the 
reason for this.

Thanks for the quick response!

Spencer

> 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.
> [HC]: We will put this into the Introduction and Abstract as you suggested.
>
>