draft-dasilva-l2tp-relaysvc-06.txt

[Thomas Narten <narten@us.ibm.com>]

IESG:

This document has a normative reference to an Informational document
(RFC 2516, PPPoE). The document describes extensions to L2TP to
support PPPoE. It's hard for this document not to have a normative
reference to PPPoE, as some of the processing depends on details that
include parsing the PPPoE messages. E.g.,:

>     Upon receipt of the SRRQ, the included PPPoE PADI message MUST be
>     processed as described in [3], be relayed to another L2TP control
>     connection, or be relayed to another PPPoE AC.

or

>     Upon receipt of an L2TP ICRQ message, the LNS parses the PADR message
>     as described in [3]. If this is an acceptable PPPoE service
>     connection (e.g. the Service-Name-Error TAG would not be included in
>     a PPPoE Active Discovery Session-confirmation packet (PADS)
>     response), the L2TP Incoming-Call-Reply (ICRP) message that is sent
>     to the LAC includes the resultant PPPoE PADS encapsulated within the
>     PPPoE Relay AVP. If the service is unacceptable, the PADS with a

and so forth.

According to 2026, Standards Track documents can't have normative
references to informational documents. Possible options:

1) put PPPoE on the standards track. The problem with this is that
   reopening PPPoE would be too controversial. There have been a
   couple of attempts to try and do this, but to close some of the
   gaping security holes in  PPPoE would require changing it in ways
   that it is no longer PPPoE and/or compatable with what is deployed.

2) Make relaysvc an informational document. While this might be
   expedient, it seems like we'd be doing this for process reasons
   only. Putting this document on standards track allows it to go
   through the normal process of advancement, interoperability
   testing, etc. Based on the technology, and the need for this to be
   implemented, PS seems like the right thing to do.

3) We could of course issue a variance and make an exception in this
   case as described in Section 9.1 of RFC 2026. That might be
   warranted if we followup on the next step.

4) Revise 2026 to allow for more exceptions to the normative reference
   issue. Note that we already    have been allowing normative
   references to security documents that are informational, and there
   have been other cases cited where exceptions should be made. Randy
   has a draft on this (that I can't find right off).

What do I recommend? Not entirely sure. Maybe a combination of 3 and
4, but I need to review the Randy's document to see if it covers this
case. Randy, can someone please repost your ID?

Thomas