Early Review of draft-ietf-trill-ia-appsubtlv-07
review-ietf-trill-ia-appsubtlv-07-rtgdir-early-mcpherson-2016-05-05-00

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.

Document: draft-ietf-trill-ia-appsubtlv-07.txt

Reviewer: Danny McPherson

Review Date: May 4, 2016

Intended Status: Proposed Standard

Summary:

 I have some minor concerns about this document that I think should be resolved
 before publication.

Comments:

I believe the draft is technically sound, however, the quality and readability
needs a bit more work, particularly as it relates to introduction of new terms,
and consistent application and use of all terms.  There are also some general
error handling and encoding issues that need to be given consideration.

Major Issues:

I have no “Major” issues with this I-D.

Minor Issues:

ERROR HANDLING: There are a number of places in the document where it discusses
the receipt of malformed, badly encoded, non-matching, or corrupt messages, and
the advice is to either [silently] discard or ignore the messages.  Some
general guidance should be given here to enable operational diagnosis of any
issues that may result in temporal or persistent problems, where logging and
other actions should occur.  Some aspects of this might leverage the OAM
Framework efforts, although it appears much of the TRILL work leaves this to
the implementer.

When using “Nickname” it would be useful to define the encoding as an unsigned
16-bit integer, or just reference "as specified in S 3.7 of RFC6325”.

The inclusion of the “TLV” acronym in the "APPsub-TLV” TLV name seems loose and
redundant to me, as opposed to “APPsub TLV” or similar.

Inconsistent use of “Interface Address APPsub-TLV”, “IA APPSub-TLV”, “Interface
Address APP-subTLV”, and “AppsubTLV” makes it seem like you’re talking about
different things.

The use of “sub-sub-TLV” seems a bit loose and sloppy to me as well, and should
be cleaned up.  E.g., S 5.2 “IA Appsub-TLV Sub-Sub-TLVs SubRegistry"

Only one of the “Figures” is labeled / captioned

The use of “Address Sets” and “Address Sets Ends” makes it a bit hard to read
when used in sentences.  Perhaps an acronym for each, or
hyphenating/underscoring them would make it more readable.

S 3.4 the 2-byte “Type” value in the diagram should be “TOPOLOGY”, not
“DATALEN”.

I noticed that Radia was a co-author until the last revision, and now she
doesn’t even exist in the Acknowledgements section.  While no explanation is
required here, I did find this a bit odd.

IANA Considerations: Some guidance from the IANA folks on the formatting of
this section might be in order.  It’s not as clear as it could be about what
their instructions are here.

S 2: It’s unclear to me if the “Confidence” value of 255 “being treated as if
it was 254” is inline with RFC6325 S 4.8.1 guidance?

In general, I agree there appear to be no new Security Considerations here.  I
do not believe Asymmetry will be an issue with the forged packet discard issue
although some consideration of this might be in order (or perhaps simply a
reference to SAVI or other work here).  I wonder if some consideration should
be given to broader disclosure of reachable layer 2 addresses here, but that
seems a bit reaching as well.

Nits:

Abstract & Introduction: s/by-pass/bypass/

S.2: s/Data Label is reachable from /Data Label are reachable/

A reference for the first use of AFN would be useful, perhaps to the IANA
registry.

Expressing TBD code points in [ ] brackets might help with readability as well

S 3.2 “if the Length is 0 or 1 or less” — not sure the “or less" is necessary?

Attachment:

smime.p7s

Description:

 S/MIME cryptographic signature