Re: [Ace] Early warning: Rewrite of vanderstok-ace-coap-est

2017-11-12 Thread Hannes Tschofenig 
I disagree with you, Panos.

The normative reference, include among other things, 
[I-D.ietf-anima-bootstrapping-keyinfra].

As you will see with my write-up there is a way to offer EST over CoAP support 
without creating any such dependency. This will allow for generic uses of EST 
over CoAP, very much in spirit of the original spec EST spec

Ciao
Hannes

From: Panos Kampanakis (pkampana) [mailto:pkamp...@cisco.com]
Sent: 13 November 2017 12:14
To: Hannes Tschofenig; ace@ietf.org
Subject: RE: Early warning: Rewrite of vanderstok-ace-coap-est

Hi Hannes,
I think the current draft offers that. The BRSKI EST APIs are not mandatory to 
implement by any means. The bindings of just the EST (RFC7030) APIs explained 
in the doc would suffice. If you are saying that the current doc is too 
complicated, may that is something that can be addressed. If you are saying 
that there need to be two docs, one for pure EST and one for the BRSKI EST 
messages, maybe it makes sense. The list can chime in on that.
Looking forward to your draft.
Panos


From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Sunday, November 12, 2017 9:55 PM
To: ace@ietf.org
Subject: [Ace] Early warning: Rewrite of vanderstok-ace-coap-est

Hi all,

I had provided comments on the EST over CoAP document in the past. 
Unfortunately, my recommendations have been ignored and instead the document 
went into the other direction getting more complex with every draft version.

I need something that just allows me to run EST over CoAP - nothing more. As a 
result, I don't want profiling, don't want normative dependency to the ANIMA 
work, and don't want any relationship to IEEE 802.15.4. EST over CoAP should be 
able to run in a variety of context and over a number of networks.

For this purpose I am planning to write a new draft during this week that 
covers only one thing, namely carrying EST over CoAP without any profiling and 
without any new functionality.
If someone is interested in collaborating with me please drop me a note.

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Early warning: Rewrite of vanderstok-ace-coap-est

2017-11-12 Thread Panos Kampanakis (pkampana) 
Hi Hannes,
I think the current draft offers that. The BRSKI EST APIs are not mandatory to 
implement by any means. The bindings of just the EST (RFC7030) APIs explained 
in the doc would suffice. If you are saying that the current doc is too 
complicated, may that is something that can be addressed. If you are saying 
that there need to be two docs, one for pure EST and one for the BRSKI EST 
messages, maybe it makes sense. The list can chime in on that.
Looking forward to your draft.
Panos


From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Sunday, November 12, 2017 9:55 PM
To: ace@ietf.org
Subject: [Ace] Early warning: Rewrite of vanderstok-ace-coap-est

Hi all,

I had provided comments on the EST over CoAP document in the past. 
Unfortunately, my recommendations have been ignored and instead the document 
went into the other direction getting more complex with every draft version.

I need something that just allows me to run EST over CoAP - nothing more. As a 
result, I don't want profiling, don't want normative dependency to the ANIMA 
work, and don't want any relationship to IEEE 802.15.4. EST over CoAP should be 
able to run in a variety of context and over a number of networks.

For this purpose I am planning to write a new draft during this week that 
covers only one thing, namely carrying EST over CoAP without any profiling and 
without any new functionality.
If someone is interested in collaborating with me please drop me a note.

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Early warning: Rewrite of vanderstok-ace-coap-est

2017-11-12 Thread peter van der Stok 

Hi Hannes,

thanks for the early warning.
Looking forward to reading your version.
Let's see afterwards how we continue ( one document or two complementary 
documents)


cheerio,

peter

Hannes Tschofenig schreef op 2017-11-13 03:55:

Hi all,

I had provided comments on the EST over CoAP document in the past.
Unfortunately, my recommendations have been ignored and instead the
document went into the other direction getting more complex with every
draft version.

I need something that just allows me to run EST over CoAP - nothing
more. As a result, I don't want profiling, don't want normative
dependency to the ANIMA work, and don't want any relationship to IEEE
802.15.4. EST over CoAP should be able to run in a variety of context
and over a number of networks.

For this purpose I am planning to write a new draft during this week
that covers only one thing, namely carrying EST over CoAP without any
profiling and without any new functionality.

If someone is interested in collaborating with me please drop me a
note.

Ciao

Hannes

  IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose
the contents to any other person, use it for any purpose, or store or
copy the information in any medium. Thank you.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Early warning: Rewrite of vanderstok-ace-coap-est

2017-11-12 Thread Hannes Tschofenig 
Hi all,

I had provided comments on the EST over CoAP document in the past. 
Unfortunately, my recommendations have been ignored and instead the document 
went into the other direction getting more complex with every draft version.

I need something that just allows me to run EST over CoAP - nothing more. As a 
result, I don't want profiling, don't want normative dependency to the ANIMA 
work, and don't want any relationship to IEEE 802.15.4. EST over CoAP should be 
able to run in a variety of context and over a number of networks.

For this purpose I am planning to write a new draft during this week that 
covers only one thing, namely carrying EST over CoAP without any profiling and 
without any new functionality.
If someone is interested in collaborating with me please drop me a note.

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] some thoughts about vanderstok-ace-coap-est

2017-11-12 Thread Michael Richardson 
Michael Richardson  wrote:
> Section 4.1 provides for the process to start with a discovery
> operation.

...

>  REQ: GET /.well-known/core?rt=ace.est

> I can see the architectural reasons for why we do that, but I really
> have to ask why if we really really need this extra round trip.

Having read rfc6690 over again in order to implement this, I am now further
convinced that using this mechanism as a way to shorten the /.well-known/est
to something else is not entirely right.

I can see how a CoAP multicast to /.well-known/core?rt=ace.est ought to
return a list of hosts that support EST, and that EST ought to be returned in
a list of supported interfaces.

I'm less convinced that we ought to be using this mechanism to shorten
/.well-known/est to /est (why stop there? can't we go to /?)
It seems like maybe a 301-like (Moved Permantly) reply from
/.well-known/est/*, but CoAP doesn't have 301 codes





(weird to me that rfc6690 got published with an informative reference to CoAP,
as WIP... I guess the WG wanted to get it out. I wish our process would let
us update that reference to the RFC, because it confuses the rfc dependancy
process)

> The alternative is that we either have to use /.well-known/est, or that
> we wind up standardizing something (maybe /e) that isn't inside
> /.well-known.

> Can DTLS compression do better things for us instead?


> 2) DTLS and HelloVerifyRequest.

> SHOULD CoAP-EST servers always perform the HelloVerifyRequest state?
> Again, it's an extra round trip.  Always doing it would simplify the
> code paths on both ends.



> --
> Michael Richardson , Sandelman Software Works -=
> IPv6 IoT consulting =-




--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace