Subject: [core] Draft minutes from CORE WG interim call on June 4

From: Cullen Jennings <[email-masked]>
Date: Mon, 4 Jun 2012 09:13:47 -0600

CoRE Virtual Interim 2012-06-04

People on call:

Akbar, Angelo, Bert G, Carsten, Cullen, Dan Romascanu, Esko Dijk, Giri Mandyam, Guido, Kepeng, Klaus, Matthias, Salvatore, Zach 

* CoAP (59 min)

#230  Multiple Location options need to be processed as a unit   new      protocol defect   minor
	- Proposed solution in Section 6 of coap-misc-17

Long discussion on trade off between places we put complexity. Two uses brought up our location URI and grouping up set of options a proxy need to understand. 

Few people in favor of doing this, few people in favor of not doing it. 

Bert made the point made to resist the urge to introduce new functionality into the protocol that is only to deal with corner cases that perhaps a constrained protocol just does not need to do. We don’t need to do every corner case. 

Klaus: Made point that we can’t add end to end options that don’t need to be understood by intermediaries. 

Klaus: Other issue is that to process something like a Location part options, you have to process all of them or none of them. 

Proposal made to complete all the options we need to fully define an URI so we don’t have to add things later. 

Proposal made that we have a rule that “safe to forward without understanding options” have a number of something like option number mod 7 = 5. (of course more thought on 7 and 5 but you get the idea)

Proposal made to complete all the options we need to fully define an URI so we don’t have to add things later. 

Action going forward:

Would not add envelope now - might add later. 

In addition we allocate a few reserved number for use be later specs in the URI that have to be understood. Could use for port, host, etc later. 

Proposal made that we have a rule that “safe to forward without understanding options” have a number of something like option number mod 7 = 5. (of course more thought on 7 and 5 but you get the idea)

#201  Clarify use of retransmission window for duplicate detection   new      editorial   minor
	- Are we OK with Carsten's proposed solution in Section 7 of coap-misc-17?

People seemed ok with a MAX_TRANSMIT_WAIT of 93 seconds.

The key use of the EXCHANGE_LIFETIME is that after that time you can re-use a MSID 

Zach proposed we just use that number for when to timeout both cases. 

Point made that a large value will limit the speed and response of system. 

On previous call think number should be between 60 and 256 seconds. TCP is 120 seconds?

Kerry & Angelo pointed out - The larger we make this value, the more state we need to keep. 

Point made these calculations are different for confirmable and non confirmable messages. 

Matthias made point: If you have channel check time of 5 seconds and 20 hops, you need a long time. Base draft does not need to deal with this - it’s a case where you will onfigure devices with different values than default. 

Carsten: this is trade off between points Kerry & Angelo made and working in networks with larger latency

Proposal for draft:

We agree that range is 45 to 256 seconds. But the default should be - we need to choose one of ( 45, 93, 120, 248, other )

Draft will have the guidance for implementers and not try to take on all theory of how to pick this. 

Draft will point out lower number for NON messages.

#238  Proxy terminology   new      editorial   minor
	- Zach proposes "translating proxy"

Another proposal “cross protocol proxy”, “translating proxy”, “mapping proxy”, “coap-http proxy”, “cross proxy”

Carsten made point like to know what it is translating. 

Conclusion:

Go with term “cross proxy”

#214  Adopt vendor-defined option into core-coap   new      protocol enhancement   minor
	- Cullen had some push-back on this in the last interim meeting. Felt it was better to 
	make the registration more permissible instead. Needs more discussion.  

Carsten proposal:  reserved a option number that first 2 bytes of data is an code point that is allocated by IANA. reserver another options for 3 bytes, 1 byte, etc. Need two sets of these numbers - one for critical and one for elective. 

Action: Carsten will write up in COAP misc. 

#215  editorial issues around Congestion Control   new      editorial   major
	- Carsten has an open AP to propose changes in the ticket

-- tickets with a clear solution (not planning to discuss)

Action: Carsten is going to write up a proposal of text to fix this

Main issue is what is the rules around when you can start another discussion between two devices. 

Carsten view is that HTTP has gone to you can have any number of connections between two devices and it is a policy issue. 

* Observe (59 min)

-- check defined resolution and go ahead

#204  Introduce a minimal version of Pledge   new      protocol enhancement   major
	- Max-Age is OK as is
	- Proposal for Pledge in Section 4.3 of coap-misc-17

A few key contributors are still working on this and will send out their suggestion to list Real Soon Now. 

Zach: Max Age seems pretty good - don’t mess with it much. Also, pledge is pretty good so tweak it but don’t totally change. 

Action: Klaus will write up proposal and put in misc. 

#221  Occasionally sending CON is not just a security consideration   new      protocol defect   minor
	- Cullen proposed that we define a constant of at least once a day for this. OK?

Point out this may be too often - for example sensors that wake up once a week. 

Point made many applications need to do it much more frequently. 

Conclusion:
People seemed OK with this. Move forward with this change. 

#217  how fast must the observe clock be able to go?   new      protocol enhancement   major
	- Need to agree on how long a packet can be in the network (conclusion from last interim meeting notes)

Carsten: issue here is reordering - so one packet has latency 100 s and next is 1 second. 

Matthias: has to do with wrap around counter on observations. 

One proposal to use variable length counters and never have them wrap - just reset when the observation refreshes?

Matthias has a proposal in email.

Also issue of if one has a per device counter or per resource counter. 

One issue with Matthias proposal is need quiet period to reset the counter. 

Plan moving forward: we need people to write up a few proposal and send to list. 

Please send as a reply to the ticket on the list by next monday. 

Matthias send email to list 

-------------

Dan R introduced COMA list.
https://www.ietf.org/mailman/listinfo/coma

Congrats to all on Link Format getting approved. 

Next revision of CoAP out on June 12 - will get as much as we can in by then but won’t be everything.

Will do another version of drafts close to IETF deadline (July 16)

Carsten and Cullen to send email to list and consider another interim meeting on June 27

---

From: Barry Leiba <[email-masked]>
Date: Tue, 5 Jun 2012 05:30:03 -0400

Thanks very much for getting these posted tout de suite!

Barry, whose AD job is easier when this happens