draft-ietf-sigtran-m3ua-implementors-guide-06.txt   draft-ietf-sigtran-m3ua-implementors-guide-07.txt 
Network Working Group Javier Pastor-Balbas Network Working Group Javier Pastor-Balbas
INTERNET-DRAFT Ericsson INTERNET-DRAFT Ericsson
Expires: April 2004 Expires: August 2004
Ken Morneault Ken Morneault
Cisco Systems Cisco Systems
October, 2003 February, 2004
M3UA Implementor's Guide M3UA Implementor's Guide
<draft-ietf-sigtran-m3ua-implementors-guide-06.txt> <draft-ietf-sigtran-m3ua-implementors-guide-07.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 15 skipping to change at page 2, line 15
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction.......................................................3 1. Introduction.......................................................3
1.1 Abbreviations.....................................................3 1.1 Abbreviations.....................................................3
2. Conventions........................................................3 2. Conventions........................................................3
3. Corrections to RFC3332.............................................3 3. Corrections to RFC3332.............................................3
3.1 Parameter Containing Subparameters with Padding Bytes..............3 3.1 Parameter Containing Subparameters with Padding Bytes..............3
3.2 Dynamic Registration Not Supported.................................4 3.2 Dynamic Registration Not Supported.................................4
3.3 Contents of User Protocol Data.....................................6 3.3 Contents of User Protocol Data.....................................6
3.4 Scope of Network Appearance........................................7 3.4 Scope of Network Appearance........................................7
3.5 Conditional RC parameter...........................................9 3.5 Conditional RC and NA parameters...................................9
3.6 Receiving REG for a RK already registered.........................11 3.6 Receiving REG for a RK already registered.........................11
3.7 Dynamic Registration Support for Alias Point Code.................14 3.7 Dynamic Registration Support for Alias Point Code.................15
3.8 Auditing procedure and congestion state...........................15 3.8 Auditing procedure and congestion state...........................16
3.9 Response to an ASPIA message......................................17 3.9 Response to an ASPIA message......................................18
3.10 INFO and DIAG parameter length...................................19 3.10 INFO and DIAG parameter length...................................20
3.11 IPSP stuff.......................................................21 3.11 IPSP stuff.......................................................21
3.12 Messages and Streams.............................................27 3.12 Messages and Streams.............................................28
3.13 ASP Id for IPSP communication....................................28 3.13 ASP Id for IPSP communication....................................28
3.14 n+k redundancy...................................................29 3.14 n+k redundancy...................................................30
3.15 Multiple Parameters of the Same Type in a Message................34 3.15 Multiple Parameters of the Same Type in a Message................35
3.16 Registered Routing Key State After Unexpected ASP Up Message.....35 3.16 Registered Routing Key State After Unexpected ASP Up Message.....35
3.17 Location of Network Appearance...................................36 3.17 Location of Network Appearance...................................36
3.18 Determination of Congestion Abatement When ASP Sends SCON........37 3.18 Determination of Congestion Abatement When ASP Sends SCON........37
3.19 Removing CIC and SSN from RK.....................................38 3.19 Removing CIC and SSN from RK.....................................38
3.20 ASP comes to ASP-ACTIVE state without full SS7 connectivity......45 3.20 ASP comes to ASP-ACTIVE state without full SS7 connectivity......45
3.21 NOTIFY messages are missing in Examples section..................47 3.21 NOTIFY messages are missing in Examples section..................47
3.22 Sending NTFY after sending ASP-UP-ACK............................56 3.22 Sending NTFY after sending ASP-UP-ACK............................56
3.23 Re-registration after failure....................................57 3.23 Re-registration after failure....................................57
3.24 No Configured AS Error...........................................58 3.24 No Configured AS Error...........................................58
3.25 NIF not available on SGP.........................................59 3.25 NIF not available on SGP.........................................60
3.26 Notify(ASP-Failure) usage clarification..........................60 3.26 Notify(ASP-Failure) usage clarification..........................61
3.27 Alignment of ASP Active message with ASP Inactive message........61 3.27 Alignment of ASP Active message with ASP Inactive message........62
4. Acknowledgements..................................................63 3.28 Invalid Version parameter explanation............................64
5. Authors' Addresses................................................63 4. Acknowledgements..................................................66
6. References........................................................64 5. Authors' Addresses................................................66
7. Changes Control...................................................64 6. References........................................................66
7.1 Changes from v00 to v01...........................................64 7. Changes Control...................................................67
7.2 Changes from v01 to v02...........................................64 7.1 Changes from v00 to v01...........................................67
7.3 Changes from v02 to v03...........................................64 7.2 Changes from v01 to v02...........................................67
7.4 Changes from v03 to v04...........................................65 7.3 Changes from v02 to v03...........................................67
7.5 Changes from v04 to v05...........................................65 7.4 Changes from v03 to v04...........................................67
7.6 Changes from v05 to v06...........................................66 7.5 Changes from v04 to v05...........................................68
7.6 Changes from v05 to v06...........................................68
7.7 Changes from v06 to v07...........................................69
1. Introduction 1. Introduction
This document contains a compilation of all defects found up until This document contains a compilation of all defects found up until
the publication date for the MTP3 User Adaptation Layer (M3UA) the publication date for the MTP3 User Adaptation Layer (M3UA)
[RFC3332]. These defects may be of an editorial or technical nature. [RFC3332]. These defects may be of an editorial or technical nature.
This document may be thought of as a companion document to be used in This document may be thought of as a companion document to be used in
the implementation of M3UA to clarify errors in the original M3UA the implementation of M3UA to clarify errors in the original M3UA
document. This document updates RFC3332 and text within this document. This document updates RFC3332 and text within this
document, where noted, supersedes the text found in RFC3332. Each document, where noted, supersedes the text found in RFC3332. Each
skipping to change at page 9, line 5 skipping to change at page 9, line 5
IMPLEMENTATION NOTE: For simplicity of configuration it may be IMPLEMENTATION NOTE: For simplicity of configuration it may be
desirable to use the same NA value across all nodes sharing a desirable to use the same NA value across all nodes sharing a
particular network context. particular network context.
3.4.3 Solution description 3.4.3 Solution description
The text is modified to show that NA has to be coordinated between AS The text is modified to show that NA has to be coordinated between AS
to SG. This correction also aligns this text with the NA definition to SG. This correction also aligns this text with the NA definition
in section 1.2 of the RFC. in section 1.2 of the RFC.
3.5 Conditional RC parameter 3.5 Conditional RC and NA parameters
3.5.1 Description of the problem 3.5.1 Description of the problem
Some optional parameters are not always optional. The text should be Some optional parameters are not always optional. The text should be
clear when conditionally optional parameters are mandatory. clear and set a new label to differentiate the behavior of these
parameters.
3.5.2 Text changes to the document 3.5.2 Text changes to the document
--------- ---------
Old text: (Section 3.3.1) Old text: (Section 3.3.1)
--------- ---------
3.3.1 Payload Data Message (DATA) 3.3.1 Payload Data Message (DATA)
The DATA message contains the SS7 MTP3-User protocol data, which is The DATA message contains the SS7 MTP3-User protocol data, which is
skipping to change at page 9, line 37 skipping to change at page 9, line 38
--------- ---------
New text: (Section 3.3.1) New text: (Section 3.3.1)
--------- ---------
3.3.1 Payload Data Message (DATA) 3.3.1 Payload Data Message (DATA)
The DATA message contains the SS7 MTP3-User protocol data, which is The DATA message contains the SS7 MTP3-User protocol data, which is
an MTP-TRANSFER primitive, including the complete MTP3 Routing Label. an MTP-TRANSFER primitive, including the complete MTP3 Routing Label.
The DATA message contains the following variable length parameters: The DATA message contains the following variable length parameters:
Network Appearance Optional Network Appearance Conditional
Routing Context Conditional Routing Context Conditional
Protocol Data Mandatory Protocol Data Mandatory
Correlation Id Optional Correlation Id Optional
--------- ---------
Old text: (Section 3.4.1) Old text: (Section 3.4.1)
--------- ---------
Network Appearance Optional
Routing Context Optional Routing Context Optional
--------- ---------
New text: (Section 3.4.1) New text: (Section 3.4.1)
--------- ---------
Network Appearance Conditional
Routing Context Conditional Routing Context Conditional
--------- ---------
Old text: (Section 3.4.2) Old text: (Section 3.4.2)
--------- ---------
Network Appearance Optional
Routing Context Optional Routing Context Optional
--------- ---------
New text: (Section 3.4.2) New text: (Section 3.4.2)
--------- ---------
Network Appearance Conditional
Routing Context Conditional Routing Context Conditional
--------- ---------
Old text: (Section 3.4.3) Old text: (Section 3.4.3)
--------- ---------
Network Appearance Optional
Routing Context Optional Routing Context Optional
--------- ---------
New text: (Section 3.4.3) New text: (Section 3.4.3)
--------- ---------
Network Appearance Conditional
Routing Context Conditional Routing Context Conditional
--------- ---------
Old text: (Section 3.4.4) Old text: (Section 3.4.4)
--------- ---------
Network Appearance Optional
Routing Context Optional Routing Context Optional
--------- ---------
New text: (Section 3.4.4) New text: (Section 3.4.4)
--------- ---------
Network Appearance Conditional
Routing Context Conditional Routing Context Conditional
--------- ---------
Old text: (Section 3.4.5) Old text: (Section 3.4.5)
--------- ---------
Network Appearance Optional
Routing Context Optional Routing Context Optional
--------- ---------
New text: (Section 3.4.5) New text: (Section 3.4.5)
--------- ---------
Network Appearance Conditional
Routing Context Conditional Routing Context Conditional
--------- ---------
Old text: (Section 3.4.6) Old text: (Section 3.4.6)
--------- ---------
Network Appearance Optional
Routing Context Optional Routing Context Optional
--------- ---------
New text: (Section 3.4.6) New text: (Section 3.4.6)
--------- ---------
Network Appearance Conditional
Routing Context Conditional Routing Context Conditional
3.5.3 Solution description 3.5.3 Solution description
Stating that the parameter is conditional implies that it is not Stating that these parameters are conditional implies that they are
either optional or mandatory. In the parameter description, the text not either optional or mandatory. In the parameter description, the
explains when Routing Context is mandatory and when optional. text explains when Routing Context and Network Appearance are
mandatory and when optional.
3.6 Receiving REG for a RK already registered 3.6 Receiving REG for a RK already registered
3.6.1 Description of the problem 3.6.1 Description of the problem
The RFC does not clearly specify what the SG should do when it The RFC does not clearly specify what the SG should do when it
receives a Registration Request for a Routing Key that has already receives a Registration Request for a Routing Key that has already
been registered. There are two scenarios to consider: the been registered. There are two scenarios to consider: the
registration request is a duplicate or the registration request registration request is a duplicate or it overlaps partially an
indicates a desire to modify the Routing Key already registered RK. Also there is a desire to include the
possibility of modifying a registered Routing Key.
The RFC does not clearly specify what the SG should do when it
receives a Registration Request for a Routing Key that has already
been registered. There are 3 scenarios to consider:
1. The registration request is an exact duplicate of a registered RK.
2. The registration request partially overlaps a registered RK.
3. The ASP is requesting to modify a registered RK.
3.6.2 Text changes to the document 3.6.2 Text changes to the document
--------- ---------
Old text: (Section 3.6.1) Old text: (Section 3.6.1)
--------- ---------
The format of the Routing Key parameter is as follows. The format of the Routing Key parameter is as follows.
0 1 2 3 0 1 2 3
skipping to change at page 13, line 20 skipping to change at page 13, line 39
| Destination Point Code | | Destination Point Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Indicators (optional) | | Service Indicators (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating Point Code List (optional) | | Originating Point Code List (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Circuit Range List (optional) | | Circuit Range List (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--------- ---------
Old text: (Section 4.4.1) Old text: (Section 3.6.2)
--------- ---------
Registration Status: 32-bit integer Registration Status: 32-bit integer
The Registration Result Status field indicates the success or the The Registration Result Status field indicates the success or the
reason for failure of a registration request. reason for failure of a registration request.
Its values may be: Its values may be:
0 Successfully Registered 0 Successfully Registered
1 Error - Unknown 1 Error - Unknown
skipping to change at page 13, line 42 skipping to change at page 14, line 10
3 Error - Invalid Network Appearance 3 Error - Invalid Network Appearance
4 Error - Invalid Routing Key 4 Error - Invalid Routing Key
5 Error - Permission Denied 5 Error - Permission Denied
6 Error - Cannot Support Unique Routing 6 Error - Cannot Support Unique Routing
7 Error - Routing Key not Currently Provisioned 7 Error - Routing Key not Currently Provisioned
8 Error - Insufficient Resources 8 Error - Insufficient Resources
9 Error - Unsupported RK parameter Field 9 Error - Unsupported RK parameter Field
10 Error - Unsupported/Invalid Traffic Handling Mode 10 Error - Unsupported/Invalid Traffic Handling Mode
--------- ---------
New text: (Section 4.4.1) New text: (Section 3.6.2)
--------- ---------
Registration Status: 32-bit integer Registration Status: 32-bit integer
The Registration Result Status field indicates the success or the The Registration Result Status field indicates the success or the
reason for failure of a registration request. reason for failure of a registration request.
Its values may be: Its values may be:
0 Successfully Registered 0 Successfully Registered
1 Error - Unknown 1 Error - Unknown
2 Error - Invalid DPC 2 Error - Invalid DPC
skipping to change at page 14, line 17 skipping to change at page 14, line 36
8 Error - Insufficient Resources 8 Error - Insufficient Resources
9 Error - Unsupported RK parameter Field 9 Error - Unsupported RK parameter Field
10 Error - Unsupported/Invalid Traffic Handling Mode 10 Error - Unsupported/Invalid Traffic Handling Mode
11 Error - Routing Key Change Refused 11 Error - Routing Key Change Refused
12 Error - Routing Key Already Registered 12 Error - Routing Key Already Registered
--------- ---------
Old text: (Section 4.4.1) Old text: (Section 4.4.1)
--------- ---------
None. If the SGP determines that a unique Routing Key cannot be created,
the SGP returns a Registration Response message to the ASP, with a
Registration Status of "Error - "Cannot Support Unique Routing" An
incoming signalling message received at an SGP should not match
against more than one Routing Key.
-------- --------
New text: (Section 4.4.1) New text: (Section 4.4.1)
--------- ---------
If the SGP determines that the requested RK partially, but not
exactly, matches an existing RK, and that an incoming signalling
message received at an SGP could possibly match both the requested
and the existing RK, the SGP returns a Registration Response message
to the ASP, with a Registration Status of "Error - "Cannot Support
Unique Routing. An incoming signalling message received at an SGP
should not match against more than one Routing Key.
If the SGP determines that the received RK was already registered, If the SGP determines that the received RK was already registered,
the SGP returns a Registration Response message to the ASP, fully and exactly, either statically or dynamically, by the sending
ASP, the SGP returns a Registration Response message to the ASP,
containing a Registration Result "Error - Routing Key Already containing a Registration Result "Error - Routing Key Already
Registered ". This error applies whether the Routing Key is Active or Registered ". This error applies whether the Routing Key is Active or
Inactive. Inactive. For this error code, RC field in Registration Response
message MUST be populated with the actual value of RC in SGP
corresponding to the specified RK in Registration Request message.
An ASP MAY modify an existing Routing Key by including a Routing An ASP MAY modify an existing Routing Key by including a Routing
Context parameter in the REG REQ. If the SGP determines that the Context parameter in the REG REQ. If the SGP determines that the
Routing Context applies to an existing Routing Key, the SG MAY adjust Routing Context applies to an existing Routing Key the SG MAY adjust
the existing Routing Key to match the new information provided in the the existing Routing Key to match the new information provided in the
Routing Key parameter. A Registration Response "ERR - Routing Key Routing Key parameter. A Registration Response "ERR - Routing Key
Change Refused" is returned if the SGP does not accept the Change Refused" is returned if the SGP does not accept the
modification of the Routing Key due to either it does not support the modification of the Routing Key due to either it does not support the
re-registration procedure or the specific RC does not exist. re-registration procedure or the specific RC does not exist.
Otherwise if the change is accepted, a Registration Response
If the change is accepted, a Registration Response "Successfully "Successfully Registered" is returned.
Registered" is returned.
3.6.3 Solution description 3.6.3 Solution description
By specifying the error code and this new text, the cases of The two cases, RK overlap and RK duplication, have been
receiving a duplicate registration request or modification to a differentiated and explained in detail. The latter will use a new
Routing Key are resolved. specific Error Code as defined above. Also the possibility of
modification to a Routing Key is included with the addition of a new
parameter in the REG REQ message and the corresponding explanation in
the procedures section.
3.7 Dynamic Registration Support for Alias Point Code 3.7 Dynamic Registration Support for Alias Point Code
3.7.1 Description of the problem 3.7.1 Description of the problem
There is no text regarding the support of an Alias Point Code There is no text regarding the support of an Alias Point Code
configuration in the dynamic registration of Routing Keys. configuration in the dynamic registration of Routing Keys.
3.7.2 Text changes to the document 3.7.2 Text changes to the document
--------- ---------
Old text: (Section 3.6.1) Old text: (Section 3.6.1)
--------- ---------
Destination Point Code: Destination Point Code:
skipping to change at page 18, line 48 skipping to change at page 19, line 35
When an ASP wishes to withdraw from receiving traffic within an AS, When an ASP wishes to withdraw from receiving traffic within an AS,
or the ASP wants to initiate the process of deactivation, the ASP or the ASP wants to initiate the process of deactivation, the ASP
sends an ASP Inactive message to the SGP or IPSP. sends an ASP Inactive message to the SGP or IPSP.
An ASP Inactive message MUST be always responded by the peer An ASP Inactive message MUST be always responded by the peer
(although other messages may be sent in the middle) in the following (although other messages may be sent in the middle) in the following
way: way:
- If the ASP Inactive message contains a RC parameter and the - If the ASP Inactive message contains a RC parameter and the
corresponding RK is defined (by either static configuration or corresponding RK is defined (by either static configuration or dynamic
dynamic registration), the peer MUST respond with an ASP registration), the peer MUST respond with an ASP Inactive Ack message.
Inactive Ack message.
- If the ASP Inactive message contains a RC parameter that is not - If the ASP Inactive message contains a RC parameter that is not
defined (by either static configuration or dynamic defined (by either static configuration or dynamic
registration), the peer MUST respond with an ERROR message with registration), the peer MUST respond with an ERROR message with
Error Code = "Invalid Routing Context". Error Code = "Invalid Routing Context".
- If the ASP Inactive message does not contain a RC parameter and - If the ASP Inactive message does not contain a RC parameter and
the RK is defined (by either static configuration or dynamic the RK is defined (by either static configuration or dynamic
registration), the peer must turn the ASP/IPSP to ASP-INACTIVE registration), the peer must turn the ASP/IPSP to ASP-INACTIVE
state in all the ASes it serves and MUST respond with an ASP state in all the ASes it serves and MUST respond with an ASP
skipping to change at page 57, line 45 skipping to change at page 58, line 28
--------- ---------
None. None.
--------- ---------
New text: (Section 4.4.1) New text: (Section 4.4.1)
--------- ---------
If an SGP determines that a received Routing Key is already If an SGP determines that a received Routing Key is already
registered, the SG returns a Registration Response message to the registered, the SG returns a Registration Response message to the
ASP, containing a Registration Result "Error routing key already ASP, containing a Registration Result "Error -
- routing key already
registered" and also the RC value previously assigned. registered" and also the RC value previously assigned.
3.23.3 Solution Description 3.23.3 Solution Description
By specifying that RC must be present in the response message when By specifying that RC must be present in the response message when
the routing key is registered, the problem is solved. the routing key is registered, the problem is solved.
3.24 No Configured AS Error 3.24 No Configured AS Error
3.24.1 Description of the problem 3.24.1 Description of the problem
During the third M3UA Plugtest there was a stated preference to allow During the third M3UA Plugtest there was a stated preference to allow
the SG to return Error ("no AS configured") in response to ASP Active the SG to return Error ("no AS configured") in response to ASP Active
(RC) when RC is not configured. (RC) when RC is not configured.
skipping to change at page 63, line 31 skipping to change at page 64, line 13
become active). become active).
- If the RC parameter is not included in the ASP Active message and - If the RC parameter is not included in the ASP Active message and
there are no RKs defined, the peer node SHOULD respond with and there are no RKs defined, the peer node SHOULD respond with and
ERROR message with the Error Code = "No configured AS for ASP". ERROR message with the Error Code = "No configured AS for ASP".
3.27.3 Solution Description 3.27.3 Solution Description
The text changes include similar wording in both sections. The text changes include similar wording in both sections.
3.28 Invalid Version parameter explanation
3.28.1 Description of the problem
There is a typo in the current RFC within the ERROR message sub-
section. "Invalid Stream identifier" parameter is explained twice
while the "Invalid Version" is not even mentioned.
3.28.2 Text changes to the document
---------
Old text: (Section 3.8.1)
---------
The Error message is used to notify a peer of an error event
associated with an incoming message. For example, the message type
might be unexpected given the current state, or a parameter value
might be invalid.
---------
New text: (Section 3.8.1)
---------
The Error message is used to notify a peer of an error event
associated with an incoming message. For example, the message type
might be unexpected given the current state, or a parameter value
might be invalid. Error messages MUST NOT be generated in response to
other Error messages.
---------
Old text: (Section 3.8.1)
---------
The "Invalid Stream Identifier" error is sent if a message is
received on an unexpected SCTP stream (e.g., a MGMT message was
received on a stream other than "0"). Error messages MUST NOT be
generated in response to other Error messages.
---------
New text: (Section 3.8.1)
---------
The "Invalid Version" error is sent if a message with an unsupported
version is received, the receiving end responds with an Error
message, indicating the version the receiving node supports and
notifies layer management.
3.28.3 Solution Description
The duplicated text has been substituted by an explanation of the
missing parameter "Invalid Version". Also, the last sentence next to
the duplicated text has been moved to the beginning of the section
3.8.1.
4. Acknowledgements 4. Acknowledgements
The authors would like to thank Lyndon Ong, Tolga Asveren, Brian The authors would like to thank Lyndon Ong, Tolga Asveren, Brian
Bidulock, Umesh Vats, Barry Nagelberg, Samuel Dur D. Jeyaseelan, Bidulock, Umesh Vats, Barry Nagelberg, Samuel Dur D. Jeyaseelan,
Antonio Canete, Kamesh Kaul, Vivek Toky and many others for their Antonio Canete, Kamesh Kaul, Vivek Toky and many others for their
valuable comments and suggestions. valuable comments and suggestions.
5. Authors' Addresses 5. Authors' Addresses
Javier Pastor-Balbas Javier Pastor-Balbas
skipping to change at page 67, line 5 skipping to change at page 69, line 21
- New section 3.24: there is a stated preference to allow the SG to - New section 3.24: there is a stated preference to allow the SG to
return Error ("no AS configured") in response to ASP Active (RC) return Error ("no AS configured") in response to ASP Active (RC)
when RC is not configured when RC is not configured
- New section 3.25: NIF section removed with the change to version 4 - New section 3.25: NIF section removed with the change to version 4
is included again but as an implementation note instead of is included again but as an implementation note instead of
normative text. normative text.
- New section 3.26: Clarifies the Notify(ASP-Failure) usage. - New section 3.26: Clarifies the Notify(ASP-Failure) usage.
7.7 Changes from v06 to v07
- In section 3.5: NA parameter is labeled as conditional.
- In section 3.6: reworked for clarification. Stating clearly the
difference of registering a duplicate RK versus an overlapping RK.
- New section 3.6: Solves a typo in the RFC removing a duplicated
paragraph and including the "invalid version" parameter explanation
in the ERROR message.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/