[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

re: IETF last call on draft-dasilva-l2tp-relaysvc-05.txt



I realize the last call is over but I looked at this document and have a
few comments.

- normative/informative split needed for references

- what is the content of the <attribute type> transmitted
  in the PPPoE Service Relay Response Capability AVP and
  PPPoE Service Relay Forward Capability AVP?

- what is the recommended speed at which a host should retry
  sending PADRs to establish a session?  When should it give
  up after not getting a PADS?  In general - what happens
  if there are failures and delays?  I believe this could
  cause congestion problems on the network and resource
  consumption issues on the LNS's (who do not know if the 
  PADS has been sucessfully delivered, right?)

  RFC 2516 addresses this for PADI and PADO messages:

  section 8
  When a host does not receive a PADO packet within a specified amount
   of time, it SHOULD resend it's PADI packet and double the waiting
   period. This is repeated as many times as desired.  If the Host is
   waiting to receive a PADS packet, a similar timeout mechanism SHOULD
   be used, with the Host re-sending the PADR.  After a specified number
   of retries, the Host SHOULD then resend a PADI packet.

  but I do not see the equivalent here.

- it looks to me like from RFC 2516 as if the PADO contains
  a human readable string. 

   section 5.2
      The PADO packet MUST contain one AC-Name TAG containing the Access
   Concentrator's name, a Service-Name TAG identical to the one in the
   PADI, and any number of other Service-Name TAGs indicating other
   services that the Access Concentrator offers. 

   section 8
   UTF-8 [5] is used throughout this document instead of ASCII.  UTF-8
   supports the entire ASCII character set while allowing for
   international character sets as well.  See [5] for more details.

   Are service names protocol identifiers or human readable strings?
   If they are protocol ids, where are they documented?  If they are
   human readable, what language are they written in?  I believe a
   language tag must be present in this case.  [RFC 2277, section 4.2]

- as this is a discovery protocol, a full example of what the
  client requests and gets would help.

- how does the receiver of the SRRQ alert the sender if it is invalid?
  Should the receiver throw the request away or send back some form
  of error message?

Best regards,

Erik