Re: [trill] My thoughts/wording corrections -> draft-ietf-trill-ia-appsubtlv-02.txt

Hi Gayle,

Thanks. Those changes looks like good clarifications and corrections
to the draft. I'll go over them more closely and incorporate them.

Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

On Wed, Feb 25, 2015 at 11:44 PM, gayle noble <windy_1@skyhighway.com> wrote:
> My thoughts/wording corrections ->[trill]
> draft-ietf-trill-ia-appsubtlv-02.txt
>
> 1)     Abstract
> (this sentence is very long and complicated.)
> This document specifies a TRILL (Transparent Interconnection of Lots of
> Links) IS-IS application sub-TLV that enables the reporting by a TRILL
> switch of sets of addresses such that all of the addresses in each set
> designate the same interface (port) and the reporting for such a set of the
> TRILL switch by which it is reachable.
> (maybe re-adjust it something like this)
> This document specifies a TRILL (Transparent Interconnection of Lots of
> Links) IS-IS application sub-TLV that enables the reporting by a TRILL
> switch of sets of information; each set consists of addresses and a nickname
> of the TRILL switch by which those addresses can be reached; all of the
> addresses in a set designate the same end station interface (port).
>
> 2)      page 10
> (I would change "the" to "then")
> (as written)
> If they were used in a IA-APPsubTLV in a traditional LSP [ISO-10589], the
> only one byte Types and Lengths could be used.
> (it would become)
> If they were used in a IA-APPsubTLV in a traditional LSP [ISO-10589], then
> only one byte Types and Lengths could be used.
>
> 3)    page 12
> (Should be "topology given" instead of "topology give")
> (as written)
>   The presence of this sub-sub-TLV indicates that the interfaces given in
> the IA APPsub-TLV are reachable in the topology give.
> (I'd change it to)
>   The presence of this sub-sub-TLV indicates that the interfaces given in
> the IA APPsub-TLV are reachable in the topology given.
>
> 4)    page 12
> (This is not real clear as to what it is trying to communicate .. at least
> to me)
> (what is written)
> It is useful if the IA APPsub-TLV occurs outside of the context of a message
> indicating the topology or if it is desired and permitted to override that
> specification.
> (if I figured this out)
> You might want to use the Data Label or Topology sub-sub-TLVs where the IA
> APPsub-TLV is not in a message or some other context that specifies the Data
> Label or Topology. (Multi-topologyTRILL really isn't fully specified yet but
> the Topology sub-sub-TLV is provided for future use.) Alternatively, even if
> the IA APPsub-TLV is inside a message or some other context, you might want
> to specify that for some particular IA APPsub-TLV, a different Data Label or
> different Topology should be used, so you might want to use the sub-sub-TLV
> to override that specification.
>
> 5)    page 14
> (I'd change "providing" to "provided")
> (what is written)
> Security on the wire, or in storage, for this data is to be providing by the
> transport or storage used.
> (What I'd put)
> Security on the wire, or in storage, for this data is to be provided by the
> transport or storage used.
>
> 6)    page 19 last paragraph
> (the word "give" is used where I'd use "given")
> (as written)
> The Fixed Address sub-sub-TLV causes the IPv6/64 value give to be treated as
> if it occurred as a 4th entry inside each of the three Address Sets.
> (I'd write)
> The Fixed Address sub-sub-TLV causes the IPv6/64 value given to be treated
> as if it occurred as a 4th entry inside each of the three Address Sets.
>
> 7)    page 20 last paragraph
> (I think "them" should be "then")
> (as written)
> The OUI would them be supplied by a second Fixed Address sub-sub-TLV proving
> the OUI.
> (I think it should be)
> The OUI would then be supplied by a second Fixed Address sub-sub-TLV proving
> the OUI.
>
> acronyms
> AFN              Address Family Number
> APPsub-TLV    Application sub-TLV
> ARP              Address Resolution Protocol
> Data Label     VLAN or FGL
> ESADI           End Station Address Distribution Information
> FGL              Fine Grained Label
> FS-LSP                   Flooding Scoped Label Switched Paths
> IA                Interface Addresses
> IETF             Internet Engineering Task Force
> IS-IS            Intermediate System to Intermediate System
> LAN              Local-Area Network
> MAC             Media Access Control
> ND               Neighbor Discovery
> OUI              Organizationally Unique Identifier
> PDU              Protocol Data Unit
> RARP            Reverse Address Resolution Protocol
> RBridge         An alternative name for a TRILL switch
> TLV              Type Length Value
> TRILL             Transparent Interconnection of Lots of Links
> TRILL switch   A device that implements the TRILL protocol
> VLAN            Virtual Local-Area Network
> _______________________________________________
> trill mailing list
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill