IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2013-06-13. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: Pete, Barry, Benoit
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Services Field Protocol Reference -------------- -------- --------- SIP+D2W WS TBD: this document SIPS+D2W WS TBD: this document
PROBE Retransmit timeout, Increase timeout UNREACHABLE N or more Send multicast NS retransmissions.How is it possible for the event of 'more than N retransmissions' to happen in PROBE state? You probably need:
PROBE Retransmit timeout, Increase timeout UNREACHABLE Nth retransmission Send multicast NS
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
2.2.2 Returning Items
2.3 Status Changes
2.3.1 New Items
2.3.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
3.2.2 Returning Items
3.3 Status Changes
3.3.1 New Items
3.3.2 Returning Items
3.4 IRTF and Independent Submission Stream Documents
3.4.1 New Items
3.4.2 Returning Items
3.4.3 For Action
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
1222 EDT break
1227 EDT back
5. IAB News We can use
6. Management Issues
7. Agenda Working Group News
Jari: remember BoF call next week
1401 EDT Adjourned
(at 2013-06-13 07:30:11 PDT)
Joel noticed this in his comment: wss = tls in 5.2.1 sips + ws = port 443 in 5.3. wouldn't it be wss? If this is in fact a problem, the same problem might exist in 10.2: Services Field Protocol Reference -------------- -------- --------- SIP+D2W WS TBD: this document SIPS+D2W WS TBD: this document I am saying this not because I know it's wrong but because it looked like it might be, so no need to respond if this is in fact correct. I agree with Barry's comment on '_this section is non-normative_', and would tend to echo Pete's recommendation not to use UTF-8 transport. Overall, the document looks good—thanks for doing this work!
(1) I don't get why section 7 is non-normative? Don't you (practically) have to require some method for user authentication? And if so, doesn't something have to be MTI so that a random client and a random server can choose that option and get interop? Also, depending on the fact that digest auth in SIP is MTI would only be right if that's actually used - is it? This also relates to the ongoing discussion generated by Yaron's secdir review  with which I mostly agree. That discussion is treading now well-worn ground about the difference between MTI and mandatory to use but looks like its heading in the right direction and the authors have said they'll be updating the draft because of it.  http://www.ietf.org/mail-archive/web/secdir/current/msg03890.html (2) 9.1 'probably not be appropriate' seems very vague. Can't you do better? Maybe say that different private keys SHOULD be used for these (as they're at different layers of the s/w stack). And you also need to consider how the subject name in the certificate(s) needs to (or doesn't need to) match any SIP identifiers. This was also raised in the secdir review. on Barry's discuss: HTTP Forwarded (and XFF) headers have some privacy considerations. If you are going to add text about using those, then you may need to also consider that. (I've not thought through whether it'd expose something that is sometimes better not always exposed in this case.)
write-up nit: AD should now be Richard I guess - Abstract: I don't get why this 'updates' 3261? Isn't it ok to implement 3261 without this? I guess that's down to section 3 changing a 3261 MUST, but that still doesn't seem to require a 3261 implementer to do something different if they're not doing WS. (In which case, how is section 3 non-normative? Is the ref to section 3 in section 1 correct actually?) Aha! Is it 5.2 that you mean and is the reason for the updates because you're adding to the ABNF and don't want someone else to add a conflicting thing later? If so, saying that in section 1 would be good. (And its a fine reason to update 3261.) - 4.1: what is version 13? - Is 5.2.4 really an update to 3261? It doesn't seem like one to me, but rather you're saying that implementations of this are ok if they only do WS. That is a difference from, but not an update to, 3261. - 9.1 s/recommended/RECOMMENDED/ would be better if you do mean the 2119 term. - 10.2 - what's D2W mean? No harm explaining. - 9.2 seems to imply that 5246 needs to be a normative reference.
Suresh Krishnan's Gen-ART review caused some discussion between Suresh and the authors in April. My understanding is that changes were agreed. For instance, Suresh raised an issue about Section 5.2.2 mixing 'transport' and 'transport-param'. I think it would be important to get this and possibly other agreed changes into the draft before the final approval. Will we see a -09 soon?
4.2: There are two cases where I'm very worried about using UTF-8 framing for SIP messages: The first is for binary content, which though relatively unused in SIP is still possible. For a binary body, you'd have to figure out some sort of encoding that could go into UTF-8 framing. The other case is body Content-Types that have non-ASCII and non-UTF-8 charsets. Again, rare, but I would hate to see how implementers deal with putting an ISO-2022-JP body into a UTF-8 frame. I think you've got two solutions: 1) Say 'MUST NOT use UTF-8 framing for non-ASCII/UTF-8 data; or 2) Say 'MUST use binary framing'. I have a slight inclination towards simply requiring binary framing; it's simpler for the implementer and allowing UTF-8 framing at all makes it possible to accidentally do the wrong thing. But either one will do.
I agree with Barry and Stephen regarding the labeling of non-normative sections, and go one step further: Your use of the word normative is pretty bogus. There are lots of statements throughout otherwise unlabeled sections that are not normative (i.e., do not describe a standard of behavior), and there are places in labeled non-normative sections that clearly do describe a standard of behavior. Please get rid of these labels. Describe what things need to be done for interoperability's sake with MUSTs and SHOULDs and use other descriptive text for the rest. At best, these are unnecessary distractions. At worst, their existence will have implementers ignoring important information. (Yes, this is just a COMMENT; I'm not going to pitch a fit if I end up in the rough on this point. But you're hearing from a few people that these statements are a problem and I hope you take that into account.) Abstract: This document normatively updates RFC 3261. What would it be to non-normatively update a document? Delete the word 'normatively'. 4.1: The WebSocket messages transmitted over this connection MUST conform to the negotiated WebSocket sub-protocol. This is a little ambiguous. Do you mean, 'Messages other than SIP requests and responses MUST NOT be transmitted over this connection.'? That makes a bit more sense to me. I'm not sure what the current sentence means. 5.1: Content-Length header in SIP messages is optional when they are transported using the WebSocket sub-protocol. The word 'optional' sounds like a 2119 use to me. Any reason it's lowercase? (Note: Please don't just change it blindly. Maybe it's not meant as a 2119 use. In that case, you might want to change it to 'not necessary'. But I thought you might want to check it.) 5.2.3: I agree with Stephen that there's no need to update 3261, but rather say that SIP-over-Websocket simply relaxes a requirement of 3261.
- Agreed with Barry's comment on Section 3 ' _This section is non-normative._' I see Section 3 as a useful introductory text, exactly like Section 1. And ... Section 1 doesn't have '_This section is non-normative._ '. I wonder why if I follow your logic? If the Section 3 content was included in section 1, would this required '_This section is non-normative._If '? You see, ' _This section is non-normative._' leads to so more questions than clarifications. Like Barry (and others), 'I *really* ask you not to do this. ' - - As far as I can tell at https://www.iana.org/assignments/websocket/websocket.xml#subprotocol-name, SIP will be the first RFC-specified assignment. From 6455 10. The request MAY include a header field with the name |Sec-WebSocket-Protocol|. If present, this value indicates one or more comma-separated subprotocol the client wishes to speak, ordered by preference. The elements that comprise this value MUST be non-empty strings with characters in the range U+0021 to U+007E not including separator characters as defined in [RFC2616] and MUST all be unique strings. The ABNF for the value of this header field is 1#token, where the definitions of constructs and rules are as given in [RFC2616]. Should this document explain what happens if some other subprotocols are requested at the same time? Disclaimer: I'm not an expert in Websocket, and this comment might just prove it. In other words, if this is a stupid comment, don't bother replying. - Any reason why second paragraph of Section 4.1 is indented. I looks like a quotation Same remark for the last paragraph of section 5.1
I like this document, and think this extension to SIP will be useful. I have one blocking point that should be easy to sort out, and then a few non-blocking comments that I hope you'll consider. -- Section 5.2.3 -- Given draft-ietf-appsawg-http-forwarded (in the RFC Editor queue), which defines the HTTP 'Forwarded' header, shouldn't this protocol also specify that if 'received' *is* used, information should be taken from the handshake's 'Forwarded' header if there is one?
Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them: -- General -- _This section is non-normative._ I understand that the WebSockets document does this, but... is this really necessary? The IETF manages to publish a large number of normative documents that contain non-normative sections, examples, and so on. Most of them don't have this silliness in them. This is non-blocking -- I can't justify a DISCUSS on this point -- but I *really* ask you not to do this. -- Section 4.1 -- In the description of the handshake, you say that the Sec-WebSocket-Protocol header must 'include' and 'contain' the string 'sip'. Does that mean that there might also be other things in the value of that header? Or should these say 'consist of'? -- Section 5.2.4 -- I suggest wrapping this up by being explicit about the change to the 3261 text. Like this: ADD The sentence quoted above from [RFC3261] section 18 is thus amended as follows: All SIP elements MUST implement at least one of the following: * Both UDP and TCP * SIP WebSocket SIP elements MAY implement other protocols. END -- Section 6 -- Can you add any explanation of the differences among the various keepalives, and any advice about how one might choose which to use? Is there any reason to use multiple of them? If so, please explain; if not, please say so. ======== Other comments; no need to respond to these. Take them or modify them as you please: -- Section 4.2 -- I find this section very odd, though, I suppose, not objectionable. I expected he third sentence to say something like, 'Therefore, everything's A-OK, and we can do SIP over WebSockets. But no, you simply say that the SIP clients and servers you're defining here are just like any other SIP clients and servers. Is this really necessary to say? Would anyone possibly imagine that, say, they could write a client that didn't do binary? -- Section 7 -- For many web applications the value of such a Cookie is provided by the web server once the user has authenticated themselves to the web server Oof. Can we avoid singular usage of 'themselves'? It should work fine to say, 'once the user is [or has] authenticated to the web server,' leaving off the reflexive pronoun.
I did have one question. In this text: 3. The WebSocket Protocol The WebSocket connection handshake is based on HTTP [RFC2616] and utilizes the HTTP GET method with an 'Upgrade' request. This is sent by the client and then answered by the server (if the negotiation succeeded) with an HTTP 101 status code. Once the handshake is completed the connection upgrades from HTTP to the WebSocket protocol. This handshake procedure is designed to reuse the existing HTTP infrastructure. During the connection handshake, client and server agree on the application protocol to use on top of the WebSocket transport. Such application protocol (also known as a 'WebSocket sub-protocol') defines the format and semantics of the messages exchanged by the endpoints. This could be a custom protocol or a standardized one (as the WebSocket SIP sub-protocol defined in this document). Once the HTTP 101 response is processed both client and server reuse the underlying TCP connection for sending WebSocket messages and control frames to each other. Unlike plain HTTP, this ^^^^^^ ^^^^^ ^^^^ I think I understand what's meant here, but this statement doesn't seem quite right, when viewed through http://tools.ietf.org/html/rfc2616#section-8.1, which describes Persistent Connections. Could you look for more precise wording for this statement? connection is persistent and can be used for multiple message exchanges.
Support Stephen's discuss positions.
draft-ietf-sipcore-sip-websocket 5.2.1 vs 5.3 wss = tls in 5.2.1 sips + ws = port 443 in 5.3. wouldn't it be wss? In the absence of DNS SRV resource records or an explicit port, the default port for a SIP URI using the 'sip' scheme and the 'ws' transport parameter is 80, and the default port for a SIP URI using the 'sips' scheme and the 'ws' transport parameter is 443.
The document looks good. Is there any hope of a 4861bis?
I support the comments from other ADs about precision in language. I think you would be well advised to tighten the specification. --- The proposed new state machine entry is: PROBE Retransmit timeout, Increase timeout UNREACHABLE N or more Send multicast NS retransmissions. How is it possible for the event of 'more than N retransmissions' to happen in PROBE state? You probably need: PROBE Retransmit timeout, Increase timeout UNREACHABLE Nth retransmission Send multicast NS --- Although you have retained the garbage collection from 4861, you say: A node MAY garbage collect a Neighbor Cache Entry at any time as specified in RFC 4861. This does not change with the introduction of the UNREACHABLE state in the conceptual model. I would have thought that the garbage collection LRU scheme should consider a trade between LRU and UNREACHABLE state? Which would you discard: not used for 29 seconds or unreachable and not used for 28 seconds? Or is this too much fine-tuning?
I'm just short of a DISCUSS on this because there was no response to the appsdir review, which did raise a couple of minor things apart from the many editorial comments in it. I know that Erik isn't happy with the level of editorial commenting in the directorate reviews, but we have to accept that thorough reviewers feel the need to do that. Please do address Murray's comments (and my reply to it) that go beyond mere editorial stuff. -- Section 3 -- A node MAY unicast the first few Neighbor Solicitation messages even while in UNREACHABLE state, but it MUST switch to multicast Neighbor Solicitations sooner or later. This was brought up in the appsdir review: 'first few' and 'sooner or later' are sufficiently inspecific that it calls the need for a 2119 MUST into question. How is the operation of the protocol affected if the node interprets 'first few' to be 3? How about 12? What about 3,141,592? Is it OK if I decide that 'sooner or later' amounts to 'just before the Rapture'? It would probably better here to say what the problem is that the switch to multicast will address, and it's most likely better to skip the 2119 words on that. Something on the order of this: A node can unicast the first few Neighbor Solicitation messages even while in UNREACHABLE state, but [this bad stuff will happen] until it switches to multicast Neighbor Solicitations. Other comments; no need to respond to these. Take them or modify them as you please: -- Section 1 -- nit: 'These short can be' -> 'These short timeouts can be' The last sentence of the first paragraph is punctuated oddly, and I'm not quite sure what it really means: In these cases, when NUD fails, the host will try the alternative neighbor; the next router in the Default Router List, or discard the NCE which will also send using a different router. Is the semicolon just wrong, and there are meant to be three items in the list of what can happen when NUD fails? If so: NEW In these cases, when NUD fails the host will try the alternative neighbor, try the next router in the Default Router List, or discard the NCE which will also send using a different router. (You need to repeat the verb 'try' because the third item in the list has a different verb.) Still on that sentence, what does the last item mean?: discard the NCE which will also send using a different router. It looks like this is saying that the third option is to discard the NCE, and a result of that will be a switch to a different router. Is that right? If so, re-wording a little will help; 'will send using a different router' makes me think that there's some noun missing after 'send'. Maybe, 'discard the NCE (which also results in the use of a different router).' -- Section 3 -- Packets should be sent following the next-hop selection algorithm in section 5.2 in [RFC4861] which disregards NCEs that are not reachable. There's nothing at all wrong with this, but I want to note that if you write it this way: ...algorithm in [RFC4861], Section 5.2, which... then the tool that converts the RFCs to HTML will generate a link to the correct section directly. Otherwise, the link will just go to the top of 4861.
I like this document. It's short and clear. I do have one comment I'm hoping you'll consider. In this text: 4. Example Algorithm This section is NOT normative, but specifies a simple implementation which conforms with this document. I'm seeing the 'NOT normative' statement, which is fine, but I'm also seeing several occurrences of 'recommended' in the following paragraphs. I'm not confused by the use of 'recommended' in lower case. My issue is that I'm not sure where the recommendation is coming from - whether it's in the context of this example algorithm, or from somewhere else. If I'm guessing right, and the context is this example algorithm, would it be easier to understand if you replace 'recommended behavior' with something like 'behavior used by this implementation'? The recommended behavior is to have 5 attempts, with timing spacing of 0 (initial request), 1 second later, 3 seconds after the first retransmission, then 9, then 27, and switch to UNREACHABLE after the first three transmissions. Thus relative to the time of the first transmissions the retransmissions would occur at 1 second, 4 seconds, 13 seconds, and finally 40 seconds. At 4 seconds from the first transmission the NCE would be marked UNREACHABLE. That recommended behavior corresponds to: MAX_UNICAST_SOLICIT=5 RETRANS_TIMER=1 (default) MAX_RETRANS_TIMER=60 BACKOFF_MULTIPLE=3 MARK_UNREACHABLE=3 After 3 retransmissions the implementation would mark the NCE UNREACHABLE. That results in trying an alternative neighbor, such as another default router or ignoring a redirect as specified in [RFC4861]. With the above recommended values that would occur after 4 seconds after the first transmission compared to the 2 seconds using the fixed scheme in [RFC4861]. That additional delay is small compared to the default 30,000 milliseconds ReachableTime. After 5 transmissions, i.e., 40 seconds after the initial transmission, the recommended behavior is to switch to multicast NUD probes. In the language of the state machine in [RFC4861] that corresponds to the action 'Discard entry'. Thus any attempts to send future packets would result in sending multicast NS packets. An implementation MAY retain the backoff value as it switches to multicast NUD probes. The potential downside of deferring switching to multicast is that it would take longer for NUD to handle a change in a link-layer address i.e., the case when a host or a router changes their link-layer address while keeping the same IPv6 address. However, [RFC4861] says that a node MAY send unsolicited NS to handle that case, which is rather infrequent in operational networks.
I found the chatty style at odds with the demands of a precise definition of the operation of a state machine. Please can you look at the following: 'Giving up after three packets spaced one second apart...' You need to say what you are 'giving up', but in any case I am not sure 'giving up' is the right term. +++ 'from implementations that try for a long time' Try what? +++ 'link-layer address of the destination has changed' Isn't that the LL addr of the neighbor? +++ 'we will instead transition' I imagine the node will rather than the authors +++ 'then it makes sense to stop..' Don't you mean: 'it is RECOMMENDED' +++ 'but it MUST switch to multicast Neighbor Solicitations sooner or later.' Do you really mean 'when it can be bothered' which is what the statement says? ==== A few nits that might usefully be addressed if you are re-spinning the draft: 'If implementations' I think that should be 'If an implementation'
This is a style nit; feel free to ignore, but consider this text: In the HELD protocol, the inclusion of a measurement request in an error response with a code of 'locationUnknown' indicates that the LIS believes that providing the indicated measurements would increase the likelihood of a subsequent request being successful. Of course, the LIS has no beliefs. Rather, the LIS has capabilities—it can make use of certain types of information, and might want to indicate to the peer that measurements of that type might result in a location result being determined where none can presently be determined. So I would phrase it thusly (and probably incorrectly—I'm just doing this to illustrate my gripe): In the HELD protocol, the inclusion of a measurement request in an error response with a code of 'locationUnknown' indicates that the LIS has the capability to use the indicated measurements to increase the likelihood of a subsequent request being successful. As I say, this is a style gripe, and if you want to just ignore it, I won't complain. The use of the term 'believes' to refer to capabilities also occurs earlier in this section, and may occur elsewhere in the document—I don't know because I haven't finished reading yet, but I won't call out any more of these that I see, since I think this gets the point across. Though many of the underlying protocols support extension, creation of specific XML- based extensions to the measurement format is favored over accommodating protocol-specific extensions in generic containers. By 'is favored' do you mean 'works better because of X' or 'we recommend as a standard practice for consistency' or something else? It might be better to use the active voice here and be more explicit about what you mean. This may be unnecessary for readers who are already deeply familiar with geopriv, so feel free to ignore this, but as a relatively naive reader I am left somewhat confused by this advice. The definition for giaddr says the address is a dotted quad or an IPv6 address, but in the example you use an IPv6-encoded IPv4 address. This seems contradictory. If dotted quads and IPv6-encoded IPv4 addresses are interchangeable, the normative text should say so, but why create the opportunity for trouble here? If it were up to me I would require dotted quad for IPv4 and IPv6 address representations only for IPv6 addresses. In 5.3, this doesn't parse: parameter: The 'parameter' element identifies an optional measurements are requested for each measured access point. I think someone might have made a cut-and-paste error here. I don't know what this text is supposed to say, so I can't suggest an edit, but you ought to fix this prior to publication. In 7.1.3, Would a LIS ever use GPS information provided by handsets in combination with WiFi information provided by mobile nodes to populate a mapping database that could then be used to determine locations of other mobile nodes that don't have GPS receivers? IOW, is one benefit of this sort of attack that you could corrupt the LIS' measurement map? In 8.6, the enterprise number is given as optional, but the field is always present in the remote ID option. So why is it optional in the XML? Cool stuff.
As I observed in my Abstain on RFC 6772, I am not comfortable with the motivation for this work, but I (of course) accept that there is a working group chartered to do the work and that there is support from part of the community. In this document my concern manifests that, under the guise of a device doing something to find out where it is located, the device supplies information to a third party that allows that third party to work out where is is located and then (possibly) report back to the device. I can't see how that is consistent with privacy and I regret that we have not devised a way for a device to determine its location without giving away its location. The argument that a Device does not have to supply information to an LIS or ask for its location is true. However, I am exceedingly doubtful that such features will be off by default or that they will be configurable by the average user. We should be looking for ways to improve function for the user without sacrificing privacy or security. It is almost certain that this work could be turned around to allow the Device to request, and the LIS to supply, information that the Device could use together with its own measurements to determine its location. Such an approach is computationally identical, but moves the venue of the computation to the Device and so preserves privacy. It seems doubtful that there is anything that the authors can do to this document to resolve my concerns, and so rather than force a debate with unlikely positive outcome, I will Abstain on this document. --- There are so many Discusses and Comments on this document it is hard to find something new to say. I would observe that I found the document generally quite readable, and that the techncial work seems sound modulo the concerns expressed by others. --- Need to expand LIS in the Abstract. --- 4.1.2 A Device can use this attribute to prevent the LIS from retaining measurement data or limit the time that a LIS retains this information. I doubt this! I think the attribute is a request. The device cannot actually control the LIS. And this is not mitigated by: The LIS MUST NOT keep location-related measurement data beyond the time indicated in the 'expires' attribute. You are attempting to use 2119 language to constrain implementations of function that are not relevant to bits on the wire. Such statements are at best false comforts. It would be better to not include them. Perhaps there is a relationship to how the information is used in the scope of this document that you *can* say. For example: The LIS MUST NOT use location-related measurement data to determine location information returned to the Device beyond the time indicated in the 'expires' attribute. --- 6.1 It is less desirable to distribute measurement data in the same fashion as location information. Measurement data is less useful to location recipients than location information. Therefore, a simple distribution model is desirable. I think there is a double negative here. If there is an implicit statement that location information is distributed in a privacy-safe way, then you are probably saying that the measurement information is less privacy-sensistive and could be distributed in a less privacy-safe way. But that is not 'it is less desirable' which would mean there is a desire not to. Maybe 'there is less need'. --- 6.1 No entity is permitted to redistribute measurement data. The Device directs other entities in how measurement data is used and retained. You surely understand that writing this in an RFC will not actually have any impact on what implementations of an LIS do, or what the NSA instructs operators to do. [Other secret agencies also exist.] What, then, is the value of this statement? Ditto 6.2 A LIS MUST NOT reveal location-related measurement data or location information based on measurement data to any other entity unless directed to do so by the Device.
As a bit of background, geopriv's security and privacy model does my head in (that's my fault, not yours;-). I really do appreciate the obvious effort that's been devoted to security and privacy issues in this draft, but yet again, I don't see how it all adds up to being other than privacy unfriendly. That said, I have a number of specific discuss points - some of 'em should be very easy to clear, so don't be put off that there's so many. There may also be some that can be cleared based on a bit more text describing the schema, which I didn't go over fully. (1) I think this draft needs to say that a device MUST include some interface(s) that allows for user or sysadmin control over what measurements will be sent and to whom. I don't think that can be done in a single sentence so I'm not sure right now how to fix this. You may argue that those controls are elsewhere in the geopriv set of RFCs, but I didn't see any references that helped me on this. So putting this as a question: how is an implementer supposed to know when to just send a requested measurement and when to not send some? (If all implementers just make this up, then the only way to get good interop seems to be if all coders send all the measurements that they can all the time.) (2) There are a bunch of IPR declarations on this. I didn't see where the WG had discussed those. Can someone point me at the relevant bit of WG archive or minutes? I did see discussion on IPR related to 4119 but I've no idea if that's the same thing or not. I'm also not clear if the 4 declarations are really one or not, but I expect the WG know, so I'm just checking that the WG did consider all that and were ok to proceed. (The write-up says there is one disclosure and that was discussed, but I see 4, hence the question, maybe its just the writeup or maybe all 4 are really one thing, I dunno.) (3) section 3 says: 'Use of location-related measurement data is at the discretion of the LIS' - that's ambiguous and in a possibly bad way. I think you mean that the LIS can use the data its given in order to estimate a location using any algorithm. There are two ambiguities in how its stated though: a) it might be read as saying that the LIS is in charge of telling the Device what location-related measurements are to be supplied, and b) it might be read as saying that the LIS can do whatever it wants with the measurements, e.g. send all measurements off to big brother for archiving or to a marketing company without asking. Both a) and b) should be stated as not being at the discretion of the LIS and the statement ought be unambiguous. (4) 4.1.2: What does 'MUST NOT keep' mean? If the request containing the measurements was logged has the LIS 'kept' the measurement? I think you need to be clear on that. I'd prefer if you said it means yes, the measurements MUST NOT be logged. But will implementers really do that? If not, then it seems that the draft is at least a bit misleading. (5) 4.3: could a compromised LIS mount a nice DoS on a network by asking a lot of devices to make many measurements that impact on those devices but maybe also on the n/w as a whole? Is that threat noted? Should you RECOMMEND that devices have some way to sanity check what they're asked to do by/for a LIS? (6) 5.1, if LLDP measurements expose IP addressing then that may a) expose topology information that a sys admin would rather hide and b) involve sending private IP addresses over the public Internet. Don't you need to note those issues and say how to deal with them? You do approach saying that in section 6/7 but I think you need to be more explicit and say which pieces of measurement information are sensitive in which ways (e.g. by adding a list of them) so that implementers can get this right. As-is, I don't think there's enough information in the draft for coders to do a good job. (7) 5.2, (just checking) - aren't there models for using DHCP where the subscriber-id is considered sensitive information? I seem to recall some cases like that but didn't check. Did you? (8) 5.2, if I tell the LIS my DHCP relay/server address doesn't that allow the LIS to start pretending to be that DHCP server in some networks? I didn't see that noted in section 7. (9) 5.3, Why is so much information about an AP allowed to be sent? Why is that all needed? (10) section 6, why don't you say that measurement data MUST be afforded the same protection as location information and then say what that means for interop, e.g. that if location data has to go via TLS, then so MUST measurement data? (11) 6.1, 'No entity is permited to redistribute measurement data' also needs a MUST NOT I think, as in 'A LIS MUST NOT redistribute measurement data.' But then in 6.2 you (twice) say 'unless directed to do so by the Device' - I didn't get how a device can do that? (12) 6.3 - I just want to check since I don't think I get the implications. When would a device request a location URI? What does 'use the measurement data in serving requests' mean? If it means, use the measurements to generate the URI and location information that seems ok (modulo the 1st question). If it means 'also expose the measurement when the location URI is de-referenced' that'd be problematic I think. (13) 6.4 - I don't understand how the 'MUST be trusted' by the LIS thing works. Can you explain? And if that's not covered here, where it it specified? Otherwise how can it be implemented so as to achieve interop? (14) 7.1 - why are threats caused by a LIS revealing location measurements or location information not part of the threat model? (15) 7.1.1 - I don't get this - are you saying that knowing measurement data alone is enough to convince any LIS to hand over location information? That would seem fatal if true so I must be missing something. (16) 7.2.1 to 7.2.3 - what are the mitigations here that I can implement? I don't see 'em. (17) 7.2.4 - this has a MUST saying to put 'trusted' location information first, but doesn't say how to decide if location information is trusted or not so how can I implement that MUST? (18) 7.2.5 - I don't understand what 'stateful examination' might mean here so how can I implement something? Can you clarify what you mean?
- 4 IPR declarations and we start our 70 pages with 'A method is described' ... that gives me patent-cringe (sorry for the snark;-) - section 2: 'Location-related measurement data does not identify a Device' - that is too absolute, such data certainly can identify a Device and a user (even if it changes over time). - section 3, 2nd last para: there are privacy issues even without 3rd parties. - section 3, last para: s/security/security and privacy/ - 4.1.1: last sentence - is that SHOULD correct? What do I do if I'm not abiding by the SHOULD? e.g. can I put in 2 timestamps in one measurement element? If not, then isn't that a MUST? - 4.1.2: How do I know if an expires means which of these things and how do they really differ? I can't see how a LIS can programatically know that. - 4.2 & 4.2.1: Don't you need to say how to calculate the RMS error? Won't coders do different things otherwise? - 5.4, typo: s/cellar/cellular/ nice typo if you consider how serial killers in movies might make use of this protocol though:-) - 5.5.1, I wondered why there are no initial registrations for e.g. Russian or Chinese GNSS systems. Not objecting but I'm curious. - 7.1.5, 1st sentence is broken, not sure what's meant
Discussion between Martin and Suresh (based on Suresh's Gen-ART review) resulted in an agreement to make some changes. Shouldn't we wait for the agreed changes to be submitted in a -08 before approving this document?
4: The example in section 4 shows a 'lm:measurements' element, and many examples in section 5 show a 'measurements' element, but the text in 4.1 talks about a 'measurement' element, and I only find a 'measurement' element example in section 4.3. Which one is section 4.1 (and 4.1.1, 4.2, 4.2.1, and 4.3) intending to talk about? 4.1.1: The 'time' attribute is optional... However, time SHOULD be provided whenever possible. I think your uppercasing is reversed. The 'time' attribute is, as far as I can tell, OPTIONAL, in that it is not required for interoperation, but it should (or perhaps 'is helpful to') be provided whenever possible. 4.1.2: A Device can use this attribute to prevent the LIS from retaining measurement data or limit the time that a LIS retains this information. [...] The LIS MUST NOT keep location-related measurement data beyond the time indicated in the 'expires' attribute. Is this a privacy requirement or is there some other reason why a device would want to 'prevent' retention? Making expires mean something other than simple validity and making it a hard requirement to dispose of the data seems to indicate something is going on here that is unstated. If it's a privacy requirement, instead of putting the MUST here, just put a forward pointer to section 6.
4.1.1. Time of Measurement Do you require synchronized times between the Device and the LIS, or it doesn't matter because you don't need to correlate any information from different Devices? AFAICT, the following sentence implies that synchronization is required: The LIS MUST NOT keep location-related measurement data beyond the time indicated in the 'expires' attribute. AFAICT, the LIS coul combine information from the Device and from the Third Party (other), so time synchronization is required between Device and Third Party devices as well. I see section 4.2.1, but don't find the information in there. Background: This is the typical syslog situation for which the NMS doesn't know if the time is synchronized. The convention (at least in Cisco, http://www.cisco.com/en/US/technologies/collateral/tk869/tk769/white_paper_c11-557812.html) is: * Means that time is not authoritative: the software clock is not in sync or has never been set. The * (asterisk) and. (period) characters preceding a syslog message are indicators of a problem with NTP.
- On the edge of being a DISCUSS... Not too happy about the 'measurement' term. http://www.collinsdictionary.com/dictionary/english/measurement?showCookiePolicy=true I wonder what the measurement is: ATM VPI/VCI, VLAN STAG/CTAG, RADIUS fields, L2TP IP address/session, etc.. So basically these are not measurements, simply observed metadata, observed context information. Can you give one example of an attribute that is actually measured? To prove my point, the definition correctly speaks about 'physical properties', not measurement Location Measurement: An observation about the physical properties of a particular Device's network access. I don't know the WG history behind this term, but it confused me. I'll leave that point to the AD to make the right decision. - without basic information about LCP and LIS (described in the introduction), the abstract didn't make sense to me. I had to read it multiple times to understand whether it was the device sending its location to the LIS for a kind of registration, or the LIS using clues (location- related measurement data) received from the device in order to generate more precisely the location for the device. The introduction text helped me understand the abstract. I wish the abstract would be unambiguous. You know, something such as: A method is described by which a Device is able to provide location-related measurement data that gives the location information server extra context information in order to help in a more precise estimation of the Device location. ... EDITORIAL - expand LIS in the abstract - parameter: The 'parameter' element identifies an optional measurements are requested for each measured access point.
Three points I'd like to clarify, please: 1... There's probably just something basic I'm missing here, and when you tell me I'll slap myself on the forehead. -- Section 3 -- Location-related measurement data need not be provided exclusively by Devices. A third party location requester can request location information using measurement data, if they are able and authorized. I am now confused. Based on what I've read up to this point, I thought that devices were giving the LIS masurement data, the LIS was using that to aid in figuring out the locations of the devices, and then whenever any query was made for a device's location, the LIS would give out whatever location it had for the device, as long as the requestor was authorized to make the query. But now I'm not sure that's right. I now think that the device asks for its own location, and as part of the query it gives the measurement data. Do I have that right? Or am I really completely confused? And how do third parties 'request location information using measurement data'? Where do they get the measurement data from? Did the device they're asking about give it to them, too? 2... -- Section 7.1.5 -- Measurement data that is susceptible to this sort of influence MUST be treated as though it were produced by an untrusted Device for those cases where a location recipient might attribute the location information to the LIS. That's a very strong MUST: in order to have a MUST here, I think you have to be sure you've completely identified the 'data that is susceptible to this sort of influence', or at least given enough information that implementors can reliably and completely do the identification. That strikes me as a tall order, and I don't think you've met that here. 3... -- Section 7.2.1 -- Independent confirmation of the veracity of measurement data ensures that the measurement is accurate and that it applies to the correct Device. By gathering the same measurement data from a trusted and independent source, the LIS is able to check that the measurement data is correct. I don't understand: if the LIS can do that, what value is there in having the device sent it? Isn't the whole point of this protocol that having the LIS do that is not possible, or is too difficult or expensive?
Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them: -- Section 8 -- I did not review the schemas. The shepherd says she has passed them through an automated validator, but that expert review of them is not necessary. As these are variations on other, similar geopriv schemas, I think it's OK to accept that assessment, though I'd be happier to have some idea that they were at least thoroughly reviewed by the working group, and not just glossed over as routine. -- Section 3 -- Use of location-related measurement data is at the discretion of the LIS, but the 'method' parameter in the Presence Information Data Format - Location Object (PIDF-LO) [RFC4119] SHOULD be adjusted to reflect the method used. I don't see any connection between the bit before the 'but' and the bit after it, so the conjunction seems weird. If the 'method' parameter is meant to give the LIS useful information for deciding whether to use the data, then it would help to say so. -- Section 4 -- The 'time' attribute is attached to the root 'measurement' element. If it is necessary to provide multiple sets of measurement data with different times, multiple 'measurement' elements SHOULD be provided. I don't understand the SHOULD: what's the alternative? If it's *necessary* to provide multiple sets with different times, it seems to me that the *only* way to do that is to use multiple 'measurement' elements. -- Section 5.3 -- In the definition of regclass: which can be followed by an 'O', 'I' or 'X'. ...which mean what? You have no citation here, as you do in some of the other definitions, so I don't know where to find the meaning. -- Section 7.1.5 -- In the discussion of altering radio signal strength, you say this: Note: This particular 'attack' is more often completely legitimate. Radio repeaters are commonplace mechanism used to increase radio coverage. Well, sure, but by discussing radio signal strength here you're talking about situations when measuring the signal strength matters. There had better NOT be a legitimate repeater involved in any situation of that sort! -- Section 18.104.22.168 -- Any costs in acquiring supporting observations are balanced against the degree of integrity desired of the resulting location information. I think this is a really important, general point in this whole discussion, and shouldn't be hidden down here in the outback. I think you should change 'acquiring supporting observations' to 'validation', and move that sentence up to Section 7.2. ======== Other comments; no need to respond to these. Take them or modify them as you please: Please expand 'LIS' in the abstract. -- Introduction -- A location information server (LIS) is the server that provides location information; information that is available due to the knowledge about the network and physical environment that is available to the LIS. The semicolon is the wrong punctuation for that: a comma will work, or perhaps a colon, but not a semicolon. But anyway, it's an odd sentence. The first part is too obvious to mention. How about this?: NEW A location information server (LIS) is the server that provides location information that is available due to the knowledge it has about the network and physical environment. (or I might say '...that is derivable from the knowledge...'). As a part of the access network, the LIS is able to acquire measurement results from network Devices within the network that are related to Device location. This looks like it's the Devices that are related to Device location. I think you mean that the measurement results are related to Device location. Try this: NEW As a part of the access network, the LIS is able to acquire, from network Devices within the network, measurement results that are related to the locations of those Devices. I would also remove the 'However,' at the end of the paragraph. -- Section 3 -- Measurement data that the LIS does not support or understand can be ignored. This is a sentence that just screams for active voice: is there any entity that would ignore it other than the LIS? NEW The LIS can ignore measurement data it does not support or understand. -- Section 4 -- In the HELD protocol, the inclusion of a measurement request in an error response with a code of 'locationUnknown' indicates that the LIS believes that providing the indicated measurements would increase the likelihood of a subsequent request being successful. <heightofpedantry> Someone recently said, 'Servers hate to be anthropomorphized.' I don't think any location information server *believes* anything. Maybe remove 'the LIS believes that'? And maybe also avoid two consecutive uses of 'indicate' while you're about it? </heightofpedantry> -- Section 5.3.1 -- The 'parameter' element identifies an optional measurements are requested for each measured access point. You have a number disagreement and what appears to be a missing word; please fix this sentence. -- Section 5.4 -- Cellular Devices are common throughout the world and base station identifiers can provide a good source of coarse location information. This information can be provided to a LIS run by the cellar operator, or may be provided to an alternative LIS operator that has access to one of several global cell-id to location mapping databases. The second sentence mentions the 'cellar operator'. Perhaps too much wine was involved, which could explain a lot. The second sentence starts with 'This information', which appears to refer to the 'coarse location information.' But I think, from the rest of the sentence, that you mean it to refer to the 'base station identifiers'. If that's so, the sentence should start with 'These identifiers can be provided'. -- Section 7 -- A Device that provides location location-related measurement data might use data to: You're one short: the punch line to the old joke is 'Location, location, location.' -- Section 7.1.2 -- Allowing requests with measurements might be used to collect information about a network topology. This is possible if requests containing measurements are permitted. As 'allow' and 'permit' are synonyms, I bet you can see how these two sentences don't go together. -- Section 7.1.3 -- Another sentence that needs some fixing: Some types of measurement data are relatively easy to falsify in a way that the resulting location information to be selected with little or no error. You're doing a lot of repeating in this section: An attacker gains if they are able to coerce the LIS into providing location information based on falsified measurement data and that information can be attributed to the LIS. Some variation on that is stated in paragrahs 1, 3, 4, 5, and 7. They don't all say exactly the same thing, of course, but I found myself saying, 'Yes, they said that already,' and then, 'THEY SAID THAT ALREADY!' Please have a look through here and see how you might better organize Section 7.1.3 to minimize that effect. (Along the same line, I'll note that paragraph 8 says exactly the same thing twice.) -- Section 7.1.5 -- Some types of measurement data can be altered or influenced by a third party so that a Device. Yes...?
I'm a No Objection, but agree with Barry's Discuss on 7.1.5. My comments follow. In general, I thought this document was fairly easy to follow given the breadth of networking and location measurement technologies being discussed, and wanted to note that the security considerations section reflected a lot of work. In 3. Location-Related Measurements in LCPs Use of location-related measurement data is at the discretion of the LIS, but the 'method' parameter in the Presence Information Data Format - Location Object (PIDF-LO) [RFC4119] SHOULD be adjusted to reflect the method used. Could you help me understand why this is an RFC 2119 SHOULD? On the same page, in this text: Location-related measurement data need not be provided exclusively by Devices. A third party location requester can request location information using measurement data, if they are able and authorized. I'm somewhat confused because of a 'requester/they' mismatch, so I'm not sure what noun 'they' refers to, but I'm also confused by 'can do foo if they are able'. I'm not sure what 'are able' means in this context. In 4.1.1. Time of Measurement The 'time' attribute is attached to the root 'measurement' element. If it is necessary to provide multiple sets of measurement data with different times, multiple 'measurement' elements SHOULD be provided. I am curious why this is a SHOULD, but I'm more curious if it's obvious how you provide multiple sets of measurement data from different times without providing multiple 'measurement' elements. What did I miss? I have the same questions about this text in 4.2.1. Time RMS Error The 'timeError' attribute does not apply where multiple samples of a measurement are taken over time. If multiple samples are taken, each SHOULD be included in a different 'measurement' element. In 5. Location-Related Measurement Data Types All included measurement data definitions allow for arbitrary extension in the corresponding schema. As new parameters that are applicable to location determination are added, these can be added as new XML elements in a unique namespace. I'm reading this 'as parameters are added, these can be added'. I'm pretty sure you're saying more than that. Perhaps 'as new parameters are added in foo, they can also be added as new XML elements'? If so, including 'in foo' would be helpful to newer readers. In 5.3. 802.11 WLAN Measurements regclass: The regulatory domain and class. The 'country' attribute optionally includes the applicable two character country identifier (dot11CountryString), which can be followed by an 'O', 'I' or 'X'. The element text content includes the value of the regulatory class: an 8-bit integer in decimal form. if you could include an expansion of 'o'/'I'/'X', and for a bonus include a reference, that would be lovely. In 5.3.1. Wifi Measurement Requests Two elements are defined for requesting WiFi measurements in a measurement request: type: The 'type' element identifies the desired type (or types that are requested. is it obvious from the specification what the requester will get if the desired type(s) are not available? Something not desired, or nothing, or ... In 5.4. Cellular Measurements MCC and MNC are provided as digit sequences; a leading zero in an MCC or MNC is significant. All other values are decimal integers. We've had some extended discussions recently about numeric strings with a leading zero being assumed to be octal, and the broader IETF community is not of one mind on whether that's true or not. Based on those conversations, it might be helpful to add '... and the digit sequences must not be interpreted as octal integers'. In 5.5.3. Per-Satellite Measurement Data codephase: The observed code phase for the satellite signal, measured in milliseconds. This is converted the system-specific value of chips or wavelengths into a system independent value. The last sentence in this definition seems to be garbled. In 7.1.4. Measurement Replay For properties of a network, time-invariance is often directly as a result of the practicalities of operating the network. Limiting the changes to a network ensures greater consistency of service. A largely static network also greatly simplifies the data management tasks involved with providing a location service. I happen to agree with this - and I managed a group that administered a network for three years, so that's based on my own experience - but I'm not sure why this is a security consideration. Is it actionable? Other than recognizing that 'if you change stuff less, you'll screw stuff up less', how does a network operator respond to this reasonable observation? In 7.1.4. Measurement Replay Requesting additional supporting observations can reduce the size of the region over which location information can be altered by an attacker, or increase trust in the result, but each additional has a cost. This sentence is garbled, or a word is missing, or ... In 7.2.4. Attribution Including an authenticated identity for all sources of measurement data is presents a number of technical and operational challenges. This sentence is garbled. In 10. Acknowledgements Thanks go to Simon Cox for his comments relating to terminology that have helped ensure that this document is aligns with ongoing work in the Open Geospatial Consortium (OGC). I think 'is aligns with' is just an editorial problem, but mention it during IESG evaluation because I don't know that.
This geopriv draft did not disappoint! My usual paranoid reaction of 'oh my ... really' and 'wow ... just think about the privacy issues' was topped by Stephen's reaction ... so what he said plus these nitty-nits: s1: r/otherwise/other metric ? s4.1.1: r/The 'time' attribute is optional /The 'time' attribute is OPTIONAL Actually this happens in a lot of places in the draft. Should the schema requirements match the text requirements? s4.1.2: What's the requirement for support of the time attribute? Should the same statement about multiple measurement(s) be copied here too because expiry time is linked to measurement(s)? s4.2: over a period of time redundant?: more than once over a period of time s4.2: Is a very large value 100 or 10000000? Maybe just say: If omitted, this value can be assumed to be a large enough so that the RMS error is an indication of the standard deviation of the sample set. s5.4: Should WiMAX be listed here?
What is the purpose of section 5.2? It seems out of place with respect to the rest of this document. I can't really object to it, since what it says is true, but it seems inappropriate to mention IANA RRTYPE assignments in a document about 802 code points. What's the point of Appendix B? If it's to have a restricted list of only IETF allocations, should the IANA be maintaining this list, since what's in this document is doomed to become out of date? I don't find a list like this on the IANA web site. I don't specifically object to Appendix B; I just think that if these lists are useful, they ought to be maintained.
Thank you for including section 1.1 which helped my review considerably. --- Maybe reversing the order of sections 1.1 and 1.2 would make 1.1 easier to read. --- <pedant alert> ([RFC5342] had a requirement for parallel unicast and multicast assignments under some circumstances even when both types were not applied for. That requirement has proven impractical and is eliminated in this document.) s/both types were/one of the types was/ --- <double pedant alert> IANA always sends the Template to an appointed Expert. If the Expert recuses themselves or is non-responsive, IANA may choose an alternative appointed Expert or, if none are available, will contact the IESG. s/none are/none is/ --- I am unwarrantedly bothered by the presence of Appendix B. I struggle to see that it serves any purpose except to provide a secondary and potentially conflicting source of information compared to the registries. Would the authors consider removing it and leaving the pointers to the registries as the only source of information?
David Black's GenART review notes a typo in Section 3.2, which the author is aware of: 00-00-0E-00-42 should be 00-00-5E-00-42 This DISCUSS is holding that point, until there's a document rev or an RFC Editor note. I otherwise have no objection....
I like that you've done this and have just a few comments and some nits: - 'Attacker' definition - are you excluding nodes that are on the Internet when the MANET is conncected to the Internet? If so, I think you need to say so. And that might be fine, but did you think about attacks from the Internet? If you didn't think about those, why is that ok? (I assume when you say 'present in the network' you mean 'in the MANET' btw.) - (A related question that demonstrates my ignorance of multicast:-) is there any way to inject traffic from outside into a MANET that will then appear to be NHDP messages sent to a link local multicast address? E.g. if some PIM service or something were also being run on the MANET? (I've no clue myself, but if there were then that'd be a new attack vector that some MANETs ought worry about I think.) - section 5: isn't causing lots of traffic to be directed to a battery powered device so as to drain its battery an attack here? I'd say that's worth a mention somewhere. (Actually the word 'power' doesn't occur at all, and that seems wrong.) Most of the rest are just nits, but here they are anyway: - section 1, 2nd para: The last sentence seems to be missing something - who or what is suggesting that 'this' (what this?) be addressed? I don't get it anyway. - s1, last para: 'attacks on and mis-configurations of NHDP' would be better (if that's what you mean which I think it is). - A compromised NHDP router could send malformed packets in an attempt to get a buffer overrun or other similar attack. I don't know if there are any NHDP packets such that implementations are likely to have problems like this, but if there were then maybe a warning would be good. - References: I know there's a good bit of academic literature on MANET security so I wondered if some more pointers to good papers would be a worthwhile addition. (I'm sure the authors know far better than I do what'd be good to include.) - The authors suggested a couple of changes  based on the secdir review that look worthwhile.  http://www.ietf.org/mail-archive/web/secdir/current/msg04007.html
thanks for addressing my DISCUSS
This seems to be a fine document, thanks. I have just one, small comment: there's an RFC 2119 reference, and 2119 boilerplate in Section 2. But there are no 2119 key words in the document. You should remove the boilerplate and reference.
I did have one comment, for your consideration. I'm not an expert on MANET, of course, but most of the threat descriptions were clear enough that I could explain them to someone else if necessary. In 5.1. MPR Calculation MPR selection (as used in e.g., [I-D.ietf-manet-olsrv2] and [RFC6621]) uses information about a router's 1-hop and 2-hop neighborhood, assuming that (i) this information is accurate, and (ii) all 1-hop neighbors are apt to act as as MPR, depending on the willingness they report. Thus, a Compromised NHDP router will seek to manipulate the 1-hop and 2-hop neighborhood information in a router such as to cause the MPR selection to fail, leading to a flooding disruption of TC messages. I didn't understand the threat except in the most general terms, and I think the problem is that 'manipulate the information so that MPR selection fails' wasn't helpful for me. If it's possible to give an example ('if the Compromised NHDP router doesn't propagate the framitz field'), I suspect this section would be as clear as the rest of the very readable draft.
It would be helpful to the RFCeditor to do an unexpanded abbreviation scrub before the draft is sent to them.
Thanks for this well written draft. Just want to discuss a couple of things: 0) In s3, it seems like the scope is set to just an attacker using NHDP messages to cause havoc. Is there a concern about deliberate exposure? That is an attacker gains control of a device and just starts blasting the routing information off to its friends? If so/not I think maybe just a sentence in s3 could address this. 1) In s4.4, identity and link spoofing is discussed. Is there any concern that the spoofers will somehow inject themselves in order to redirect traffic so that they can then eavesdrop? I see there's something in s4.5 about recording the traffic and then having another replay it but it's not quite the same thing. 2) Any concerns about traffic analysis (i.e., who is talking to who)? Or, is that lumped in with eavesdropping? The two are slightly different in that for traffic analysis the attacker can deduce information even if encryption is applied.
And now for some comments: 0) I always go back to RFC 4593. Curious if the routing community does? Not asking for wholesale changes just a nod or two to 4593: a) s4.1, s4.2, s4.7: I hope I'm not splitting too fine a hair here (i.e., tell me if you think so) but aren't Jamming and DoS Attacks when not carried out to their fullest both forms of Interference? When carried out of their fullest aren't Jamming and DoS Attacks as well as Indirect Channel Overloading forms of Overloading? -s4.1: Jamming, depending on how jammed the link, is a form of Interference and Overload with threat consequences of Disruption [RFC4593]. -s4.2: DoS Attacks are a form of Interference and Overload with threat consequences of Disruption [RFC4593]. -s4.7: Indirect Channel Overloading is a form of Interference and Overload with threat consequences of Disruption [RFC4593]. b) s4.2: At the end of the first paragraph: , so called byzantine routers [RFC4593]. c) s4.3: At the end of the section: [RFC4593] would categorize the threat consequence as Disclosure. d) s4.4.1: At the end of the section: [RFC4593] would categorize the threat consequence as Disclosure and Deception. e) s4.4.2: Often times spoofing is done for other reasons. I think s4.4.1 does a good job explaining the impersonation issue, but s4.4.2 seems to be about falsification, i.e., overclaiming. misclaiming, and misstatements (see s4.5 of RFC 4593). Maybe adding the following to 1st sentence: , sometimes referred to as Falsification [RFC4593]. And then at the end: [RFC4593] would categorize the threat consequence as Usurpation, Deception, and Disruption. f) s4.5: At the end of the section: [RFC4593] would categorize this as a Falsification and Interference threat with a threat consequence of Usurpation, Deception, and Disruption. g) 4.6.1/4.6.2: At the end of the section: [RFC4593] would categorize the threat consequence as Usurpation. 1) s4.1: r/between them/between themselves 2) s4.2: I'd add battery to the last paragraph. 3) s4.3: sniffing is kind of synonymous so maybe: Eavesdropping, sometimes referred to as sniffing, is a common ...