Advertising L2 Bundle Member Link Attributes in IS-IS
draft-ietf-isis-l2bundles-07

Note: This ballot was opened for revision 05 and is now closed.

Alia Atlas Yes

Deborah Brungard No Objection

Ben Campbell No Objection

Comment (2017-05-24 for -05)
I support the various DISCUSS points concerning the security considerations.

I note that the remaining authors have made their IPR statements, so that discussion is moot.

I share some of the discomfort concerning the shepherd report. I'm willing to accept that the shepherd is in the rough, but it would be nice to have stronger evidence of that, perhaps in the form of an opinion from the other chair. To quote a wise area director: I leave it to the responsible AD to do the right thing, whatever that might be.

Benoit Claise No Objection

Comment (2017-05-24 for -05)
1. "IPR declarations from Clarence Filsfils and Ebben Aries are missing.". Adam is right. That's a showstopper.

2. Reading the write-up:

    (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.

    An operational review on the question how should management of L3 bundles
    be handled would be a good recommendation. 

This is exactly what Mahesh's OPS DIR feedback is about: https://datatracker.ietf.org/doc/review-ietf-isis-l2bundles-04-opsdir-telechat-jethanandani-2017-04-20/
I've seen Les' answers. I believe those should be documented in the draft.

Alissa Cooper No Objection

Comment (2017-05-24 for -05)
(1) I support Adam and Ekr's DISCUSSes about the security considerations.

(2) I also agree that this document should not go forward until Clarence confirms that all appropriate IPR disclosures have been filed.

(3) Given the point raised by the shepherd about protocol-agnosticism, it seems like the existence of single mail (all I could find, but maybe there is more?) from another WG participant who works for the same vendor as several of the authors saying that he believes the encodings are adaptable to OSPF is not quite sufficient justification for putting the shepherd's concerns aside. OTOH, perhaps there is more context that is not present in the ballot text, list archives, and minutes I reviewed, so just flagging this in case there is further explanation that could be provided to the IESG (don't think this would imply changes to the draft).

Suresh Krishnan No Objection

Comment (2017-05-23 for -05)
* I would like to suggest rewriting the examples with IPv4 addresses from the documentation block(s) defined in RFC5737 instead of using random IP addresses.

* It would have been nice to include an example with IPv6 addresses. 

* Appendix A: The length value for "L2 Bundle Attribute Descriptors" under "TLV for Adjacency #2" is wrong. It says 29 but it needs to be 32

* I would like to see Adam's DISCUSS points addressed as well.

Terry Manderson No Objection

Comment (2017-05-24 for -06)
I'm in agreement with the current DISCUSSes raised. (watching carefully)

Kathleen Moriarty (was Discuss) No Objection

Comment (2017-05-25)
Thanks for the updated security considerations section text.

Eric Rescorla (was Discuss) No Objection

Alvaro Retana No Objection

Comment (2017-05-24 for -05)
The main motivation (from the Introduction) for this extension seems to be to provide information to "entities external to IS-IS such as Path Computation Elements".  I would like to see some discussion related to the "interface" with these external entities.  [Note: I am not asking for a comparison with other potential solutions like BGP-LS.]  I would also like to see the conversation with the OPS DIR reviewer reflected in the document.

I also support the DISCUSS points about the Security Considerations.

About other potential or protocol agnostic solutions...  I read the related discussion [1] that took place before the WG adoption of the document, and trust that the subsequent adoption and WGLC reflect the consensus of the WG.  As has been put in evidence by the development of multiple routing protocols and other solutions, one size doesn't always fit all.

[1] https://mailarchive.ietf.org/arch/msg/isis-wg/cK6dBtjvFZgNnZsQGZBgrpGG8jc/?qid=0a77495659ebc27956fe54d200bf3f33

Adam Roach (was Discuss) No Objection

Mirja K├╝hlewind Abstain

Comment (2017-05-23 for -05)
The shepherd raises multiple concerns about this document including the need for additional discussions in rtgwg, more operator feedback, technical concerns, and no discussion about the filed IPR. Further, the security considerations section only says 'None' which also seems not appropriate. I didn't follow the working group, nor am I an expert on this work, therefore I abstain. However, for me this document does not seems to fulfill the needed processing requirements to be published but I'll leave the judgement to the responsible AD.