Glen,

I was just sitting down to write to you, when this arrived. I will address my response here.

In APC-1480, a PricingIndication was intended to be acknowledged by a PricingConfirm. I realise that this is awkward, using the one message for more than one role, and is asymmetric. Annex G has the DescriptorUpdate, which serves a similar role, and is unacknowledged. I think that this is undesireable.

Even if the receiver asks for the updated descriptors of interest, it is not an unequivocal confirmation that the update was received. Several solutions are possible, some of them more kludgy than others.

Probably the cleanest method would be an additional message, DescriptorUpdateAck. [As a kludge, nonStandardConfirmation/Rejection witht the same sequenceNumber would suffice]. An optimisation of embedding the acknowledgement in the DescriptorRequest (if sent) could cause implementation problems in matching request with response.

One of the reasons put forward for the descriptorID mechanism is for caching. I think that to make this effective, a version number has to be incorporated into the descriptor identification mechanism. The version number allows the receiver to know if the cached information is still valid, or updated information must be requested. This could be a "last sequence number" or "last updated on" timestamp.

In merging Annex G and BEST, we would still be different in identifying templates. While Annex G would identify them with a descriptorID, I would identify them with a pattern. I feel that a pattern supports a hierarchical representation which allows the requestor to know what is in the template before it is requested, and to "drill-down" into the hierarchy structure of templates that are of interest.

Perhaps, pending discussion and decision, we could adopt the following, in DescriptorIDConfirmation and DescriptorUpdate, to allow qualification later?

SEQUENCE { descriptorID DescriptorID, ... }

This would allow version, pattern, or other information to be added later, something that would be difficult to impossible as these things stand.

I can't see how "drill-down" could be achieved in the current model. This means that a "flat" template model must be used. I haven't thought it thrugh yet, but adding a messageType of "sendDescriptorRequest" to RouteInformation, with "descriptors SEQUENCE OF DescriptorID OPTIONAL" might do it.

A question that comes to mind is: when would a descriptorID stay the same, and when would it change? I suspect that it would stay the same, if I alter the routeInfo, but change if I alter the pattern. If it changes, I must send out a delete for the old, and an add for the new. (I would think it imperative that this information not get lost.)

Editorially:

1.7.1:

* receiving descriptors from other border elements in response *to* general requests

1.7.1.2:

replace the words "statically configured" with "public" on line 1.

should the last paragraph allow the use of reliable transport (TCP) as an alternative to multiple messages for known endpoints?

1.7.1.3:

Fragmentation, and it's consequences are so variable, I doubt that it should be expressed in quite that way. Where and how are the listed numbers defined? I thought that the numbers were around 1500 octets for ethernet and 4000 bytes for FDDI.

1.8.2.2:

here, and in other places (1.7.1 and 1.7.1.1), does the "+" form part of the pattern? Are spaces permitted? How are private and public numbers differentiated (e.g. "For private 31*...")?

I'll now keep looking at the revised draft.

Douglas

At 16:38 15/12/98 -0700, Glen Freundlich wrote:

Dear colleagues,

I have placed review copies of Annex G in the Incoming directory of avc-site. The file annexg10c contains change marks from the last draft at the Torino meeting. The file annexg10n is the same document with no change marks.

I would appreciate any comments. Remember that the white drafts are due 19 December, so I plan to deliver Annex G on 18 December. I've compiled the ASN.1, but I would appreciate if someone else could also compile it as a sanity check.

Regards, Glen

-- Glen Freundlich ggf@lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA