Hi Stan, hi all,
Am 02.03.2015 um 23:02 schrieb Stan Ratliff <ratliffstan@xxxxxxxxx
<mailto:ratliffstan@xxxxxxxxx>>:
Vicky,
We need to close on this item. I appreciate the arguments on both
sides of the discussion. Don't mean to be blunt, but "I'm undecided"
doesn't help a whole lot... ;-)
I'm just tired of being beaten silly by the RFC 5444 authors as to
(1) that the AODVv2 editorial team doesn't understand RFC 5444, (2)
that we're not using it right, (3) that it's really, really easy, and
should be intuitively obvious to the casual observer, and (4) why
can't we get it right.
Full ack. I believe I've started out with a very positive attitude
towards RFC 5444, and I still like the idea behind it, but I've
started to become extremely annoyed at the fact that we are supposed
to conform to some API that the 5444 authors cannot be bothered to
actually publish, despite being asked to do so for a very long time.
However.
I'm still of the opinion that you don't hand your adversary (and it
unfortunately HAS become adversarial) the ammunition needed to blow
you up.
I'm not quite sure if the pseudocode is the real ammunition here.
I've never been a fan of adding blobs of pseudocode this big to the
draft, especially since the algorithms just sum up what the draft
should have put into words anyway, but I have to admit that they've
become pretty neat. I can see how this pseudocode may help some people
with their implementation, and I even can see how they may help with
building RFC 5444 messages, but it extremely frustrates me that I'd
probably have to wade through this pseudocode *and* RFC5444 to
understand what exactly I have to feed my builder/parser, because the
descriptions in section 10 are still somewhat ambiguous (see earlier
e-mail). I'd prefer to have the sharper definitions outside of the
appendix, but I'm not sure if we have the time.
I have a problem with the following parts of the pseudocode:
[in Generate_RREQ ]
MF (Message Flags) = 4 (only msg-hop-limit field is present)
MAL (Message Address Length) = 3 for IPv4, 15 for IPv6
msg-size = NN (octets - counting MsgHdr, AddrBlk, and AddrTLVs)
[...]
msg.tlvs-length := 0
[...]
msg.tlvs-length += metricMsgTlv total length
[...]
num-addr := 2
origSeqNumAddrBlkTlv.thassingleindex := 1
origSeqNumAddrBlkTlv.index-start := 0
[...]
targSeqNumAddrBlkTlv.thassingleindex := 1
targSeqNumAddrBlkTlv.index-start := 1
[...]
metricAddrBlkTlv.thassingleindex := 1
metricAddrBlkTlv.index-start := 0
[...]
VALIDITY_TIMEAddrBlkTlv.thassingleindex := 1
VALIDITY_TIMEAddrBlkTlv.index-start := 0
[the same with Regenerate_RREQ, Generate_RREP and Regenerate_RREP]
The rest of it is generic enough to not be ammunition (I think).
I'd assume people who aren't going to use a RFC5444 parser but still
want to build RFC5444 packets will have to consult RFC 5444 anyway,
and they're going to come up with ways how to build those headers that
suit them best. Trying to help them by adding pseudocode that
describes how to put together a 5444 header sounds like ammunition to
me too. Not only can and will the 5444 people attack this, but it
might actually confuse said implementors. I believe that this kind of
stuff should stay in RFC5444 alone.
TL;DR: I can live with having a pseudocode summary of AODVv2's
operations in the appendix, but in my opinion, the parts describing
how to build 5444 internals will have to go in favor of more precise
packet descriptions (if we still have the time).
Regards,
Lotte
Regards,
Stan
On Mon, Mar 2, 2015 at 4:15 PM, Victoria Mercieca
<vmercieca0@xxxxxxxxx <mailto:vmercieca0@xxxxxxxxx>> wrote:
Hi Stan,
I think Charlie has a point that the RFC 5444 stuff would be
useful to people who arent going to use a parser. But I also
agree with you that we could get a lot of grief if it's wrong. So
I'm undecided!
Would it be an option to remove it but to leave a note in there
that should the reader wish to see some implementation advice on
the RFC 5444 message format, they can contact the authors?
Charlie what do you think? We could then worry about the
correctness separately to the draft?
Regards,
Vicky.
On Monday, March 2, 2015, Stan Ratliff <ratliffstan@xxxxxxxxx
<mailto:ratliffstan@xxxxxxxxx>> wrote:
OK, gang -
Monday has pretty much come and gone, at least in the CET
timezone. Since we have a deadline for submission of the
draft, I think we need to finally settle on the issue of the
amount of RFC 5444 discussion in Appendix A and Appendix B.
To recap, we have (I believe) 3 opinions to remove the
references, 1 opinion to keep them.
I'm ready to declare that consensus has been reached, and the
5444
tutorial/discussion/recommendation/however-we-classify-it
goes bye-bye.
Differing opinions? Serve 'em up quick.
Regards,
Stan
