Re: [trill] Ben Campbell's No Objection on draft-ietf-trill-aa-multi-attach-04: (with COMMENT)

[Mingui Zhang <[e-mail]>]

Hi Ben,

Thanks for the comments. Please check the responses in-line below.

> -----Original Message-----
> From: Ben Campbell [mailto:[e-mail]]
> Sent: Wednesday, August 19, 2015 6:09 AM
> To: The IESG
> Cc: [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Subject: Ben Campbell's No Objection on draft-ietf-trill-aa-multi-attach-04:
> (with COMMENT)
> 
> Ben Campbell has entered the following ballot position for
> draft-ietf-trill-aa-multi-attach-04: 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-trill-aa-multi-attach/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> A few minor comments (no show stoppers):
> 
> -- section 4.1, first paragraph:  "However, alternative implementations MAY
> be used to produce the same expected behavior."
> 
> Does this talk about same “behavior”  of an RBridge (as in the observable
> one-the-wire bits are identical) or same “results” for the system (as in the
> receiving RBridge does not flip-flop)? If the former, it probably should not be
> normative.

[MZ] It means the latter. The "expected behavior" will be explicitly explained to be "the receiving RBridge does not flip-flop"

> 
> -- section 5.3.2:
> This section defines a sub-tlv, and related behavior. That probably doesn’t
> belong in the design goals analysis section. (I predict that many readers will
> skip section 5 entirely). Please consider moving this under section 4.

[MZ] Fine. It can be moved to Section 4. This TLV actually talks about the "discovery" within the AAE group and there is another TLV in Section 4.1, talking about "discovery" within the campus. The movement seems reasonable. Further, I prefer to leave the analysis part of current Section 5.3.2 in Section 5 while only move the TLV specification and related behavior to Section 4. And, a pointer will be included in the analysis text. 

> 
> Also, can you cite something for the "well-known 'split horizon'
> technique"?

[MZ] Yes. Let's refer to "Section 2.2.1 of RFC 1508". The split horizon is discussed there.

> 
> -- section 7:
> This draft defines new data elements. It seem likely that nothing in those new
> elements add security considerations beyond those in the cited specs. But it
> would be helpful to explicitly state that.

[MZ] OK. That statement will be included.

> 
> -- 8.3:
> Are you for specific flag values (16 and 4 respectively), rather than allowing
> IANA to assign the values as needed? Also, it seems odd to recreate the entire
> flag registries in a spec that merely adds new flags.
> The registry will change over time; this runs the risk of a reader assuming the
> contents listed here are current at any point in the future.
>  (But I see that other TRILL specs have done the same.)

[MZ] Values 4 and 16 are suggested. The ever specified flags will be dropped from this document.

> 
> Editorial Comments and Nits:
> 
> -- Abstract:
> Please expand TRILL on first mention in the abstract.
> 
> -- section 1, first paragraph:
> Please expand TRILL on first mention in the body, too.

[MZ] OK.

> 
> -- 4.1, first paragraph:
> "... in MAC learned from the TRILL...": Missing article s/It's/It is "A promising
> way..." : “promising” in this context seems to imply the option is likely, but not
> certain to work. Is that the intent?

[MZ] No, it's not the intent. That sentence will be dropped.

> s/So the receiving edge.../The receiving edge...
> 
> -- 4.1, 2nd paragraph:
> Sentence 1 is a little confusing. I assume the intent is to say that this draft
> allocates the reserved flags, and the flags are used to advertise the data labels?
> As it is, it sounds like the act of allocation advertises the data labels.

[MZ] The data labels are advertised in two TLVs and these two TLVs have a field of flags. This draft opens one flag in each.
s/Enabled Data Labels for an LAALP are advertised/ Interest in enabled Data Labels for an LAALP are advertised/

> In sentence two, should "this flag" be "these flags"?

[MZ] Yes.
> 
> -- 4.1, paragraph 3: "...it MUST be advertised..."
> I assume this means that the originating RBridge MUST advertise it?
> (Please consider active voice for 2119 requirements. )

[MZ] Yes.
> 
> -- 5:
> Consider “This section explores how this specification meets the major design
> goals of AAE”
> 

[MZ] Accepted.

Thanks,
Mingui