Subject: [nsc] Explicitly identifying design analysis activities in the charter

From: <[email-masked]>
Date: Mon, 9 Sep 2013 11:33:44 +0200

Dear all,

I share both Joel's and Med's positions. I think the design analysis should be (1) explicitly mentioned as one of the activities conducted by the nsc WG in its charter and (2) documented in a chartered nsc WG document (be it the architecture document, as mentioned by Joel).

Cheers,

Christian.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Joel M. Halpern
Envoyé : lundi 9 septembre 2013 11:14
À : BOUCADAIR Mohamed IMT/OLN
Cc : [email-masked]; Ken Gray; Ron Parker
Objet : Re: [nsc] NSC Working Group Charter Proposal

I agree that capturing architecture / design rationale is very useful.
I don't want it in a separate from the architecture / design that it is supporting.

Also, we should be careful not to get to wrapped up in getting the perfect explanation of the decisions.  We need good explanations, not perfect ones with all the nuances.

Yours,
Joel

On 9/9/13 4:32 AM, [email-masked] wrote:
> Hi Ken,
>
> I still think there is a value to include an explicit charter item for 
> the design choice analysis document, at least for the following
> reasons:
>
> * The mailing list archives can be used to retrieve some of the 
> justifications for some design choices, but the result is not 
> guaranteed, the data is not structured, etc.
>
> * There are even some WGs that do not publish the meeting 
> minutes...and for those WGs it is hard to find when and why a design 
> choice was made.
>
> * IESG review may sometimes conflict with the WG consensus. Authors 
> are invited to engage in discussions to explain the motivations and 
> provide justification for the choices recorded in the draft. For the 
> context of the nsc effort, I do think that energy (time to resolve
> concerns) can be optimized if a formal tool was provided by the 
> working group: (1) simple specification document + (2) a companion 
> document that motivates the design choices and the candidates 
> solutions that were considered.
>
> * Given the aggressive proposed milestones for nsc, we need the work 
> to be focused so as to be able to produce the expected deliverables 
> while being open to any proposal that can put on the table.
>
> Cheers, Med
>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 9 Sep 2013 12:31:09 +0000

The risk, and a very real one, is that design analysis turns into design paralysis.

I support Joel's call for simplifying the doc set and not letting perfect be the enemy of good. In this, a focused small design analysis complementing key architectural decisions is useful, as adding color to the main docs.

Thanks,

-- Carlos.

On Sep 9, 2013, at 5:33 AM, [email-masked] wrote:

> _______________________________________________
> nsc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nsc

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Mon, 9 Sep 2013 12:34:34 +0000

+1

Sent from my iPhone

---

From: <[email-masked]>
Date: Mon, 9 Sep 2013 15:01:10 +0200

Hi Carlos,

If there is a risk for paralysis then the root causes are elsewhere ... not in the analysis itself. 

We all agree there is no perfect solution. That's not the point. The main point of the analysis is to explain the design choices and make sure we are not over specifying as per:

      "A protocol design is complete not when you can't think of any
      more things to add, but when you have removed everything you can
      and you can't see how to remove any more",

Cheers,
Med

>De : Carlos Pignataro (cpignata) [mailto:[email-masked]]
>Envoyé : lundi 9 septembre 2013 14:31
>À : JACQUENET Christian IMT/OLN
>Cc : Joel M. Halpern; BOUCADAIR Mohamed IMT/OLN; [email-masked]; Ken Gray;
>Ron Parker
>Objet : Re: [nsc] Explicitly identifying design analysis activities in the
>charter
>
>I support Joel's call for simplifying the doc set and not letting perfect
>be the enemy of good. In this, a focused small design analysis
>complementing key architectural decisions is useful, as adding color to the
>main docs.
>
>Thanks,
>
>-- Carlos.
>
>> I share both Joel's and Med's positions. I think the design analysis
>should be (1) explicitly mentioned as one of the activities conducted by
>the nsc WG in its charter and (2) documented in a chartered nsc WG document
>(be it the architecture document, as mentioned by Joel).
>>
>> Cheers,
>>
>> Christian.
>>
>> Also, we should be careful not to get to wrapped up in getting the
>perfect explanation of the decisions.  We need good explanations, not
>perfect ones with all the nuances.
>>
>> Yours,
>> Joel
>>
>___________________________________________________________________________
>______________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations
>confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>electroniques etant susceptibles d'alteration,
>> This message and its attachments may contain confidential or privileged
>information that may be protected by law;

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 9 Sep 2013 13:14:25 +0000

Hi, Med,

Thanks for the follow-up, please see inline.

On Sep 9, 2013, at 9:01 AM, <[email-masked]>
 wrote:

> We all agree there is no perfect solution.

I think that the best approach is to sparringly sprinkle analysis details when needed for a particularly important or contentious decision, inside another doc as per charter, and not peanut-butter (meaning adding unconditionally everywhere) design decision rationale or create a new doc.

> That's not the point. The main point of the analysis is to explain the design choices and make sure we are not over specifying as per:

I would not feel the need to explain every design choice. Only very small number of limited ones.

>      and you can't see how to remove any more",

"Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher.", Antoine de Saint Exupéry.

And RFC 1925. 

Indeed, that should be a guiding principle here.

Thanks,

-- Carlos.

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Mon, 9 Sep 2013 13:35:54 +0000

I agree wholeheartedly with Carlos that the best approach is to include
design analysis within individual documents where appropriate; it seems
unnecessary and overly complex to try and write a single analysis document
that details all valid and non-valid design choices as many will be
obvious such as the rejection of the notion of placing post-it's on the
backs of carrier pigeons to enable service chaining!

On 9/9/13 9:14 AM, "Carlos Pignataro (cpignata)" <[email-masked]>
wrote:

>I think that the best approach is to sparringly sprinkle analysis details
>when needed for a particularly important or contentious decision, inside
>another doc as per charter, and not peanut-butter (meaning adding
>unconditionally everywhere) design decision rationale or create a new doc.
>
>> That's not the point. The main point of the analysis is to explain the
>>design choices and make sure we are not over specifying as per:
>
>"Il semble que la perfection soit atteinte non quand il n'y a plus rien à
>ajouter, mais quand il n'y a plus rien à retrancher.", Antoine de Saint
>Exupéry.
>
>And RFC 1925. 
>
>>> The risk, and a very real one, is that design analysis turns into
>>>design
>>> paralysis.
>>> 
>>>> I don't want it in a separate from the architecture / design that it
>>>>is
>>> supporting.
>>>> 
>>>> Orange decline toute responsabilite si ce message a ete altere,
>>>>deforme
>>> ou falsifie. Merci.
>>>>

---

From: <[email-masked]>
Date: Wed, 11 Sep 2013 08:53:27 +0200

Hi Carlos,

Glad to see we are voicing for a simple design and avoid over-specifying.

Given the answers received so far: 
* there is a common agreement (some) design analysis is useful and will be needed
* the analysis can be included in the documents already listed in the charter proposal. 

That's fair and fine by me. 

Can we update the charter to reflect that outcome: i.e., update items (3) and (4) of the proposed charter to mention the design analysis?

Cheers,
Med 

>Envoyé : lundi 9 septembre 2013 15:14
>Cc : JACQUENET Christian IMT/OLN; Joel M. Halpern; [email-masked]; Ken Gray;
>Ron Parker