Subject: [Pana] Issue 222: Misc. comments on Section 4.3 (editorial part)

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 31 Jan 2006 11:59:50 -0500

According to AD's suggestion, the first couple of paragraphs of
section 4.3 should be revised 

From:

"
4.3  Discovery and Handshake Phase

   When a PaC attaches to a network, and it does not already know the IP
   address of the PAA, it MUST rely on dynamic discovery methods, such
   as a multicast-based and a traffic-driven discovery.

   The PaCs and PAAs MUST implement multicast-based discovery where the
   PaC sends a PANA-PAA-Discover message to a well-known
   administratively scoped multicast address (To Be Assigned by IANA)
   and UDP port (To Be Assigned by IANA).

   The network administrator MUST configure the multicast scope such
   that the discovery messages can reach only the designated PAA(s).  In
   case the PAA(s) is on the same link as the PaC, the administratively
   scoped multicast messages MUST not be forwarded by the routers.
   Details of scope configuration are discussed in [RFC2365].

   The PAA(s) that receive the discovery message MUST respond with a
   unicast PANA-Start-Request message sent to the soliciting PaC.

   Alternatively, the PaC MAY also choose to start sending data packets
   before getting authenticated.  The EP in an access network that
   implements PANA SHOULD drop such 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 the PaC
   explicitly soliciting for a PAA).  Deployment of this alternate
   scheme is optional.

   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].
"

To:

"
4.3.  Discovery and Handshake Phase

   When a PaC attaches to a network, and it does not already know the IP
   address of the PAA, it MUST rely on dynamic discovery methods, such
   as a multicast-based and a traffic-driven discovery (see below).  The
   multicast-based discovery MUST be implemented.  The traffic-driven
   discovery MAY be implemented.

   Multicast-Based Discovery:

      In the multicast-based discovery, the PaC sends a PANA-PAA-
      Discover message to a well-known administratively scoped multicast
      address (To Be Assigned by IANA) and UDP port (To Be Assigned by
      IANA).

      The network administrator MUST configure the multicast scope such
      that the discovery messages can reach only the designated PAA(s).
      In case the PAA(s) is on the same link as the PaC, the
      administratively scoped multicast messages MUST not be forwarded
      by the routers.  Details of scope configuration are discussed in
      [RFC2365].

      The PAA(s) that receive the discovery message MUST respond with a
      unicast PANA-Start-Request message sent to the soliciting PaC.

   Traffic-Driven Discovery:

      In the traffic-driven discovery, the PaC starts sending data
      packets before getting authenticated.  The EP in an access network
      that implements PANA SHOULD drop such 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.

      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].
"

Yoshihiro Ohba

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