Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)
draft-ietf-manet-timetlv-08
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
08 | (System) | post-migration administrative database adjustment to the Abstain position for David Ward |
2012-08-22
|
08 | (System) | post-migration administrative database adjustment to the No Objection position for Jari Arkko |
2012-08-22
|
08 | (System) | post-migration administrative database adjustment to the No Objection position for Tim Polk |
2012-08-22
|
08 | (System) | post-migration administrative database adjustment to the No Objection position for Dan Romascanu |
2012-08-22
|
08 | (System) | post-migration administrative database adjustment to the No Objection position for Magnus Westerlund |
2012-08-22
|
08 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
2012-08-22
|
08 | (System) | post-migration administrative database adjustment to the No Objection position for Ronald Bonica |
2009-01-14
|
08 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2009-01-14
|
08 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2009-01-14
|
08 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2009-01-13
|
08 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2009-01-06
|
08 | (System) | IANA Action state changed to In Progress from On Hold |
2008-11-26
|
08 | (System) | IANA Action state changed to On Hold from In Progress |
2008-11-25
|
08 | (System) | IANA Action state changed to In Progress |
2008-11-19
|
08 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
2008-11-18
|
08 | Amy Vezza | IESG state changed to Approved-announcement sent |
2008-11-18
|
08 | Amy Vezza | IESG has approved the document |
2008-11-18
|
08 | Amy Vezza | Closed "Approve" ballot |
2008-11-18
|
08 | Ross Callon | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Ross Callon |
2008-11-18
|
08 | Ron Bonica | [Ballot Position Update] Position for Ron Bonica has been changed to No Objection from Abstain by Ron Bonica |
2008-10-19
|
08 | Cullen Jennings | [Ballot comment] My position is largely the same as Ron's. I have not seen any arguments for why it needs to be this complex. However, … [Ballot comment] My position is largely the same as Ron's. I have not seen any arguments for why it needs to be this complex. However, I don't think it will harm the internet and thus do not think it is appropriate to hold a discuss on this case. I |
2008-10-19
|
08 | Cullen Jennings | [Ballot Position Update] Position for Cullen Jennings has been changed to Abstain from Undefined by Cullen Jennings |
2008-10-16
|
08 | Lisa Dusseault | [Ballot comment] I am voting ABSTAIN. I too, find the document and its design choices very confusing. I can't see why a *general-purpose* duration type … [Ballot comment] I am voting ABSTAIN. I too, find the document and its design choices very confusing. I can't see why a *general-purpose* duration type would necessarily need to work this way. I find there are some choices in the design that are bad for general interoperability. It may be that those choices could be justified for certain use cases and in a protocol more limited than MANET, but I just can't see it for general-purpose time typing. |
2008-10-16
|
08 | Lisa Dusseault | [Ballot Position Update] New position, Abstain, has been recorded by Lisa Dusseault |
2008-10-16
|
08 | Chris Newman | [Ballot comment] I'm still dubious of the complexity of creating a new custom 8-bit floating point number format rather than just using a simple 32-bit … [Ballot comment] I'm still dubious of the complexity of creating a new custom 8-bit floating point number format rather than just using a simple 32-bit integer or a 32-bit IEEE floating point number. However, at least the motivation for doing so is documented in the document. |
2008-10-16
|
08 | Chris Newman | [Ballot comment] I'm still dubious of the complexity of creating a new custom 8-bit floating point number format rather than just using a simple 32-bit … [Ballot comment] I'm still dubious of the complexity of creating a new custom 8-bit floating point number format rather than just using a simple 32-bit integer. However, the motivation for doing so is now well-justified in the document. |
2008-10-16
|
08 | Chris Newman | [Ballot Position Update] Position for Chris Newman has been changed to No Objection from Abstain by Chris Newman |
2008-10-12
|
08 | David Ward | [Ballot comment] As with others, I find this design the Wrong Thing (tm). If you can afford the overhead of a TLV in your protocol … [Ballot comment] As with others, I find this design the Wrong Thing (tm). If you can afford the overhead of a TLV in your protocol you surely do not need to bit bum values down to 8 bits. The range of times they can represent is 1 to 64 seconds times some magic constant with some arbitrary variable degree of precision. Magic constants are always bad news unless you have a protocol to negotiate them and even then they are bad news. They could quite reasonably take a slice out of the middle of the NTP format. If they were to use say two bytes of seconds and one byte of fractional seconds that would give them 18 hours in 4ms accuracy. If they make the structure a nice round 4 bytes you get 6 months in 4ms accuracy, and that has got to be enough for any application that I can think of without needing some global magic number. |
2008-10-07
|
08 | David Ward | [Ballot Position Update] Position for David Ward has been changed to Abstain from Discuss by David Ward |
2008-09-29
|
08 | Ron Bonica | [Ballot comment] After some discussion with the authors, I agree that this level of complexity is required if you are going to try to convey … [Ballot comment] After some discussion with the authors, I agree that this level of complexity is required if you are going to try to convey that amount of information in only 8 bits. I support Lars' objection, that the TLV should be simplified at the cost of a few more bits. However, I won't stand in the way of this draft and change my position to ABSTAIN. |
2008-09-29
|
08 | Ron Bonica | [Ballot comment] After some degree of discussion with the authors, I support Lars' objection, that the TLV should be simplified at the cost of a … [Ballot comment] After some degree of discussion with the authors, I support Lars' objection, that the TLV should be simplified at the cost of a few more bits. However, I won't stand in the way of this draft and change my position to ABSTAIN. |
2008-09-29
|
08 | Ron Bonica | [Ballot Position Update] Position for Ron Bonica has been changed to Abstain from Discuss by Ron Bonica |
2008-09-26
|
08 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2008-09-26
|
08 | (System) | New version available: draft-ietf-manet-timetlv-08.txt |
2008-09-26
|
08 | (System) | Removed from agenda for telechat - 2008-09-25 |
2008-09-25
|
08 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
2008-09-25
|
08 | Cullen Jennings | [Ballot Position Update] Position for Cullen Jennings has been changed to Undefined from No Objection by Cullen Jennings |
2008-09-25
|
08 | David Ward | [Ballot discuss] This doc does not incorporate comments from my review. |
2008-09-25
|
08 | David Ward | [Ballot Position Update] Position for David Ward has been changed to Discuss from Abstain by David Ward |
2008-09-25
|
08 | David Ward | [Ballot Position Update] New position, Abstain, has been recorded by David Ward |
2008-09-25
|
08 | Mark Townsley | [Ballot comment] I share some of the same concerns as Jari. The document doesn't need a tutorial by any means, but a little bit of … [Ballot comment] I share some of the same concerns as Jari. The document doesn't need a tutorial by any means, but a little bit of context around why such a complicated time format is needed would be helpful. I question whether this is truly necessary, and whether again the "make it general for any purpose" pendulum has swung a bit too far again here. A little bit of explanation would be helpful. |
2008-09-25
|
08 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
2008-09-25
|
08 | Pasi Eronen | [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen |
2008-09-24
|
08 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2008-09-24
|
08 | Ron Bonica | [Ballot discuss] This discuss is along the same lines as Chris Newman's ABSTAIN. The authors generate a new mechanism for representing time, but they never … [Ballot discuss] This discuss is along the same lines as Chris Newman's ABSTAIN. The authors generate a new mechanism for representing time, but they never explain the following: - why are we constrained to 8 bits - if all MANET nodes must have the same value C, why is it included in the calculation? - what granularity is required (seconds, milliseconds?) - what high and low values must be represented If some of this was in the document and I missed it, I apologize in advance. The document was very difficult to read. |
2008-09-24
|
08 | Ron Bonica | [Ballot discuss] This discuss is along the same lines as Chris Newman's ABSTAIN. The authors generate a new mechanism for representing time, but they never … [Ballot discuss] This discuss is along the same lines as Chris Newman's ABSTAIN. The authors generate a new mechanism for representing time, but they never explain the following: - why are we constrained to 8 bits - since all systems need to use the same value of C, why not mandate 0 - what granularity is required (seconds, milliseconds?) - what high and low values must be represented If some of this was in the document and I missed it, I apologize in advance. The document was very difficult to read. |
2008-09-24
|
08 | Ron Bonica | [Ballot discuss] This discuss is along the same lines as Chris Newman's ABSTAIN. The authors generate a new mechanism for representing time, but they never … [Ballot discuss] This discuss is along the same lines as Chris Newman's ABSTAIN. The authors generate a new mechanism for representing time, but they never explain the following: - why are we constrained to 8 bits - since all systems need to use the same value of C, why not mandate 0 - what granularity is required (seconds, milliseconds?) - what high and low values must be represented If some of this was in the document and I missed it, I apologize in advance. The document was very difficult to read. |
2008-09-24
|
08 | Ron Bonica | [Ballot Position Update] Position for Ron Bonica has been changed to Discuss from Abstain by Ron Bonica |
2008-09-24
|
08 | Ron Bonica | [Ballot Position Update] New position, Abstain, has been recorded by Ron Bonica |
2008-09-18
|
08 | Ross Callon | State Changes to IESG Evaluation from IESG Evaluation::AD Followup by Ross Callon |
2008-09-18
|
08 | Ross Callon | Placed on agenda for telechat - 2008-09-25 by Ross Callon |
2008-09-18
|
08 | Ross Callon | Ballot has been issued by Ross Callon |
2008-09-18
|
08 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk |
2008-09-18
|
08 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk |
2008-09-18
|
08 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu |
2008-09-16
|
07 | (System) | New version available: draft-ietf-manet-timetlv-07.txt |
2008-08-17
|
08 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
2008-08-01
|
06 | (System) | New version available: draft-ietf-manet-timetlv-06.txt |
2008-07-11
|
08 | Magnus Westerlund | [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss by Magnus Westerlund |
2008-07-10
|
08 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko |
2008-07-10
|
08 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2008-07-10
|
05 | (System) | New version available: draft-ietf-manet-timetlv-05.txt |
2008-06-26
|
08 | Jari Arkko | [Ballot discuss] The functionality that this draft specifies is good and needed. However, I had difficulty in reading this specification. My main issue is that … [Ballot discuss] The functionality that this draft specifies is good and needed. However, I had difficulty in reading this specification. My main issue is that it has been made so general that in many places it is hard to understand what the actual rules about the TLV are. Some examples: > A Time TLV may be a packet, message or address block TLV. This is the only place in the document that mentions packet TLV. However, according to packetbb (that I have just glanced at so far) packet, message, and address block TLVs appear to be separate entities. If you really intended to allow the Time TLV to be used as a Packet TLV, perhaps you need specify this in more detail. Otherwise, you can change the quoted text to include only message and address block TLVs. What is needed to resolve the Discuss: please explain this in more detail. > IANA is requested to assign the same numerical value to the message > TLV and address block TLV types with the same mnemonic. So, you have two different entities with different names, but they have the same mnemonic and code points. Confusing. I wonder if one entity which is simply used in different contexts would work better, or if the packetbb structure does not allow this, just define clearly separate entities with separate names and code points (but possibly the same format). Or maybe you have gone too far in the definitions; you could have just defined the format and allowed other MANET documents employ the time format in the definition of specific TLVs. That way it would have been very clear what kind of requirements apply (e.g., how many times are needed, what the times apply to, etc.) I am not convinced that messages and address blocks are the only things that ever need time values in the MANET space. What is needed to resolve the Discuss: please explain exactly what you mean, or change the definitions so that there is no ambiguity. > = {}* Parsing this format requires knowning the length. You get the length from the TLV header. Perhaps obvious, but stating this would have made reading the document easier for me. What is needed to resolve the Discuss: please explain this in more detail. > In a multivalue Time TLV, each single value subfield of the > multivalue Time TLV is defined as above. Note that [1] requires that > each single value subfield has the same length (i.e. the same value > of n) but they need not use the same values of to . I do not understand how you differentiate between a single value and multiple values. For instance, if there are three values then the number of octets is odd, which is also true for single values. What is needed to resolve the Discuss: please explain this in more detail. > A VALIDITY_TIME TLV is an address block TLV that defines the validity > time of the addresses to which the TLV is associated. After this > time the receiving node MUST consider the addresses to no longer be > valid (unless these are repeated in a later message). What addresses? See also the last paragraph of my IANA comment above. What is needed to resolve the Discuss: please explain this in more detail. |
2008-06-26
|
08 | Jari Arkko | [Ballot comment] What makes it hard to read this spec is that the definitions are almost, but not entirely, free of context. A set of … [Ballot comment] What makes it hard to read this spec is that the definitions are almost, but not entirely, free of context. A set of addresses is a context for some statement about them. Your specification defines the format of the statement about time, but does not fully define what objects (addresses) it applies to. You could also have chosen between including the object in question in the format or leaving the object to the definition of whoever uses this format. Let me compare this definition to something that we've done in the RADIUS, Diameter, or MIB spaces. Typically, there's a definition of a datatype (such as integer, time, utf8 string or even a filter definition). Separate from these we have definition of attributes or MIB objects that employ these datatypes. Those definitions give the context and rules how to interprete the values. The datatype definitions are simply for data items, void of any context such as what this integer/time/string would relate to. Something to consider here? Here's what idnits had to say: The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? |
2008-06-26
|
08 | Jari Arkko | [Ballot discuss] The functionality that this draft specifies is good and needed. However, I had difficulty in reading this specification. My main issue is that … [Ballot discuss] The functionality that this draft specifies is good and needed. However, I had difficulty in reading this specification. My main issue is that it has been made so general that in many places it is hard to understand what the actual rules about the TLV are. Some examples: > A Time TLV may be a packet, message or address block TLV. This is the only place in the document that mentions packet TLV. However, according to packetbb (that I have just glanced at so far) packet, message, and address block TLVs appear to be separate entities. If you really intended to allow the Time TLV to be used as a Packet TLV, perhaps you need specify this in more detail. Otherwise, you can change the quoted text to include only message and address block TLVs. > IANA is requested to assign the same numerical value to the message > TLV and address block TLV types with the same mnemonic. So, you have two different entities with different names, but they have the same mnemonic and code points. Confusing. I wonder if one entity which is simply used in different contexts would work better, or if the packetbb structure does not allow this, just define clearly separate entities with separate names and code points (but possibly the same format). Or maybe you have gone too far in the definitions; you could have just defined the format and allowed other MANET documents employ the time format in the definition of specific TLVs. That way it would have been very clear what kind of requirements apply (e.g., how many times are needed, what the times apply to, etc.) I am not convinced that messages and address blocks are the only things that ever need time values in the MANET space. > = {}* Parsing this format requires knowning the length. You get the length from the TLV header. Perhaps obvious, but stating this would have made reading the document easier for me. > In a multivalue Time TLV, each single value subfield of the > multivalue Time TLV is defined as above. Note that [1] requires that > each single value subfield has the same length (i.e. the same value > of n) but they need not use the same values of to . I do not understand how you differentiate between a single value and multiple values. For instance, if there are three values then the number of octets is odd, which is also true for single values. > A VALIDITY_TIME TLV is an address block TLV that defines the validity > time of the addresses to which the TLV is associated. After this > time the receiving node MUST consider the addresses to no longer be > valid (unless these are repeated in a later message). What addresses? See also the last paragraph of my IANA comment above. |
2008-06-26
|
08 | Jari Arkko | [Ballot comment] Let me compare this definition to something that we've done in the RADIUS, Diameter, or MIB spaces. Typically, there's a definition of a … [Ballot comment] Let me compare this definition to something that we've done in the RADIUS, Diameter, or MIB spaces. Typically, there's a definition of a datatype (such as integer, time, utf8 string or even a filter definition). Separate from these we have definition of attributes or MIB objects that employ these datatypes. Those definitions give the context and rules how to interprete the values. The datatype definitions are simply for data items, void of any context such as what this integer/time/string would relate to. Something to consider here? Here's what idnits had to say: The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? |
2008-06-26
|
08 | Jari Arkko | [Ballot discuss] The functionality that this draft specifies is good and needed. However, I had difficulty in reading this specification. My main issue is that … [Ballot discuss] The functionality that this draft specifies is good and needed. However, I had difficulty in reading this specification. My main issue is that it has been made so general that in many places it is hard to understand what the actual rules about the TLV are. Some examples: > A Time TLV may be a packet, message or address block TLV. This is the only place in the document that mentions packet TLV. However, according to packetbb (that I have just glanced at so far) packet, message, and address block TLVs appear to be separate entities. If you really intended to allow the Time TLV to be used as a Packet TLV, perhaps you need specify this in more detail. Otherwise, you can change the quoted text to include only message and address block TLVs. > IANA is requested to assign the same numerical value to the message > TLV and address block TLV types with the same mnemonic. So, you have two different entities with different names, but they have the same mnemonic and code points. Confusing. I wonder if one entity which is simply used in different contexts would work better, or if the packetbb structure does not allow this, just define clearly separate entities with separate names and code points (but possibly the same format). Or maybe you have gone too far in the definitions; you could have just defined the format and allowed other MANET documents employ the time format in the definition of specific TLVs. That way it would have been very clear what kind of requirements apply (e.g., how many times are needed, what the times apply to, etc.) I am not convinced that messages and address blocks are the only things that ever need time values in the MANET space. > = {}* Parsing this format requires knowning the length. You get the length from the TLV header. Perhaps obvious, but stating this would have made reading the document easier for me. > In a multivalue Time TLV, each single value subfield of the > multivalue Time TLV is defined as above. Note that [1] requires that > each single value subfield has the same length (i.e. the same value > of n) but they need not use the same values of to . I do not understand how you differentiate between a single value and multiple values. For instance, if there are three values then the number of octets is odd, which is also true for single values. > A VALIDITY_TIME TLV is an address block TLV that defines the validity > time of the addresses to which the TLV is associated. After this > time the receiving node MUST consider the addresses to no longer be > valid (unless these are repeated in a later message). What addresses? See also the last paragraph of my IANA comment above. What makes it hard to read this spec is that the definitions are almost, but not entirely, free of context. A set of addresses is a context for some statement about them. Your specification defines the format of the statement about time, but does not fully define what objects (addresses) it applies to. You could also have chosen between including the object in question in the format or leaving the object to the definition of whoever uses this format. |
2008-02-28
|
08 | Ross Callon | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Ross Callon |
2008-01-24
|
08 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza |
2008-01-24
|
08 | Tim Polk | [Ballot discuss] The Security Considerations section is inadequate. It needs to be noted that the format does not support any of the security services (authentication, … [Ballot discuss] The Security Considerations section is inadequate. It needs to be noted that the format does not support any of the security services (authentication, integrity, confidentiality). Provisioning such services, if required, is left to the designers of any protocol that uses this format. In particular, authenticating the source of the TLV and the integrity of the contents would seem important to *any* protocol that uses this TLV. Otherwise, substitution attacks would cause the reciever to trust out-of-date information, reject current information as stale, etc. (On the other hand, confidentiality may not always be required.) |
2008-01-24
|
08 | Tim Polk | [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk |
2008-01-24
|
08 | Magnus Westerlund | [Ballot discuss] Section 6: The field of a single value Time TLV is specified, using the regular expression syntax of [1], by: In … [Ballot discuss] Section 6: The field of a single value Time TLV is specified, using the regular expression syntax of [1], by: In my opinion the stated reference does not define a working language for expressing syntax. It for example lacks precedence rules and has no words about usage of any type of parantheses despite them being used. |
2008-01-24
|
08 | Magnus Westerlund | [Ballot Position Update] Position for Magnus Westerlund has been changed to Discuss from No Objection by Magnus Westerlund |
2008-01-24
|
08 | Magnus Westerlund | [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss by Magnus Westerlund |
2008-01-24
|
08 | Magnus Westerlund | [Ballot Position Update] New position, Discuss, has been recorded by Magnus Westerlund |
2008-01-24
|
08 | Dan Romascanu | [Ballot discuss] The document is depending on draft-ietf-manet-packetbb which is already the object of a number of DISCUSSes arounf the justification and efficiency of the … [Ballot discuss] The document is depending on draft-ietf-manet-packetbb which is already the object of a number of DISCUSSes arounf the justification and efficiency of the multi-message format. I believe these need to be solved first before this document is approved. I am also concerned about the null content security considerations section. I would expect that at least authentication considerations and possible attacks resulting in the modification or non-delivery of the time TLVs be mentioned together with references to the security measures to prevent these. I would hold this part of the DISCUSS until a security review is posted, or the issue is covered by one of the Security ADs. |
2008-01-24
|
08 | Dan Romascanu | [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu |
2008-01-23
|
08 | Lars Eggert | [Ballot comment] I agree with the gen-art reviewer that the concept of "distance" is not well-explained. I'm also questioning why it makes sense to specify … [Ballot comment] I agree with the gen-art reviewer that the concept of "distance" is not well-explained. I'm also questioning why it makes sense to specify a relatively complex construct such as distance-dependent time in a generic TLV format - is this really common enough across MANET protocols so that it needs to be specified generically? (I've never seen it used for any other protocol.) Finally, Chris raises a good point - it's unclear why a new fixed-point format is the right thing here, especially since it can only be understood if one knows what "C" is in use. Burning a few more bits and eliminating "C" seems to be the right tradeoff. |
2008-01-23
|
08 | Jari Arkko | [Ballot discuss] The functionality that this draft specifies is good and needed. However, I had difficulty in reading this specification. My main issue is that … [Ballot discuss] The functionality that this draft specifies is good and needed. However, I had difficulty in reading this specification. My main issue is that it has been made so general that in many places it is hard to understand what the actual rules about the TLV are. Some examples: > A Time TLV may be a packet, message or address block TLV. This is the only place in the document that mentions packet TLV. However, according to packetbb (that I have just glanced at so far) packet, message, and address block TLVs appear to be separate entities. If you really intended to allow the Time TLV to be used as a Packet TLV, perhaps you need specify this in more detail. Otherwise, you can change the quoted text to include only message and address block TLVs. > IANA is requested to assign the same numerical value to the message > TLV and address block TLV types with the same mnemonic. So, you have two different entities with different names, but they have the same mnemonic and code points. Confusing. I wonder if one entity which is simply used in different contexts would work better, or if the packetbb structure does not allow this, just define clearly separate entities with separate names and code points (but possibly the same format). Or maybe you have gone too far in the definitions; you could have just defined the format and allowed other MANET documents employ the time format in the definition of specific TLVs. That way it would have been very clear what kind of requirements apply (e.g., how many times are needed, what the times apply to, etc.) I am not convinced that messages and address blocks are the only things that ever need time values in the MANET space. > = {}* Parsing this format requires knowning the length. You get the length from the TLV header. Perhaps obvious, but stating this would have made reading the document easier for me. > In a multivalue Time TLV, each single value subfield of the > multivalue Time TLV is defined as above. Note that [1] requires that > each single value subfield has the same length (i.e. the same value > of n) but they need not use the same values of to . I do not understand how you differentiate between a single value and multiple values. For instance, if there are three values then the number of octets is odd, which is also true for single values. > A VALIDITY_TIME TLV is an address block TLV that defines the validity > time of the addresses to which the TLV is associated. After this > time the receiving node MUST consider the addresses to no longer be > valid (unless these are repeated in a later message). What addresses? See also the last paragraph of my IANA comment above. What makes it hard to read this spec is that the definitions are almost, but not entirely, free of context. A set of addresses is a context for some statement about them. Your specification defines the format of the statement about time, but does not fully define what objects (addresses) it applies to. You could also have chosen between including the object in question in the format or leaving the object to the definition of whoever uses this format. Let me compare this definition to something that we've done in the RADIUS, Diameter, or MIB spaces. Typically, there's a definition of a datatype (such as integer, time, utf8 string or even a filter definition). Separate from these we have definition of attributes or MIB objects that employ these datatypes. Those definitions give the context and rules how to interprete the values. The datatype definitions are simply for data items, void of any context such as what this integer/time/string would relate to. Something to consider here? |
2008-01-23
|
08 | Lars Eggert | [Ballot Position Update] New position, Abstain, has been recorded by Lars Eggert |
2008-01-23
|
08 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko |
2008-01-23
|
08 | Jari Arkko | |
2008-01-22
|
08 | Russ Housley | [Ballot discuss] Eric Gray wrote a fairly critical Gen-ART Review, but there has not been a response to it. The review can be found … [Ballot discuss] Eric Gray wrote a fairly critical Gen-ART Review, but there has not been a response to it. The review can be found at: http://www.alvestrand.no/ietf/gen/reviews/ draft-ietf-manet-timetlv-04-gray.txt While I do not expect the authors to agree with all of the concerns that are raised, I do expect to see a response to these Last Call comments. |
2008-01-22
|
08 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley |
2008-01-21
|
08 | Chris Newman | [Ballot comment] I saw no discussion in this document justifying the complexity of creating a new custom 8-bit floating point number format rather than just … [Ballot comment] I saw no discussion in this document justifying the complexity of creating a new custom 8-bit floating point number format rather than just using a simple 32-bit integer. |
2008-01-21
|
08 | Chris Newman | [Ballot Position Update] New position, Abstain, has been recorded by Chris Newman |
2008-01-19
|
08 | Ross Callon | [Ballot Position Update] New position, Yes, has been recorded for Ross Callon |
2008-01-19
|
08 | Ross Callon | Ballot has been issued by Ross Callon |
2008-01-19
|
08 | Ross Callon | Created "Approve" ballot |
2008-01-19
|
08 | Ross Callon | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Ross Callon |
2008-01-18
|
08 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Angelos Keromytis. |
2008-01-16
|
08 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2008-01-07
|
08 | Amanda Baber | IANA Last Call comments: [ Note: The registries defined by draft-ietf-manet-packetbb-11.txt do not contain elements for Type Extension or Description. Either that document or this … IANA Last Call comments: [ Note: The registries defined by draft-ietf-manet-packetbb-11.txt do not contain elements for Type Extension or Description. Either that document or this document needs to be adjusted accordingly. ] Action 1 (Section 9.1): Upon approval of this document, the IANA will make the following assignments in the "MANET Parameters" registry located at http://www.iana.org/assignments/TBD sub-registry "Message TLV Types" Type Name Reference ------ -------------------- ------------------------ TBD1 VALIDITY_TIME [RFC-manet-timetlv-04] TBD2 INTERVAL_TIME [RFC-manet-timetlv-04] Action 2 (Section 9.2): Upon approval of this document, the IANA will make the following assignments in the "MANET Parameters" registry located at http://www.iana.org/assignments/TBD sub-registry "Address Block TLV Types" Type Name Reference ------ -------------------- ------------------------ TBD3 VALIDITY_TIME [RFC-manet-timetlv-04] TBD4 INTERVAL_TIME [RFC-manet-timetlv-04] We understand the above to be the only IANA Actions for this document. |
2008-01-03
|
08 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Angelos Keromytis |
2008-01-03
|
08 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Angelos Keromytis |
2008-01-02
|
08 | Amy Vezza | Last call sent |
2008-01-02
|
08 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2008-01-02
|
08 | Ross Callon | Placed on agenda for telechat - 2008-01-24 by Ross Callon |
2008-01-02
|
08 | Ross Callon | State Changes to Last Call Requested from Publication Requested by Ross Callon |
2008-01-02
|
08 | Ross Callon | Last Call was requested by Ross Callon |
2008-01-02
|
08 | (System) | Ballot writeup text was added |
2008-01-02
|
08 | (System) | Last call text was added |
2008-01-02
|
08 | (System) | Ballot approval text was added |
2007-12-17
|
08 | Dinara Suleymanova | PROTO Write-up 1. Have the chairs personally reviewed this version of the Internet Draft (I-D), and in particular, do they believe this I-D is ready … PROTO Write-up 1. Have the chairs personally reviewed this version of the Internet Draft (I-D), and in particular, do they believe this I-D is ready to forward to the IESG for publication? Yes the chairs have reviewed this document, and we believe that it is ready to go to the IETF for publication. 2. Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? Yes the I-D has been adequately reviewed. 3. Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? We do not have any particular concerns regarding additional required reviews for this document. 4. Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. No contentious issues were raised during WG discussion on this document. 5. How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The three main WG protocol documents contain a reference to this I-D. That is, NHDP, DYMO, and OLSRv2 all utilize the TLV format and types specified in this document. 6. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email to the Responsible Area Director. There was no WG conflict regarding this document. 7. Have the chairs verified that the document adheres to all of the I-D Checklist items ? Yes the document adheres to the I-D checklist items. 8. Is the document split into normative and informative references? Are there normative references to I-Ds, where the I-Ds are not also ready for advancement or are otherwise in an unclear state? (note here that the RFC editor will not publish an RFC with normative references to I-Ds, it will delay publication until all such I-Ds are also ready for publication as RFCs.) Yes the references are split into normative and informative references. 9. What is the intended status of the document? (e.g., Proposed Standard, Informational?) Proposed Standard. 10. For Standards Track and BCP documents, the IESG approval announcement includes a write-up section with the following sections: * Technical Summary This document specifies the syntax of a PacketBB (publication requested) TLV for representing time. It also defines two TLV types that conform to the TimeTLV representation. * Working Group Summary This document contains information that was originally in OLSRv2. It was pulled out and generalized, since it is applicable to many MANET WG protocols. It is an integral component of NHDP, OLSRv2, and DYMO. * Protocol Quality The TimeTLV format was architected to represent a wide range of time values. The necessity and flexibility of the format is demonstrated by the two TimeTLV type instances specified in this document. |
2007-12-17
|
08 | Dinara Suleymanova | Draft Added by Dinara Suleymanova in state Publication Requested |
2007-11-19
|
04 | (System) | New version available: draft-ietf-manet-timetlv-04.txt |
2007-11-15
|
03 | (System) | New version available: draft-ietf-manet-timetlv-03.txt |
2007-08-28
|
02 | (System) | New version available: draft-ietf-manet-timetlv-02.txt |
2007-07-03
|
01 | (System) | New version available: draft-ietf-manet-timetlv-01.txt |
2007-04-20
|
00 | (System) | New version available: draft-ietf-manet-timetlv-00.txt |