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

[Matt Mathis <[e-mail]>]

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 <[e-mail]> wrote:

> 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:
>
>> marcelo bagnulo braun <[e-mail]> wrote:
>> >
>> > 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>
>> )
>>
>>   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 <[e-mail]>
>> ______________________________**_________________
>> conex mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/**listinfo/conex<https://www.ietf.org/mailman/listinfo/conex>
>>
>
> ______________________________**______________________________**____
> Bob Briscoe,                                BT Innovate & Design
> ______________________________**_________________
> conex mailing list
> [e-mail]
> https://www.ietf.org/mailman/**listinfo/conex<https://www.ietf.org/mailman/listinfo/conex>
>