Common Requirements for Carrier-Grade NATs (CGNs)
draft-ietf-behave-lsn-requirements-10

[Ballot discuss]
(1) cleared

(2) cleared

(3) Does REQ-7 mean "CGNs SHOULD use EIF"? Its not clear to
me if you mean that, or if you mean "CGNS SHOULD implement
EIF"? I think "RECOMMENDED [to] ...  have... behaviour" is
ambiguous. I think we agreed that s/have/use/ was the change
to make but that seems to have gotten missed.

(4) cleared

(5) cleared

[Ballot discuss]
Updated based on discussions with the author:

1) addressed

Will wait for a new version before clearing this.

2) s4: doesn't transport protocol need to be added to the list?

[Ballot comment]
I am fine with this being BCP.  (the prior version of the ballot was a typo)

Section 3., paragraph 50:

>    REQ-10:  CGN implementrers SHOULD make their equipment manageable.
>            Standards-based management using standards such as
>            "Definitions of Managed Objects for NAT" [RFC4008] is
>            RECOMMENDED.

  s/implementrers/implementers/

[Ballot comment]
I share Ralph's question about how this updates RFC4787.

It worries me that we are requiring the implementation of a new protocol (pcp) as part of a BCP.
It would be more work to write "you need to do all the things pcp lets you do", but it would be more in the spirit of RFC4787 to have done so.

[Ballot discuss]
1) s4: Shouldn't the requirements for the timestamp be identical to the requirement in 6302:

  A timestamp, RECOMMENDED in UTC, accurate to the second, from a
  traceable time source (e.g., NTP [RFC5905]).

2) s4: doesn't transport protocol need to be added to the list?

[Ballot comment]
s4: Because you gave an out in the previous paragraph it's worth noting in the following that one reason might be that the CGN isn't following 6302:

  This requirement is at the SHOULD level to account for the fact
  that there may be other reasons for logging destination addresses
  or ports.

[Ballot discuss]
Updated my position, after reading REQ-9 again:

>> Section 3., paragraph 42:
>
>>>    REQ-9:  A CGN MUST include a Port Control Protocol server
>>>            [I-D.ietf-pcp-base] with the following constraints on its
>>>            behavior:
>>
>>    Is this saying that each and every CGN MUST have PCP or that CGN
>>    implementing PCP must follow the constraints?

> Each and every CGN MUST have PCP and MUST follow the constraints. I'll
> fix the text in a later revision.

Can we mandate a specific protocol to be used for this or can we only mandate that such a type of protocol is being used? I don't see the IETF in the position to mandate this type of protocol for CGNs.

There are other protocols out there which might be suitable. Note that I am co-author of some, but this isn't the reason for the question. I do not get any reward if I promote these protocols.

It is more:
do we need to constrain CGN deployments to a protocol (PCP) which is developed right now, or are we open to existing or future protocols, or whatever folks deploying this deem right?

I would propose to change REQ-9 to :
REQ-9: A CGN MUST include a middlebox control protocol that allows manipulation of CGN bindings with the following contstraints
REQ-9a: If PCP is used these contstraints MUST be applied in addition to contraints A and B:

[Ballot comment]
I am fine with this being informational.

Section 3., paragraph 50:

>    REQ-10:  CGN implementrers SHOULD make their equipment manageable.
>            Standards-based management using standards such as
>            "Definitions of Managed Objects for NAT" [RFC4008] is
>            RECOMMENDED.

  s/implementrers/implementers/

[Ballot comment]
For the IESG: 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.

For the authors/WG: I agree with Stephen's point about REQ-1, but disagree with the solution suggested on the IESG list; I think it reversed the sense of the statement. You had:

OLD:

          If NAT behavioral requirements documents are created for
          additional protocols, then these new documents MUST update
          this list by adding themselves to it.

NEW:

          Any future NAT behavioral requirements documents for IPv4
          transport protocols will also need to consider the
          requirements for CGNs stated here.

But this loses the sense that new NAT behavioral requirements documents will impose new requirements on CGNs. Might I instead suggest:


          Any future NAT behavioral requirements documents for IPv4
          transport protocols will impose additional requirements for
          CGNs on top of those stated here.

The requirement is not a requirement for future documents; it's a requirement for CGNs.

[Ballot comment]
For the IESG: 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.

For the authors/WG: I agree with Stephen's point about REQ-1, but disagree with the solution suggested on the IESG list; I think it reversed the sense of the statement. You had:

OLD:

          If NAT behavioral requirements documents are created for
          additional protocols, then these new documents MUST update
          this list by adding themselves to it.

NEW:

          Any future NAT behavioral requirements documents for IPv4
          transport protocols will also need to consider the
          requirements for CGNs stated here.

But this loses the sense that new NAT behavioral requirements documents will impose new requirements on CGNs. Might I instead suggest:


          Any future NAT behavioral requirements documents for IPv4
          transport protocols will impose additional requirements for
          CGNs on top of those stated here.

[Ballot comment]
I second the view that is should be an informational RFC, not BCP.

Section 3., paragraph 41:

>      Note that this requirement also applies to the case when a CGN
>      loses state (due to a crash, reboot, failover to a cold standby,
>      etc.).  In that case, ports that were in use at the time of state
>      loss SHOULD NOT be reallocated until at least 120 seconds have
>      passed.

  How can this 'SHOULD NOT' be exercised if the CGN does not keep
  state during reboots or crashes?

Section 3., paragraph 42:

>    REQ-9:  A CGN MUST include a Port Control Protocol server
>            [I-D.ietf-pcp-base] with the following constraints on its
>            behavior:

  Is this saying that each and every CGN MUST have PCP or that CGN
  implementing PCP must follow the constraints?


Section 3., paragraph 50:

>    REQ-10:  CGN implementrers SHOULD make their equipment manageable.
>            Standards-based management using standards such as
>            "Definitions of Managed Objects for NAT" [RFC4008] is
>            RECOMMENDED.

  s/implementrers/implementers/

[Ballot comment]
I agree with Russ's DISCUSS concerning the classification of
this document as BCP. Informational seems more appropriate.

===

Why does REQ-1 not also specify  draft-ietf-behave-sctpnat-06?

===

Limiting the rate of allocation is intended to prevent
      against CPU resource exhaustion.

d/against/

====

REQ-12:  A CGN SHOULD NOT log destination addresses or ports.

  Justification:  Destination logging at the CGN creates privacy
      issues. 

Why is this not "SHOULD NOT log destinations addresses or
ports unless required to do so for administrative reasons"
followed by  privacy advice?

As much as the IETF finds it distasteful, this sort of logging
may well be administratively required at number of levels,
and we should deal with minimizing the privacy issues
when this happens.

====

[Ballot discuss]
I want to discuss the indication that this document updates RFC 4787.
My position does not require any changes to the document by the
authors at this time.

In my opinion, this document builds on RFC 4787 to list requirements
for use cases or deployment scenarios not in the scope of RFC 4787,
but does not update or replace any of the text in RFC 4787.  While
a couple of requirements in this document are described as "stronger
versions" of the corresponding requirements from RFC 4787, I don't see
any indication that these modified requirements are to be
retroactively applied to RFC 4787.

If it does update RFC 4787, exactly what text in RFC 4787 updated with
new text from this document?

[Ballot discuss]

  In the Gen-ART Review by Alexey Melnikov on 3-July-2012, he asked:
  >
  > 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.
  >
  The authors made no attempt to encourage the publication as BCP.  They
  appear to be satisfied with either BCP or Informational.  Requirements
  documents are normally published as Informational RFCs.  I see no
  reason for an exception in this case.

[Ballot discuss]
(1) As written, REQ-1 is followed by a MUST that applies to
anyone who ever writes a NAT-considerations for any transport
protocol for all time. (Even though CGN is presumably a
transition technology intended to vanish in a decade or so
when IPv6 is everywhere.) That seems wrong in lots of ways.
In fact it seems backwards. Oughtn't the onus be on CGN folks
to update to meet the needs of new transports and not the
other way around and oughtn't CGN be designed so as to work
(to the maximum extent possible) with any transport that we
can now envisage.  If in fact its not possible for a GGN to
be designed to be friendly towards future transport networks,
then the argument that that is the case needs to be made.
(And be convincing if you want the MUST this way about.) I'm
not sure what kind of change might help out here but I think
some change is needed.

(2) REQ-4 calls for "limits ... per transport protocol" in
bullet B. Is that meant to be per-subscriber? If so, why are
you limiting how a subscriber chooses to use their bandwidth
on a per-transport protocol basis? If not, then it really
seems like a different requirement that is not part of REQ-4
and is very odd - why would a CGN want the set of subscribers
behind it to use e.g. 50% less UDP than TCP?

(3) Does REQ-7 mean "CGNs SHOULD use EIF"? Its not clear to
me if you mean that, or if you mean "CGNS SHOULD implement
EIF"? I think "RECOMMENDED [to] ...  have... behaviour" is
ambiguous.

(4) cleared

(5) I agree with the changes suggested by Sam Hartman in his
secdir review for REQ-9 and section 8. [1] Sam suggested text
that'd work for me, and the authors seem receptive but I'm
not clear if the discussion has converged or not. (I expect
it will, so this mainly for tracking.)

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03392.html

[Ballot comment]
- Ought you do s/must/MUST/ in "In other words, a CGN must
use the same external IP address mapping for all sessions
associated with the same internal IP address, be they TCP,
UDP, ICMP, something else, or a mix of different protocols."

- s/rarity of/scarcity of new/ after REQ-3. They're not rare,
we see 'em all the time, but new ones are scarce.

- The justification for REQ-4 seems confused, in particular
the last sentence about CPU consumption doesn't seem to
relate to port consumption at all. The justification for
REQ-5 seems to make a similar error, saying CPU consumption
when memory consumption is at stake.

- REQ-8 seems to use the terms deallocated and state loss as
if they're synonyms. Are they? If so, then using one term is
probably better. If not, then maybe say how they differ. The
justification text just before REQ-9 seems to say they
differ. You also have 2119 keywords in the justification text
here, which you seem to have tried to avoid elsewhere so
maybe some edits are needed?

- Section 4 could note that logging mappings might also cause
privacy issues, e.g. the pattern of a subscriber's behaviour,
and that logs need to be protected.

- I think you could explain more why small consecutive port
sets provide poorer security.

- I'm also a bit wary of the IPR declaration here. If that
could be clarified some more or if the WG could now see a
published application, that'd be great. But I accept that
that WG have chosen to go ahead as-is.

[Ballot discuss]
Section 5, as it is currently composed, strays from requirements into potential solutions.

From the perspective of a requirements document, Section 5 is really about:

- a port utilization requirement
- a log volume requirement
- a security / port guessing requirement

All of these should be called out as real requirements (REQ-xx). A discussion of these requirements should mention that they compete with one another. An implementation optimizes to satisfy one requirement at the expense of another. Therefore, these are soft requirements (SHOULD as opposed to MUST).

It might be OK to mention that an implementation's choice of port allocation scheme influences which requirement gets priority. However, when we mention three specific port allocation schemes (traditional, scattered and consecutive) we put one toe out of bounds. When we make statement about which scheme optimizes for which requirement, the rest of the body follows the toe.

Honestly, I would have never noticed this problem had it not been for the IPR declaration and the authors assumption that the IPR related to Section 5. But one closer examination, the section has a problem, regardless of the IPR.

[Ballot discuss]

(1) As written, REQ-1 is followed by a MUST that applies to
anyone who ever writes a NAT-considerations for any transport
protocol for all time. (Even though CGN is presumably a
transition technology intended to vanish in a decade or so
when IPv6 is everywhere.) That seems wrong in lots of ways.
In fact it seems backwards. Oughtn't the onus be on CGN folks
to update to meet the needs of new transports and not the
other way around and oughtn't CGN be designed so as to work
(to the maximum extent possible) with any transport that we
can now envisage.  If in fact its not possible for a GGN to
be designed to be friendly towards future transport networks,
then the argument that that is the case needs to be made.
(And be convincing if you want the MUST this way about.) I'm
not sure what kind of change might help out here but I think
some change is needed.

(2) REQ-4 calls for "limits ... per transport protocol" in
bullet B. Is that meant to be per-subscriber? If so, why are
you limiting how a subscriber chooses to use their bandwidth
on a per-transport protocol basis? If not, then it really
seems like a different requirement that is not part of REQ-4
and is very odd - why would a CGN want the set of subscribers
behind it to use e.g. 50% less UDP than TCP?

(3) Does REQ-7 mean "CGNs SHOULD use EIF"? Its not clear to
me if you mean that, or if you mean "CGNS SHOULD implement
EIF"? I think "RECOMMENDED [to] ...  have... behaviour" is
ambiguous.

(4) REQ-7 says a CGN MAY use address dependent filtering but
doesn't say how to know when that's ok. Is the intent that
specifications claiming to meet these requirements do need to
specify that or not?  If so, then I think you're missing some
2119 language. If not, is it ok to leave that just open for
implementers?

(5) I agree with the changes suggested by Sam Hartman in his
secdir review for REQ-9 and section 8. [1] Sam suggested text
that'd work for me, and the authors seem receptive but I'm
not clear if the discussion has converged or not. (I expect
it will, so this mainly for tracking.)

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03392.html

[Ballot comment]

- Ought you do s/must/MUST/ in "In other words, a CGN must
use the same external IP address mapping for all sessions
associated with the same internal IP address, be they TCP,
UDP, ICMP, something else, or a mix of different protocols."

- s/rarity of/scarcity of new/ after REQ-3. They're not rare,
we see 'em all the time, but new ones are scarce.

- The justification for REQ-4 seems confused, in particular
the last sentence about CPU consumption doesn't seem to
relate to port consumption at all. The justification for
REQ-5 seems to make a similar error, saying CPU consumption
when memory consumption is at stake.

- REQ-8 seems to use the terms deallocated and state loss as
if they're synonyms. Are they? If so, then using one term is
probably better. If not, then maybe say how they differ. The
justification text just before REQ-9 seems to say they
differ. You also have 2119 keywords in the justification text
here, which you seem to have tried to avoid elsewhere so
maybe some edits are needed?

- Section 4 could note that logging mappings might also cause
privacy issues, e.g. the pattern of a subscriber's behaviour,
and that logs need to be protected.

- I think you could explain more why small consecutive port
sets provide poorer security.

- I'm also a bit wary of the IPR declaration here. If that
could be clarified some more or if the WG could now see a
published application, that'd be great. But I accept that
that WG have chosen to go ahead as-is.

[Ballot discuss]
The practice of posting IPR against requirements documents is troubling. What does such IPR mean? That all fully compliant implementations are IPR encumbered?

I realize that it is impossible to answer this question, because the IPR relates to an unpublished patent application.

[Ballot comment]
1. In section 3, the text states "If NAT behavioral requirements documents are created for additional protocols, then these new documents MUST update this list by adding themselves to it."  Do these new behavioral requirements documents need to update this document?  Does this document need to be updated each time a new behavioral document is published as an RFC?

2. For REQ-6, what is the impact of disabling translation on state tables within the NAT?  If no state is maintained, is there a DoS vulnerability for the client?  For example, if I know that traffic from X2:x2 --> X1:x1 is not translated, could I use that knowledge to attack the client?

3. REQ-8 recommends not re-using a port until 120 seconds elapses.  Is that value applicable to all transport protocols?  How do you envision a CGN enforcing that value after a crash (as mentioned in the last paragraph of the requirement justification)?

[Ballot comment]
Substantive comments; these are non-blocking, but please consider them
seriously, and feel free to chat with me about them:

-- REQ-5 --
      It is at the SHOULD level to account for the
      fact that means other than rate limiting may be used to attain the
      same goal.

It seems, then, that there is a higher-level requirement that's missing, and that this "requirement" is really stating a suggested means to achieve it.

UPDATE: Simon explains that "It" in the above quotation refers to list item B only.  I'm requesting that he change "It" to "Item B" to make that clear.

      This state consumes resources for which, in the
      case of a CGN, subscribers may compete.  It is necessary to ensure
      that each subscriber has access to a fair share of the CGN's
      resources.  Limiting TCP sessions per subscriber and per time unit
      is an effective mitigation against inter-subscriber DoS attacks.

UPDATE: Simon also explains that the last sentence in the paragraph above needs to be removed.

[Ballot comment]
Substantive comments; these are non-blocking, but please consider them
seriously, and feel free to chat with me about them:

-- REQ-5 --
      It is at the SHOULD level to account for the
      fact that means other than rate limiting may be used to attain the
      same goal.

It seems, then, that there is a higher-level requirement that's missing, and that this "requirement" is really stating a suggested means to achieve it.  You explain:

      This state consumes resources for which, in the
      case of a CGN, subscribers may compete.  It is necessary to ensure
      that each subscriber has access to a fair share of the CGN's
      resources.  Limiting TCP sessions per subscriber and per time unit
      is an effective mitigation against inter-subscriber DoS attacks.

The trouble is that when I read this I'm not fully sure what the actual requirement is; is it:
a. A CGN MUST limit the resources consumed by maintaining state information for each subscriber.
b. A CGN MUST ensure that each subscriber has access to a fair share of the CGN's resources.
c. A CGN MUST protect itself against inter-subscriber DoS attacks.

...or is it something different from all of those?

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Common requirements for Carrier Grade NATs (CGNs)) to Best Current Practice


The IESG has received a request from the Behavior Engineering for
Hindrance Avoidance WG (behave) to consider the following document:
- 'Common requirements for Carrier Grade NATs (CGNs)'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-07-10. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines common requirements for Carrier-Grade NAT
  (CGN).  It updates RFC 4787.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-behave-lsn-requirements/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-behave-lsn-requirements/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1648/

State changed to AD Evaluation::Revised ID Needed from Publication Requested.
AD Review of draft-ietf-behave-lsn-requirements-05

Major comment:
IETF should focus on technical issues that affect interoperability, so this document should be specifying the on-the-wire requirements. Some of the requirements cited here seem to be internal details that do not appear to have any effect on on-the-wire interoperability. They really do not belong in an IETF document.

1) in 1., I question whether the statement that "this is not considered a solution to the shortage of IPv4 addresses" is useful. First, CGN has been discussed as necessary to help ISPs address IPv4 address exhaustion while IPv6 deployment occurs. So to say that CGN is not to be considered as a solution of IPv4 address shortage seems inaccurate. Second, in the same paragraph, you state that "there are driving forces other than the shortage of IPv4 addresses.", which seems to argue that CGN **is** considered a solution for IPv4 address shortage.

2) This document contains some marketing promises. That doesn't really belong in an IETF document. We should be discussing the technical issues. "Meeting this set of requirements will greatly increase the likelihood that subscribers' applications will function properly" strikes me as marketing more than technical standardization work.

3) in 1, "requirements that are to be expected of" strikes me as inappropriate use of "requirements". Either it is REQUIRED for interoperability or it is not.

4) in 2, there is a discussion of carrier-grade not being related to quality. The document is titled large scale nat requirements. So why not use the term last-scale-nat rather than carrier-grade, which makes it unnecessary to discuss the relationship to quality.

5) in 2, the last paragraph talks about hotspots. I don't see what point is being made, if "this, however, has no impact on CGN requirements." It would seem better to change the description of CGN in the whole document as being a service-provider-administered NAT, which has one or more subscribers on the private side of the NAT. The subscriber may or may not have one or more subscriber-administered NATs in their portion of the network.

6) it is much easier for readers to provide a title for references. For example, in 2, "Readers are expected to be familiar with [RFC4787] …" It would be nice to provide the title so readers do not need to interrupt their reading to go to the references to see what you expect them to be familiar with.

7) in 3, REQ-1 makes IETF standard transports such as SCTP and DCCP optional. My experience is that when you make protocols like this optional, implementers will choose to not support them to save development costs. Since applications that depend on these protocols will not work if there is a CGN that does not support them between endpoints, this does not make the Internet run better. The mission statement of the IETF is to make the Internet run better. So I expect you will have great difficulty getting this REQ approved by the IESG.

8) in REQ-2, you say the default must be xxx, but a CGN may do something else. Typically, combining MUST with a MAY means you should be using a SHOULD. MUST should be used used when a protocol will not work if the specified behavior is not done.

9) REQ-2 changes the requirement specified in REQ-2 of RFC4787 from a RECOMMENDED to a MUST. If this document updates any requirement in RFC4787, then there must be an updates (or obsoletes) in the document header, and discussion within the text of what specifically is being changed from the existing BCP or standard.

10) in REQ-2, you specify some requirements in terms of subscribers. But subscribers is not a technical term. How does an implementer implement an IP-to-subscriber relationship in code?

11) in REQ-2, you say the IP address pooling behavior applies to mappings between external IP addresses and subscribers, rather than to internal IP addresses. But two paragraphs later, you say a CGN must use the same external IP address mapping for all sessions associated with the same internal address. Is the mapping from external IP address to a subscriber of an internal IP address? you need to be consistent (and technical).

12) REQ-3 is likely to be affected by the size of the /10 space allocated for CGNs, if the /10 is approved. I think you probably need REQs to address the issues raised by the /10, if ti is allocated.  This REQ-3 might be impacted by those requirements.

13) REQ-4 is written from the standpoint of the CGN administrator. But for interoperability, we really should be paying attention to the external behaviors that must be accommodated by the subscriber on the private side, and the Internet on the public side.

14) REQ-4 A. is a SHOULD, but this seems to be an internal detail. Is this a SHOULD because some CGN admins want to be able to configure limits. If we want to sere that admins CAN configure limits if they choose, then this should be a MUST for implementers; if implementers do not implement this ability, then operators cannot use the feature. So, is the ability to do this really a requirement, i.e., the CGN will not work without this feature, or is this a nice-to-have optional feature? If this is nice-to-have, then the "requirement" should probably be specified as "an implementer MAY" supper this feature, and an operator MAY utilize this feature, therefore implementers of subscriber equipment MUST be able to handle non-contiguous addressing, etc. 

15) If a CGN can limit the number of ports, doesn't that potentially interfere with applications, and make it harder to design protocols that utilize registered ports? How does that make the Internet run better?

16) REQ-7: I don't see how this strengthens RFC4787:REQ-8. That REQ is conditionally RECOMMENDED EIF, and conditionally RECOMMENDED AIF. The new RQ is RECOMMENDED EIF and MAY AIF.

17) REQ-8 says a CGN MUST NOT reuse, except …" That means this is a SHOULD, with the exceptions being ...

18) REQ-8 says MUST NOT reuse … for 120 seconds; REQ-9 says this value SHOULD be configurable. If it is acceptable that it is configurable, then it is not a MUST. CGN should not prevent SCTP and DCCP and other IETF standard protocols from working; will this reuse timer have any impact on protocols other then TCP? It would probably be best to have a protocol-specific default.

19) REQ-8 discusses pool swapping. This is an implementation detail and not in interoperability requirement. It doesn't really belong in a requirements document. If you have implementation suggestions, it might be more approbate to gather them together in a on-normative section entitled "implementation suggestions" or "implementation guidelines".

20) REQ-9: how is this different from REQ-8? please explain from an interoperability standpoint how implementations that have been configured with different values should work relative to the communicating entities. What guidelines should be followed in a sending entity, what guidelines should be followed in a receiving entity? Given these operational behaviors, what is required from implementations?

21) REQ-9 prevents users from receiving unwanted traffic. What is "unwanted traffic"? Who defines "unwanted" - the implementer, the SP admin or the subscriber?  How exactly does it stop unwanted traffic?

22) REQ-9: The current wording doesn't say it stops unwanted traffic; it says it "prevents the subscriber from receiving …"; I think is not the intention, but the text needs to be clear. Is this a feature that, for example, allows a provider to impose rules about what news a subscriber is allowed to receive?

23) REQ-10: According to REQ-6, in the context of a CGN it is important to minimize application breakage. If having pcp greatly increases the likelihood that applications will function properly, why is this not a MUST implement?

24) REQ-10: based on various studies, misconfiguration is a huge contributor to network problems. So why in this requirement do we assume subscribers can correctly configure NAT state? Let me state that I support subscribers having some ability to monitor the CGN, and possibly to manipulate the NAT relative to their applications, but having multiple cooks spoils the broth. If a CGN-admin configures things one way, and a subscriber, who doesn't necessarily understand the topology of the SP's network, changes that configuration, why do we think that will make things work better? I think this deserves much more discussion of which parameters a subscriber should be able to manipulate.

25) REQ-11: RFC4008 is a MIB. MIBs are typically only used with the SNMP protocol. So is there a requirement that SPs must implement SNMP to manage their CGN? Whether a CGN is manageable is already controllable by an ISP when they make their choice of equipment to buy.

26) REQ-11: I am a bit concerned that you are specifying a particular MIB module revision (RFC4008) which might be updated in the future. Do you expect to write a CGN-reqs-bis to update the requirements when RFC4008 is updated?
I recommend rewording this to say implementers should make their CGN equipment manageable, and standards-baed management using standard such as RFC4008 is recommended. (make rfc4008 an example of standardized management, not the requirement itself)

27) REQ-12: the "session initiator" - does this apply for non-TCP transports such as UDP (which doesn't have sessions)?

28) REQ-12: the only notification to subscribers is a SHOULD. A subscriber's communications can be seriously affected by the presence of a CGN. I think the provider should try harder than just a "SHOULD send ICMP".

29) REQ-12: SNMP trap should be sent to a management station, but it doesn't say whether that management station is an SP-managed notification receiver or a subscriber-managed notification receiver.

30) REQ-12: Since a notification to a subscriber would cross admin-boundaries, syslog might be a good choice of notification to a subscriber of problems that affect subscriber traffic.

31) REQ-12: I suggest that the document should contain some operations and management considerations regarding things like ICMP messages. Should subscriber equipment by default allow ICMP code 3 to pass from the SP to the subscriber? should subscriber firewalls be configured to accept such messages? ICMP is a pretty low-level notification. How should subscriber equipment respond to receiving such notifications? Should the OS alert the user to the ICMP message so the user knows their traffic was dropped by the CGN?

32) REQ-12: what ar the security implications of notifying the session initiator that there traffic has been droped because of resource constraints or policy restrictions?

33) section 4 specifies that logging should be done for purposes of lawful intercept. RFC2804 states "The IETF has decided not to consider requirements for wiretapping as
  part of the process for creating and maintaining IETF standards."
This document should be using lawful intercept as a requirement in IETF standards.

34) The logging that is described does not appear to be relative to interoperability between endpoints. The logging discussion about the interface between a service provider and other non-protocol entities such as governmental agencies. This is not about on-the-wire interoperability between implementations, such as protocols or formatted message content. Therefore, I question whether this whole section is within the scope of IETF work. These types of logging requirements are within the scope of governmental agencies to require, not the IETF.

35) section 5 is written from the standpoint of a service provider and different deployment approaches. This specification should be focused on the requirements for implementers. Section 5 doesn't list the requirements that must be met so operators can deploy these approaches. What do implementers need to provide in their equipment so operators can deploy as desired?

36) section 5 discusses deployment scenarios tat are internal to an admin's network. This document should be focusing on what is required in terms of the requirements to achieve on-the-wire interoperability. What is the externally-observable behaviors that are caused by these deployment scenarios? How should senders and receivers respond to those behaviors to ensure interoperability?

37) section 5 discusses logging destination addresses and ports on per-session basis. But REQ-13 says destination addresses and ports SHOULD NOT be logged due to privacy issues.

38) section 6 points points to RFC6269 section 26.2. I don't find a section 26.2 in RFC6269.

39) section 6 points to RFC6269 for guidance on picking an appropriate ratio. To properly understand the whole issue of ratios, one would need to understand RFC6269. That makes RFC6269 normative. But RFC6269 is not a BCP or a standard, therefore this is a downref. A BCP should not depend on an Informational document to explain the BCP of address sharing ratio. The BCP should specify the normative behavior relative to the address sharing ratio.

40) section 8 says "preventing this can be accomplished with ingress filtering" but it doesn't specify who should do the ingress filtering. Please use active voice rather than passive voice, such as "Subscribers SHOULD employ ingress filtering to prevent this attack"; that would make it much clearer whose responsibility it is to perform what actions.

41) please check the whole document for instances of passive voice, and please try to convert them to active voice so we have clear and unambiguous specification of who has responsibility for what actions.
http://www.rfc-editor.org/rfc-style-guide/rfc-style says
    *  Passive voice (e.g., "The dog was kicked by you") may be used but
      is frowned upon.  Text should be written in active voice (e.g.,
      "You kicked the dog").

41) section 8 says the EIF security considerations are discussed in RFC4787. That's nice to know, but what we really want to know is how to the security considerations of EIF relate to CGNs, and that is not discussed here.

UPDATED PROTO Write-up:

  (1.a)  Who is the Document Shepherd for this document?

document: draft-ietf-behave-lsn-requirements-05
shepherd: Dan Wing, dwing@cisco.com

          Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?
Yes.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

Yes, sufficient review has been performed. 


  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

No concerns.


  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

No concerns.

An IPR declaration exists against the document,
https://datatracker.ietf.org/ipr/1648.  The actual claims are
not available.

At IETF82, consensus of the working group was to continue with
publication of the document. 


  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

Consensus is strong, except for a split between some WG members wanting
"SHOULD support bulk port allocation" (in order to reduce logging) and
other WG members who think no recommendation should be made.  So,
the document merely describes the trade-offs in its Section 5.


  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No significant conflict with this document has occurred.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?

No such reviews are needed.

          If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

Intended status:  BCP

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

Yes, all references are split.


  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

This document does not need any IANA action.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

There is nothing in this document defined in a formal language.


  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document.  If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

  "This document defines common requirements for Carrier-Grade NAT
    (CGN)."

          Working Group Summary
            Was there anything in the WG process that is worth noting?
            For example, was there controversy about particular points
            or were there decisions where the consensus was
            particularly rough?

Some controversy around bulk port allocation, as described above.

          Document Quality
            Are there existing implementations of the protocol?  Have a
            significant number of vendors indicated their plan to
            implement the specification?  Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues?  If
            there was a MIB Doctor, Media Type, or other Expert Review,
            what was its course (briefly)?  In the case of a Media Type
            Review, on what date was the request posted?

          Personnel
            Who is the Document Shepherd for this document?  Who is the
            Responsible Area Director?  If the document requires IANA
            experts(s), insert 'The IANA Expert(s) for the registries
            in this document are .'

shepherd:  Dan Wing, dwing@cisco.com
responsible AD:  David Harrington

  The Document Shepherd MUST send the Document Shepherd Write-Up to the
  Responsible Area Director and iesg-secretary@ietf.org together with
  the request to publish the document.  The Document Shepherd SHOULD
  also send the entire Document Shepherd Write-Up to the working group
  mailing list.  If the Document Shepherd feels that information which
  may prove to be sensitive, may lead to possible appeals, or is
  personal needs to be written up, it SHOULD be sent in direct email to
  the Responsible Area Director, because the Document Shepherd Write-Up
  is published openly in the ID Tracker.  Question (1.f) of the
  Write-Up covers any material of this nature and specifies this more
  confidential handling.

(1.a) Who is the Document Shepherd for this document?

document: draft-ietf-behave-lsn-requirements-05
shepherd: Dan Wing, dwing@cisco.com

Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?
Yes.


(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

Yes, sufficient review has been performed.


(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization, or XML?

No concerns.


(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No concerns.

An IPR declaration exists against the document,
https://datatracker.ietf.org/ipr/1648/


(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

Consensus is strong, except for a split between some WG members wanting
"SHOULD support bulk port allocation" (in order to reduce logging) and
other WG members who think no recommendation should be made. So,
the document merely describes the trade-offs in its Section 5.


(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No significant conflict with this document has occurred.



(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type, and URI type reviews?

No such reviews are needed.

If the document
does not already indicate its intended status at the top of
the first page, please indicate the intended status here.

Intended status: BCP


(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

Yes, all references are split.


(1.i) Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process, has the Document
Shepherd conferred with the Responsible Area Director so that
the IESG can appoint the needed Expert during IESG Evaluation?

This document does not need any IANA action.


(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

There is nothing in this document defined in a formal language.


(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

"This document defines common requirements for Carrier-Grade NAT
(CGN)."




Working Group Summary
Was there anything in the WG process that is worth noting?
For example, was there controversy about particular points
or were there decisions where the consensus was
particularly rough?


Some controversy around bulk port allocation, as described above.


Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type, or other Expert Review,
what was its course (briefly)? In the case of a Media Type
Review, on what date was the request posted?

Personnel
Who is the Document Shepherd for this document? Who is the
Responsible Area Director? If the document requires IANA
experts(s), insert 'The IANA Expert(s) for the registries
in this document are .'

shepherd: Dan Wing, dwing@cisco.com
responsible AD: David Harrington



The Document Shepherd MUST send the Document Shepherd Write-Up to the
Responsible Area Director and iesg-secretary@ietf.org together with
the request to publish the document. The Document Shepherd SHOULD
also send the entire Document Shepherd Write-Up to the working group
mailing list. If the Document Shepherd feels that information which
may prove to be sensitive, may lead to possible appeals, or is
personal needs to be written up, it SHOULD be sent in direct email to
the Responsible Area Director, because the Document Shepherd Write-Up
is published openly in the ID Tracker. Question (1.f) of the
Write-Up covers any material of this nature and specifies this more
confidential handling.