Subject: [conex] WGLC for draft-ietf-conex-abstract-mech-03.txt

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 17 Nov 2011 02:52:21 +0100

This note issues the WGLC for draft-ietf-conex-abstract-mech-03.txt.
(http://www.ietf.org/id/draft-ietf-conex-abstract-mech-03.txt)

Please review the document and send comments before the 5th december.

Thanks, marcelo

---

From: John Leslie <[email-masked]>
Date: Thu, 17 Nov 2011 09:22:30 -0500

> (http://www.ietf.org/id/draft-ietf-conex-abstract-mech-03.txt)

   This LastCall seems way premature.

   abstract-mech as it stands depends heavily on ReECN, which is quite
outside our charter. I believe it should instead discuss mechanism
such as the Destination Option we seem to be headed to (unless someone
can convince me there are other mechanisms being seriously considered).

   YMMV, I suppose...

> Please review the document and send comments before the 5th december.

   I am willing to go into particulars; but that seems a bit pointless
until we get some consensus on whether ReECN is the proper primary
focus.

--
John Leslie <[email-masked]>

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 17 Nov 2011 18:50:09 +0000

John,

You've correctly pointed out a hang-over from when the doc started 
from re-ECN.

We intended to change it to start from destopt, before justifying a 
generalisation to abstract requirements. See the start of S.3
"   the experimental ConEx encoding chosen for IPv6
    [I-D.ietf-conex-destopt] had to make compromises on tunnelling.  The
    abstract encoding requirements that follow still stand despite this
    choice, in case experience shows these were not the best compromises
    to make."

However, you're right that we haven't toned down the re-ECN-based 
entry-point to the doc that follows just after this, before it again 
justifies generalising out to abstract requirements. Re-ECN does 
rather act as the anchor throughout the rest of S3.

Nonetheless, this is surely a wrinkle to remove, not something that 
causes everyone to have to stop in their tracks, stop the WGLC, press 
the PANIC button and prevent the sky from falling. I don't believe it 
leads to any /technical/ problems with the draft.

Bob

At 14:22 17/11/2011, John Leslie wrote:
>_______________________________________________
>conex mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/conex

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Matt Mathis <[email-masked]>
Date: Fri, 18 Nov 2011 13:40:58 -0800

John I don't understand your point at all.  -destopt- is an example of a
specific encoding that is consistent with abstract mech.

I actually have a different problem with that text: abstract mech is likely
to be done long before the final publication for -destopt- ready, which
means that it might be held up by dangling references.    At the last IETF
it was suggested that abstract mech needs to reference more of the current
ConEx documents.  However after re-reviewing the text I realized that to be
the best possible foundation for future work -abstract-mech- should
strongly site already completed (past) work but only hint at the future.
 And it certainly should not comment on documents that will not be
completed until after it is done.

(Part of the problem is the citation is really for the specific version of
the ID, but during the rfc editor process, citation will be (incorrectly)
updated to point to future drafts or even the final version of destopt, at
which point the text will no longer be correct, furthermore this process
will delay publication of abstract mech.)

Circular references between RFCs need to be deliberate and carefully
managed.

Sorry I didn't catch this earlier.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

On Thu, Nov 17, 2011 at 10:50 AM, Bob Briscoe <[email-masked]> wrote:

> John,
>
> You've correctly pointed out a hang-over from when the doc started from
> re-ECN.
>
> justifies generalising out to abstract requirements. Re-ECN does rather act
> as the anchor throughout the rest of S3.
>
> Nonetheless, this is surely a wrinkle to remove, not something that causes
> everyone to have to stop in their tracks, stop the WGLC, press the PANIC
> button and prevent the sky from falling. I don't believe it leads to any
> /technical/ problems with the draft.
>
>
> Bob
>
>
>> > This note issues the WGLC for draft-ietf-conex-abstract-**mech-03.txt.
>> > (http://www.ietf.org/id/draft-**ietf-conex-abstract-mech-03.**txt<http://www.ietf.org/id/draft-ietf-conex-abstract-mech-03.txt>
>> )
>>
>> ______________________________**_________________
>> conex mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/conex<https://www.ietf.org/mailman/listinfo/conex>
>>
>
> ______________________________**______________________________**____
> ______________________________**_________________
> conex mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/conex<https://www.ietf.org/mailman/listinfo/conex>
>