Subject: Re: [i2rs] [RTG-DIR] Routing directorate review of draft-ietf-i2rs-problem-statement

From: Alia Atlas <[email-masked]>
Date: Tue, 6 Jan 2015 17:28:43 -0500

Hi Eric,

Thanks for your review.  I really appreciate it.

On Tue, Dec 16, 2014 at 8:33 PM, Eric Gray <[email-masked]> wrote:

> Hello,
>
> I have been selected as the Routing Directorate reviewer for this draft.
>
> The Routing Directorate seeks to review all routing or routing-related
> drafts as they pass through IETF last call and IESG review, and sometimes
> on special request.
>
> The purpose of the review is to provide assistance to the Routing ADs.
>
> For more information about the Routing Directorate, please see:
>
>         ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing ADs, it
> would be helpful if you could consider them along with any other IETF
> Last Call comments that you receive, and strive to resolve them through
> discussion or by updating the draft.
>
> Document: draft-ietf-i2rs-problem-statement
> Reviewer: Eric Gray
> Review Date: 12/16/2014
> Intended Status: Informational
>
> Summary: I have some minor concerns about this document that I think
> should be resolved before before publication.  The document has nits
> that should also be considered prior to publication.
>
> Minor Issues:
> ==========
>
> Section 5 title is "Desired Aspects of ..." but the first sentence talks
> about
> "required aspects ..."  I believe that the authors should be consistent.

Keeping required

> The actual "key aspects needed" are a mixture or required and desired
> behaviors.  Because the draft does not refer to RFC 2119 terminology,
> it is not clear if this is intended or a result of narrative style choices.
>

I'm not sure which ones you are reading as desired vs. required.  The intent
is that all are required; trade-offs do happen.

> If the terminology is meant to be interpreted according to RFC 2119,
> then this should be added as a reference.  Otherwise, perhaps the title
> of the section should be changed to:
>
>   "Aspects to be Considered in Designing Protocol for I2RS"
>

Yes, slightly tweaked to
"Aspects to be Considered for an I2RS Protocol"
since I2RS is expecting to modify an existing protocol rather than design
a new one.

> In this section, in addition to "Secure Control" we may want to suggest
> similar "Secure Access."  Information about routing may be useful to an
> attacker for other forms of attack than direct control.
>

 True - just updated the bullet to be "Secure Control and Access".
The content now reads:

"   Any ability to manipulate routing state must be subject to
authentication and
      authorization.  Sensitive routing information may also need to
      be provided via secure access back to the I2RS client.  Such
      communications must be integrity protected.  Some communications
      will also require confidentiality.
"

> Section 8 ("Security Considerations") - Minimally, this section should
> point to security aspects mentioned in the preceding section.
>

Done and extended

> Note that this section mentions "extraction of detailed router state"
> which is one form of access that may both require that requests
> are authenticated and that information may not be intercepted.
>
> NITS:
> ====
>
> In the Introduction, second line of the first paragraph, "With scale ..."
> should start a new paragraph to be consistent with the next paragraph.
>

eh, not worried about the consistency given it would leave the first
paragraph
with one sentence.

In the appendix the first paragraph should probably end in much the
> same way as the second paragraph, i.e. -
>
>    "CLI Standardization is not considered as a candidate solution for the
>      I2RS."
>
> It is not clear what we are trying to say in saying "I2RS does not involve
> CLI Standardization."
>

Sure - changed.

Thanks again,
Alia

---

From: Eric Gray <[email-masked]>
Date: Wed, 7 Jan 2015 16:13:51 +0000

Alia,

                Hope everyone enjoyed the holidays.

                Responses in-line below…

From: Alia Atlas [mailto:[email-masked]]
Sent: Tuesday, January 06, 2015 5:29 PM
To: Eric Gray
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [RTG-DIR] Routing directorate review of draft-ietf-i2rs-problem-statement
Importance: High

Hi Eric,

Thanks for your review.  I really appreciate it.
On Tue, Dec 16, 2014 at 8:33 PM, Eric Gray <[email-masked]<mailto:[email-masked]>> wrote:
Hello,

Minor Issues:
==========

Section 5 title is "Desired Aspects of ..." but the first sentence talks about
"required aspects ..."  I believe that the authors should be consistent.

Keeping required

Changing the section title helps.  The issues that remain are less significant
when considered as “aspects to be considered.”

I wanted to avoid being pedantic, but one example (now more minor) is as
follows:

-          1st paragraph uses the phrase “describes required aspects”

-          the 1st list item (multiple simultaneous asynchronous operations),

however, says that a single application should be able to …

Without the reference to RFC 2119, “should” may be ambiguously interpreted
according to standard English as something likely but not required.

I think what was probably meant in this case is that protocol is required to
support applications that perform multiple concurrent operations (which is
something we believe applications should be able to do).

The current text is not explicit about this as a protocol requirement, if that is
what is intended, instead making the protocol requirement implicit based on
the way that we believe applications would likely use it.

There are similar issues with “High Throughput”, “Low Latency” and “Multi-
Channel.”

One advantage of referring to RFC 2119 is it makes “should” less ambiguous,
and defines this term (and other terms) as “requirement levels.”

But I am okay with leaving this as is, because of the heading change.  Most
people will be able to figure out what is meant, eventually.  ☺

Yes, slightly tweaked to

D’accord.

"   Any ability to manipulate routing state must be subject to authentication and
D’accord.

Done and extended

D’accord.

NITS:
====

eh, not worried about the consistency given it would leave the first paragraph
with one sentence.

Single-sentence paragraphs are quite common.

See, for instance the earlier paragraph in the latest draft that reads “This draft
will expire on July 10, 2015.”

Again, I was trying to avoid pedanticism.  Sigh.

More important in either prose or specification is that a paragraph represents a
single block/concept in whatever it is you are trying to construct.

Even in prose, if you have an opening sentence that introduces two things you
want to talk about, then either both of them or neither of them should be in
the same paragraph.  For prose, this is mostly about flow.

In specification, it is slightly more important.  A reader who is skimming the
introductory text before plowing into the salient parts of the specification is
likely to actually miss the point you’re making about scale because it’s buried
in the paragraph that introduces issues with both scale and complexity.

If scale were  important, it probably would be in a separate paragraph.

Of course, you could (in prose anyway) do this deliberately as a way to place
greater emphasis on the second point, sort of along the following lines:

“There are two major kinds of ideas that we can expect to encounter in our
discussions: good ideas and bad ideas.  Bad ideas are obviously something
we want to quickly dispense with.

“Good ideas, on the other hand, should be …”

In my opinion, use of this sort of literary device in a specification would be just
a bit inappropriate.  If the text is not worth emphasis, leave it out.

Sure - changed.

Thanks again,
Alia

---

From: Alia Atlas <[email-masked]>
Date: Wed, 7 Jan 2015 20:55:06 +0000

Hi Eric,

Responses in-line below (but with agreements removed).
I’ll push out the slightly modified version as soon as I hear back from you.

Thanks again,
Alia

From: Eric Gray [mailto:[email-masked]]
Sent: Wednesday, January 07, 2015 11:14 AM
To: Alia Atlas
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [RTG-DIR] Routing directorate review of draft-ietf-i2rs-problem-statement

Alia,

                Responses in-line below…

From: Alia Atlas [mailto:[email-masked]]
Sent: Tuesday, January 06, 2015 5:29 PM
To: Eric Gray
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [RTG-DIR] Routing directorate review of draft-ietf-i2rs-problem-statement
Importance: High

Hi Eric,

Minor Issues:
==========

Keeping required

I am well used to pendatry ;-)

I think so also.   This is describing what the solution should look like – not giving the
detailed protocol requirements.

NITS:
====

I do think it is worth the emphasis and agree that there is almost parallelism in
the text deliberately.    I just didn’t feel it was necessary, but if you feel strongly
enough to write many paragraphs about it, I’ll change it.

---

From: Eric Gray <[email-masked]>
Date: Wed, 7 Jan 2015 21:09:47 +0000

Alia,

                I’m happy with not changing the text further in section 5 and I would
appreciate it if you make the minor change to the introduction.

                So it looks like we have converged…

--
Eric

From: Alia Atlas [mailto:[email-masked]]
Sent: Wednesday, January 07, 2015 3:55 PM
To: Eric Gray; Alia Atlas
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [RTG-DIR] Routing directorate review of draft-ietf-i2rs-problem-statement
Importance: High

Hi Eric,

Thanks again,
Alia

Alia,

                Responses in-line below…

Hi Eric,

Minor Issues:
==========

Keeping required

NITS:
====

---

From: Alia Atlas <[email-masked]>
Date: Wed, 7 Jan 2015 16:13:55 -0500

Eric,

Ok.  Done and posted as version -06.

Thanks,
Alia

On Wed, Jan 7, 2015 at 4:09 PM, Eric Gray <[email-masked]> wrote:

> *From:* Alia Atlas [mailto:[email-masked]]
> *Sent:* Wednesday, January 07, 2015 3:55 PM
> *To:* Eric Gray; Alia Atlas
> *Cc:* [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> *Subject:* RE: [RTG-DIR] Routing directorate review of
> draft-ietf-i2rs-problem-statement
> *Importance:* High
>
>
>
> Hi Eric,
>
>
>
> *From:* Eric Gray [mailto:[email-masked] <[email-masked]>]
>
> *Sent:* Wednesday, January 07, 2015 11:14 AM
> *To:* Alia Atlas
> *Cc:* [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> *Subject:* RE: [RTG-DIR] Routing directorate review of
> draft-ietf-i2rs-problem-statement
>
>
>
> Alia,
>
>
>
>                 Responses in-line *below*…
>
>
>
> *From:* Alia Atlas [mailto:[email-masked] <[email-masked]>]
> *Sent:* Tuesday, January 06, 2015 5:29 PM
> *To:* Eric Gray
> *Cc:* [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> *Subject:* Re: [RTG-DIR] Routing directorate review of
> draft-ietf-i2rs-problem-statement
> *Importance:* High
>
>
>
> Hi Eric,
>
>
>
> *Changing the section title helps.  The issues that remain are less
> significant*
>
> *when considered as “aspects to be considered.”*
>
>
>
> *I wanted to avoid being pedantic, but one example (now more minor) is as*
>
> *follows:*
>
> -          *1st paragraph uses the phrase “describes required aspects”*
>
> -          *the 1st list item (multiple simultaneous asynchronous
> operations),*
>
> *however, says that a single application should be able to …*
>
>
>
> *Without the reference to RFC 2119, “should” may be ambiguously
> interpreted*
>
> *according to standard English as something likely but not required.*
>
>
>
> *I think what was probably meant in this case is that protocol is required
> to*
>
> *support applications that perform multiple concurrent operations (which
> is*
>
> *something we believe applications should be able to do).*
>
>
>
> *The current text is not explicit about this as a protocol requirement, if
> that is *
>
> *what is intended, instead making the protocol requirement implicit based
> on *
>
> *the way that we believe applications would likely use it.*
>
>
>
> *There are similar issues with “High Throughput”, “Low Latency” and
> “Multi-*
>
> *Channel.”*
>
>
>
> *One advantage of referring to RFC 2119 is it makes “should” less
> ambiguous,*
>
> *and defines this term (and other terms) as “requirement levels.”*
>
>
>
> *But I am okay with leaving this as is, because of the heading change.
> Most*
>
> *people will be able to figure out what is meant, eventually.  **J*
>
>
>
> *Single-sentence paragraphs are quite common.*
>
>
>
> *See, for instance the earlier paragraph in the latest draft that reads
> “This draft *
>
> *will expire on July 10, 2015.”*
>
>
>
> *Again, I was trying to avoid pedanticism.  Sigh.*
>
>
>
> *More important in either prose or specification is that a paragraph
> represents a*
>
> *single block/concept in whatever it is you are trying to construct.*
>
>
>
> *Even in prose, if you have an opening sentence that introduces two things
> you*
>
> *want to talk about, then either both of them or neither of them should be
> in*
>
> *the same paragraph.  For prose, this is mostly about flow.*
>
>
>
> *In specification, it is slightly more important.  A reader who is
> skimming the *
>
> *introductory text before plowing into the salient parts of the
> specification is*
>
> *likely to actually miss the point you’re making about scale because it’s
> buried*
>
> *in the paragraph that introduces issues with both scale and complexity.*
>
>
>
> *If scale were  important, it probably would be in a separate paragraph.*
>
>
>
> *Of course, you could (in prose anyway) do this deliberately as a way to
> place*
>
> *greater emphasis on the second point, sort of along the following lines:*
>
>
>
> *“There are two major kinds of ideas that we can expect to encounter in
> our*
>
> *discussions: good ideas and bad ideas.  Bad ideas are obviously something*
>
> *we want to quickly dispense with.*
>
>
>
> *“Good ideas, on the other hand, should be …”*
>
>
>
> *In my opinion, use of this sort of literary device in a specification
> would be just*
>
> *a bit inappropriate.  If the text is not worth emphasis, leave it out.*
>
>
>