Subject: [manet] IDs presemted in Berlin

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 16 Aug 2013 12:59:03 +0000

I don't believe that the chairs have raised the WG adoption of the IDs I presented at Berlin.

Two of these, draft-dearlove-manet-olsrv2-rmpr-optimization and draft-dearlove-manet-nhdp-olsrv2-tlv-extension are intended for Standards Track, and as minor updates to NHDP and OLSRv2, which we would like to progress as fast as possible.

The third, draft-dearlove-manet-olsrv2-multitopology, we'd obvious have no problem with being adopted as a WG document, but it needs at least one more revision, which we intend to do as an author draft, so there isn't the same time pressure there. However of course we would like discussion any time from now.

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Fri, 16 Aug 2013 15:37:23 +0000

OK, so to the WG - do we have consensus to adopt these documents as working group docs? 

Regards,
Stan

---

From: Teco Boot <[email-masked]>
Date: Fri, 16 Aug 2013 18:00:01 +0200

Does draft-dearlove-manet-nhdp-olsrv2-tlv-extension introduce problems in a network with and without routers that implement this?
If so, I think we need some discussion first.

Teco

Op 16 aug. 2013, om 17:37 heeft Stan Ratliff (sratliff) <[email-masked]> het volgende geschreven:

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

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 16 Aug 2013 09:28:19 -0700

I am in favor of WG adoption of the two intended std tracks documents. As
Chris suggested, I would prefer to see another revision / some more
discussion of the MT document before adoption.

Ulrich

On Fri, Aug 16, 2013 at 8:37 AM, Stan Ratliff (sratliff) <[email-masked]
> wrote:

> > Two of these, draft-dearlove-manet-olsrv2-rmpr-optimization and
> draft-dearlove-manet-nhdp-olsrv2-tlv-extension are intended for Standards
> Track, and as minor updates to NHDP and OLSRv2, which we would like to
> progress as fast as possible.
> >
> > The third, draft-dearlove-manet-olsrv2-multitopology, we'd obvious have
> no problem with being adopted as a WG document, but it needs at least one
> more revision, which we intend to do as an author draft, so there isn't the
> same time pressure there. However of course we would like discussion any
> time from now.
> >
> > --
> > Christopher Dearlove

---

From: Christopher Dearlove <[email-masked]>
Date: Fri, 16 Aug 2013 17:43:41 +0100

I think my starting point with such a discussion would be who has an implementation? Yes, there are possible minor issues for implementations (though it's also possible for an implementation to need no changes at all). But the most pointless thing would be protecting (in a minor way) hypothetical implementations while people actually with them want this.

(I'm not saying those with them have all said they want this. I'm asking.)

--  
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)

---

From: Teco Boot <[email-masked]>
Date: Fri, 16 Aug 2013 19:05:51 +0200

May I read that there are problems?
If so, we cannot bring out a std track RFC followed up with something that can not interoperate with it. Or we mark the to_be RFC as obsolete. That's how it works.

Teco

PS1. you mentioned something about IESG and correctness...
PS2: I understand the motivation. discussion could be how to deal with it.

---

From: Christopher Dearlove <[email-masked]>
Date: Fri, 16 Aug 2013 18:14:01 +0100

You can read this that there are minor issues, which I wouldn't elevate to the level of problems.

Your comment on the inability to modify RFCs is just plain wrong. Was RFC 791 obsoleted when the TOS bits function was changed? No. Many more such examples could be given.

I'm actually not aware of anyone with an implementation who doesn't support this. Just in case not obvious, that includes me.

Does anyone with an implementation have an issue?

---

From: Teco Boot <[email-masked]>
Date: Fri, 16 Aug 2013 22:27:08 +0200

If anyone in the future writes code that complies with std track RFC, he/she may assume that it is compatible with any other implementation. If an update of that RFC will break compatibility, that RFC shall be obsoleted, I think. 

RFC 791 was 1981. Wording on TOS: "provides an indication", "are to be used to guide", "may". Remapping to DSCP is highly backwards compatible.

Did I say I'm against? I just want to know the issues / problems. At least they should be documented.

Teco

---

From: Christopher Dearlove <[email-masked]>
Date: Fri, 16 Aug 2013 21:37:29 +0100

I think you are quite wrong on the obsoleted point. Especially when we are talking changes to define what was previously undefined. Nothing defined has changed. Which is just like the TOS change.

But if you want to know what's changed, read the draft.

I'd be interested in hearing from people with implementations. If the bottom line is that there isn't anyone with an implementation who has a problem, I think worries over a hypothetical unwritten implementation are rather beside the point. Anyone coming to something new could always check the "updated by" bit.

---

From: Teco Boot <[email-masked]>
Date: Fri, 16 Aug 2013 22:58:14 +0200

I understand the change is documented.
My concerns are on what happens when different implementations are in same network. This has to be documented. Asking on mailing list is not enough.

Teco

---

From: Christopher Dearlove <[email-masked]>
Date: Fri, 16 Aug 2013 22:12:11 +0100

Have you read the draft?

---

From: Teco Boot <[email-masked]>
Date: Fri, 16 Aug 2013 23:36:31 +0200

Yes.

Teco

---

From: Henning Rogge <[email-masked]>
Date: Fri, 16 Aug 2013 23:41:19 +0200

If I understand the draft right we have the following situations:

1) an "old" implementation should interop with a "new" one without any
extensions easily.
2) an "old" implementation might just drop messages from a "new"
implementation which use an extension

Henning Rogge

-- 
We began as wanderers, and we are wanderers still. We have lingered
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan

---

From: Teco Boot <[email-masked]>
Date: Sat, 17 Aug 2013 09:36:51 +0200

Can I read this as:

1) an implementations that did not implement this new specification might drop these new messages and therefore is not compatible
2) an implementations that did not implement this new specification might accept these new messages and therefore is compatible

"old" of "new" is not important. It is about stability of the standard. We have to stop incremental changes that are not backwards compatible. Or step to new version or similar tag.

Teco

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 27 Aug 2013 09:40:13 +0000

I thought I'd replied to this, but can't see on list. I think your characterisation of this whole issue is wrong.

Currently, there is no specification what to do when seeing an unknown value. This defines one. Of course with no specification, people can do anything (including dropping the message). That's undesirable, let's fix it.

As for the sacrosanctness of the specification, let's be real. How many implementations actually are there yet? Is there anyone with one who finds this other than a positive thing?

-----Original Message-----
From: Teco Boot [mailto:[email-masked]] 
Sent: 17 August 2013 08:37
To: Henning Rogge
Cc: Christopher Dearlove; Dearlove, Christopher (UK); [email-masked] List; Joe Macker ([email-masked]); Thomas Heide Clausen ([email-masked]); Stan Ratliff (sratliff)
Subject: Re: [manet] IDs presemted in Berlin

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Can I read this as:

Teco

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 27 Aug 2013 20:06:53 +1000

Hi Co-Chair,

I don't agree to adopt any draft only after reviewed by WG and getting
answers/discussions of all questions of the WG related. If that is done
then I have no objection.

AB

On Sat, Aug 17, 2013 at 1:37 AM, Stan Ratliff (sratliff) <[email-masked]

---

From: Teco Boot <[email-masked]>
Date: Tue, 27 Aug 2013 13:03:02 +0200

My concerns are about struggle getting away from experimental status.

If the intention is that the RFC have to implement something what was not written down that well, I think an errata would work. Then the new draft just has to specify how to use it.

If the new RFC breaks compatibility, I wonder if this is worth the effort.

Teco

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 27 Aug 2013 12:16:01 +0000

The point of the new draft is to enable extensions more cleanly, and that's used in the multitopology draft, it's not just change for change's sake. (But neither do I expect MT is the only case.)

It's not errata, so that is not an appropriate approach. (One might slip in part of it as errata, though even that would not be appropriate in my view.)

Some of us who have implementations think this is worth the effort, or we wouldn't be doing this. Do you, or are you just second guessing those who do?

-----Original Message-----
From: Teco Boot [mailto:[email-masked]] 
Sent: 27 August 2013 12:03
To: Dearlove, Christopher (UK)
Cc: Henning Rogge; Christopher Dearlove; [email-masked] List; Joe Macker ([email-masked]); Thomas Heide Clausen ([email-masked]); Stan Ratliff (sratliff)
Subject: Re: [manet] IDs presemted in Berlin

Teco

---

From: Teco Boot <[email-masked]>
Date: Tue, 27 Aug 2013 17:08:32 +0200

I'm mainly on the user side of the table. I want to be sure stuff that is compliant with an RFC is compatible with whatever other implementation. That's why we have RFCs, isn't it?

Teco

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 27 Aug 2013 19:05:49 -0700

I don't see any issues with the approach of the TLV extension draft. Like
Chris said, it specifies a behavior that was previously unspecified (and
thus undefined).
On the procedural question, the IETF has introduced "updates RFCxxxx" for a
good reason, and I think this particular case is such a case.

Ulrich

On Tue, Aug 27, 2013 at 2:40 AM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> I thought I'd replied to this, but can't see on list. I think your
> characterisation of this whole issue is wrong.
>
> Currently, there is no specification what to do when seeing an unknown
> value. This defines one. Of course with no specification, people can do
> anything (including dropping the message). That's undesirable, let's fix it.
>
> As for the sacrosanctness of the specification, let's be real. How many
> implementations actually are there yet? Is there anyone with one who finds
> this other than a positive thing?
>
> --
> Christopher Dearlove
> Cc: Christopher Dearlove; Dearlove, Christopher (UK); [email-masked]; Joe Macker (
> [email-masked]); Thomas Heide Clausen (
> [email-masked]); Stan Ratliff (sratliff)
> 1) an implementations that did not implement this new specification might
> drop these new messages and therefore is not compatible
> 2) an implementations that did not implement this new specification might
> accept these new messages and therefore is compatible
>
> "old" of "new" is not important. It is about stability of the standard. We
> have to stop incremental changes that are not backwards compatible. Or step
> to new version or similar tag.
>
> Teco
>
> >> Op 16 aug. 2013, om 23:12 heeft Christopher Dearlove <
> [email-masked]> het volgende geschreven:
> >>
> >>> Have you read the draft?
> >>>
> >>> --
> >>> Christopher Dearlove
> >>>> My concerns are on what happens when different implementations are in
> same network. This has to be documented. Asking on mailing list is not
> enough.
> >>>>
> >>>> Teco
> >>>>
> >>>> Op 16 aug. 2013, om 22:37 heeft Christopher Dearlove <
> [email-masked]> het volgende geschreven:
> >>>>
> >>>>> I think you are quite wrong on the obsoleted point. Especially when
> we are talking changes to define what was previously undefined. Nothing
> defined has changed. Which is just like the TOS change.
> >>>>>
> >>>>> I'd be interested in hearing from people with implementations. If
> the bottom line is that there isn't anyone with an implementation who has a
> problem, I think worries over a hypothetical unwritten implementation are
> rather beside the point. Anyone coming to something new could always check
> the "updated by" bit.
> >>>>>
> >>>>>
> >>>>>> If anyone in the future writes code that complies with std track
> RFC, he/she may assume that it is compatible with any other implementation.
> If an update of that RFC will break compatibility, that RFC shall be
> obsoleted, I think.
> >>>>>>
> >>>>>> RFC 791 was 1981. Wording on TOS: "provides an indication", "are to
> be used to guide", "may". Remapping to DSCP is highly backwards compatible.
> >>>>>>
> >>>>>> Op 16 aug. 2013, om 19:14 heeft Christopher Dearlove <
> [email-masked]> het volgende geschreven:
> >>>>>>
> >>>>>>> Your comment on the inability to modify RFCs is just plain wrong.
> Was RFC 791 obsoleted when the TOS bits function was changed? No. Many more
> such examples could be given.
> >>>>>>>
> >>>>>>> I'm actually not aware of anyone with an implementation who
> doesn't support this. Just in case not obvious, that includes me.
> >>>>>>>
> >>>>>>>> If so, we cannot bring out a std track RFC followed up with
> something that can not interoperate with it. Or we mark the to_be RFC as
> obsolete. That's how it works.
> >>>>>>>>
> >>>>>>>> Teco
> >>>>>>>>
> >>>>>>>> Op 16 aug. 2013, om 18:43 heeft Christopher Dearlove <
> [email-masked]> het volgende geschreven:
> >>>>>>>>
> >>>>>>>>> I think my starting point with such a discussion would be who
> has an implementation? Yes, there are possible minor issues for
> implementations (though it's also possible for an implementation to need no
> changes at all). But the most pointless thing would be protecting (in a
> minor way) hypothetical implementations while people actually with them
> want this.
> >>>>>>>>>
> >>>>>>>>>> Does draft-dearlove-manet-nhdp-olsrv2-tlv-extension introduce
> problems in a network with and without routers that implement this?
> >>>>>>>>>> Op 16 aug. 2013, om 17:37 heeft Stan Ratliff (sratliff) <
> [email-masked]> het volgende geschreven:
> >>>>>>>>>>
> >>>>>>>>>>>> Two of these, draft-dearlove-manet-olsrv2-rmpr-optimization
> and draft-dearlove-manet-nhdp-olsrv2-tlv-extension are intended for
> Standards Track, and as minor updates to NHDP and OLSRv2, which we would
> like to progress as fast as possible.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The third, draft-dearlove-manet-olsrv2-multitopology, we'd
> obvious have no problem with being adopted as a WG document, but it needs
> at least one more revision, which we intend to do as an author draft, so
> there isn't the same time pressure there. However of course we would like
> discussion any time from now.
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>> Christopher Dearlove
> >>>>>>>>>>>> Registered Office: Warwick House, PO Box 87, Farnborough
> Aerospace Centre, Farnborough, Hants, GU14 6YU, UK

---

From: Justin Dean <[email-masked]>
Date: Fri, 30 Aug 2013 10:35:22 -0400

I support adoption of this draft by the working group as it addresses a
previously undefined behavior of the NHDP/OLSRv2 protocols.  I do have
implementations and I don't see any issues with this document.  I just so
happened to make similar choices in behavior, if I hadn't however the
changes would be simple to implement and even if I didn't nothing would
"break" as no new TLVs or values are introduced with this document.  Even
protocols extended with future TLVs (and values) which took advantage of
the behaviors outlined in this document wouldn't break anything in
non-compliant protocols, they just wouldn't play as nice together (which is
the current case anyhow).

I do have issue with some of the language and found it overly difficult to
understand what was being specified.  I'm willing to provide some more
concrete feedback in this regard later.

Justin

On Tue, Aug 27, 2013 at 10:05 PM, Ulrich Herberg <[email-masked]>wrote:

> On the procedural question, the IETF has introduced "updates RFCxxxx" for
> a good reason, and I think this particular case is such a case.
>
> Ulrich
>
>
>
>> "old" of "new" is not important. It is about stability of the standard.
>> We have to stop incremental changes that are not backwards compatible. Or
>> step to new version or similar tag.
>>
>> Teco
>>
>> >>>> My concerns are on what happens when different implementations are
>> in same network. This has to be documented. Asking on mailing list is not
>> enough.
>> >>>>
>> >>>> Teco
>> >>>>
>> >>>>>> RFC 791 was 1981. Wording on TOS: "provides an indication", "are
>> to be used to guide", "may". Remapping to DSCP is highly backwards
>> compatible.
>> >>>>>>

---

From: Christopher Dearlove <[email-masked]>
Date: Fri, 30 Aug 2013 16:34:44 +0100

Your feedback is always welcome, whether at author stage or WG stage.

To be clear you say "this draft", which from comments must be the TLV extensions draft. There are actually two drafts we're asking about, the other being the MPR optimisation (which has no compatibility issues at all I believe) but support to adopt as WG draft welcome.

We hope soon to have a new version of the MT draft, which comment will also be welcome on.

On 30 Aug 2013, at 15:35, Justin Dean wrote:

> I support adoption of this draft by the working group as it addresses a previously undefined behavior of the NHDP/OLSRv2 protocols.  I do have implementations and I don't see any issues with this document.  I just so happened to make similar choices in behavior, if I hadn't however the changes would be simple to implement and even if I didn't nothing would "break" as no new TLVs or values are introduced with this document.  Even protocols extended with future TLVs (and values) which took advantage of the behaviors outlined in this document wouldn't break anything in non-compliant protocols, they just wouldn't play as nice together (which is the current case anyhow).
> 
> I do have issue with some of the language and found it overly difficult to understand what was being specified.  I'm willing to provide some more concrete feedback in this regard later.
> 
> Justin
> 
> 
> On Tue, Aug 27, 2013 at 10:05 PM, Ulrich Herberg <[email-masked]> wrote:
> I don't see any issues with the approach of the TLV extension draft. Like Chris said, it specifies a behavior that was previously unspecified (and thus undefined).
> On the procedural question, the IETF has introduced "updates RFCxxxx" for a good reason, and I think this particular case is such a case.
> 
> Ulrich
> 
> 
> 
> On Tue, Aug 27, 2013 at 2:40 AM, Dearlove, Christopher (UK) <[email-masked]> wrote:

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 30 Aug 2013 18:34:32 +0200

I should add that I have a *strict* implementation of OLSRv2, finished well before these I-Ds were as much as a twinkle in Chris' eyes, and conforming strictly to draft-ietf-manet-olsrv2 as currently sitting with the RFC Editor.

While that implementation - of course - will not generate TLVs of the form described in TLV-Extensions, it will happily process them and will do the right thing when presented with such TLVs (i.e., already interprets fields as bit-vectors, process value field lengths "correctly", behave appropriately when seeing unknown values and not discard the message as a consequence hereof, etc.) Much the same as Justin describes for his implementations. 

For the Routing MPR optimization I-D, the same applies: no interoperability issues.

Such interoperability was, indeed, a condition for me to join Chris in this (these) I-D, and something I verified with my implementation in advance hereof: I actually wrote a small piece of test code that generates OLSRv2 messages containing TLVs formatted according to the TLV-Extension I-D, and feed them to my OLSRv2 implementation, just to be sure.

Justin: like Chris, I look forward to your - always very useful and constructive - detailed feedback and comments to the I-Ds.

Teco: I appreciate that you worry about "running code" - that makes two of us (you know my position: running code is king, and pushing specs through without them is unacceptable). My conclusion is, based on the above, that there are no interoperability issues between a "conformant" implementation of OLSRv2 and a "conformat" implementation of OLSRv2 + TLV-Extensions and/or routing MPR optimization.

(Of course, if someone shows up with a non-conformat implementation of a spec, then all bets are off on interoperability - but the IETF can't really guard against implementations not following the specs, other than to try to "limit the damage" ..... which I think that OLSRv2 does nicely).

Respectfully,

Thomas

Sent from my iPad

---

From: Henning Rogge <[email-masked]>
Date: Fri, 30 Aug 2013 18:41:23 +0200

Hi,

I am pretty sure (but have not tested it) the Olsr.org OLSRv2
implementation would also have no trouble with the "TLV extension"
draft, as long as the currently unused bitfields are not used. In
fact, I accidentally implemented parts of the extension because I used
the value 255 as "no TLV found" for a few TLVs.

The only think I can see that will happen is that a "non TLV
extension" implementation will not interoperate with Chris planned
Multitopology implementation, when it use the unused bitfields.

Which is okay for me, it cannot process the Multitopology information anyways.

Henning Rogge

On Fri, Aug 30, 2013 at 6:34 PM, Thomas Heide Clausen
<[email-masked]> wrote:
> I should add that I have a *strict* implementation of OLSRv2, finished well
> before these I-Ds were as much as a twinkle in Chris' eyes, and conforming
> strictly to draft-ietf-manet-olsrv2 as currently sitting with the RFC
> Editor.
>
> While that implementation - of course - will not generate TLVs of the form
> described in TLV-Extensions, it will happily process them and will do the
> right thing when presented with such TLVs (i.e., already interprets fields
> as bit-vectors, process value field lengths "correctly", behave
> appropriately when seeing unknown values and not discard the message as a
> consequence hereof, etc.) Much the same as Justin describes for his
> implementations.
>
> Such interoperability was, indeed, a condition for me to join Chris in this
> (these) I-D, and something I verified with my implementation in advance
> hereof: I actually wrote a small piece of test code that generates OLSRv2
> messages containing TLVs formatted according to the TLV-Extension I-D, and
> feed them to my OLSRv2 implementation, just to be sure.
>
> Justin: like Chris, I look forward to your - always very useful and
> constructive - detailed feedback and comments to the I-Ds.
>
> Teco: I appreciate that you worry about "running code" - that makes two of
> us (you know my position: running code is king, and pushing specs through
> without them is unacceptable). My conclusion is, based on the above, that
> there are no interoperability issues between a "conformant" implementation
> of OLSRv2 and a "conformat" implementation of OLSRv2 + TLV-Extensions and/or
> routing MPR optimization.
>
> (Of course, if someone shows up with a non-conformat implementation of a
> spec, then all bets are off on interoperability - but the IETF can't really
> guard against implementations not following the specs, other than to try to
> "limit the damage" ..... which I think that OLSRv2 does nicely).
>
> Respectfully,
>
> Thomas
>
> Sent from my iPad
>
> protocols extended with future TLVs (and values) which took advantage of the
> behaviors outlined in this document wouldn't break anything in non-compliant
> protocols, they just wouldn't play as nice together (which is the current
> case anyhow).
>
>>> Cc: Christopher Dearlove; Dearlove, Christopher (UK); [email-masked]
>>> List; Joe Macker ([email-masked]); Thomas Heide Clausen
>>> ([email-masked]); Stan Ratliff (sratliff)
>>> >> Op 16 aug. 2013, om 23:12 heeft Christopher Dearlove
>>> >> <[email-masked]> het volgende geschreven:
>>> >>
>>> >>> Have you read the draft?
>>> >>>
>>> >>> --
>>> >>> Christopher Dearlove
>>> >>>> Op 16 aug. 2013, om 22:37 heeft Christopher Dearlove
>>> >>>> <[email-masked]> het volgende geschreven:
>>> >>>>
>>> >>>>>> Op 16 aug. 2013, om 19:14 heeft Christopher Dearlove
>>> >>>>>> <[email-masked]> het volgende geschreven:
>>> >>>>>>
>>> >>>>>>>> Op 16 aug. 2013, om 18:43 heeft Christopher Dearlove
>>> >>>>>>>> <[email-masked]> het volgende geschreven:
>>> >>>>>>>>
>>> >>>>>>>>> minor way) hypothetical implementations while people actually with them want
>>> >>>>>>>>> this.
>>> >>>>>>>>>
>>> >>>>>>>>>> Op 16 aug. 2013, om 17:37 heeft Stan Ratliff (sratliff)
>>> >>>>>>>>>> <[email-masked]> het volgende geschreven:
>>> >>>>>>>>>>
>>> >>>>>>>>>>>> obvious have no problem with being adopted as a WG document, but it needs at
>>> >>>>>>>>>>>> least one more revision, which we intend to do as an author draft, so there
>>> >>>>>>>>>>>> isn't the same time pressure there. However of course we would like

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 30 Aug 2013 18:44:38 +0200

The nitpicker in me insists that I be more precise on one point:

On 30 août 2013, at 18:34, Thomas Heide Clausen <[email-masked]> wrote:

> While that implementation - of course - will not generate TLVs of the form described in TLV-Extensions, it will happily process them and will do the right thing when presented with such TLVs (i.e., already interprets fields as bit-vectors,

It, of course, doesn't "interpret fields as bit-vectors", but as numerical values. However, as the bit-vectors are set up so that the numerical values that OLSRv2 expects match with the bits set/cleared, it will "interpret the bit-vectors as the expected values" and do the right thing.

Thomas

> process value field lengths "correctly", behave appropriately when seeing unknown values and not discard the message as a consequence hereof, etc.) Much the same as Justin describes for his implementations. 
>

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Fri, 30 Aug 2013 16:51:13 +0000

OK, so with the emails from Henning and Thomas, it looks like the issue of interoperability has been covered. And again, the request was simply for adopting these documents as working group documents - not for ratification. 

My vote is to accept all three as WG documents. Consider this email as "last call for opposition"...

Regards,
Stan

---

From: Joe Macker <[email-masked]>
Date: Fri, 30 Aug 2013 12:55:17 -0400

I also agree so far I see no strong opposition and because they are only being adopted for further work the raised issues such as Justin's can continue to be worked in the normal process.
-Joe

---

From: Christopher Dearlove <[email-masked]>
Date: Fri, 30 Aug 2013 18:32:34 +0100

Indeed. While I want to go further than the WG with them, to the WG is all that's being considered now.

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 31 Aug 2013 10:55:25 +0200

>questions before the above>

>May I read that there are problems?
If so, we cannot bring out a std track RFC followed up with something
that can not interoperate with it. Or we mark the to_be RFC as
obsolete. That's how it works.
+++++++++++++++++++++++++++++++++++++

I agree, that problems/questions that made MANET WG to update such
RFC, SHOULD be documented/listed or discussed into IETF, we SHOULD not
hide any information related to OLSRv2 problems.

 I still not foud answers from the new draft authors of the document
requested to adopt, I agree with Teco's questions and approach to
update MANET documents.

AB