Subject: Re: [manet] Start work: update draft for RFC5444-Packets

From: "Rick Taylor" <[email-masked]>
Date: Mon, 23 Jul 2012 10:16:44 +0100

Hi Abdussalam,

I would recommend that you be very careful about attempting to
adapt/extend RFC5444, particularly with respect to DLEP, because it is
still open to debate whether any future DLEP draft will use RFC5444 for
its packet format, and I believe the authors are leaning away from it.

Also, there has been a lot of comment on this mailing list about not
updating RFC5444 yet as there appears little consensus about the actual
failings of the format w.r.t applicable protocols, i.e. all the
'complaints' about the format appear to be short-comings in the
consuming protocols, not the packetBB format itself.

Can you perhaps outline what you see as the failings of RFC5444 here
before you produce a lengthy document, in order to gather some quick
peer-review comments, as many on this list struggle to find time to
digest long formal drafts, and I wouldn't want you to suffer from TL;DR
('too-long; didn't-read').

Rick Taylor
Cassidian Systems

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Abdussalam Baryun
> Sent: 21 July 2012 14:33
> To: manet
> Subject: [manet] Start work: update draft for RFC5444-Packets
> 
> Hi
> 
> I started working on a new draft to make some updates to the RFC5444,
> so manet-packets can be more used by AODVv2, DLEP, and other possible
> protocols.
> 
> I will consider your input below of  the discussions regarding
> 5444-packets, also in the past there was a request that there is a
> need for how to use 5444, so this draft may include as well,
> 
> http://www.ietf.org/mail-archive/web/manet/current/msg13212.html
> http://www.ietf.org/mail-archive/web/manet/current/msg13105.html
> http://www.ietf.org/mail-archive/web/manet/current/msg12430.html
> 
> If you have any comment or advise to this started work please reply,
> 
> AB
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 23 Jul 2012 12:03:03 +0200

Hi Rick,

I thank you for your comments, but I mentioned references to the
reason why I am updating. Regarding DLEP, I was one of the first
participants to oppose that it uses RFC5444 (the document is for
routers formats), but I am with the idea of having similar format for
MANET R2RIs, which can be added as a section in this new I-D I am
working on. The aim of this work is routers first, then optional
related protocols like DLEP or other R2RI. However, I will send
shortly an outline as you requested.

Regards
Abdussalam
==============

---

From: Thomas Clausen <[email-masked]>
Date: Mon, 23 Jul 2012 12:42:07 +0200

I agree with Rick, and want to add a few things ...

> its packet format, and I believe the authors are leaning away from it.

Yes - plus, it is also not established yet that RFC5444 isn't appropriate for carrying DLEP signals (should the authors/WG go that way).

> consuming protocols, not the packetBB format itself.

+1

> ('too-long; didn't-read').

Even before that, it would be helpful to see a real routing protocol (which DLEP is not), with a real usecase & industry behind it (so, not just a thought experiment), with requirements pushed from real deployments (so, outside of a lab), which  is within the [manet] scope - and for which its signals cannot properly be expressed in RFC5444.

Best,

Thomas

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 23 Jul 2012 13:19:35 +0200

Hi Thomas,

comments in line,

On 7/23/12, Thomas Clausen <[email-masked]> wrote:
> Yes - plus, it is also not established yet that RFC5444 isn't appropriate
> for carrying DLEP signals (should the authors/WG go that way).

Discussion has been established already on the list and in the last
meeting of MANET WG

> Even before that, it would be helpful to see a real routing protocol (which
> DLEP is not), with a real usecase & industry behind it (so, not just a
> thought experiment), with requirements pushed from real deployments (so,
> outside of a lab), which  is within the [manet] scope - and for which its
> signals cannot properly be expressed in RFC5444.

nothing real/production comes to life without a start of ideas and
discussions, please note that any discussion is in scope of the MANET
WG, and that MANET theory I-Ds may be accepted and become RFCs which
is also in scope.

Regards
AB

---

From: Bo Berry <[email-masked]>
Date: Mon, 23 Jul 2012 07:27:46 -0400

As a co-author of DLEP, I agree w/ Rick&Thomas.  We (DLEP authors) are
working on DLEP revisions.

-Bo

>>> If you have any comment or advise to this started work please reply,

----
[email-masked]
This email may contain confidential and privileged material for the sole use of the intended recipient. This email may contain information that is protected by NDA. Any unauthorized review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Mon, 23 Jul 2012 15:00:13 +0000

+1

Regards,
Stan

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 23 Jul 2012 10:10:20 -0700

I don't see the need for updating RFC5444 at the moment.

Best
Ulrich

On Mon, Jul 23, 2012 at 8:00 AM, Stan Ratliff (sratliff) <[email-masked]
> wrote:

> >> Yes - plus, it is also not established yet that RFC5444 isn't
> appropriate for carrying DLEP signals (should the authors/WG go that way).
> >>
> >> Even before that, it would be helpful to see a real routing protocol
> (which DLEP is not), with a real usecase & industry behind it (so, not just
> a thought experiment), with requirements pushed from real deployments (so,
> > This email may contain confidential and privileged material for the sole
> use of the intended recipient. This email may contain information that is
> protected by NDA. Any unauthorized review, use, distribution or disclosure
> by others is strictly prohibited. If you are not the intended recipient (or
> authorized to receive for the recipient), please contact the sender by
> reply email and delete all copies of this message.
> >

---

From: Bo Berry <[email-masked]>
Date: Mon, 23 Jul 2012 13:16:40 -0400

+1, big agreement here!
 
On Jul 23, 2012, at 1:10 PM, Ulrich Herberg wrote:

> On Mon, Jul 23, 2012 at 8:00 AM, Stan Ratliff (sratliff) <[email-masked]> wrote:
> +1
> 
> Regards,
> Stan
> 

----
[email-masked]

---

From: Joseph Macker <[email-masked]>
Date: Mon, 23 Jul 2012 13:27:54 -0400

+1 also against this right now.

On Mon, Jul 23, 2012 at 1:16 PM, Bo Berry <[email-masked]> wrote:

> > > This email may contain confidential and privileged material for the
> sole use of the intended recipient. This email may contain information that
> is protected by NDA. Any unauthorized review, use, distribution or
> disclosure by others is strictly prohibited. If you are not the intended
> recipient (or authorized to receive for the recipient), please contact the
> sender by reply email and delete all copies of this message.
> > >

---

From: Daniel He <[email-masked]>
Date: Mon, 23 Jul 2012 18:30:35 +0100

Me 2 against this update.
Regards,
Dan

-- 
Dan He
---------------------
Tel: +44-788-686-3428

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 24 Jul 2012 10:09:51 +0000

I want to be a bit stronger than the various +1s that have been added.

Work in the IETF should be about things that people want. And in particular 5444, and other supporting documents, is always going to be the last place to start. There are at least two steps before that, and more if you break things down. First it's what do users want? And second it's what do protocols need to do? You'd start with first that people need this (for some value of this that matters to a user) to happen. Then second that needs a protocol that, once designed (one of the sub-steps noted) needs this information transferred. And only then, right at the end of the journey, it's saying "I can't see how to do this in 5444" and waiting to see if someone else says "but I can". Only at the end of that process (and putting aside also possibilities of not using 5444, so it's only MANET routing protocols that the use of 5444 is strongly preferable) do you get to "should we update 5444" and even then you need to recognise the significant costs of so doing in the issues of versions and normative dependences. (And if you don't understand those issuers, you shouldn't be going anywhere near it.) And that's putting aside issues of who owns what aspects of 5444 (which are also important).

I'm afraid I feel I need to say that I'm seeing a lot of enthusiasm, but it's all starting from drafts and revisions (link layer, terminology, 2501, DSR, 5444 and others I may have missed and/or outside this WG). Those are not the starting points. All have preceding steps, and all include the question "is this what we want?" and so far (in the five quoted examples at least) it's always been "no", or at least "no case has been made for that yet, and a strong one would be needed".

-- 
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

-----Original Message-----
From: Thomas Clausen [mailto:[email-masked]] 
Sent: 23 July 2012 11:42
To: Rick Taylor
Cc: Abdussalam Baryun; manet
Subject: Re: [manet] Start work: update draft for RFC5444-Packets

----------------------! 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.
--------------------------------------------------------

+1

Best,

Thomas

>> If you have any comment or advise to this started work please reply,

********************************************************************
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: "Rick Taylor" <[email-masked]>
Date: Tue, 24 Jul 2012 11:25:10 +0100

+1 (or more if allowed)

Rick Taylor

> From: Dearlove, Christopher (UK) [mailto:[email-masked]]
> Sent: 24 July 2012 11:10
> To: Thomas Clausen; Rick Taylor
> Subject: RE: [manet] Start work: update draft for RFC5444-Packets
> 
> Work in the IETF should be about things that people want. And in
> particular 5444, and other supporting documents, is always going to be the
> last place to start. There are at least two steps before that, and more if
> you break things down. First it's what do users want? And second it's what
> do protocols need to do? You'd start with first that people need this (for
> some value of this that matters to a user) to happen. Then second that
> needs a protocol that, once designed (one of the sub-steps noted) needs
> this information transferred. And only then, right at the end of the
> journey, it's saying "I can't see how to do this in 5444" and waiting to
> see if someone else says "but I can". Only at the end of that process (and
> putting aside also possibilities of not using 5444, so it's only MANET
> routing protocols that the use of 5444 is strongly preferable) do you get
> to "should we update 5444" and even then you need to recognise the
> significant costs of so doing in the issues of versions and normative
> dependences. (And if you don't understand those issuers, you shouldn't be
> going anywhere near it.) And that's putting aside issues of who owns what
> aspects of 5444 (which are also important).
> 
> I'm afraid I feel I need to say that I'm seeing a lot of enthusiasm, but
> it's all starting from drafts and revisions (link layer, terminology,
> 2501, DSR, 5444 and others I may have missed and/or outside this WG).
> Those are not the starting points. All have preceding steps, and all
> include the question "is this what we want?" and so far (in the five
> quoted examples at least) it's always been "no", or at least "no case has
> been made for that yet, and a strong one would be needed".
> 
> --
> Christopher Dearlove
> (which DLEP is not), with a real usecase & industry behind it (so, not
> just a thought experiment), with requirements pushed from real deployments
> (so, outside of a lab), which  is within the [manet] scope - and for which
> its signals cannot properly be expressed in RFC5444.
> 
> Best,
> 
> Thomas
> 
> 
> > Rick Taylor
> > Cassidian Systems
> >

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 24 Jul 2012 13:05:27 +0200

I couldn't have phrased it better than Chris.

+1000

-- 
Thomas Heide Clausen
http://www.thomasclausen.org/

"Any simple problem can be made insoluble if enough meetings are held to
 discuss it."
   -- Mitchell's Law of Committees

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 24 Jul 2012 14:22:29 +0000

Well said, Chris. I completely agree. 

Regards,
Stan