[GROW] Barry Leiba's No Objection on draft-ietf-grow-irr-routing-policy-considerations-05: (with COMMENT)

["Barry Leiba" <[e-mail]>]

Barry Leiba has entered the following ballot position for
draft-ietf-grow-irr-routing-policy-considerations-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-grow-irr-routing-policy-considerations/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I find some of the writing throughout the document to be a bit hard to
get through -- not to the extent that I think it's a serious problem, but
enough so that I'd say this is making the reader work a bit too hard. 
Some examples:

   While these resources
   are generally allocated by hierarchical authorities, a general
   mechanism for formally verifying (such as through cryptographic
   mechanisms) when parties have been allocated resource remains an open
   challenge.  We generally define such a system a Resource
   Certification System, and we note that some candidate examples of how
   such a general system might be implemented and deployed exist[.]

The structure of both of these sentences makes understanding them require
a bit of rewinding and re-parsing, at least for me.  Phrases such as
"have been allocated resource" seem odd ("allocated resources" or
"allocated a resource" would seem better).  Phrases such as "some
examples exist" are straightforward, but get harder when a long modifying
phrase is stuck in before "exist", as here.  This is an example; there
are other such bits in the document.

In the end, it's probably fine, though I think it'd be a good idea to
alert the RFC Editor to watch for complicated sentences whose structure
makes then a bit difficult to read smoothly.  Below I suggest a few
specific sentences that I hope the authors will re-do themselves, before
it goes to the RFC Editor.

-- Section 4.1 --

   One of the largest weaknesses often cited with the IRR system is that
   the data contained within the IRRs is out of date or lacks integrity.
   This is largely attributable to the fact that existing IRR mechanisms
   do not provide ways for a relying party to (cryptographically) verify
   the validity of an IRR object.  That is, there has never existed a
   resource certification infrastructure that enables a resource holder
   to authorize a particular autonomous system to originate network
   layer reachability advertisements for a given IPv4 or IPv6 prefix.

Two questions here:

1. The last sentence is written as a clarification of the one before it
("that is..."), but seems to veer.  Would it perhaps be better to say,
"...that enables a resource holder to verifiably authorize...", or,
"...that enables a resource holder to provide verifiable authorization
that a particular autonomous system may originate..." ?

2. This clearly explains the "lacks integrity" piece, but adding
cryptographic verifiability will not fix out-of-date information, will
it?  Isn't there also an issue of keeping the information current in the
first place, which is not mentioned here?

-- Section 4.5 --

   Only now is an
   experimental test bed that reports to provide this function

I think "purports" is the word you're looking for here.

-- Section 5.2 --

   An ISP's customers may not adequately plan for pre-planned
   maintenance or, more likely, need to rapidly begin announcing a new
   IP prefix as a result of, for example, an emergency turn-up of the
   ISP customer's new downstream customer.

I'm having trouble making sense of this sentence.  The subject seems to
change throughout the sentence, starting as "an ISP's customers", and
shifting to the ISP later.  Can you please re-word this, perhaps
splitting it into two sentences?  (It'd also be nice if you'd use "might"
to refer to something that might happen, and save "may" for referring to
something that's *allowed* to happen.)

   It is likely that the length of time at which IRRs mirror
   changes will have to be dramatically reduced with a corresponding
   reduction in time at the ISPs that, in turn, need to evaluate whether
   changes in a set of IRR resources need to get reflected in updated
   router policies that will get pushed out to ASBR's, connected to
   peering circuits, on their network.

I get this one, in the end, but it's also in need of splitting into two,
please.

-- Section 6 --

   Ultimately, either of the two scenarios above further lengthen the
   effective time it would take for changes in IRR resources to take
   affect within BGP in the network.

That should be "take effect", not "take affect".  And I think the
combination of "effective time" and "take effect" can be confusing, so
maybe try some rewording?