Hi, 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. This document is on the Standards Track, and specifies support for advertisement of prefix attribute flags and the source router ID originator, for IS-IS. Summary: Ready with issues Major: None. Minor: General: This document contains as pre-RFC5378 disclaimer, but was submitted after Nov 2008, and does not indicate it contains any pre-5378 text verbatim (from an update, obsolete, etc.) I think it is problematic to have this text not granting rights to the IETF Trust, when really it is not the case. Or alternatively, there is text imported into this draft, in which case it would be beneficial to indicate it explicitly, as it is not self-evident or obvious. 1. Introduction There are existing use cases in which knowing additional attributes of a prefix is useful. It is useful to know that there are cases for which these extensions are useful. However, it is more useful to know what those are :-) If, as it follows, the use case is [SR]. then that likely makes a Normative (not Informational) reference. It is useful to know whether an advertised prefix is directly connected to the advertising router or not. In the case of [SR] … 6.2. Informational References [SR] "IS-IS Extensions for Segment Routing, draft-ietf-isis- segment-routing-extensions-05 (work in progress)", June 2015. In other words, if this is a direct solution for SR, then the SR ISIS extensions are likely Normative. 2.1. IPv4/IPv6 Extended Reachability Attribute Flags Undefined bits SHOULD be transmitted as 0 and MUST be ignored on receipt. In which case it might not be transmitted as zero? In other words, should this be MUST instead of SHOULD? Bits which are NOT transmitted MUST be treated as if they are set to 0 on receipt. This is an interesting sentence. I think, as an editorial, that the “NOT” ought to be “not”. But more importantly, how does the receiver know that there are more bits not transmitted? And extrapolating the concept, how do different routers know how many bits each implementation know about? This seems like an important point for interop. 4. Security Considerations This section does not discuss privacy considerations as related to making available identification about the source node that was previously unknown. Should it at least mention it, or not? Nits: 3. IANA Considerations This document also introduces a new registry for bit values in the Prefix Attribute Flags sub-TLV. Registration policy is Expert Review as defined in [RFC5226]. Defined values are: Bit # Name ----- ------------------------ 0 External Prefix Flag 1 Re-advertisement Flag 2 Node Flag Could you specify for IANA that these are in the "IS-IS TLV Codepoints” registry? 5. Acknowledgements TBD At these point in the lifecycle of the document, Acknowledgements should likely have been determined already. I hope these comments are useful. Thanks, -- Carlos. Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail