[Ballot comment]
Former DISCUSS text for the record:

I agree with Adrian's concern to the point where I am raising this to a DISCUSS.  The document currently contains an appendix that describes the differences between this document and 6327 but not a section that describes what is being updated from 6325.  In response to Adrian's comment, the authors said that it is possible they created a conflict and just wanted to force readers of 6325 to read 6327bis.  *If* 6327bis is updating 6325, it should clearly spell out how it relates to 6325.  Adding a section similar to the appendix describing the changes from 6327 should suffice.  Another outcome would be that the authors discover that there is not an Updates relationship and the meta-tag is dropped.

[Ballot discuss]
I agree with Adrian's concern to the point where I am raising this to a DISCUSS.  The document currently contains an appendix that describes the differences between this document and 6327 but not a section that describes what is being updated from 6325.  In response to Adrian's comment, the authors said that it is possible they created a conflict and just wanted to force readers of 6325 to read 6327bis.  *If* 6327bis is updating 6325, it should clearly spell out how it relates to 6325.  Adding a section similar to the appendix describing the changes from 6327 should suffice.  Another outcome would be that the authors discover that there is not an Updates relationship and the meta-tag is dropped.

[Ballot comment]
I agree with Adrian's concern and am wondering why there is an appendix that describes the differences between this document and 6327 but not a section that describes what is being updated from 6325.  Such a section would clearly identify what an implementer of 6325 would have to look at when supporting this draft and provide a level of assurance that any conflicts between the two documents were created consciously.

[Ballot comment]
I couldn't find a clear statement of what parts of RFC 6325 are being
updated. Is the intention of the "updates" metadata and the text that
says:
  In case of conflict between this document and [RFC6325], this
  document prevails.
...just in case this document creates a conflict with 6325?
I would prefer that "updates" was used to reflect a deliberate and
conscious change, and that such a change was called out.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-trill-rfc6327bis-02, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion. IANA requests that the IANA Considerations section of the document remain in place upon publication.

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

The following Last Call announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <trill@ietf.org>
Reply-To: ietf@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-trill-rfc6327bis-02.txt> (TRILL: Adjacency) 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: Adjacency'
  <draft-ietf-trill-rfc6327bis-02.txt> 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 2013-12-23. 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


  The IETF TRILL (TRansparent Interconnection of Lots of Links)
  protocol supports arbitrary link technologies between TRILL switches
  including point-to-point links and multi-access LAN (Local Area
  Network) links that can have multiple TRILL switches and end stations
  attached. TRILL uses IS-IS (Intermediate System to Intermediate
  System) routing. This document specifies the establishment,
  reporting, and termination of IS-IS adjacency between TRILL switches,
  also known as RBridges. It also concerns four other link-local
  aspects of TRILL: Designated RBridge (DRB) selection, MTU (Maximum
  Transmission Unit) testing, pseudonode creation, and BFD (Bi-
  Directional Forwarding Detection) session bootstrapping in connection
  with adjacency. State diagrams are included where appropriate.  This
  document obsoletes RFC 6327 and updates RFC 6325.






The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-trill-rfc6327bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-trill-rfc6327bis/ballot/


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