Subject: [clue] #20: Action item vii: Rejecting Configure

From: "clue issue tracker" <[email-masked]>
Date: Sat, 13 Oct 2012 18:06:41 -0000

#20: Action item vii:  Rejecting Configure

 Action item vii from 19-20 Sept. 2012 interim.

 Andy: Add text to Framework for rejecting Configure

-- 
--------------------------------+----------------------------
 Reporter:  mary.ietf.barnes@…  |      Owner:  Andy Pepperell
     Type:  task                |     Status:  new
 Priority:  minor               |  Milestone:
Component:  framework           |    Version:
 Severity:  -                   |   Keywords:
--------------------------------+----------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/clue/trac/ticket/20>
clue <http://tools.ietf.org/wg/clue/>

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 14 Oct 2012 13:53:50 -0400

(as individual)

Perhaps it shouldn't overload Issue#20 on rejecting configure messages,
but ISTM there also needs to be a way to reject an advertisement.

There are more reasons for rejecting a config (e.g. it references an 
advertisement that is no longer remembered), but there are reasons in 
common between the two: e.g. syntactically incorrect message.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Wed, 17 Oct 2012 09:40:58 +1100

Hello Paul,

I agree that there needs to be a way to reject a configure especially if 
the framework allows the consumer to select configuration other than 
what is advertised.

With respect to the advertisement, what do we mean by "reject"? Are you 
thinking more of error handling (i.e. I can't parse what you sent me) or 
the consumer doesn't like the configurations being offerred?

Regards, Christian

On 15/10/2012 4:53 AM, Paul Kyzivat wrote:
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Oct 2012 19:21:58 -0400

> the framework allows the consumer to select configuration other than

The advertisement is like a menu for a take out restaurant, with a date 
on it. When you call to order, you can only order off the menu. You are 
expected to mention *which* menu you are ordering from, and you may be 
told that the menu you are ordering from is no longer supported. The 
only menu you can be sure is supported is the one that was most recently 
sent. (And it *could* happen that a new menu is "in the mail" and you 
have not yet received it. So your order may be refused and you will then 
need to wait for the new menu before you can order.) But based on 
discussion from the interim, there was a suggestion that the labels for 
items on the menu be maintained as stable across menu changes whenever 
possible. In such a case, it may be possible to honor an order on an old 
menu even though the old menu isn'available any longer, because the 
items are understood relative to the newer menu.

> the consumer doesn't like the configurations being offerred?

Having said all that above, if you send a configure that references an 
unknown/unremembered advertisement, then there may be need to reject it. 
Or if you send a configure referencing the most recent advertisement, 
but it references things not mentioned in that advertisement, then you 
would need to reject. Also if syntactically malformed.

There was some discussion of rejecting superficially valid 
configurations (based on the advertisement) as a way of imposing 
additional constraints indescribable in the advertisement. Personally I 
am opposed to that, because it can make the process of finding a valid 
configuration unsolvable. IMO any configuration that is consistent with 
the advertisement should be acceptable.

	Thanks,
	Paul