Subject: [core] What's to be presented to IESG in December?

From: Peter Bigot <[email-masked]>
Date: Fri, 29 Oct 2010 06:16:32 -0500

Two items raise this question:

- The appearance in coap-03 of the option values associated with the drafts
for coap-observe and coap-block
- A reference by Zack to how coap-observe simplifies caching of updatable
values

To the WG chairs: is it your expectation that coap-observe and coap-block
will be submitted to IESG in December along with the core CoAP document?

Peter

---

From: Zach Shelby <[email-masked]>
Date: Fri, 29 Oct 2010 14:28:04 +0300

On Oct 29, 2010, at 2:16 PM, Peter Bigot wrote:

> - The appearance in coap-03 of the option values associated with the drafts for coap-observe and coap-block

To be clear, I did this only as a temporary placeholder for those option type IDs to prevent collisions with people working with experimental options in other drafts. It is not meant to be interpreted that core-block and core-observe need to go to the IESG at precisely the same time (nor that those table values even need to be in the CoAP RFC). Now that they are both WG documents I think this is helpful to list them in the coap option table for now. 

In my personal opinion, it is most important that we concentrate on completing core-coap in December according to our charter. However, as core-block and core-observe are both part of the same charter work item, it would be a good goal to have them in stable shape at the same time. The chairs will surely give more information on the procedure. 

Peter, it seems you are worried about future innovation around CoRE? I wouldn't be. coap-block and coap-observe are two optional mechanisms that can be used with CoAP to fulfill basic application requirements we have. After this charter is fulfilled, we'll have the opportunity to re-charter the WG and to work on new things. This is a really good WG in my opinion and people have already identified useful future work, so I think we definitely should aim at re-chartering. 

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Peter Bigot <[email-masked]>
Date: Fri, 29 Oct 2010 07:37:27 -0500

I am worried that coap-observe sets precedence for using CoAP with multiple
responses to a single request.  I would be much less concerned, and might
support it technically, if it were changed to use a new method instead of a
200 response for its announcements, but I don't think that can be
satisfactorily designed and evaluated before December.  So, I object to
promotion of coap-observe in this time frame.

I feel coap-block is unnecessary if one can defer to alternative protocols
(and we will need Uri-Scheme back to enable that, which I very much want)
and therefore would not use it myself, but with a change that prevents
servers from introducing it in the response when Block doesn't appear in the
request---and pending a final review---I would support it for December.

I have not read the slice-related draft, but feel it is far too close to
December (five weeks) to go that way.

I'm not worried about innovation; I certainly expect to use a variety of
alternative solutions for observe, all at the application level.  But I
think the perception of the Internet community will be that CoRE working
group/IETF is implicitly recommending a specific approach by releasing it
along with the main document.  I don't plan to use it (or support it); my
impression from comments from others is that they wouldn't either; and we're
back at the dozen-incompatible-solutions situation, without the motivation
to unify them that absence of a formal IETF solution would provide.

That CoAP does not have provision for user-defined options and methods makes
it much harder to innovate compatibly, but that's another topic.

My motivation to volunteer to review ways to support observe in the base
protocol for discussion in Beijing was to help satisfy the charter
requirement for an observation capability.  My assessment is that observe is
a hard problem with a lot of application-influenced variables and
constraints, and there is too little experience with the protocol in real
applications and environments to formally recognize any single solution as
preferred at this time.  If the working group disagrees with this
assessment, or the charter requirement is to be met some other way such as
by proposing a specific solution, I don't see any need to do such a review
now.  It merely distracts from the job of getting something out in December.

Peter

On Fri, Oct 29, 2010 at 6:28 AM, Zach Shelby <[email-masked]> wrote:

> To be clear, I did this only as a temporary placeholder for those option
> type IDs to prevent collisions with people working with experimental options
> in other drafts. It is not meant to be interpreted that core-block and
> core-observe need to go to the IESG at precisely the same time (nor that
> those table values even need to be in the CoAP RFC). Now that they are both
> WG documents I think this is helpful to list them in the coap option table
> for now.
>
> In my personal opinion, it is most important that we concentrate on
> completing core-coap in December according to our charter. However, as
> core-block and core-observe are both part of the same charter work item, it
> would be a good goal to have them in stable shape at the same time. The
> chairs will surely give more information on the procedure.
>
> Peter, it seems you are worried about future innovation around CoRE? I
> wouldn't be. coap-block and coap-observe are two optional mechanisms that
> can be used with CoAP to fulfill basic application requirements we have.
> After this charter is fulfilled, we'll have the opportunity to re-charter
> the WG and to work on new things. This is a really good WG in my opinion and
> people have already identified useful future work, so I think we definitely
> should aim at re-chartering.
>
> Zach
>
> --

---

From: [email-masked]
Date: Fri, 29 Oct 2010 16:11:02 +0200

Hi Peter,

(and we will need Uri-Scheme back to enable that, which I very much want)
and therefore would not use it myself, but >with a change that prevents
servers from introducing it in the response when Block doesn't appear in
the request---and pending a final review---I would support it for December.

I think we should clearly expose the use cases where coap-block would be
necessary.
I see the following items from the previous emails.
1) transfer resources larger than the 1280-x limit
2) force small transactions due to limited available RAM for CoAP buffers
3) semantic segmentation of a large resource to be able to produce and
consume it incrementally. It also reduces the hardware (RAM, CPU)
requirements to process the resource.
4) optimize link-layer fragmentation and avoid network congestion

Protocols like tftp would probably only solve item 1) and maybe 4) within
limits.
Do you think other items are acceptable and need a solution ?

Regards,
Matthieu

             Peter Bigot                                                   
             <pab@peoplepowerc                                             
             o.com>                                                      A 
             Envoyé par :              Zach Shelby <[email-masked]>    
             core-bounces@ietf                                          cc 
             .org                      core <[email-masked]>                
                                                                     Objet 
                                       Re: [core] What's to be presented   
             29/10/2010 14:37          to IESG in December?                

                                                                           

I feel coap-block is unnecessary if one can defer to alternative protocols
(and we will need Uri-Scheme back to enable that, which I very much want)
and therefore would not use it myself, but with a change that prevents
servers from introducing it in the response when Block doesn't appear in
the request---and pending a final review---I would support it for December.

I'm not worried about innovation; I certainly expect to use a variety of
alternative solutions for observe, all at the application level.  But I
think the perception of the Internet community will be that CoRE working
group/IETF is implicitly recommending a specific approach by releasing it
along with the main document.  I don't plan to use it (or support it); my
impression from comments from others is that they wouldn't either; and
we're back at the dozen-incompatible-solutions situation, without the
motivation to unify them that absence of a formal IETF solution would
provide.

That CoAP does not have provision for user-defined options and methods
makes it much harder to innovate compatibly, but that's another topic.

My motivation to volunteer to review ways to support observe in the base
protocol for discussion in Beijing was to help satisfy the charter
requirement for an observation capability.  My assessment is that observe
is a hard problem with a lot of application-influenced variables and
constraints, and there is too little experience with the protocol in real
applications and environments to formally recognize any single solution as
preferred at this time.  If the working group disagrees with this
assessment, or the charter requirement is to be met some other way such as
by proposing a specific solution, I don't see any need to do such a review
now.  It merely distracts from the job of getting something out in
December.

Peter

      On Oct 29, 2010, at 2:16 PM, Peter Bigot wrote:

      > - The appearance in coap-03 of the option values associated with
      the drafts for coap-observe and coap-block

      To be clear, I did this only as a temporary placeholder for those
      option type IDs to prevent collisions with people working with
      experimental options in other drafts. It is not meant to be
      interpreted that core-block and core-observe need to go to the IESG
      at precisely the same time (nor that those table values even need to
      be in the CoAP RFC). Now that they are both WG documents I think this
      is helpful to list them in the coap option table for now.

      In my personal opinion, it is most important that we concentrate on
      completing core-coap in December according to our charter. However,
      as core-block and core-observe are both part of the same charter work
      item, it would be a good goal to have them in stable shape at the
      same time. The chairs will surely give more information on the
      procedure.

      Peter, it seems you are worried about future innovation around CoRE?
      I wouldn't be. coap-block and coap-observe are two optional
      mechanisms that can be used with CoAP to fulfill basic application
      requirements we have. After this charter is fulfilled, we'll have the
      opportunity to re-charter the WG and to work on new things. This is a
      really good WG in my opinion and people have already identified
      useful future work, so I think we definitely should aim at
      re-chartering.

      Zach

      --
      Zach Shelby, Chief Nerd, Sensinode Ltd.
      http://zachshelby.org  - My blog "On the Internet of Things"
      http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded
      Internet"
      Mobile: +358 40 7796297

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
______________________________________________________________________
_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 29 Oct 2010 11:03:33 -0600

On Oct 29, 2010, at 5:16 AM, Peter Bigot wrote:

> 
> To the WG chairs: is it your expectation that coap-observe and coap-block will be submitted to IESG in December along with the core CoAP document?

(WIth my chair hat on)

No - that was not my expectation. I would be surprised to see us have observer or block done at that point. I expected us to have the core-coap sent to IESG before the others. but the others well under way by the point core-coap goes to IESG. Which brings up a interesting question  for the group. When do we think that  draft-ietf-core-coap will be ready to send to IESG?

---

From: Zach Shelby <[email-masked]>
Date: Sun, 31 Oct 2010 23:02:10 +0200

Peter,

I stared a new thread on this technical comment. 

On Oct 29, 2010, at 3:37 PM, Peter Bigot wrote:

>  if it were changed to use a new method instead of a 200 response for its announcements

You missed some of the early mailing list fun in CoRE.... we've been through this several times before. This WG clearly *does not* want any new methods added to CoAP (we tried in first versions of CoRE subscription). This is the beauty of how simple coap-observe is... with just one lifetime option it enables observation in the transfer protocol. 

Now, it might really make sense to send a response code different than 200 for observe notifications. Something in the CoAP reserved range? Or would a new 2xx code make more sense as it could be weird to mix errors and success in the new 6xx range.

Zach

---

From: Zach Shelby <[email-masked]>
Date: Sun, 31 Oct 2010 23:34:12 +0200

On Oct 29, 2010, at 3:37 PM, Peter Bigot wrote:

> I feel coap-block is unnecessary if one can defer to alternative protocols (and we will need Uri-Scheme back to enable that, which I very much want)

I don't agree that this has anything to do with CoAP, which is a transfer protocol. If you want to provide a link to a different protocol, this should be done in your resource representation (just like an HTML link). Alternatively, the CoRE link format would allow you to include links to other protocols. I absolutely do not agree that CoAP should be returning some header option redirecting a client to use some other protocol. 

You have already indicated that you personally want to use TFTP for your application, fine. There is nothing in the current specifications that prevents you from doing that. The core-block draft is separate (and thus optional) from the base protocol exactly for that reason, some applications might not need that at all and some might use a different protocol for large transfers. In Maastricht the WG made the decision to keep optional features as separate drafts, the original plan was to include link-format, observe and block in the base specification.

That you do not need an optional feature is not a valid argument for CoRE not specifying one. We are designing for the whole M2M industry and Internet community here, not just your application. 

Zach

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 31 Oct 2010 22:36:59 +0100

On Oct 31, 2010, at 22:02, Zach Shelby wrote:

> it might really make sense to send a response code different than 200 for observe notifications

Or it might not.  What is so different about a second or third observe notification from an initial response?  Can't the client simly remember it got the first?

The status code might actually mean something.
E,g, we should at some point be able to do a 304, or maybe we want to use something like 226 (RFC 3229 -- this is just an example) instead of 200 later.  Let's not overload the status code with state machine state.

If we do need to transmit that state bit, we probably should put it into the subscription-lifetime option of the response, which is the other half of that state.
(Do we?)

Gruesse, Carsten

---

From: <[email-masked]>
Date: Sun, 31 Oct 2010 21:59:57 +0000

On 31 Oct 2010, at 21:34, Zach Shelby wrote:
> 
> You have already indicated that you personally want to use TFTP for your application, fine.

Why would anyone want to use tftp for _anything_?

puzzled,

L.

Lloyd Wood
[email-masked]
http://sat-net.com/L.Wood

---

From: Peter Bigot <[email-masked]>
Date: Sun, 31 Oct 2010 17:14:43 -0500

On Sun, Oct 31, 2010 at 4:34 PM, Zach Shelby <[email-masked]> wrote:

> > I feel coap-block is unnecessary if one can defer to alternative
> protocols (and we will need Uri-Scheme back to enable that, which I very
> much want)
>
> I don't agree that this has anything to do with CoAP, which is a transfer
> protocol. If you want to provide a link to a different protocol, this should
> be done in your resource representation (just like an HTML link).
> Alternatively, the CoRE link format would allow you to include links to
> other protocols. I absolutely do not agree that CoAP should be returning
> some header option redirecting a client to use some other protocol.
>

Could you clarify: are you saying that you don't want to require CoAP to
redirect to another protocol in this case, or that you don't want CoAP to
ever support redirection to another protocol?

That you do not need an optional feature is not a valid argument for CoRE
> not specifying one. We are designing for the whole M2M industry and Internet
> community here, not just your application.
>

Agreed.  The remainder of that sentence you quoted noted my willingness to
support coap-block if a particular technical issue was addressed.

Peter

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 31 Oct 2010 23:30:33 +0100

On Oct 29, 2010, at 14:37, Peter Bigot wrote:

> we will need Uri-Scheme back

I completely agree, if for a different reason:
Uri-scheme is needed to tell a multi-scheme proxy which scheme is actually needed.
E.g., a coap-to-http proxy has no idea whether the resource the client wants has a URI with scheme http or https.
A more general proxy might also support ftp (or even tftp).
Encoding the URI scheme into the port number of the proxy becomes a configuration nightmare quickly, unless we have a way to fully automate that configuration.

Gruesse, Carsten