Transparent Interconnection of Lots of Links (TRILL): ARP and Neighbor Discovery (ND) Optimization
draft-ietf-trill-arp-optimization-09

[Ballot comment]

- Can you clarify on which device type you need to enable the following option:

    TRILL already provides an option to disable data-plane learning from
    the source MAC address of end-station frames on a per port basis (see
    Section 5.3 of [RFC6325]).

-

    1) IP address - indicated protocol address that is normally an IPv4
    address in ARP or an IPv6 address in ND.

"normally"?  I've seen the term "Non-zero IP" later on in the draft



Below is Mahesh's OPS DIR review

I have reviewed this document as part of the Operational directorate’s ongoing
effort to review all IETF documents being processed by the IESG.
These comments were written with the intent of improving the
operational aspects of the IETF drafts. Comments that are not addressed in last
call may be included in AD reviews during the IESG review.  Document editors
and WG chairs should treat these comments just like any other last
call comments.

Document reviewed:  draft-ietf-trill-arp-optimization-08

Summary: Ready with Nits

Document Status: Standard Track

General Comments: The abstract of the document says that the draft tries “To
reduce the burden on a TRILL campus caused by these multi-destination messages,
RBridges MAY implement an "optimized ARP/ND response", as specified herein,
when the target's location is known by the ingress RBridge or can be obtained
from a directory. This avoids ARP/ND query and answer flooding.” Implementation
of this draft will impact the operations of the network. As such careful
consideration should be placed on operational and management impact of the
draft.

The following comments look at the document both from an operational
perspective as well as a management perspective.

Operational Considerations:

Operational considerations include installation and initial setup, migration
path, requirements on other protocols, impact on network operations and
verification of correct operation.

>From an impact on network operations perspective, this draft proposes to reduce
the traffic in the network by preventing a network wide broadcast and multicast
of messages. As such it should reduce the impact on the network, when operating
correctly. In the worst case, that it is not operating or operating
incorrectly, these network broadcast and multicast messages will “leak” into
the broader network, where they will be treated just as they are in todays
network. For this reason, a migration path may not be required, or existing
protocols modified to deal with the change.

>From a verification of correct operations, it is not clear how one determines
that the RBridge is operating correctly beyond observing individual ARP/ND
messages. Does it keep track of ARP/ND messages it has intercepted and
responded to on the local network, which would have escaped to the broader
network? Keeping track of statistics will allow for tracking the operation of
what is defined in the draft.

Management Considerations:

Management considerations include interoperability, fault management,
configuration management, accounting, performance and security.

>From a configuration management perspective, it is not clear how the
configuration of the RBridge is realized. For example, per the draft, RBridge
might not verify an IP address if the network manager's policy is to have the
network behave, for each Data Label, as if it were a single link and just
believe an ARP/ND it receives. If such a configuration is desired, this or an
accompanying document needs to define the manageability aspect of RBridge,
preferably in the form of a YANG model.

>From a accounting perspective, For example, in the draft, RBridge could for
generic ARP/ND request seeking the MAC address corresponding to an IP address,
if the edge RBridge knows the IP address and corresponding MAC, behavior is as
in item (a), otherwise behavior is as in item (b). Behavior for gratuitous ARP
and ND Unsolicited Neighbor Advertisements [RFC4861] is given in item (c). And
item (d) covers handling of Address Probe ARP Query. Are there specific
statistics being maintained for each of these options? Keeping track of
individual options allows for capacity management and planning.

A run of idnits revealed a few warnings:

Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == Line 99 has weird spacing: '...enience  along...'

  -- The document date (April 17, 2017) is 79 days in the past.  Is this
    intentional?

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  == Missing Reference: 'IA-draft' is mentioned on line 390, but not defined

  == Unused Reference: 'RFC7356' is defined on line 540, but no explicit
    reference was found in the text

  == Outdated reference: draft-ietf-trill-directory-assist-mechanisms has
    been published as RFC 8171

    Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--).

    Run idnits with the --verbose option for more detailed information about
    the items above.

[Ballot discuss]
It's not clear to me how the security properties of this mechanism
compare to existing TRILL. The text says:

  Unless Secure ND (SEND [RFC3971]) is used, ARP and ND messages can be
  easily forged. Therefore the learning of MAC/IP addresses by RBridges
  from ARP/ND should not be considered as reliable. See Section 4.1 for
  SEND Considerations.

"not considered as reliable" seems suboptimal. You need to cover how
this mechanism compares to the non-use of this mechanism.


This document seems very sketchy on what you do when you get duplicate
IPs.

  In the case where the former owner replies, a Duplicate Address has
  been detected. In this case the querying RBridge SHOULD log the
  duplicate so that the network administrator can take appropriate
  action.

How does logging solve the problem? What do you reply to ARPs with
and/or propagate to other nodes? Do you tell the originator of the
advertisement you have a duplicate?


  When a newly connected end-station exchanges messages with a DHCP
  [RFC2131] server an edge RBridge should snoop them (mainly the
  DHCPAck message) and store IP/MAC mapping information in its ARP/ND
  cache and should also send the information out through the TRILL
  control plane using ESADI.

What happens if the attacker sets up a fake DHCP server and pretends
to assign addresses to himself? It seems like maybe that's the same
as fake ARPs but maybe not.

In general, the security considerations need a complete threat
analysis per 3552.

[Ballot comment]
S 2.

  plane on the edge RBridges, it should be possible to completely
  suppress flooding of ARP/ND messages in a TRILL Campus, When all end-
  station MAC addresses are similarly known, it should be possible to
  suppress unknown unicast flooding by dropping any unknown unicast
  received at an edge RBridge.

Are these "should be possibles" normative? Descriptive?

S 4.
This is a sequence of steps, so it would be nice to preface them with
a list of the steps. It's also odd to have SEND considerations right
in the middle here.


4.3 Get Sender's IP/MAC Mapping Information for Non-zero IP
Please explain what a non-zero IP is and why it's relevant.
This graf also needs an introductory sentence or something before
the bullets.


S 4.4.
  It is not essential that all RBridges use the same strategy for which
  option to select for a particular ARP/ND query. It is up to the
  implementation.

This seems inconsistent with the MUST in arm (b) below, because I
can just take some other arm. It's also kind of surprising to be this
non-prescriptive.


S 8.
  some other location (MAC/VM Mobility) and gets connected to egde-

Nit: edge is mispelled.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-trill-arp-optimization-08.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: draft-ietf-trill-arp-optimization@ietf.org, trill-chairs@ietf.org, trill@ietf.org, skh@ndzh.com, akatlas@gmail.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (TRILL: ARP/ND Optimization) to Proposed Standard


The IESG has received a request from the Transparent Interconnection of Lots
of Links WG (trill) to consider the following document: - 'TRILL: ARP/ND
Optimization'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-06-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document describes mechanisms to optimize the ARP (Address
  Resolution Protocol) and ND (Neighbor Discovery) traffic in TRILL
  campus. Such optimization reduces packet flooding over a TRILL
  campus.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-trill-arp-optimization/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-trill-arp-optimization/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2896/

Shepherd write-up Template version: 24 February 2012.
Shepherd: Susan Hares
Date: 5/31/2017
Status:  Awaiting further resolution of Alvaro's and Suresh's SEND comments.
https://www.ietf.org/mail-archive/web/trill/current/msg07575.html

===================================
type of RFC: Proposed standard

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Specifies an optimized ARP/ND responses to be implemented in
TRILL RBridges.  Standard specifies an optional, but highly
useful additional to TRILL to reduce ARP/ND query flooding. 

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary
  This document describes mechanisms to optimize the ARP (Address
  Resolution Protocol) and ND (Neighbor Discovery) traffic in TRILL
  campus. Such optimization reduces packet flooding over a TRILL
  campus.

Working Group Summary

This WG Draft is part of a directory service solution
that has been discussed for 3 years.  Consensus
is strong on the complete solution.

Status:  Awaiting further resolution of Alvaro's and Suresh's SEND comments.
https://www.ietf.org/mail-archive/web/trill/current/msg07575.html

Document Quality
a) Are there existing implementations of the protocol?

This draft is part of the TRILL WG directory service work item. 
The lack of directory services was one of the major challenges deployments
of TRILL have encounter in the field.

Protocol standards
1) draft-ietf-trill-directory-assist-mechanisms - directory service for TRILL Edge switches (at RFC editors)
2) [RFC7978 - RBridge Channel Header Extension (secure tunnel method allows encapsulation of address information)
3) RFC 7961 - reporting of addresses for TRILL interfaces in ISIS application sub-TLV (replaces ARP/ND)
4) draft-ietf-trill-arp-optimization - mechanism to optimize ARP and ND traffic
    on TRILL campus
5) Smart end nodes - reducing size of end-node table in rbridges by allowing "smart" endnodes to volunteer
for ending node learning.
6)draft-ietf-trill-directory-assisted-encap-04  - encapsulation modification for data centers

b) Have a significant number of vendors indicated their plan to
  implement the specification?
 
  Directory service mechanism are currently implemented as proprietary
  fashions by every vendor that does some variant of TRILL (cisco, brocade, Huawei
  and others).  Until we get a full standard solution approved, the
  existing vendors with "early TRILL" implementations have little reason
  to switch.

  Huawei is planning implementations. Potentially Brocade and Cisco
  could switch to these mechanisms, but unless IETF standards are out
  as a set - this may not occur. 

Shepherd review:
https://mailarchive.ietf.org/arch/msg/trill/SVmP0QNwY3UaVhbjkweULl1ZxLE
Revision -01
https://mailarchive.ietf.org/arch/msg/i-d-announce/2hbdxmCfRW34_AgGaBC0mGGJMF8
(note: no change to RFC2119 text, Shepherd is checking on the right RFC2199 text).

Revision -07 WG LC
https://www.ietf.org/mail-archive/web/trill/current/msg07575.html
Shepherd's review is contained in this WG LC.

Revision -08 WG LC
https://www.ietf.org/mail-archive/web/trill/current/msg07748.html
 
Routing QA review: Eric Gray
http://www.ietf.org/mail-archive/web/rtg-dir/current/msg02606.html

Routing QA 2nd review: Geoff Houston
https://datatracker.ietf.org/doc/review-ietf-trill-arp-optimization-05-rtgdir-early-huston-2016-04-25/

WG LC  of version-8
https://www.ietf.org/mail-archive/web/trill/current/msg07748.html

Personnel
AD: Alia Atlas
WG chairs: Susan Hares and Jon Hudson
Document Shepherd: Susan Hares
Routing QA Review:  2 done

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

1) review of text and concepts
https://mailarchive.ietf.org/arch/msg/trill/SVmP0QNwY3UaVhbjkweULl1ZxLE

2) Routing QA Reviewer: Eric Gray: Minor concerns
Minor concerns: resolved.
http://www.ietf.org/mail-archive/web/rtg-dir/current/msg02606.html

3) Routing QA 2nd review: Geoff Houston:
Status: ready with nits:
https://datatracker.ietf.org/doc/review-ietf-trill-arp-optimization-05-rtgdir-early-huston-2016-04-25/

4) IESG review cycle found a problem with the
Status:  Awaiting further resolution of Alvaro's and Suresh's SEND comments.
https://www.ietf.org/mail-archive/web/trill/current/msg07442.html

call for WG LC on changes
https://www.ietf.org/mail-archive/web/trill/current/msg07575.html
Shepherd's indication that not all was fixed
https://www.ietf.org/mail-archive/web/trill/current/msg07646.html
final WG LC ((5/2 to 5/9)
https://www.ietf.org/mail-archive/web/trill/current/msg07748.html

3) WG LC comments -
After the initial WG LC, the IESG review and resend to the WG,
and 2 WG LCs on this document.  The final review was a "final check review".
No one has indicated any problems with version draft-ietf-trill-arp-optimization-08.txt.

The shepherd does not see any additional issues.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.  After 4 cycles of review and WG LC, I believe we've final nailed down all the issues.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Suresh and Alvaro should - double check the ARP/ND problems
one more time during AD evaluation, then hopefully - it will go quickly.
I have sent a request to Suresh and Alvaro to review this document in
parallel to AD evaluation.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns.
After 4+ years of work on Directory solution, this has been discussed at
length and throughly in WG. 

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

IPR filed:
https://www.ietf.org/mail-archive/web/trill/current/msg07564.html
This filing was before the WG LC.

Yizhou LI
https://www.ietf.org/mail-archive/web/trill/current/msg07194.html

Radia Perlman
https://www.ietf.org/mail-archive/web/trill/current/msg07202.html

Linda Dunbar
https://www.ietf.org/mail-archive/web/trill/current/msg07203.html

Donald Eastlake
https://www.ietf.org/mail-archive/web/trill/current/msg07193.html
(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR Disclosures

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Based on 4 years of work on directory service and lots of discussion,
the consensus is strong with all parties agreeing on the solution set.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

no.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

NITS - TBD on last draft

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review for any criteria.

(13) Have all references within this document been identified as
either normative or informative?

yes  - RFC7357 - will be added by authors (version -05.txt)

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
none

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
No 

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No - this is new work.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

No IANA Actions

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

None needed.

Shepherd write-up Template version: 24 February 2012.
Shepherd: Susan Hares
Date: 5/31/2017
Status:  Awaiting further resolution of Alvaro's and Suresh's SEND comments.
https://www.ietf.org/mail-archive/web/trill/current/msg07575.html

===================================
type of RFC: Proposed standard

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Specifies an optimized ARP/ND responses to be implemented in
TRILL RBridges.  Standard specifies an optional, but highly
useful additional to TRILL to reduce ARP/ND query flooding. 

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary
  This document describes mechanisms to optimize the ARP (Address
  Resolution Protocol) and ND (Neighbor Discovery) traffic in TRILL
  campus. Such optimization reduces packet flooding over a TRILL
  campus.

Working Group Summary

This WG Draft is part of a directory service solution
that has been discussed for 3 years.  Consensus
is strong on the complete solution.

Status:  Awaiting further resolution of Alvaro's and Suresh's SEND comments.
https://www.ietf.org/mail-archive/web/trill/current/msg07575.html

Document Quality
a) Are there existing implementations of the protocol?

This draft is part of the TRILL WG directory service work item. 
The lack of directory services was one of the major challenges deployments
of TRILL have encounter in the field.

Protocol standards
1) draft-ietf-trill-directory-assist-mechanisms - directory service for TRILL Edge switches (at RFC editors)
2) [RFC7978 - RBridge Channel Header Extension (secure tunnel method allows encapsulation of address information)
3) RFC 7961 - reporting of addresses for TRILL interfaces in ISIS application sub-TLV (replaces ARP/ND)
4) draft-ietf-trill-arp-optimization - mechanism to optimize ARP and ND traffic
    on TRILL campus
5) Smart end nodes - reducing size of end-node table in rbridges by allowing "smart" endnodes to volunteer
for ending node learning.
6)draft-ietf-trill-directory-assisted-encap-04  - encapsulation modification for data centers

b) Have a significant number of vendors indicated their plan to
  implement the specification?
 
  Directory service mechanism are currently implemented as proprietary
  fashions by every vendor that does some variant of TRILL (cisco, brocade, Huawei
  and others).  Until we get a full standard solution approved, the
  existing vendors with "early TRILL" implementations have little reason
  to switch.

  Huawei is planning implementations. Potentially Brocade and Cisco
  could switch to these mechanisms, but unless IETF standards are out
  as a set - this may not occur. 

Shepherd review:
https://mailarchive.ietf.org/arch/msg/trill/SVmP0QNwY3UaVhbjkweULl1ZxLE
Revision -01
https://mailarchive.ietf.org/arch/msg/i-d-announce/2hbdxmCfRW34_AgGaBC0mGGJMF8
(note: no change to RFC2119 text, Shepherd is checking on the right RFC2199 text).

Revision -07 WG LC
https://www.ietf.org/mail-archive/web/trill/current/msg07575.html
Shepherd's review is contained in this WG LC.

Revision -08 WG LC
https://www.ietf.org/mail-archive/web/trill/current/msg07748.html
 
Routing QA review: Eric Gray
http://www.ietf.org/mail-archive/web/rtg-dir/current/msg02606.html

Routing QA 2nd review: Geoff Houston
https://datatracker.ietf.org/doc/review-ietf-trill-arp-optimization-05-rtgdir-early-huston-2016-04-25/

WG LC  of version-8
https://www.ietf.org/mail-archive/web/trill/current/msg07748.html

Personnel
AD: Alia Atlas
WG chairs: Susan Hares and Jon Hudson
Document Shepherd: Susan Hares
Routing QA Review:  2 done

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

1) review of text and concepts
https://mailarchive.ietf.org/arch/msg/trill/SVmP0QNwY3UaVhbjkweULl1ZxLE

2) Routing QA Reviewer: Eric Gray: Minor concerns
Minor concerns: resolved.
http://www.ietf.org/mail-archive/web/rtg-dir/current/msg02606.html

3) Routing QA 2nd review: Geoff Houston:
Status: ready with nits:
https://datatracker.ietf.org/doc/review-ietf-trill-arp-optimization-05-rtgdir-early-huston-2016-04-25/

4) IESG review cycle found a problem with the
Status:  Awaiting further resolution of Alvaro's and Suresh's SEND comments.
https://www.ietf.org/mail-archive/web/trill/current/msg07442.html

call for WG LC on changes
https://www.ietf.org/mail-archive/web/trill/current/msg07575.html
Shepherd's indication that not all was fixed
https://www.ietf.org/mail-archive/web/trill/current/msg07646.html
final WG LC ((5/2 to 5/9)
https://www.ietf.org/mail-archive/web/trill/current/msg07748.html

3) WG LC comments -
After the initial WG LC, the IESG review and resend to the WG,
and 2 WG LCs on this document.  The final review was a "final check review".
No one has indicated any problems with version draft-ietf-trill-arp-optimization-08.txt.

The shepherd does not see any additional issues.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.  After 4 cycles of review and WG LC, I believe we've final nailed down all the issues.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Suresh and Alvaro should - double check the ARP/ND problems
one more time during AD evaluation, then hopefully - it will go quickly.
I have sent a request to Suresh and Alvaro to review this document in
parallel to AD evaluation.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns.
After 4+ years of work on Directory solution, this has been discussed at
length and throughly in WG. 

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

IPR filed:
https://www.ietf.org/mail-archive/web/trill/current/msg07564.html
This filing was before the WG LC.

Yizhou LI
https://www.ietf.org/mail-archive/web/trill/current/msg07194.html

Radia Perlman
https://www.ietf.org/mail-archive/web/trill/current/msg07202.html

Linda Dunbar
https://www.ietf.org/mail-archive/web/trill/current/msg07203.html

Donald Eastlake
https://www.ietf.org/mail-archive/web/trill/current/msg07193.html
(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR Disclosures

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Based on 4 years of work on directory service and lots of discussion,
the consensus is strong with all parties agreeing on the solution set.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

no.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

NITS - TBD on last draft

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review for any criteria.

(13) Have all references within this document been identified as
either normative or informative?

yes  - RFC7357 - will be added by authors (version -05.txt)

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
none

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
No 

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No - this is new work.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

No IANA Actions

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

None needed.

Shepherd write-up Template version: 24 February 2012.
Shepherd: Susan Hares
Date: 1/13/2017
Status:  Awaiting further resolution of Alvaro's and Suresh's SEND comments.
https://www.ietf.org/mail-archive/web/trill/current/msg07575.html

===================================
type of RFC: Proposed standard

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Specifies an optimized ARP/ND responses to be implemented in
TRILL RBridges.  Standard specifies an optional, but highly
useful additional to TRILL to reduce ARP/ND query flooding. 

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary
  This document describes mechanisms to optimize the ARP (Address
  Resolution Protocol) and ND (Neighbor Discovery) traffic in TRILL
  campus. Such optimization reduces packet flooding over a TRILL
  campus.

Working Group Summary

This WG Draft is part of a directory service solution
that has been discussed for 3 years.  Consensus
is strong on the complete solution.

Document Quality
a) Are there existing implementations of the protocol?

This draft is part of a 4 draft directory service dealing
with directory services.  The four drafts are:
draft-ietf-trill-directory-assist-mechanisms () - describes the push/pull (After IETF LC)
draft-ietf-trill-channel-tunnel-05 - secure tunnel for directory push (
draft-ietf-trill-ia-appsubtlv-05 - reporting of addresses for TRILL interfaces
    in ISIS application sub-TLV (reduces/replaces need for ARP/ND )
draft-ietf-trill-arp-optimization - mechanism to optimize ARP and ND traffic
    on TRILL campus

b) Have a significant number of vendors indicated their plan to
  implement the specification?
 
  Directory service mechanism are currently implemented as proprietary
  fashions by every vendor that does some variant of TRILL (cisco, brocade, Huawei
  and others).  Until we get a full standard solution approved, the
  existing vendors with "early TRILL" implementations have little reason
  to switch.

  Huawei is planning implementations. Potentially Brocade and Cisco
  could switch to these mechanisms, but unless IETF standards are out
  as a set - this may not occur. 

Shepherd review:
https://mailarchive.ietf.org/arch/msg/trill/SVmP0QNwY3UaVhbjkweULl1ZxLE
Revision -01
https://mailarchive.ietf.org/arch/msg/i-d-announce/2hbdxmCfRW34_AgGaBC0mGGJMF8
(note: no change to RFC2119 text, Shepherd is checking on the right RFC2199 text).

Revision -07 WG LC
https://www.ietf.org/mail-archive/web/trill/current/msg07575.html
Shepherd's review is contained in this WG LC.


 
Routing QA review: Eric Gray
http://www.ietf.org/mail-archive/web/rtg-dir/current/msg02606.html

WG LC:

Personnel
AD: Alia Atlas
WG chairs: Susan Hares and Jon Hudson
Document Shepherd: Susan Hares
Routing QA Review: No

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

1) review of text and concepts
https://mailarchive.ietf.org/arch/msg/trill/SVmP0QNwY3UaVhbjkweULl1ZxLE

2) Routing QA Reviewer: Eric Gray: Minor concerns
http://www.ietf.org/mail-archive/web/rtg-dir/current/msg02606.html

3) WG LC comments - TBD

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.  - TBD additional comments.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Internet Directorate should review for ARP/ND.  Ralph Droms knows these concepts.
OPS/NM Directorate and SEC-DIR should review.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns.
After 3 years of work on Directory solution, this has been discussed at
length and throughly in WG. 

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

IPR filed:
https://www.ietf.org/mail-archive/web/trill/current/msg07564.html
This filing was before the WG LC.

Yizhou LI
https://www.ietf.org/mail-archive/web/trill/current/msg07194.html

Radia Perlman
https://www.ietf.org/mail-archive/web/trill/current/msg07202.html

Linda Dunbar
https://www.ietf.org/mail-archive/web/trill/current/msg07203.html

Donald Eastlake
https://www.ietf.org/mail-archive/web/trill/current/msg07193.html
(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR Disclosures

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Based on 3 years of work on directory service and lots of discussion,
the consensus is strong with all parties agreeing on the solution set.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

no.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

NITS - TBD on last draft

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review for any criteria.

(13) Have all references within this document been identified as
either normative or informative?

yes  - RFC7357 - will be added by authors (version -05.txt)

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
none

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
No 

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No - this is new work.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

No IANA Actions

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

None needed.

Shepherd write-up Template version: 24 February 2012.
Shepherd: Susan Hares
Date: 1/13/2017
Status:  Awaiting further resolution of Alvaro's and Suresh's SEND comments.
https://www.ietf.org/mail-archive/web/trill/current/msg07575.html

===================================
type of RFC: Proposed standard

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Specifies an optimized ARP/ND responses to be implemented in
TRILL RBridges.  Standard specifies an optional, but highly
useful additional to TRILL to reduce ARP/ND query flooding. 

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary
  This document describes mechanisms to optimize the ARP (Address
  Resolution Protocol) and ND (Neighbor Discovery) traffic in TRILL
  campus. Such optimization reduces packet flooding over a TRILL
  campus.

Working Group Summary

This WG Draft is part of a directory service solution
that has been discussed for 3 years.  Consensus
is strong on the complete solution.

Document Quality
a) Are there existing implementations of the protocol?

This draft is part of a 4 draft directory service dealing
with directory services.  The four drafts are:
draft-ietf-trill-directory-assist-mechanisms () - describes the push/pull (After IETF LC)
draft-ietf-trill-channel-tunnel-05 - secure tunnel for directory push (
draft-ietf-trill-ia-appsubtlv-05 - reporting of addresses for TRILL interfaces
    in ISIS application sub-TLV (reduces/replaces need for ARP/ND )
draft-ietf-trill-arp-optimization - mechanism to optimize ARP and ND traffic
    on TRILL campus

b) Have a significant number of vendors indicated their plan to
  implement the specification?
 
  Directory service mechanism are currently implemented as proprietary
  fashions by every vendor that does some variant of TRILL (cisco, brocade, Huawei
  and others).  Until we get a full standard solution approved, the
  existing vendors with "early TRILL" implementations have little reason
  to switch.

  Huawei is planning implementations. Potentially Brocade and Cisco
  could switch to these mechanisms, but unless IETF standards are out
  as a set - this may not occur. 

Shepherd review:
https://mailarchive.ietf.org/arch/msg/trill/SVmP0QNwY3UaVhbjkweULl1ZxLE
Revision -01
https://mailarchive.ietf.org/arch/msg/i-d-announce/2hbdxmCfRW34_AgGaBC0mGGJMF8
(note: no change to RFC2119 text, Shepherd is checking on the right RFC2199 text).

Revision -07 WG LC
https://www.ietf.org/mail-archive/web/trill/current/msg07575.html
Shepherd's review is contained in this WG LC.


 
Routing QA review: Eric Gray
http://www.ietf.org/mail-archive/web/rtg-dir/current/msg02606.html

WG LC:

Personnel
AD: Alia Atlas
WG chairs: Susan Hares and Jon Hudson
Document Shepherd: Susan Hares
Routing QA Review: No

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

1) review of text and concepts
https://mailarchive.ietf.org/arch/msg/trill/SVmP0QNwY3UaVhbjkweULl1ZxLE

2) Routing QA Reviewer: Eric Gray: Minor concerns
http://www.ietf.org/mail-archive/web/rtg-dir/current/msg02606.html

3) WG LC comments - TBD

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.  - TBD additional comments.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Internet Directorate should review for ARP/ND.  Ralph Droms knows these concepts.
OPS/NM Directorate and SEC-DIR should review.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns.
After 3 years of work on Directory solution, this has been discussed at
length and throughly in WG. 

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

IPR filed:
https://www.ietf.org/mail-archive/web/trill/current/msg07564.html
This filing was before the WG LC.

Yizhou LI
https://www.ietf.org/mail-archive/web/trill/current/msg07194.html

Radia Perlman
https://www.ietf.org/mail-archive/web/trill/current/msg07202.html

Linda Dunbar
https://www.ietf.org/mail-archive/web/trill/current/msg07203.html

Donald Eastlake
https://www.ietf.org/mail-archive/web/trill/current/msg07193.html
(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR Disclosures

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Based on 3 years of work on directory service and lots of discussion,
the consensus is strong with all parties agreeing on the solution set.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

no.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

NITS - TBD on last draft

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review for any criteria.

(13) Have all references within this document been identified as
either normative or informative?

yes  - RFC7357 - will be added by authors (version -05.txt)

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
none

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
No 

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No - this is new work.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

No IANA Actions

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

None needed.

Shepherd write-up Template version: 24 February 2012.
Shepherd: Susan Hares
Date: 8/26/2016
Status:  Awaiting further resolution of Alvaro's and Suresh's SEND comments.

===================================
type of RFC: Proposed standard

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Specifies an optimized ARP/ND responses to be implemented in
TRILL RBridges.  Standard specifies an optional, but highly
useful additional to TRILL to reduce ARP/ND query flooding. 

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary
  This document describes mechanisms to optimize the ARP (Address
  Resolution Protocol) and ND (Neighbor Discovery) traffic in TRILL
  campus. Such optimization reduces packet flooding over a TRILL
  campus.

Working Group Summary

This WG Draft is part of a directory service solution
that has been discussed for 3 years.  Consensus
is strong on the complete solution.

Document Quality
a) Are there existing implementations of the protocol?

No, and this draft is part of a 4 draft directory service dealing
with directory services.  The four drafts are:
draft-ietf-trill-directory-assist-mechanisms () - describes the push/pull
draft-ietf-trill-channel-tunnel-05 - secure tunnel for directory push
draft-ietf-trill-ia-appsubtlv-05 - reporting of addresses for TRILL interfaces
    in ISIS application sub-TLV (reduces/replaces need for ARP/ND )
draft-ietf-trill-arp-optimization - mechanism to optimize ARP and ND traffic
    on TRILL campus

b) Have a significant number of vendors indicated their plan to
  implement the specification?
 
  Directory service mechanism are currently implemented as proprietary
  fashions by every vendor that does some variant of TRILL (cisco, brocade, Huawei
  and others).  Until we get a full standard solution approved, the
  existing vendors with "early TRILL" implementations have little reason
  to switch.

  Huawei is planning implementations. Potentially Brocade and Cisco
  could switch to these mechanisms, but unless IETF standards are out
  as a set - this may not occur. 

Shepherd review:
https://mailarchive.ietf.org/arch/msg/trill/SVmP0QNwY3UaVhbjkweULl1ZxLE
Revision -01
https://mailarchive.ietf.org/arch/msg/i-d-announce/2hbdxmCfRW34_AgGaBC0mGGJMF8
(note: no change to RFC2119 text, Shepherd is checking on the right RFC2199 text).
 
Routing QA review: Eric Gray
http://www.ietf.org/mail-archive/web/rtg-dir/current/msg02606.html

WG LC:

Personnel
AD: Alia Atlas
WG chairs: Susan Hares and Jon Hudson
Document Shepherd: Susan Hares
Routing QA Review: No

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

1) review of text and concepts
https://mailarchive.ietf.org/arch/msg/trill/SVmP0QNwY3UaVhbjkweULl1ZxLE

2) Routing QA Reviewer: Eric Gray: Minor concerns
http://www.ietf.org/mail-archive/web/rtg-dir/current/msg02606.html

3) WG LC comments - TBD

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.  - TBD additional comments.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Internet Directorate should review for ARP/ND.  Ralph Droms knows these concepts.
OPS/NM Directorate and SEC-DIR should review.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns.
After 3 years of work on Directory solution, this has been discussed at
length and throughly in WG. 

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

IPR filed:
https://www.ietf.org/mail-archive/web/trill/current/msg07564.html
This filing was before the WG LC.

Yizhou LI
https://www.ietf.org/mail-archive/web/trill/current/msg07194.html

Radia Perlman
https://www.ietf.org/mail-archive/web/trill/current/msg07202.html

Linda Dunbar
https://www.ietf.org/mail-archive/web/trill/current/msg07203.html

Donald Eastlake
https://www.ietf.org/mail-archive/web/trill/current/msg07193.html
(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR Disclosures

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Based on 3 years of work on directory service and lots of discussion,
the consensus is strong with all parties agreeing on the solution set.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

no.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

NITS - TBD on last draft

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review for any criteria.

(13) Have all references within this document been identified as
either normative or informative?

yes  - RFC7357 - will be added by authors (version -05.txt)

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
none

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
No 

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No - this is new work.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

No IANA Actions

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

None needed.

Shepherd write-up Template version: 24 February 2012.
Shepherd: Susan Hares
Date: 8/26/2016
Status:  Awaiting version 7 to resolve Alavaro's comments.
===================================
type of RFC: Proposed standard

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Specifies an optimized ARP/ND responses to be implemented in
TRILL RBridges.  Standard specifies an optional, but highly
useful additional to TRILL to reduce ARP/ND query flooding. 

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary
  This document describes mechanisms to optimize the ARP (Address
  Resolution Protocol) and ND (Neighbor Discovery) traffic in TRILL
  campus. Such optimization reduces packet flooding over a TRILL
  campus.

Working Group Summary

This WG Draft is part of a directory service solution
that has been discussed for 3 years.  Consensus
is strong on the complete solution.

Document Quality
a) Are there existing implementations of the protocol?

No, and this draft is part of a 4 draft directory service dealing
with directory services.  The four drafts are:
draft-ietf-trill-directory-assist-mechanisms () - describes the push/pull
draft-ietf-trill-channel-tunnel-05 - secure tunnel for directory push
draft-ietf-trill-ia-appsubtlv-05 - reporting of addresses for TRILL interfaces
    in ISIS application sub-TLV (reduces/replaces need for ARP/ND )
draft-ietf-trill-arp-optimization - mechanism to optimize ARP and ND traffic
    on TRILL campus

b) Have a significant number of vendors indicated their plan to
  implement the specification?
 
  Directory service mechanism are currently implemented as proprietary
  fashions by every vendor that does some variant of TRILL (cisco, brocade, Huawei
  and others).  Until we get a full standard solution approved, the
  existing vendors with "early TRILL" implementations have little reason
  to switch.

  Huawei is planning implementations. Potentially Brocade and Cisco
  could switch to these mechanisms, but unless IETF standards are out
  as a set - this may not occur. 

Shepherd review:
https://mailarchive.ietf.org/arch/msg/trill/SVmP0QNwY3UaVhbjkweULl1ZxLE
Revision -01
https://mailarchive.ietf.org/arch/msg/i-d-announce/2hbdxmCfRW34_AgGaBC0mGGJMF8
(note: no change to RFC2119 text, Shepherd is checking on the right RFC2199 text).
 
Routing QA review: Eric Gray
http://www.ietf.org/mail-archive/web/rtg-dir/current/msg02606.html

WG LC:

Personnel
AD: Alia Atlas
WG chairs: Susan Hares and Jon Hudson
Document Shepherd: Susan Hares
Routing QA Review: No

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

1) review of text and concepts
https://mailarchive.ietf.org/arch/msg/trill/SVmP0QNwY3UaVhbjkweULl1ZxLE

2) Routing QA Reviewer: Eric Gray: Minor concerns
http://www.ietf.org/mail-archive/web/rtg-dir/current/msg02606.html

3) WG LC comments - TBD

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.  - TBD additional comments.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Internet Directorate should review for ARP/ND.  Ralph Droms knows these concepts.
OPS/NM Directorate and SEC-DIR should review.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns.
After 3 years of work on Directory solution, this has been discussed at
length and throughly in WG. 

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yizhou LI
https://www.ietf.org/mail-archive/web/trill/current/msg07194.html

Radia Perlman
https://www.ietf.org/mail-archive/web/trill/current/msg07202.html

Linda Dunbar
https://www.ietf.org/mail-archive/web/trill/current/msg07203.html

Donald Eastlake
https://www.ietf.org/mail-archive/web/trill/current/msg07193.html
(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR Disclosures

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Based on 3 years of work on directory service and lots of discussion,
the consensus is strong with all parties agreeing on the solution set.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

no.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

NITS - TBD on last draft

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review for any criteria.

(13) Have all references within this document been identified as
either normative or informative?

yes  - RFC7357 - will be added by authors (version -05.txt)

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
none

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
No 

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No - this is new work.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

No IANA Actions

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

None needed.

Shepherd write-up Template version: 24 February 2012.
Shepherd: Susan Hares
Date: 8/26/2016
Status:  Awaiting discussion with Alia (ETA 9/6/2016) 

===================================
type of RFC: Proposed standard

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Specifies an optimized ARP/ND responses to be implemented in
TRILL RBridges.  Standard specifies an optional, but highly
useful additional to TRILL to reduce ARP/ND query flooding. 

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary
  This document describes mechanisms to optimize the ARP (Address
  Resolution Protocol) and ND (Neighbor Discovery) traffic in TRILL
  campus. Such optimization reduces packet flooding over a TRILL
  campus.

Working Group Summary

This WG Draft is part of a directory service solution
that has been discussed for 3 years.  Consensus
is strong on the complete solution.

Document Quality
a) Are there existing implementations of the protocol?

No, and this draft is part of a 4 draft directory service dealing
with directory services.  The four drafts are:
draft-ietf-trill-directory-assist-mechanisms () - describes the push/pull
draft-ietf-trill-channel-tunnel-05 - secure tunnel for directory push
draft-ietf-trill-ia-appsubtlv-05 - reporting of addresses for TRILL interfaces
    in ISIS application sub-TLV (reduces/replaces need for ARP/ND )
draft-ietf-trill-arp-optimization - mechanism to optimize ARP and ND traffic
    on TRILL campus

b) Have a significant number of vendors indicated their plan to
  implement the specification?
 
  Directory service mechanism are currently implemented as proprietary
  fashions by every vendor that does some variant of TRILL (cisco, brocade, Huawei
  and others).  Until we get a full standard solution approved, the
  existing vendors with "early TRILL" implementations have little reason
  to switch.

  Huawei is planning implementations. Potentially Brocade and Cisco
  could switch to these mechanisms, but unless IETF standards are out
  as a set - this may not occur. 

Shepherd review:
https://mailarchive.ietf.org/arch/msg/trill/SVmP0QNwY3UaVhbjkweULl1ZxLE
Revision -01
https://mailarchive.ietf.org/arch/msg/i-d-announce/2hbdxmCfRW34_AgGaBC0mGGJMF8
(note: no change to RFC2119 text, Shepherd is checking on the right RFC2199 text).
 
Routing QA review: Eric Gray
http://www.ietf.org/mail-archive/web/rtg-dir/current/msg02606.html

WG LC:

Personnel
AD: Alia Atlas
WG chairs: Susan Hares and Jon Hudson
Document Shepherd: Susan Hares
Routing QA Review: No

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

1) review of text and concepts
https://mailarchive.ietf.org/arch/msg/trill/SVmP0QNwY3UaVhbjkweULl1ZxLE

2) Routing QA Reviewer: Eric Gray: Minor concerns
http://www.ietf.org/mail-archive/web/rtg-dir/current/msg02606.html

3) WG LC comments - TBD

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.  - TBD additional comments.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Internet Directorate should review for ARP/ND.  Ralph Droms knows these concepts.
OPS/NM Directorate and SEC-DIR should review.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns.
After 3 years of work on Directory solution, this has been discussed at
length and throughly in WG. 

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yizhou LI
https://www.ietf.org/mail-archive/web/trill/current/msg07194.html

Radia Perlman
https://www.ietf.org/mail-archive/web/trill/current/msg07202.html

Linda Dunbar
https://www.ietf.org/mail-archive/web/trill/current/msg07203.html

Donald Eastlake
https://www.ietf.org/mail-archive/web/trill/current/msg07193.html
(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR Disclosures

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Based on 3 years of work on directory service and lots of discussion,
the consensus is strong with all parties agreeing on the solution set.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

no.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

NITS - TBD on last draft

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review for any criteria.

(13) Have all references within this document been identified as
either normative or informative?

yes  - RFC7357 - will be added by authors (version -05.txt)

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
none

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
No 

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No - this is new work.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

No IANA Actions

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

None needed.

Please look at the outstanding IESG Discusses.  Donald Eastlake, as document shepherd, is engaged in the
conversations.  We believe that technical changes to the document are necessary - so it is being returned to
the WG

[Ballot discuss]
Section 3.2 discusses several options for obtaining an answer to a ND query. The section also mentions SEND, which prevents spoofing of results by the bridge itself. I believe it would be useful though to make a clearer recommendation on what to do with regards to the different options on obtaining an answer. Some of them are compatible with SEND, some of them are not. Also, how does one know SEND is being used?

Perhaps the document could specify a configurable mode where SEND is assumed to be in use and then you could not use the options that make this problematic. Or, perhaps better, if a node has been observed as using send, then use the correct option for that node.

[Ballot discuss]
I know this is an optional optimization, as described by the “MAY” in the Introduction.  However, some of the other normative language is not as strong as it should be to clearly specify the required behavior (if the mechanisms are being used), cause confusion, or is simply out of place.

1. In 3.1 (Get Sender's IP/MAC Mapping Information for Non-zero IP) the text says that the “RBridge MAY use different strategies to do so”.  That “MAY” contradicts the “SHOULD” used before it, which directs the RBridge to verify a duplicate address.  s/MAY/may

2. Still in 3.1: “…the RBridge SHOULD verify if a duplicate IP address has already been in use…”  What are the reasons where the RBridge would not verify this situation?  IOW, why is this “SHOULD” not a “MUST”?

3. I’m confused as to whether the APPsub-TLV is required or not.  The source of my confusion comes from Section 3.3 (Determine How to Handle the ARP/ND Response) which says that “R2 SHOULD initiate a link state update to inform all the other RBridges of the target's location…The update message can be carried by an IA APPsub-TLV [IA-draft]…”  This text seems to say that the APPsub-TLV SHOULD be used to carry the information — but text in Section 2 (IP/MAC Address Mappings) sounds to me as if the use of the APPsub-TLV is optional: “If the RBridge has extracted the sender's IP/MAC address pair from the received data packet (either ARP or ND), it MAY save the information and use the IA APPsub-TLV…”  Also, 3.1 and 3.2 both say that an “RBridge MAY use the IA APPsub-TLV”.  And finally the Security Considerations section seems to recommend using it…  Maybe it’s just me, but please clarify.  [BTW, if it is required, then I think that both the IA-draft and DirMech references should be Normative.]

4. In Section 2 (IP/MAC Address Mappings) the “MAY” in the following sentence is out of place since that is already the function of the confidence (as described in draft-ietf-trill-ia-appsubtlv and RFC6325): “A different confidence level MAY also be used to indicate the reliability of the mapping information.”

5. In Section 3.2 (Determine How to Reply to ARP/ND), both options (?) a and b say that the “RBridge MAY take one…”.  If the RBridge selected that option, then I think the action is no longer optional.  s/MAY/MUST

[Ballot comment]

3.2, 2nd last para: don't you need to say to never fake
SEND responses? saying "prevent local reply" seems unclear
to me, and a MUST NOT would seem called for.  I guess
Suresh's discuss covers that though, so just to note I agree
with him on that.

[Ballot discuss]
* After the ingress RBridge learns the mapping between an IPv6 address and a MAC address how is the liveness being tested/maintained? i.e. If a "learnt" target IP goes off link and the Rbridge keeps responding to NS messages wouldn't it make troubleshooting a nightmare?
* Section 3.2 case a): There is no guidance as to why or when an Rbridge would pick cases a1..a5. e.g. When a SEND NS is received only option a2 can work and all others will fail. 
* Section 3.2 case a.1): What should be the source IPv6 address of the NA generated by the ingress RBridge? Will this be an address of the target of the NS or one of the ingress Rbridge that responds?
* Section 3.2: How is an ND message where the target IP is not known handled? This case seems to be left out.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-trill-arp-optimization-06.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-trill-arp-optimization@ietf.org, trill-chairs@ietf.org, trill@ietf.org, skh@ndzh.com, akatlas@gmail.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (TRILL: ARP/ND Optimization) to Proposed Standard


The IESG has received a request from the Transparent Interconnection of
Lots of Links WG (trill) to consider the following document:
- 'TRILL: ARP/ND Optimization'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-07-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes mechanisms to optimize the ARP (Address
  Resolution Protocol) and ND (Neighbor Discovery) traffic in TRILL
  campus. Such optimization reduces packet flooding over a TRILL
  campus.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-trill-arp-optimization/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-trill-arp-optimization/ballot/


No IPR declarations have been submitted directly on this I-D.

Shepherd write-up Template version: 24 February 2012.
Shepherd: Susan Hares
Date: 3/17/2016
Note to AD (Alia) -05.txt is expected to have RFC7357 to fix nits, but
I suspect you will have other comments.


type of RFC: Proposed standard

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Specifies an optimized ARP/ND responses to be implemented in
TRILL RBridges.  Standard specifies an optional, but highly
useful additional to TRILL to reduce ARP/ND query flooding. 

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary
  This document describes mechanisms to optimize the ARP (Address
  Resolution Protocol) and ND (Neighbor Discovery) traffic in TRILL
  campus. Such optimization reduces packet flooding over a TRILL
  campus.

Working Group Summary

This WG Draft is part of a directory service solution
that has been discussed for 3 years.  Consensus
is strong on the complete solution.

Document Quality
a) Are there existing implementations of the protocol?

No, and this draft is part of a 4 draft directory service dealing
with directory services.  The four drafts are:
draft-ietf-trill-directory-assist-mechanisms () - describes the push/pull
draft-ietf-trill-channel-tunnel-05 - secure tunnel for directory push
draft-ietf-trill-ia-appsubtlv-05 - reporting of addresses for TRILL interfaces
    in ISIS application sub-TLV (reduces/replaces need for ARP/ND )
draft-ietf-trill-arp-optimization - mechanism to optimize ARP and ND traffic
    on TRILL campus

b) Have a significant number of vendors indicated their plan to
  implement the specification?
 
  Directory service mechanism are currently implemented as proprietary
  fashions by every vendor that does some variant of TRILL (cisco, brocade, Huawei
  and others).  Until we get a full standard solution approved, the
  existing vendors with "early TRILL" implementations have little reason
  to switch.

  Huawei is planning implementations. Potentially Brocade and Cisco
  could switch to these mechanisms, but unless IETF standards are out
  as a set - this may not occur. 

Shepherd review:
https://mailarchive.ietf.org/arch/msg/trill/SVmP0QNwY3UaVhbjkweULl1ZxLE
Revision -01
https://mailarchive.ietf.org/arch/msg/i-d-announce/2hbdxmCfRW34_AgGaBC0mGGJMF8
(note: no change to RFC2119 text, Shepherd is checking on the right RFC2199 text).
 
Routing QA review: Eric Gray
http://www.ietf.org/mail-archive/web/rtg-dir/current/msg02606.html

WG LC:

Personnel
AD: Alia Atlas
WG chairs: Susan Hares and Jon Hudson
Document Shepherd: Susan Hares
Routing QA Review: No

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

1) review of text and concepts
https://mailarchive.ietf.org/arch/msg/trill/SVmP0QNwY3UaVhbjkweULl1ZxLE

2) Routing QA Reviewer: Eric Gray: Minor concerns
http://www.ietf.org/mail-archive/web/rtg-dir/current/msg02606.html

3) WG LC comments - TBD

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.  - TBD additional comments.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Internet Directorate should review for ARP/ND.  Ralph Droms knows these concepts.
OPS/NM Directorate and SEC-DIR should review.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns.
After 3 years of work on Directory solution, this has been discussed at
length and throughly in WG. 

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yizhou LI
https://www.ietf.org/mail-archive/web/trill/current/msg07194.html

Radia Perlman
https://www.ietf.org/mail-archive/web/trill/current/msg07202.html

Linda Dunbar
https://www.ietf.org/mail-archive/web/trill/current/msg07203.html

Donald Eastlake
https://www.ietf.org/mail-archive/web/trill/current/msg07193.html
(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR Disclosures

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Based on 3 years of work on directory service and lots of discussion,
the consensus is strong with all parties agreeing on the solution set.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

no.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

NITS - TBD on last draft

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review for any criteria.

(13) Have all references within this document been identified as
either normative or informative?

yes  - RFC7357 - will be added by authors (version -05.txt)

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
none

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
No 

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No - this is new work.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

No IANA Actions

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

None needed.