Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-bess-ir-04

From: Paul Kyzivat <[email-masked]>
Date: Tue, 9 Aug 2016 16:41:41 -0400

I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please treat these comments just like any other 
last call comments. For more information, please see the FAQ at 
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-bess-ir-04
Reviewer: Paul Kyzivat
Review Date: 2016-08-09
IETF LC End Date: 2016-08-10
IESG Telechat date: 2016-08-18

Summary:

Unfortunately, I don't have the expertise to review this draft.

(Of the review summaries available to me, the one I want to use is "This 
draft has serious issues, described in the review, and needs to be 
rethought." But I don't think I am in a position to make such a 
judgement given my lack of knowledge of the subject domain.)

Issues:

Major: 0
Minor: 2
Nits:  0

(1) MINOR:

Section 5 begins:

    As previously specified, when the "Tunnel Type" field of a PTA is set
    to "IR", the "Tunnel Identifier" field of that PTA does not contain
    the IR P-tunnel identifier.  This section specifies the procedures
    for setting the "Tunnel Identifier" field of the PTA when the "Tunnel
    Type" field of the PTA is set to "IR".

I have trouble parsing this so it makes sense. The problem is with "As 
previously specified". Normally when I see something like this I expect 
it to mean "previously within this document". I think in this case it 
means in RFCs 6513 and/or 6514. I think this ought to be clearer. E.g.,

    As specified in [RFC6513], ...

(2) MINOR (?!?):

Lacking any knowledge of the subject matter of this draft, I found it 
impossible to review in a meaningful way. But I tried!

I came to the tentative conclusion that this document is struggling to 
document an extremely complex system. In such a situation publishing the 
sort of documentation provided here is probably better than not doing 
so. But I fear it isn't sufficient - that it will be unlikely that a new 
implementer, schooled in the subject matter, will be able to create a 
correct implementation. The problem is with the system/algorithms, not 
with the document.

(NOTE: I've made this minor rather than major because I don't consider 
myself competent to say this is a real problem or if it is one that this 
draft should be expected to fix.)

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 15 Aug 2016 14:50:41 -0400

Thanks for your review.

On 8/9/2016 4:41 PM, Paul Kyzivat wrote:
> it will be unlikely that a new implementer, schooled in the subject 
> matter, will be able to create a correct implementation.

The material in this draft describes running code.   There are at least 
two independent, interoperable implementations.  The draft was written 
after the implementations were done, and is a faithful description of 
what was implemented.

While doing the implementation, it was discovered that the Ingress 
Replication feature of RFCs 6513/6514 was under-specified in some 
respects and unclearly specified in others.  The purpose of this draft 
is to document the procedures that had to be figured out during this 
implementation effort.

I can assure you that this draft makes it a lot easier to implement this 
feature!

Of course, Ingress Replication is just part of a larger and more complex 
system.  The draft shows how IR fits into the larger system, but the 
overall system remains complex.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Aug 2016 15:14:21 -0400

> I can assure you that this draft makes it a lot easier to implement this

Ah. Well, since it was written after the fact, by people who had 
implemented without it, that doesn't constitute an existence proof that 
a new independent implementation will be interoperable with the others. 
(Before tweaking based on interop testing.)

But I do agree that the situation should be better *with* this document 
than without it.

> overall system remains complex.

Yeah. I am really glad that *you* are implementing it, and not *me*. :-)

I now have a greater appreciation for why internet-wide multicast is 
generally thought not to work!

	Thanks,
	Paul

---

From: Jari Arkko <[email-masked]>
Date: Wed, 17 Aug 2016 22:10:53 +0200

Folks,

I don’t know what to do with this draft.

I’ve read the draft, prompted by Paul’s review. While I can understand most of what it says, I have to say it is a very difficult read. Probably due to the large complex system that it is a part of. But, I’ve been thoroughly unable to convince myself for instance that the draft covers all cases in the functionality that it describes.

I will check with my AD colleagues on how they perceived the document, and if they have any guidance on this matter. Stay tuned.

Jari