OPSDIR Last Call Review of draft-ietf-lsr-ospf-prefix-extended-flags-13

Reviewer: Tony Li
Status: Not ready

Overall: This document is missing enough discussion to make it readily
accessible. The content seems to be an accretion of small changes, not
all of which are adequately motivated.

Details:

Please note that this document is well outside of my comfort
zone. While I have some familiarity with iCalendar as a user of it, I
have a limited background in the internals.

The title is a bit confusing as it is unclear whether 'upgrades'
refers to protocol changes or content changes.  I would suggest using
the word 'enhancements' or 'extensions' instead.

I found that the abstract is not at all helpful.  It does not reflect
the content of the document. The abstract should summarize all of the
contents, starting with a succinct problem statement.

The introduction does a better job at presenting a problem statement.
Note that it seems to have no relationship to what's in the abstract.
While I think I understand the problem, I don't understand how the
proposed solution addresses the problem.  If you want an efficient way
to determine if there is an update, then it is wholly unclear why you
need a different access mechanism.  It seems to me like the Sync-Token
is both necessary and sufficient to address this issue.

The remainder of the mechanisms in the document seem to lack clear
motivation.

Section 2:
I don't understand why this is helpful, but in general it seems fine
until I get to the statement:

      Note that the target for an upgraded service may be the same as
      for the initial resource.

You can provide a pointer back to the same thing? This seems extremely
inefficient.  Is there some benefit to this?

Section 3:
I find this confusing because we seem to be interleaving introductory
text with incomplete normative specification. What is the "Enhanced
GET" protocol? It seems like it is just a GET with a
"subscribe-enhanced-get" preference. If this is the start of this
extension, you should say that.  As stated, this seems like normative
text for providing an additional attribute.

Returning a Conflict without some explanation is not operationally
appropriate.  This is the old Unix trope of responding with '?'  to
any error.  Please make error messages mandatory.

Section 3.2:
I understand the intent here, I disagree with the wording.  As
written, a DELETE is provided on "the first" GET.  I don't think
that's what you mean.  If you repeat the exact same GET does the
DELETE disappear?

I think you want the DELETE to be idempotent.  That means that if the
entity was deleted between two sync points, then the DELETE will be
returned for any GET across those sync points.

I would also suggest applying Postel's Law here and requiring that
only minimal information.  Does a DTSTAMP really affect a DELETE?  It
seems to me that as long as you have uniquely identified what is to be
deleted, that is both necessary and sufficient. Anything else is
inefficient and providing another opportunity to break
interoperability.

Section 3.3:
This section repurposes the sync token and makes the semantics of the
token very confusing. Is the sync token an indication of where we are
in the subscription timeline? Or is it an indication of where we are
in paging?

I strongly suggest that these two semantics be separated. I suggest a
separate 'paging token'.

If the server decides to page the response even if no limit was
specified, there needs to be a clear indication that this is
happening.

Section 3.5:
Please add examples to demonstrate paging.

Section 4:
Please mention that this is an update to section 3.8.1.11.  Is the
only change to add DELETED in three places?  If so, please say so.

Section 5:
Please motivate the use of a URI here over an opaque string.

Section 6.2:
What is BWS? Please define or provide a reference. RFC 7230 section
3.2.3?

Section 7:
Please provide references to the base specification that you're
updating.

Section 7.2:
Please add a reference.

Plea:
Please fix calendar interoperability in the field.