Subject: [ANCP] Guided tour of changes from -15 to -16

From: Tom Taylor <[email-masked]>
Date: Tue, 19 Apr 2011 18:56:17 -0400

Here is a section by section tour of the changes to satisfy IESG 
comments. Items introduced by NOTE are technical decisions that need 
particular review. I spotted some basically editorial changes I'd like 
to make before the document goes forward. These are noted as "To do" 
items. I'll submit a new version after the WG has had a chance to comment.

Section 1

- removed GSMPv3-related text
- added Section 1.1 Historical Note
- removed note on version 3.1 -> 3.2. See note on Section 3.1 below.
- removed note on "must", "should", "may" requirements language in old 
Section 1.1 Requirements Language. We agreed in Prague to use narrative 
descriptions for the relationship between the ANCP agent and the control 
application. In some spots I simply removed the text, in other places, 
truned it into narrative.

Section 3

- removed GSMPv3-related text

Section 3.1

- removed GSMPv3-related text. As agreed in Prague, we are going forward 
with Version only. The initial version is 50 (0x32), which means no 
change in the bits on the wire from what we had before.

Section 3.2

- added IPsec + IKEv2 to the indicated transport stack, with a pointer 
forward to Security Considerations for more detail.
- removed GSMPv3-related text
- clarified that use of destination port 6068 on the NAS was mandatory, 
as agreed in Prague
- added units (bytes) for Length

Section 3.5

- removed GSMPv3-related text

Section 3.5.1

- removed GSMPv3-related text
- merged Version/Sub-version back into Version, with an indication that 
this is the key field for distinguishing ANCP from GSMPv3 on the wire
- gave a complete description of all of the fields. Version, Timer, and 
Partition need ANCP-specific text. The other fields leading up to the 
capability-related stuff are basically copied from RFC 3292 Section 11.1.
- added a description of the Adjacency Update message. NOTE: this is 
truncated from the format shown in Section 9 of RFC 3292, since I got no 
objections from the list. Please review this decision.

- added a description of all of the fields
- editorial: gave length of the Identifier and Lenght fields in bits.

To do in this section in the next version:
-- capitalize an instance of "timer" in the description of the Timer field
-- add text to the description of the Partition ID indicating that it is 
negotiated by the adjacency protocol. The AN has the final decision, but 
will consider a request from the NAS. The value MUST be 0 if no 
partition is supported, and non-zero otherwise.

Section 3.5.2

Completely rewritten, folding in the negotiation procedures we had in 
the old text, except for differences in negotiation of Partition ID 
taken from Section 11.3 of RFC 3292.
- removed text talking about the dialogue between the ANCP agent and the 
control application

Section 3.5.2.1

New text. The description of the use of Adjacency Update here 
corresponds to the description in Section 11.5 of RFC 3292. NOTE: this 
is the only description of the procedure currently in the text, since I 
am not sure it will actually be implemented. If it will be, a more 
formal description should probably be added in a later section. The 
description does not currently include RFC 3292's warning that 
controller implementations without controller entity synchronisation 
SHOULD NOT use multiple controllers with a single switch partition. 
Comments welcome.

Sections 3.5.2.2 and 3.5.2.2.1

- mostly copied from RFC 3292 Sections 11.2 and 11.2.1
- replaced "Update peer identification" procedure with "Record adjacency 
state", which is specified in detail as part of the procedure for 
receiving a SYN message. Also added "Verify adjacency state" procedure.
- there is a slight alteration to the text on the timer in section 
3.5.2.2, raising the suggested value from 1 second to 25 seconds and 
noting that the use of TCP means it will usually expire only in ESTAB state.

Section 3.5.2.3 and subsections

New text.

- 3.5.2.3.1 is basically consistent with our previous negotiation text, 
except that settings of PType and Partition ID are based on 
interpretation of Section 11.3 of RFC 3292

- 3.5.2.3.2 opening paragraph is consistent with the old version 
negotiation procedure and the Section 11.2/RFC 3292 state table checks.

- recorded state includes peer identification (as directed by Section 
11.2/RFC 3292), own identification, and values of negotiated parameters. 
At this point, Version, Timer, and Capabilities are fully determined, 
but Partition ID is not fully settled until the SYNACK because the AN 
could accept the NAS request regardless of the AN's initial proposed value.

- NOTE the preference rule for PFlag given in 3.5.2.3.2 -- in case of 
conflict, the lower value wins. I guess this makes PFlag another 
negotiated value, fully determined once the peer's SYN or SYNACK is 
received. To do: add PFlag to the list of negotiated parameters in the 
overview and mention negotiation in the parameter description in 3.5.1.

Section 3.5.2.4 and subsections

New text.

- 3.5.2.4.1 relies on the adjacency state recorded when the SYN was 
received. Reviewing the matter of Partition ID, I've realized some text 
is missing in 3.5.2.3.1. If the NAS receives SYN before it sends its own 
SYN, it currently records adjacency state including the Partition ID 
decided by the AN, before the AN has received any proposal from the NAS. 
This is a case I didn't consider properly in the existing text.  There 
should be text saying that when the NAS sends the SYN, it MAY propose 
its own Partition ID value, even if the AN has proposed another in its 
SYN, provided partitions are supported at all. Basically the intention 
is that the AN sends its final decision in the SYNACK, possibly after 
reconsidering what it sent in the SYN.
- NOTE the halt procedure described at the end of 3.5.2.4.1 if the 
common set of capabilities is empty

- 3.5.2.4.2 is consistent with the above negotiating procedure. The 
Partition ID the NAS receives in a SYNACK can be different from what it 
sent in the SYN, so the NAS just accepts what it gets. NOTE the 
counterpart to the empty capability set halting procedure prescribed for 
the sender of the SYNACK. The text makes the sender of the SYNACK 
responsible for clearing the transport session.

To do
- add the indicated text to 3.5.2.3.1
- fix the "anothewr" typo at the end of 3.5.2.4.1

Section 3.5.2.5 and subsections

- 3.5.2.5.2, NOTE the text that tries to limit the ACK exchanges to one 
exchange per timer period. This is based on an interpretation of the 
footnotes from RFC 3292 in 3.5.2.2.1, but is new text.

Section 3.5.2.6 and subsections

- 3.5.2.6.1 NOTE new text on how to populate the non-identifier parts of 
the RSTACK. RFC 3292 doesn't give any real guidance.

- 3.5.2.6.2: only the sender really knows what went wrong, given the 
lack of space in the RSTACK for diagnostic information. Hence the 
contents of the RSTACK probably don't matter much.

Section 3.5.2.7

- NOTE: first paragraph starts out based on Section 11.4 of RFC 3292, 
but the current text directly contradicts RFC 3292 on the matter of what 
happens to connection state. It does reflect the existing contents of 
the ANCP draft. I'm raising this as a separate issue in an E-mail to the 
list.
- second paragraph was existing text except for the term "adjacency state".

To do: make the section consistent with RFC 3292 if the WG so decides.

Section 3.6

- dropped GSMPv3-related text
- merged Version and Sub-version into a single Version field
- renamed Code to Result Code to distinguish it from Code used in the 
adjacency protocol and Command Code. Change is carried through to the 
remainder of the document.

Section 3.6.1

- dropped GSMPv3-related text in this and subsequent subsections
- editorial: added length in bits to subsection headers naming fields
- dropped unnecessary reference to Section 3.1.

Section 3.6.1.1

- merged Version and Sub-version

Section 3.6.1.4

- more precise descrition of what should be logged when non-zero Result 
Codes are received
- dropped Result Code 7 (Invalid Partition ID)
- expanded recommended action for Result Code value 81.

To do:
-- change name for Result Code value in this section ("No error") to 
that in IANA Section 9.2.2  ("No result")
-- change values in this section to hexadecimal like those in Section 
9.2.2. Now that ANCP owns the registry we are free to do so.

Section 3.6.1.5

- replaced the existing procedure-oriented description (which is now 
thoroughly covered in the adjacency procedure description) with the 
statement that it contains the value negotiated for the adjacency

Section 3.6.1.6

- replaced "linearly" with "by 1" in describing incrementation of the 
Transaction ID

Section 3.6.1.7

- replaced SHOULD by MUST for the setting of the I Flag and SubMessage 
Number

Section 3.7

- replaced GSMPv3 with ANCP in opening sentence

Section 4.5

- added language tag at start of the error message, as announced on the list

To do: restore the terms "Error Message" and "Error Message Length".

Section 5

- added DHCP-related references

Section 5.1.2

- cleaned up wording of normative requirement (second paragraph, 
introducing bullets)

Sections 6.2.1 and 6.2.2

- dropped requirements relating to interaction with control application

Section 6.3

- dropped reference to GSMPv3
- simplified description of Label field, since it is no longer 
explicitly related to RFC 3292 description

To do: replace all of Port, Port Session Number, Event Sequence Number, 
and Label with a single 20 byte Unused field

Section 6.4.1

- changed text of first paragraph relating to interaction with the 
control application to narrative form
- dropped the final paragraph giving a requirement for interaction with 
the control application

Section 6.4.2

- changed interaction to narrative description (minor rewording)

Section 7.2.1

- dropped requirement on interaction between the ANCP agent and the 
control application

Section 7.2.2

- dropped requirement on interaction between the ANCP agent and the 
control application
- dropped GSMPv3-related text

To do: merge unused fields to simplify message description

Sections 8.2.1 and 8.2.2

- dropped requirements on interaction between the ANCP agent and the 
control application

Section 8.4.1

- changed interaction to narrative description (minor rewording)

Section 8.4.2

- changed interaction to narrative description (minor rewording)
- changed Result Code values to hexadecimal
- dropped mention of Result Code 0x3 in documentation of 0x500 Result Code

Section 8.5.1

Added back description of what a timeout value of 0 means. This got lost 
somewhere since version -09.

Section 9 and subsections

- rewrote most of the IANA actions and the summary, to establish 
independent ANCP registries
- created a joint GSMPv3/ANCP version registry to allow protocols to be 
distinguished based on Version
- noted that TCP port 6068 is now shared between GSMPv3 and ANCP
- NOTE the requirements for additions to the different registries, which 
have changed a bit from what I proposed on the list.

To do: see if I can rebalance the columns in the Capability Type table

Section 10

- noted that applicable requirements were copied from RFC 5713, to avoid 
a normative dependency on that Informational document

- added words to make clear up front that TLS was not the chosen solution

Remainder

- added acknowledgements
- added DHCP references and RFC 5226 (normative) regarding IANA 
considerations
- added normative language tag reference

Tom Taylor