Subject: Gen-ART review of draft-ietf-behave-lsn-requirements-07

From: Alexey Melnikov <[email-masked]>
Date: Tue, 03 Jul 2012 13:24:28 +0100

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments 
you may receive.

Document: draft-ietf-behave-lsn-requirements-07
Reviewer: Alexey Melnikov
Review Date: 3-July-2012
IETF LC End Date: 10-July-2012
IESG Telechat date: Pending

Summary: The document is ready for publication as a BCP.

Major Issues: None

Minor Issues: None

Nits/editorial comments:

I found it is to be odd to have a requirements document as a BCP, but I 
am sure
you can sort the right status out with IESG.

I found the justification for REQ-6 hard to read/understand. Why does 
access to
servers being on the internal network need to go through CGN at all?

REQ-10:

Justification:  It is anticipated that CGNs will be primarily
       deployed in ISP networks where the need for management is
       critical.  This requirement is at the SHOULD level to acocunt for

typo: account

       the fact that some CGN operators may not need management
       functionality.

Oh really :-)? (Sorry, couldn't resist.)

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 3 Jul 2012 12:51:21 +0000

On Jul 3, 2012, at 14:24, Alexey Melnikov wrote:
> I found it is to be odd to have a requirements document as a BCP, but I am sure

+1

I fail to see why Informational wouldn't be the better status.

Lars

---

From: Simon Perreault <[email-masked]>
Date: Sat, 07 Jul 2012 12:44:55 -0700

> I fail to see why Informational wouldn't be the better status.

I don't care much about the status and will defer to the IESG, but I 
thought Informational didn't mix well with 2119 language...

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Simon Perreault <[email-masked]>
Date: Tue, 10 Jul 2012 13:50:42 -0400

> servers being on the internal network need to go through CGN at all?

Here's the thing: the server is not on the internal network. It's on the 
external network, but it is still managed by the ISP. The ISP's network 
includes the internal network and some part of the external network. 
Furthermore, in many cases an ISP may run multiple CGNs, so the ISP's 
network is actually multiple internal networks and some part of the 
external network. The servers in the external network are operated by 
the ISP and "know" the internal networks (have routes to them), and can 
reach them directly without translation. And since connections from 
subscribers to those servers may account for a lot of traffic, it is 
important to not spend NAT resources on them.

Now, I'm not sure how to alter the existing text to make it easier to 
understand. It seems to me that all the information is there, just not 
with the same order/emphasis as what I wrote above. If the above was 
useful for you to understand, could you please point out in the text 
below what change would have helped you understand?

    REQ-6:  It MUST be possible to administratively turn off translation
            for specific destination addresses and/or ports.

    Justification:  It is common for a CGN administrator to provide
       access for subscribers to servers installed in the ISP's network,
       in the external realm.  When such a server is able to reach the
       internal realm via normal routing (which is entirely controlled by
       the ISP), translation is unneeded.  In that case, the CGN may
       forward packets without modification, thus acting like a plain
       router.  This may represent an important efficiency gain.

       Figure 2 illustrates this use-case.

                  X1:x1            X1':x1'            X2:x2
                  +---+from X1:x1  +---+from X1:x1    +---+
                  | C |  to X2:x2  |   |  to X2:x2    | S |
                  | l |>>>>>>>>>>>>| C |>>>>>>>>>>>>>>| e |
                  | i |            | G |              | r |
                  | e |<<<<<<<<<<<<| N |<<<<<<<<<<<<<<| v |
                  | n |from X2:x2  |   |from X2:x2    | e |
                  | t |  to X1:x1  |   |  to X1:x1    | r |
                  +---+            +---+              +---+

                         Figure 2: CGN pass-through

Thanks,
Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 17 Jul 2012 11:08:33 +0100

Hi Simon,

On 10/07/2012 18:50, Simon Perreault wrote:
> Here's the thing: the server is not on the internal network. It's on 
> the external network, but it is still managed by the ISP. The ISP's 
> network includes the internal network and some part of the external 
> network. Furthermore, in many cases an ISP may run multiple CGNs, so 
> the ISP's network is actually multiple internal networks and some part 
> of the external network. The servers in the external network are 
> operated by the ISP and "know" the internal networks (have routes to 
> them), and can reach them directly without translation. And since 
> connections from subscribers to those servers may account for a lot of 
> traffic, it is important to not spend NAT resources on them.
I like this longer explanation. I agree that once I understand what you 
are trying to say the shorter explanation in the document makes sense. 
But it is a bit cryptic. (I don't have specific suggestions, so if you 
can't improve existing text, that is Ok with me.)

---

From: Pete Resnick <[email-masked]>
Date: Tue, 17 Jul 2012 13:57:19 -0500

> I fail to see why Informational wouldn't be the better status.

Publicly reposting what I just put in my IESG ballot, just in case you 
all want to disagree with me publicly. :-)

Perhaps I'm just being contrarian today, but I *do* think this document 
should be BCP and not Informational. It is not a requirements document 
in the sense that it is laying out requirements for future protocol 
documents being developed by a WG; it is a consensus document listing 
the requirements for the operation and administration of a type of 
device. If that doesn't fall within the 2nd paragraph of RFC 2026 
section 5, I don't know what does.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: John C Klensin <[email-masked]>
Date: Tue, 17 Jul 2012 18:14:32 -0400

--On Tuesday, July 17, 2012 13:57 -0500 Pete Resnick
<[email-masked]> wrote:

> Perhaps I'm just being contrarian today, but I *do* think this
> document should be BCP and not Informational. It is not a
> requirements document in the sense that it is laying out
> requirements for future protocol documents being developed by
> a WG; it is a consensus document listing the requirements for
> the operation and administration of a type of device. If that
> doesn't fall within the 2nd paragraph of RFC 2026 section 5, I
> don't know what does.

Just to be disagreeable...

I think "requirements for the operation and administration of a
type of device" puts it squarely into the "Applicability
Statement" range, in part of permit testing of those
requirements and advancement along the standards track.  Of
course, the precedent is RFCs 1122 and 1123 which requirements
for operation and administration as well as for protocol
conformance and are clearly applicability statements (and more
or less the prototype for that category).

    john

---

From: Pete Resnick <[email-masked]>
Date: Tue, 17 Jul 2012 17:51:22 -0500

> or less the prototype for that category).

Just to be somewhat agreeable... ;-)

Normally, I would be right with you and say, "This should be on the 
standards track." However, this document is about CGNs. It's about 
things that are almost by definition not nice interoperable players on 
the Internet. They are messy local devices for (albeit large) local 
networks. Indeed, there are many folks who think that horrific plagues 
be visited upon those who deploy CGNs and that they should be dismantled 
as soon as humanly possible, if not before. But in any event, this is 
not really a spec "for hardware and software required for computer 
communication across interconnected networks", but rather is a document 
for "networks operated by a great variety of organizations, with diverse 
goals and rules" to provide "operators and administrators of the 
Internet follow some common guidelines for policies and operations". Or 
at least I think a strong case can be made for that. I think that's why 
several other behave documents ended up being BCPs. I could make an 
argument for standards track, but I think BCP is a reasonable 
alternative conclusion to come to as well for this particular document.

pr

---

From: SM <[email-masked]>
Date: Tue, 17 Jul 2012 17:50:43 -0700

Hi Pete,
At 11:57 17-07-2012, Pete Resnick wrote:
>requirements for future protocol documents being developed by a WG; 
>it is a consensus document listing the requirements for the 
>operation and administration of a type of device. If that doesn't 
>fall within the 2nd paragraph of RFC 2026 section 5, I don't know what does.

I don't recall seeing an IPR disclosure on a BCP.  Most new 
Informational RFCs are also consensus documents.  There are a few 
Informational RFCs which lists requirements for operation and 
administration.  I don't think that this document should be BCP as 
the status does not exercise the "must demonstrate at least two 
independent, separate and successful uses of the licensing process".

Regards,
-sm