Subject: Re: [Anima] Adoption call for draft-liu-anima-grasp-api-06, ends Dec. 12, 2017

From: "Michael H. Behringer" <[email-masked]>
Date: Thu, 7 Dec 2017 10:07:43 +0100

I also support the adoption of this document.

Michael

On 29/11/2017 6:35 AM, Sheng Jiang wrote:
> During the IETF100, there was a consensus that draft-liu-anima-grasp-api
> is fully consistent with the current ANIMA charter, under the condition
> it intends to be an Informational document. After the meeting, the
> authors have updated the document. The current intended status is
> Informational. There was an adoption call on this document as a ANIMA
> working group document in the ANIMA session, IETF100. There were
> supports and no objection as far as chairs heard. As an official
> procedure, we now confirm the adoption in the ANIMA mailing list. This
> message starts a two-week adoption call on draft-liu-anima-grasp-api.
> 
>  
> 
>   Title:      Generic Autonomic Signaling Protocol Application Program
> Interface (GRASP API)
> 
>   Authors :   Liu, et al.
> 
>   Filename:   draft-liu-anima-grasp-api
> 
>   https://tools.ietf.org/html/draft-liu-anima-grasp-api-06
> 
>  
> 
> Please express your support or rejection. If you think this document
> should _not_ be adopted, please also explicitly indicate the reasons.
> 
>  
> 
> This adoption call will end on December 12, 2017.
> 
>  
> 
> Regards,
> 
>  
> 
> Sheng + Toerless
> 
>  
> 
> 
> 
> _______________________________________________
> Anima mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/anima
> 

-- 

Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
    and Software Engineering
Concordia University EV 3.185     email:[email-masked]
1455 de Maisonneuve Blvd. Westhttp://users.encs.concordia.ca/~bill 
<http://users.encs.concordia.ca/%7Ebill>
Montreal, Quebec Canada H3G 1M8

        References:

  * [Anima] Adoption call for draft-liu-anima-grasp-api-06, ends Dec.
    12, 2017
    <https://mailarchive.ietf.org/arch/msg/anima/zjl6w5PUysz-ZtZKQFU_Lu3dzDA>
    Sheng Jiang <[email-masked]>

---

From: Jéferson Campos Nobre <[email-masked]>
Date: Thu, 07 Dec 2017 16:44:35 +0000

Dear ANIMA.
I read and support the adoption of this document.
Best.
Jéferson

Em qui, 7 de dez de 2017 07:07, Michael H. Behringer <
[email-masked]> escreveu:

>     <
> https://mailarchive.ietf.org/arch/msg/anima/zjl6w5PUysz-ZtZKQFU_Lu3dzDA>
> [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Fri, 08 Dec 2017 12:03:41 -0500

I have no objection to the API document being adopted.

I generally believe that the IETF should do more API documents rather than
less. I do find some of the ways that the IEEE tries to define
protocols via APIs (such as 802.15.4) unreasonably obtuse, and I don't
propose to go that route.  The way we do APIs is just fine for me.

Having said that, I would like the WG to either:
  1) progress this document very quickly with the intention of doing
     a -bis in two or three years.

  2) progress this document very slowly such that it won't be done
     until two or three years.

I am saying this because I believe that there are simply unknown unknowns
here, which we will only discover once people attempt attempt to build
non-trivial ASAs.   I point to PFKEY as an example of an API that was
standardized too soon, never revised, and turned out to be inadequate for
real use.  It was never revised because each vendor had already made their
own extensions and deployed them, and did not want to change, and the people
who did those extensions were not part of the IETF process, so there was no
energy.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 9 Dec 2017 08:01:59 +1300

On 09/12/2017 06:03, Michael Richardson wrote:
..
> non-trivial ASAs. 

I completely agree. (In fact, the same is true of GRASP itself,
which can quite easily be extended if we discover that new message
types are needed.) In particular, there's the question of exactly
how much of the protocol state machine is hidden behind the API,
and how much can be controlled by the ASA itself. Only experience
will tell us the correct answer.

>      a -bis in two or three years.

I'd prefer that approach, to encourage ASA prototyping as soon as
possible.

(Well, that's what I've already done, and everyone is invited to
join in: https://github.com/becarpenter/graspy/blob/master/graspy.pdf)

   Brian