This new version addresses review comments from GenArt.
The totality of the changes is...
Section 2.1, paragraph 3:
OLD
The PKS MUST be preceded by an ERO subobject that
identifies the LSR that must expand the PKS, so the PKS will not
be encountered in ERO processing until the LSR that can process
it.
NEW
The PKS MUST be preceded by an ERO subobject that
identifies the LSR that must expand the PKS. This means that
(following the rules for ERO processing set out in [RFC3209])
the PKS will not be encountered in ERO processing until the ERO
is being processed by the LSR that is capable of correctly handling
the PKS.
Section 4:
OLD
The retrieval of the explicit path (the CPS) associated with a PKS
by a PCC is no different than any other path computation request
with the exception that the PCReq message MUST contain a PATH_KEY
object and the Path Key bit of the RP object MUST the set.
NEW
The retrieval of the explicit path (the CPS) associated with a PKS
by a PCC is no different than any other path computation request
with the exception that the PCReq message MUST contain a PATH_KEY
object and the Path Key bit of the RP object MUST the set. On
receipt of a PCRep containing a CPS, the requesting PCC SHOULD
use insert the CPS into the ERO that it will signal, in accordance
with local policy.
Section 5, third bullet point in first list:
s/DNS attacks/DoS attacks/
Section 6.1, paragraphs 2 and 3:
Para 2: yes. Should ref Section 2.1
Para 4: Should ref Section 2.1
References:
Update references
Adrian
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
