Telechat Review of draft-ietf-isis-prefix-attributes-01
review-ietf-isis-prefix-attributes-01-opsdir-telechat-pignataro-2015-12-22-00

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