Subject: [Pana] Issue 139: Clarify L2 trigger (in figure 3) possibility in text

From: Alper Yegin <[email-masked]>
Date: Mon, 06 Dec 2004 15:57:34 -0800

http://danforsberg.info:8080/pana-issues/issue139

In Section 4.2, replace:

   The PaC MAY also choose to start sending data packets before getting
   authenticated.  The EP in an access network that implements PANA
   SHOULD drop unauthorized packets upon receipt.  Additionally, the EP
   MAY also take this traffic as an indication of unauthorized PaC and
   notify the PAA.  The EP-to-PAA notification SHOULD be sent via
   [I-D.ietf-pana-snmp].  In response, the PAA SHOULD send an
   unsolicited PANA-Start-Request message to the PaC.  This is called
   "traffic-driven PAA discovery" (an alternative to PaC explicitly
   soliciting for PAA).  Note that this optional feature MAY NOT be
   present in all deployments, therefore PaCs MUST NOT assume its
   availability.

With:

   The PaC MAY also choose to start sending data packets before getting
   authenticated.  The EP in an access network that implements PANA
   SHOULD drop unauthorized packets upon receipt.  Additionally, the EP
   MAY also take this traffic as an indication of unauthorized PaC and
   notify the PAA.  The EP-to-PAA notification SHOULD be sent via
   [I-D.ietf-pana-snmp].  In response, the PAA SHOULD send an
   unsolicited PANA-Start-Request message to the PaC.  This is called
   "traffic-driven PAA discovery" (an alternative to PaC explicitly
   soliciting for PAA).  Note that this optional feature MAY NOT be
   present in all deployments, therefore PaCs MUST NOT assume its
   availability. The EP-to-PAA notification MAY also be generated
   in response to receiving a link-up event notification on the EP 
   [I-D.ietf-dna-link-information].

Add to references:

[I-D.ietf-dna-link-information] draft-ietf-dna-link-information-00.txt

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana