Re: [Anima] Ben Campbell's No Objection on draft-ietf-anima-reference-model-08: (with COMMENT)

[Ben Campbell]

""This section discusses a topic for further research” sounds good to me.

Thanks!

Ben.

> On Oct 25, 2018, at 2:47 PM, Michael H. Behringer 
>  wrote:
> 
> Ah, now I understand. Thanks for clarifying. Yes, we really used it as sort 
> of a "boiler plate" for topics that are not part of this phase of ANIMA work. 
> I guess we just introduced (informational)^2.
> 
> I'm happy to change that "boiler plate" text.  What about "This section 
> discusses a topic for further research".
> 
> I guess we can edit that when we get to the RFC Editor queue.
> 
> Michael
> 
> On 25/10/2018 17:18, Ben Campbell wrote:
>> Hi Michael,
>> 
>> My real concern is that “informational” is a term of art in the IETF, and 
>> the use of it to label “later phase” sections is a different use than that.
>> 
>> I will leave it to the authors to decide if that would be confusing to the 
>> target audience.
>> 
>> Thanks!
>> 
>> Ben.
>> 
>>> On Oct 25, 2018, at 3:43 AM, Michael H. Behringer 
>>>  wrote:
>>> 
>>> Hi Ben, thanks for your review!
>>> 
>>> Yes, we're a bit "verbose" with those topics. There was a consistent worry 
>>> all through our work to distinguish phase 1 and phase 2 work, and to not 
>>> let phase 2 work creep into phase 1. So we probably erred on the more 
>>> "explicit" wording, trying to make REALLY sure everybody understands what's 
>>> in scope for phase 1 or not.
>>> 
>>> Unless you have a real concern at some specific points, I would prefer to 
>>> not open those debates again. Yes, from a language point of view there is 
>>> redundancy, but at least we're being very clear.
>>> 
>>> Michael
>>> 
>>> 
>>> On 25/10/2018 04:33, Ben Campbell wrote:
> On Oct 24, 2018, at 8:10 PM, Brian E Carpenter 
>  wrote:
> 
> Hi Ben,
> 
> On 2018-10-25 12:08, Ben Campbell wrote:
> 
> 
>> Thanks for the work on this. I just have one editorial comment:
>> 
>> - Several sections describe themselves as being for "informational 
>> purposes".
>> Given that this is an informational document, isn't that true of all 
>> sections?
> Those sections are among the ones tagged (*) as per:
> 
>>>   Some topics are considered architecturally
>>>   in this document, but are not yet reflected in the implementation
>>>   specifications.  They are marked with an (*).
> Possibly the (*) is sufficient and the phrase you mention can be removed.
 I think that could help. Or alternatively, put a few extra words in the 
 (*) sections to remind people what it means :-)
 
 Thanks!
 
 Ben.
> 



signature.asc
Description: Message signed with OpenPGP
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Alissa Cooper's No Objection on draft-ietf-anima-reference-model-08: (with COMMENT)

[Michael H. Behringer]

On 25/10/2018 14:01, Alissa Cooper wrote:

--
COMMENT:
--

Since draft-ietf-anima-bootstrapping-keyinfra is a normative reference in this
document, IDevID seems like it should be as well. That is, it seems to be used
in a normative way in the same manner as the other normative references in this
document. If the document were not going to have any normative references, then
I think IDevID could be informative.


I have no problem moving IDevID to the normative references. In 
draft-ietf-anima-bootstrapping-keyinfra it is also in the normative 
section, so it would make sense to do this here as well.


Will do. (Unless I hear an objection)

Michael

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Spencer Dawkins' No Objection on draft-ietf-anima-reference-model-08: (with COMMENT)

[Michael H. Behringer]

  
  
On 25/10/2018 05:21, Spencer Dawkins at
  IETF wrote:


  
  Hi, Brian,

  
On Wed, Oct 24, 2018 at 10:16 PM Brian E
  Carpenter 
  wrote:

Hi
  Spencer,
  On 2018-10-25 15:54, Spencer Dawkins wrote:
  ...
  
  >
  --
  > COMMENT:
  >
  --
  > 
  > I'm confused here ...
  > 
  >   This document describes a first, simple,
  implementable phase of an
  >    Autonomic Networking solution.  It is expected
  that the experience
  >    from this phase will be used in defining updated
  and extended
  >    specifications over time.  Some topics are
  considered architecturally
  >    in this document, but are not yet reflected in the
  implementation
  >    specifications.  They are marked with an (*).
  > 
  > This is true now, but when this document is approved,
  will it be published
  > immediately (in which case, this is "truth decay",
  because it becomes less true
  > in the unchanging RFC every time a topic is reflected
  in implementation
  > specifications), or will it be held until all the
  (*)s are stable?
  
  The intention is to publish it now; the (*) items are FFS
  (for further study)
  in ITU or ISO speak. Should we make the last sentence
  explicit?:
  
  They are marked with an (*) and are intended for further
  study.



Thanks for the quick reply. 


I think that would be an improvement, but if it was
  clear that there's a reason to include them in a document
  being published now, that might be useful to include. 


If it's possible that some of these items might be
  significantly re-thought after further study, or even
  dropped, that seems unhelpful to a reader in five years. 

  

  


Thanks for the thoughts, Spencer. I sort of see that we might end up
with a situation where one of those (*) topics completely disappears
in 5 years, in which case it might indeed look odd. 

However, the RFCs come with a publication date. I think it'll then
be clear that 5 years ago, we were thinking in a different
direction, but that over time, the views changed. 

Personally, I find it very interesting to read in older documents
why certain things were done or not done, considered or not
considered, even if things change later on. 

So, I would trust the future reader to understand that this is
context at the time of publishing the RFC, and might have changed
since. And I think we could well live with that. My suggestion:
Leave. 

Michael


  

  


Spencer
 

     Brian
  

  

  


  


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Ben Campbell's No Objection on draft-ietf-anima-reference-model-08: (with COMMENT)

[Michael H. Behringer]

Ah, now I understand. Thanks for clarifying. Yes, we really used it as 
sort of a "boiler plate" for topics that are not part of this phase of 
ANIMA work. I guess we just introduced (informational)^2.


I'm happy to change that "boiler plate" text.  What about "This section 
discusses a topic for further research".


I guess we can edit that when we get to the RFC Editor queue.

Michael

On 25/10/2018 17:18, Ben Campbell wrote:

Hi Michael,

My real concern is that “informational” is a term of art in the IETF, and the 
use of it to label “later phase” sections is a different use than that.

I will leave it to the authors to decide if that would be confusing to the 
target audience.

Thanks!

Ben.


On Oct 25, 2018, at 3:43 AM, Michael H. Behringer 
 wrote:

Hi Ben, thanks for your review!

Yes, we're a bit "verbose" with those topics. There was a consistent worry all through 
our work to distinguish phase 1 and phase 2 work, and to not let phase 2 work creep into phase 1. 
So we probably erred on the more "explicit" wording, trying to make REALLY sure everybody 
understands what's in scope for phase 1 or not.

Unless you have a real concern at some specific points, I would prefer to not 
open those debates again. Yes, from a language point of view there is 
redundancy, but at least we're being very clear.

Michael


On 25/10/2018 04:33, Ben Campbell wrote:

On Oct 24, 2018, at 8:10 PM, Brian E Carpenter  
wrote:

Hi Ben,

On 2018-10-25 12:08, Ben Campbell wrote:



Thanks for the work on this. I just have one editorial comment:

- Several sections describe themselves as being for "informational purposes".
Given that this is an informational document, isn't that true of all sections?

Those sections are among the ones tagged (*) as per:


   Some topics are considered architecturally
   in this document, but are not yet reflected in the implementation
   specifications.  They are marked with an (*).

Possibly the (*) is sufficient and the phrase you mention can be removed.

I think that could help. Or alternatively, put a few extra words in the (*) 
sections to remind people what it means :-)

Thanks!

Ben.


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Ben Campbell's No Objection on draft-ietf-anima-reference-model-08: (with COMMENT)

[Ben Campbell]

Hi Michael,

My real concern is that “informational” is a term of art in the IETF, and the 
use of it to label “later phase” sections is a different use than that.

I will leave it to the authors to decide if that would be confusing to the 
target audience.

Thanks!

Ben.

> On Oct 25, 2018, at 3:43 AM, Michael H. Behringer 
>  wrote:
> 
> Hi Ben, thanks for your review!
> 
> Yes, we're a bit "verbose" with those topics. There was a consistent worry 
> all through our work to distinguish phase 1 and phase 2 work, and to not let 
> phase 2 work creep into phase 1. So we probably erred on the more "explicit" 
> wording, trying to make REALLY sure everybody understands what's in scope for 
> phase 1 or not.
> 
> Unless you have a real concern at some specific points, I would prefer to not 
> open those debates again. Yes, from a language point of view there is 
> redundancy, but at least we're being very clear.
> 
> Michael
> 
> 
> On 25/10/2018 04:33, Ben Campbell wrote:
>> 
>>> On Oct 24, 2018, at 8:10 PM, Brian E Carpenter 
>>>  wrote:
>>> 
>>> Hi Ben,
>>> 
>>> On 2018-10-25 12:08, Ben Campbell wrote:
>>> 
>>> 
 Thanks for the work on this. I just have one editorial comment:
 
 - Several sections describe themselves as being for "informational 
 purposes".
 Given that this is an informational document, isn't that true of all 
 sections?
>>> Those sections are among the ones tagged (*) as per:
>>> 
>   Some topics are considered architecturally
>   in this document, but are not yet reflected in the implementation
>   specifications.  They are marked with an (*).
>>> Possibly the (*) is sufficient and the phrase you mention can be removed.
>> I think that could help. Or alternatively, put a few extra words in the (*) 
>> sections to remind people what it means :-)
>> 
>> Thanks!
>> 
>> Ben.
> 



signature.asc
Description: Message signed with OpenPGP
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] Alissa Cooper's No Objection on draft-ietf-anima-reference-model-08: (with COMMENT)

[Alissa Cooper]

Alissa Cooper has entered the following ballot position for
draft-ietf-anima-reference-model-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-reference-model/



--
COMMENT:
--

Since draft-ietf-anima-bootstrapping-keyinfra is a normative reference in this
document, IDevID seems like it should be as well. That is, it seems to be used
in a normative way in the same manner as the other normative references in this
document. If the document were not going to have any normative references, then
I think IDevID could be informative.


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Ben Campbell's No Objection on draft-ietf-anima-reference-model-08: (with COMMENT)

[Michael H. Behringer]

Hi Ben, thanks for your review!

Yes, we're a bit "verbose" with those topics. There was a consistent 
worry all through our work to distinguish phase 1 and phase 2 work, and 
to not let phase 2 work creep into phase 1. So we probably erred on the 
more "explicit" wording, trying to make REALLY sure everybody 
understands what's in scope for phase 1 or not.


Unless you have a real concern at some specific points, I would prefer 
to not open those debates again. Yes, from a language point of view 
there is redundancy, but at least we're being very clear.


Michael


On 25/10/2018 04:33, Ben Campbell wrote:



On Oct 24, 2018, at 8:10 PM, Brian E Carpenter  
wrote:

Hi Ben,

On 2018-10-25 12:08, Ben Campbell wrote:



Thanks for the work on this. I just have one editorial comment:

- Several sections describe themselves as being for "informational purposes".
Given that this is an informational document, isn't that true of all sections?

Those sections are among the ones tagged (*) as per:


   Some topics are considered architecturally
   in this document, but are not yet reflected in the implementation
   specifications.  They are marked with an (*).

Possibly the (*) is sufficient and the phrase you mention can be removed.

I think that could help. Or alternatively, put a few extra words in the (*) 
sections to remind people what it means :-)

Thanks!

Ben.


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima