PIM Join Attributes for Locator/ID Separation Protocol (LISP) Environments
draft-ietf-pim-join-attributes-for-lisp-06

[Ballot comment]
Discussion inspired by Lucy's Gen-ART review might result in some clarifications in the document. Please make sure any clarifications, if you decide to have them, are done before the document is finally approved.

[Ballot comment]
I think it would be helpful to have a paragraph on the goal of the "experiment", even if the goal is to gather implementation/deployment/operational experience.

There are a number of abbreviations that should be expanded on first mention.

[Ballot comment]
For the values for the "transport" (and I do agree with Mirja that it isn't entirely clear what should be there - I
was expecting different encapsulations), I'd recommend having 0 as being unallocatable & having 255 be reserved for
future use as was suggested in https://datatracker.ietf.org/doc/draft-haas-code-point-reservation-bcp.

[Ballot comment]
One minor but I think important comment (I don't think this justifies a discuss but I would really like to see that changed or at least discussed):

For me as a 'transport person' using the plain term '(underlaying) transport' is really confusing because it's very unspecific. In section 4.1. you actually call it the 'type of transport' and later on you talk about the mode of transport, but in general you just talk about the transport which is also reflected in the name of the attribute. In draft-ietf-taps-transports we classify this transport feature as part of addressing. I guess that might not be completely appropriate for your case. However, I would like to see the terminology here cleaned up to not only talk about '(underlaying) transport' but choose a more specific term. Given that you only have a 0 or 1 as choices in the attribute, I would even recommend to call this attribute 'Unicast Replication' or something like this instead of just 'Transport'.

One other minor comment:
There are many abbreviations that are not spelled out once and make the reading slightly harder, e.g. ITR and ETR and so on

Reddy, et al.          Expires December 29, 2019              [Page 22]
Internet-Draft                    TURN                        June 2019

5.  General Behavior

  This section contains general TURN processing rules that apply to all
  TURN messages.

  TURN is an extension to STUN.  All TURN messages, with the exception
  of the ChannelData message, are STUN-formatted messages.  All the
  base processing rules described in [I-D.ietf-tram-stunbis] apply to
  STUN-formatted messages.  This means that all the message-forming and
  message-processing descriptions in this document are implicitly
  prefixed with the rules of [I-D.ietf-tram-stunbis].

  [I-D.ietf-tram-stunbis] specifies an authentication mechanism called
  the long-term credential mechanism.  TURN servers and clients MUST
  implement this mechanism.  The server MUST demand that all requests
  from the client be authenticated using this mechanism, or that a
  equally strong or stronger mechanism for client authentication is
  used.

  Note that the long-term credential mechanism applies only to requests
  and cannot be used to authenticate indications; thus, indications in
  TURN are never authenticated.  If the server requires requests to be
  authenticated, then the server's administrator MUST choose a realm
  value that will uniquely identify the username and password
  combination that the client must use, even if the client uses
  multiple servers under different administrations.  The server's
  administrator MAY choose to allocate a unique username to each
  client, or MAY choose to allocate the same username to more than one
  client (for example, to all clients from the same department or
  company).  For each Allocate request, the server SHOULD generate a
  new random nonce when the allocation is first attempted following the
  randomness recommendations in [RFC4086] and SHOULD expire the nonce
  at least once every hour during the lifetime of the allocation.  To
  indicate that the server supports [I-D.ietf-tram-stunbis], the server
  prepends the NONCE attribute value with the "nonce cookie"
  (Section 9.2 of [I-D.ietf-tram-stunbis]).

  All requests after the initial Allocate must use the same username as
  that used to create the allocation, to prevent attackers from
  hijacking the client's allocation.  Specifically, if the server
  requires the use of the long-term credential mechanism, and if a non-
  Allocate request passes authentication under this mechanism, and if
  the 5-tuple identifies an existing allocation, but the request does
  not use the same username as used to create the allocation, then the
  request MUST be rejected with a 441 (Wrong Credentials) error.

  When a TURN message arrives at the server from the client, the server
  uses the 5-tuple in the message to identify the associated

Reddy, et al.          Expires December 29, 2019              [Page 23]
Internet-Draft                    TURN                        June 2019

  allocation.  For all TURN messages (including ChannelData) EXCEPT an
  Allocate request, if the 5-tuple does not identify an existing
  allocation, then the message MUST either be rejected with a 437
  Allocation Mismatch error (if it is a request) or silently ignored
  (if it is an indication or a ChannelData message).  A client
  receiving a 437 error response to a request other than Allocate MUST
  assume the allocation no longer exists.

  [I-D.ietf-tram-stunbis] defines a number of attributes, including the
  SOFTWARE and FINGERPRINT attributes.  The client SHOULD include the
  SOFTWARE attribute in all Allocate and Refresh requests and MAY
  include it in any other requests or indications.  The server SHOULD
  include the SOFTWARE attribute in all Allocate and Refresh responses
  (either success or failure) and MAY include it in other responses or
  indications.  The client and the server MAY include the FINGERPRINT
  attribute in any STUN-formatted messages defined in this document.

  TURN does not use the backwards-compatibility mechanism described in
  [I-D.ietf-tram-stunbis].

  TURN, as defined in this specification, supports both IPv4 and IPv6.
  IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-
  to-IPv4 relaying.  The REQUESTED-ADDRESS-FAMILY attribute allows a
  client to explicitly request the address type the TURN server will
  allocate (e.g., an IPv4-only node may request the TURN server to
  allocate an IPv6 address).  The ADDITIONAL-ADDRESS-FAMILY attribute
  allows a client to request the server to allocate one IPv4 and one
  IPv6 relay address in a single Allocate request.  This saves local
  ports on the client and reduces the number of messages sent between
  the client and the TURN server.

  By default, TURN runs on the same ports as STUN: 3478 for TURN over
  UDP and TCP, and 5349 for TURN over (D)TLS.  However, TURN has its
  own set of Service Record (SRV) names: "turn" for UDP and TCP, and
  "turns" for (D)TLS.  Either the DNS resolution procedures or the
  ALTERNATE-SERVER procedures, both described in Section 7, can be used
  to run TURN on a different port.

  To ensure interoperability, a TURN server MUST support the use of UDP
  transport between the client and the server, and SHOULD support the
  use of TCP, TLS-over-TCP and DTLS-over-UDP transports.

  When UDP or DTLS-over-UDP transport is used between the client and
  the server, the client will retransmit a request if it does not
  receive a response within a certain timeout period.  Because of this,
  the server may receive two (or more) requests with the same 5-tuple
  and same transaction id.  STUN requires that the server recognize
  this case and treat the request as idempotent (see

Reddy, et al.          Expires December 29, 2019              [Page 24]
Internet-Draft                    TURN                        June 2019

  [I-D.ietf-tram-stunbis]).  Some implementations may choose to meet
  this requirement by remembering all received requests and the
  corresponding responses for 40 seconds.  Other implementations may
  choose to reprocess the request and arrange that such reprocessing
  returns essentially the same response.  To aid implementors who
  choose the latter approach (the so-called "stateless stack
  approach"), this specification includes some implementation notes on
  how this might be done.  Implementations are free to choose either
  approach or choose some other approach that gives the same results.

  To mitigate either intentional or unintentional denial-of-service
  attacks against the server by clients with valid usernames and
  passwords, it is RECOMMENDED that the server impose limits on both
  the number of allocations active at one time for a given username and
  on the amount of bandwidth those allocations can use.  The server
  should reject new allocations that would exceed the limit on the
  allowed number of allocations active at one time with a 486
  (Allocation Quota Exceeded) (see Section 7.2), and should discard
  application data traffic that exceeds the bandwidth quota.

6.  Allocations

  All TURN operations revolve around allocations, and all TURN messages
  are associated with either a single or dual allocation.  An
  allocation conceptually consists of the following state data:

  o  the relayed transport address or addresses;

  o  the 5-tuple: (client's IP address, client's port, server IP
      address, server port, transport protocol);

  o  the authentication information;

  o  the time-to-expiry for each relayed transport address;

  o  a list of permissions for each relayed transport address;

  o  a list of channel to peer bindings for each relayed transport
      address.

  The relayed transport address is the transport address allocated by
  the server for communicating with peers, while the 5-tuple describes
  the communication path between the client and the server.  On the
  client, the 5-tuple uses the client's host transport address; on the
  server, the 5-tuple uses the client's server-reflexive transport
  address.  The relayed transport address MUST be unique across all
  allocations, so it can be used to uniquely identify the allocation.

Reddy, et al.          Expires December 29, 2019              [Page 25]
Internet-Draft                    TURN                        June 2019

  Both the relayed transport address and the 5-tuple MUST be unique
  across all allocations, so either one can be used to uniquely
  identify the allocation, and an allocation in this context can be
  either a single or dual allocation.

  The authentication information (e.g., username, password, realm, and
  nonce) is used to both verify subsequent requests and to compute the
  message integrity of responses.  The username, realm, and nonce
  values are initially those used in the authenticated Allocate request
  that creates the allocation, though the server can change the nonce
  value during the lifetime of the allocation using a 438 (Stale Nonce)
  reply.  For security reasons, the server MUST NOT store the password
  explicitly and MUST store the key value, which is a secure hash over
  the username, realm, and password (see Section 16.1.3 in
  [I-D.ietf-tram-stunbis]).

  The time-to-expiry is the time in seconds left until the allocation
  expires.  Each Allocate or Refresh transaction sets this timer, which
  then ticks down towards 0.  By default, each Allocate or Refresh
  transaction resets this timer to the default lifetime value of 600
  seconds (10 minutes), but the client can request a different value in
  the Allocate and Refresh request.  Allocations can only be refreshed
  using the Refresh request; sending data to a peer does not refresh an
  allocation.  When an allocation expires, the state data associated
  with the allocation can be freed.

  The list of permissions is described in Section 9 and the list of
  channels is described in Section 12.

7.  Creating an Allocation

  An allocation on the server is created using an Allocate transaction.

7.1.  Sending an Allocate Request

  The client forms an Allocate request as follows.

  The client first picks a host transport address.  It is RECOMMENDED
  that the client pick a currently unused transport address, typically
  by allowing the underlying OS to pick a currently unused port.

  The client then picks a transport protocol that the client supports
  to use between the client and the server based on the transport
  protocols supported by the server.  Since this specification only
  allows UDP between the server and the peers, it is RECOMMENDED that
  the client pick UDP unless it has a reason to use a different
  transport.  One reason to pick a different transport would be that
  the client believes, either through configuration or discovery or by

Reddy, et al.          Expires December 29, 2019              [Page 26]
Internet-Draft                    TURN                        June 2019

  experiment, that it is unable to contact any TURN server using UDP.
  See Section 3.1 for more discussion.

  The client also picks a server transport address, which SHOULD be
  done as follows.  The client uses one or more procedures described in
  [RFC8155] to discover a TURN server and uses the TURN server
  resolution mechanism defined in [RFC5928] and [RFC7350] to get a list
  of server transport addresses that can be tried to create a TURN
  allocation.

  The client MUST include a REQUESTED-TRANSPORT attribute in the
  request.  This attribute specifies the transport protocol between the
  server and the peers (note that this is NOT the transport protocol
  that appears in the 5-tuple).  In this specification, the REQUESTED-
  TRANSPORT type is always UDP.  This attribute is included to allow
  future extensions to specify other protocols.

  If the client wishes to obtain a relayed transport address of a
  specific address type then it includes a REQUESTED-ADDRESS-FAMILY
  attribute in the request.  This attribute indicates the specific
  address type the client wishes the TURN server to allocate.  Clients
  MUST NOT include more than one REQUESTED-ADDRESS-FAMILY attribute in
  an Allocate request.  Clients MUST NOT include a REQUESTED-ADDRESS-
  FAMILY attribute in an Allocate request that contains a RESERVATION-
  TOKEN attribute, for the reason that the server uses the previously
  reserved transport address corresponding to the included token and
  the client cannot obtain a relayed transport address of a specific
  address type.

  If the client wishes to obtain one IPv6 and one IPv4 relayed
  transport address then it includes an ADDITIONAL-ADDRESS-FAMILY
  attribute in the request.  This attribute specifies that the server
  must allocate both address types.  The attribute value in the
  ADDITIONAL-ADDRESS-FAMILY MUST be set to 0x02 (IPv6 address family).
  Clients MUST NOT include REQUESTED-ADDRESS-FAMILY and ADDITIONAL-
  ADDRESS-FAMILY attributes in the same request.  Clients MUST NOT
  include ADDITIONAL-ADDRESS-FAMILY attribute in a Allocate request
  that contains a RESERVATION-TOKEN attribute.  Clients MUST NOT
  include ADDITIONAL-ADDRESS-FAMILY attribute in a Allocate request
  that contains an EVEN-PORT attribute with the R bit set to 1.  The
  reason behind the restriction is if EVEN-PORT with R bit set to 1 is
  allowed with the ADDITIONAL-ADDRESS-FAMILY attribute, two tokens will
  have to be returned in success response and requires changes to the
  way RESERVATION-TOKEN is handled.

  If the client wishes the server to initialize the time-to-expiry
  field of the allocation to some value other than the default
  lifetime, then it MAY include a LIFETIME attribute specifying its

Reddy, et al.          Expires December 29, 2019              [Page 27]
Internet-Draft                    TURN                        June 2019

  desired value.  This is just a hint, and the server may elect to use
  a different value.  Note that the server will ignore requests to
  initialize the field to less than the default value.

  If the client wishes to later use the DONT-FRAGMENT attribute in one
  or more Send indications on this allocation, then the client SHOULD
  include the DONT-FRAGMENT attribute in the Allocate request.  This
  allows the client to test whether this attribute is supported by the
  server.

  If the client requires the port number of the relayed transport
  address be even, the client includes the EVEN-PORT attribute.  If
  this attribute is not included, then the port can be even or odd.  By
  setting the R bit in the EVEN-PORT attribute to 1, the client can
  request that the server reserve the next highest port number (on the
  same IP address) for a subsequent allocation.  If the R bit is 0, no
  such request is made.

  The client MAY also include a RESERVATION-TOKEN attribute in the
  request to ask the server to use a previously reserved port for the
  allocation.  If the RESERVATION-TOKEN attribute is included, then the
  client MUST omit the EVEN-PORT attribute.

  Once constructed, the client sends the Allocate request on the
  5-tuple.

7.2.  Receiving an Allocate Request

  When the server receives an Allocate request, it performs the
  following checks:

  1.  The server SHOULD require that the request be authenticated.
        The authentication of the request is optional to allow TURN
        servers provided by the local or access network to accept
        Allocation requests from new and/or guest users in the network
        who do not necessarily possess long term credentials for STUN
        authentication and its security implications are discussed in
        [RFC8155].  If the request is authenticated, the authentication
        MUST be done using the long-term credential mechanism of
        [I-D.ietf-tram-stunbis] unless the client and server agree to
        use another mechanism through some procedure outside the scope
        of this document.

  2.  The server checks if the 5-tuple is currently in use by an
        existing allocation.  If yes, the server rejects the request
        with a 437 (Allocation Mismatch) error.

Reddy, et al.          Expires December 29, 2019              [Page 28]
Internet-Draft                    TURN                        June 2019

  3.  The server checks if the request contains a REQUESTED-TRANSPORT
        attribute.  If the REQUESTED-TRANSPORT attribute is not included
        or is malformed, the server rejects the request with a 400 (Bad
        Request) error.  Otherwise, if the attribute is included but
        specifies a protocol other than UDP that is not supported by the
        server, the server rejects the request with a 442 (Unsupported
        Transport Protocol) error.

  4.  The request may contain a DONT-FRAGMENT attribute.  If it does,
        but the server does not support sending UDP datagrams with the
        DF bit set to 1 (see Section 14 and Section 15), then the server
        treats the DONT-FRAGMENT attribute in the Allocate request as an
        unknown comprehension-required attribute.

  5.  The server checks if the request contains a RESERVATION-TOKEN
        attribute.  If yes, and the request also contains an EVEN-PORT
        or REQUESTED-ADDRESS-FAMILY or ADDITIONAL-ADDRESS-FAMILY
        attribute, the server rejects the request with a 400 (Bad
        Request) error.  Otherwise, it checks to see if the token is
        valid (i.e., the token is in range and has not expired and the
        corresponding relayed transport address is still available).  If
        the token is not valid for some reason, the server rejects the
        request with a 508 (Insufficient Capacity) error.

  6.  The server checks if the request contains both REQUESTED-
        ADDRESS-FAMILY and ADDITIONAL-ADDRESS-FAMILY attributes.  If
        yes, then the server rejects the request with a 400 (Bad
        Request) error.

  7.  If the server does not support the address family requested by
        the client in REQUESTED-ADDRESS-FAMILY or is disabled by local
        policy, it MUST generate an Allocate error response, and it MUST
        include an ERROR-CODE attribute with the 440 (Address Family not
        Supported) response code.  If the REQUESTED-ADDRESS-FAMILY
        attribute is absent and the server does not support IPv4 address
        family, the server MUST include an ERROR-CODE attribute with the
        440 (Address Family not Supported) response code.  If the
        REQUESTED-ADDRESS-FAMILY attribute is absent and the server
        supports IPv4 address family, the server MUST allocate an IPv4
        relayed transport address for the TURN client.

  8.  The server checks if the request contains an EVEN-PORT attribute
        with the R bit set to 1.  If yes, and the request also contains
        an ADDITIONAL-ADDRESS-FAMILY attribute, the server rejects the
        request with a 400 (Bad Request) error.  Otherwise, the server
        checks if it can satisfy the request (i.e., can allocate a
        relayed transport address as described below).  If the server

Reddy, et al.          Expires December 29, 2019              [Page 29]
Internet-Draft                    TURN                        June 2019

        cannot satisfy the request, then the server rejects the request
        with a 508 (Insufficient Capacity) error.

  9.  The server checks if the request contains an ADDITIONAL-ADDRESS-
        FAMILY attribute.  If yes, and the attribute value is 0x01 (IPv4
        address family), then the server rejects the request with a 400
        (Bad Request) error.  Otherwise, the server checks if it can
        allocate relayed transport addresses of both address types.  If
        the server cannot satisfy the request, then the server rejects
        the request with a 508 (Insufficient Capacity) error.  If the
        server can partially meet the request, i.e. if it can only
        allocate one relayed transport address of a specific address
        type, then it includes ADDRESS-ERROR-CODE attribute in the
        response to inform the client the reason for partial failure of
        the request.  The error code value signaled in the ADDRESS-
        ERROR-CODE attribute could be 440 (Address Family not Supported)
        or 508 (Insufficient Capacity).  If the server can fully meet
        the request, then the server allocates one IPv4 and one IPv6
        relay address, and returns an Allocate success response
        containing the relayed transport addresses assigned to the dual
        allocation in two XOR-RELAYED-ADDRESS attributes.

  10.  At any point, the server MAY choose to reject the request with a
        486 (Allocation Quota Reached) error if it feels the client is
        trying to exceed some locally defined allocation quota.  The
        server is free to define this allocation quota any way it
        wishes, but SHOULD define it based on the username used to
        authenticate the request, and not on the client's transport
        address.

  11.  Also at any point, the server MAY choose to reject the request
        with a 300 (Try Alternate) error if it wishes to redirect the
        client to a different server.  The use of this error code and
        attribute follow the specification in [I-D.ietf-tram-stunbis].

  If all the checks pass, the server creates the allocation.  The
  5-tuple is set to the 5-tuple from the Allocate request, while the
  list of permissions and the list of channels are initially empty.

  The server chooses a relayed transport address for the allocation as
  follows:

  o  If the request contains a RESERVATION-TOKEN attribute, the server
      uses the previously reserved transport address corresponding to
      the included token (if it is still available).  Note that the
      reservation is a server-wide reservation and is not specific to a
      particular allocation, since the Allocate request containing the
      RESERVATION-TOKEN uses a different 5-tuple than the Allocate

Reddy, et al.          Expires December 29, 2019              [Page 30]
Internet-Draft                    TURN                        June 2019

      request that made the reservation.  The 5-tuple for the Allocate
      request containing the RESERVATION-TOKEN attribute can be any
      allowed 5-tuple; it can use a different client IP address and
      port, a different transport protocol, and even different server IP
      address and port (provided, of course, that the server IP address
      and port are ones on which the server is listening for TURN
      requests).

  o  If the request contains an EVEN-PORT attribute with the R bit set
      to 0, then the server allocates a relayed transport address with
      an even port number.

  o  If the request contains an EVEN-PORT attribute with the R bit set
      to 1, then the server looks for a pair of port numbers N and N+1
      on the same IP address, where N is even.  Port N is used in the
      current allocation, while the relayed transport address with port
      N+1 is assigned a token and reserved for a future allocation.  The
      server MUST hold this reservation for at least 30 seconds, and MAY
      choose to hold longer (e.g., until the allocation with port N
      expires).  The server then includes the token in a RESERVATION-
      TOKEN attribute in the success response.

  o  Otherwise, the server allocates any available relayed transport
      address.

  In all cases, the server SHOULD only allocate ports from the range
  49152 - 65535 (the Dynamic and/or Private Port range [Port-Numbers]),
  unless the TURN server application knows, through some means not
  specified here, that other applications running on the same host as
  the TURN server application will not be impacted by allocating ports
  outside this range.  This condition can often be satisfied by running
  the TURN server application on a dedicated machine and/or by
  arranging that any other applications on the machine allocate ports
  before the TURN server application starts.  In any case, the TURN
  server SHOULD NOT allocate ports in the range 0 - 1023 (the Well-
  Known Port range) to discourage clients from using TURN to run
  standard services.

      NOTE: The use of randomized port assignments to avoid certain
      types of attacks is described in [RFC6056].  It is RECOMMENDED
      that a TURN server implement a randomized port assignment
      algorithm from [RFC6056].  This is especially applicable to
      servers that choose to pre-allocate a number of ports from the
      underlying OS and then later assign them to allocations; for
      example, a server may choose this technique to implement the EVEN-
      PORT attribute.

Reddy, et al.          Expires December 29, 2019              [Page 31]
Internet-Draft                    TURN                        June 2019

  The server determines the initial value of the time-to-expiry field
  as follows.  If the request contains a LIFETIME attribute, then the
  server computes the minimum of the client's proposed lifetime and the
  server's maximum allowed lifetime.  If this computed value is greater
  than the default lifetime, then the server uses the computed lifetime
  as the initial value of the time-to-expiry field.  Otherwise, the
  server uses the default lifetime.  It is RECOMMENDED that the server
  use a maximum allowed lifetime value of no more than 3600 seconds (1
  hour).  Servers that implement allocation quotas or charge users for
  allocations in some way may wish to use a smaller maximum allowed
  lifetime (perhaps as small as the default lifetime) to more quickly
  remove orphaned allocations (that is, allocations where the
  corresponding client has crashed or terminated or the client
  connection has been lost for some reason).  Also, note that the time-
  to-expiry is recomputed with each successful Refresh request, and
  thus the value computed here applies only until the first refresh.

  Once the allocation is created, the server replies with a success
  response.  The success response contains:

  o  An XOR-RELAYED-ADDRESS attribute containing the relayed transport
      address.

  o  A LIFETIME attribute containing the current value of the time-to-
      expiry timer.

  o  A RESERVATION-TOKEN attribute (if a second relayed transport
      address was reserved).

  o  An XOR-MAPPED-ADDRESS attribute containing the client's IP address
      and port (from the 5-tuple).

      NOTE: The XOR-MAPPED-ADDRESS attribute is included in the response
      as a convenience to the client.  TURN itself does not make use of
      this value, but clients running ICE can often need this value and
      can thus avoid having to do an extra Binding transaction with some
      STUN server to learn it.

  The response (either success or error) is sent back to the client on
  the 5-tuple.

      NOTE: When the Allocate request is sent over UDP,
      [I-D.ietf-tram-stunbis] requires that the server handle the
      possible retransmissions of the request so that retransmissions do
      not cause multiple allocations to be created.  Implementations may
      achieve this using the so-called "stateless stack approach" as
      follows.  To detect retransmissions when the original request was
      successful in creating an allocation, the server can store the

Reddy, et al.          Expires December 29, 2019              [Page 32]
Internet-Draft                    TURN                        June 2019

      transaction id that created the request with the allocation data
      and compare it with incoming Allocate requests on the same
      5-tuple.  Once such a request is detected, the server can stop
      parsing the request and immediately generate a success response.
      When building this response, the value of the LIFETIME attribute
      can be taken from the time-to-expiry field in the allocate state
      data, even though this value may differ slightly from the LIFETIME
      value originally returned.  In addition, the server may need to
      store an indication of any reservation token returned in the
      original response, so that this may be returned in any
      retransmitted responses.

      For the case where the original request was unsuccessful in
      creating an allocation, the server may choose to do nothing
      special.  Note, however, that there is a rare case where the
      server rejects the original request but accepts the retransmitted
      request (because conditions have changed in the brief intervening
      time period).  If the client receives the first failure response,
      it will ignore the second (success) response and believe that an
      allocation was not created.  An allocation created in this matter
      will eventually timeout, since the client will not refresh it.
      Furthermore, if the client later retries with the same 5-tuple but
      different transaction id, it will receive a 437 (Allocation
      Mismatch), which will cause it to retry with a different 5-tuple.
      The server may use a smaller maximum lifetime value to minimize
      the lifetime of allocations "orphaned&(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-pim-join-attributes-for-lisp-05.txt. If any part of this review is inaccurate, please let us know.

We have a question about one of the actions requested in the IANA Considerations section of this document.

Upon approval of this document, we understand that there are two registry actions to complete.

First, in the PIM Join Attribute Types subregistry of the Protocol Independent Multicast (PIM) Parameters registry located at:

https://www.iana.org/assignments/pim-parameters/

two new types are to be registered as follows:

Value: [ TBD-at-Registration ]
Name: Transport Attribute
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Name: Receiver RLOC Attribute
Reference: [ RFC-to-be ]

We note that the author express a preference for the use of values 5 and 6 for these new attribute types.

Second, a new registry is to be created called the PIM Join/Prune Transport Types registry.

QUESTION -> Where should this new registry be located? Is it a new registry on the List of all IANA maintained protocol parameter registries or is it a subregistry of an existing registry? If it is a subregistry of an existing registry, in which registry will it be contained?

The new registry will be managed via IETF review as defined in RFC 5226. There are initial registrations in the new registry as follows:

Value Transport Type Reference
------+--------------------------------+--------------------
0 multicast [ RFC-to-be ]
1 unicast [ RFC-to-be ]
2-255 unassigned

We understand that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

mailing lists by 2016-10-24. 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 two PIM Join/Prune attributes that support the
  construction of multicast distribution trees where the root and
  receivers are located in different LISP sites.  These attributes
  allow the receiver site to select between unicast and multicast
  underlay transport and to convey the receiver ETR's RLOC address to
  the control plane of the root ITR.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pim-join-attributes-for-lisp/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-pim-join-attributes-for-lisp/ballot/


No IPR declarations have been submitted directly on this I-D.

==== AD Review of draft-ietf-pim-join-attributes-for-lisp-04 ====

I have a couple of Major comments (the most significant being the one related to the IANA registry for the Transport field).  I think all comments should be easy to resolve.  I do need you to please resolve (at least) the comment about the reference to I-D.portoles-lisp-eid-mobility before I start the IETF Last Call — you can update the text to resolve the other comments along with any last call comments.

Thanks!!

Alvaro.


Major:

M1. Section 4.1. (Transport Attribute Format) defines two values for the Transport field.  However, it is not completely clear whether this field is a bit-field or if it can include values from 0-255 (I'm assuming the latter).  Also, there is no guidance to IANA as to how other values should be managed (registry creation).  Please define the registry.

M2. Errors.  What should the receiver of the attributes do if the attributes contain an unsupported or unknown value (in the Transport, or even the Addr Family)?


Minor:

m1. Please (at least) add a reference to RFC5384 in the Security Considerations section.

m2. References

m2.1. RFC4601 has been Obsoleted by RFC7761.
m2.2. I-D.ietf-pim-hierarchicaljoinattr has been published as RFC7887.
m2.3. [AFI] is listed in the References section, but not un the text.
m2.4. I don't think that I-D.portoles-lisp-eid-mobility needs to be Normative reference.  Note that if it is, then the RFC Editor will hold publication of this document until that other one comes through (at at this point it still isn't a WG document).


Nits:

n1. s/URPF/uRPF

n2. There's a superfluous " "> " in 5.1.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Experimental. This is clearly stated and is the agreed upon status between the WG, chairs and AD.

(2) 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:
This document defines two PIM Join/Prune attributes that support the construction of multicast distribution
trees where the root and receivers are located in different LISP sites.  These attributes allow the receiver
site to select between unicast and multicast underlay transport and to convey the receiver ETR's RLOC
address to the control plane of the root ITR.

Working Group Summary:
There was several comments on the mailing list during the working group last call. Both the PIM and LISP
WG's were included. All comments have been addressed in this latest draft. We have complete consensus
for progressing this document.

Document Quality:

At least two vendors have indicated that they have implemented the functionality documented in this draft.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?
Mike McBride, PIM WG co-chair. Alvaro Retana is the Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

Mike McBride, PIM WG Co-Chair, is the document Shepherd. After thorough review by two working groups, the chairs, and the AD (Alvaro), the document is ready for publication. My Co-Chair, Stig Venaas, has also reviewed the document and agrees that the document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No, there were several comments made during the WGLC and all have been addressed.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No

(6) Describe any specific concerns or issues that the Document Shepherd has 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.

I have no concerns about this document.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Authors have confirmed no IPR

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR

(9) 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?

The consensus is solid. From two WG's. We had many individuals, from a variety of companies, indicate their support and offered comments.

(10) 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 publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No additional nits found.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

Not Applicable

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) 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 plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

Publication of this document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

Two new PIM Join/Prune attribute types need to be assigned.  Type 5 is being requested for the Transport Attribute.  Type 6 is being requested for the Receiver RLOC Attribute.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registry, only new attribute types from an existing registry

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

Not Applicable