IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2013-02-07. These are not an official record of the meeting.
Narrative scribe: John Leslie, Susan Hares, and Richard Barnes (The scribe was sometimes uncertain who was speaking.)
Corrections from: Pete, Martin, Adrian, Barry
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
+----------------+---------+--------------------+ | OPT_LURI4 | len | payload | +----------------+---------+--------------------+ option-code: OPT_LURI4 (TBD)
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
Telechat:
2.2 Individual Submissions
2.2.1 New Items
2.2.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
3.2.2 Returning Items
3.3 IRTF and Independent Submission Stream Documents
3.3.1 New Items
Telechat:
3.3.2 Returning Items
Telechat:
1246 EST break
1250 EST back
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat:
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat:
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat:
Telechat:
7. Agenda Working Group News
1305 EST scribes left telechat
(at 2013-02-07 07:30:06 PST)
draft-ietf-geopriv-dhcp-lbyr-uri-option
1) I suspect there's an unfounded assumption built in to this draft (and plenty of other IETF work) that runs counter to good privacy practices and current reality. The maybe unfounded assumption: Applications running on a host can be considered to be acting in the interests of the end-user or administrator of that host. If the above description of today's reality is true, (and I think it is), then there is a missing privacy consideration here which is that Targets or DHCP clients MUST provide the end-user or administrator a way to override the actions that applications might otherwise make related to the use of these URLs. (In fact, I suspect this will be done anyway, but it'd still be good to impose that requirement here regardless.) 2) RFC 6753 distinguishes between an authorization by possession model and a model where (real:-) authorization can be done via access control done during the HTTP exchange to re-reference the URL. I would argue that only the latter model ought be supported here since anyone can send a DHCP request and see the associated response and (some) wireless networks can span large areas so a bad actor can learn more in seeing such a response. That also raises the question as to what HTTP authentication and access controls a client using these URIs MUST support. (I see that 3.1 says that the 'possession model' aka supposedly secret URI values, is the default, but no justification is given for that.) 3) The intro (3rd last para) seems to suggest that home routers be configured to set these options in responses but says nothing about privacy. Personally, I think any such router configuration would for privacy reasons be REQUIRED to be off by default and only turned on if the user wishes. I can see that other opionions would be reasonable and have no doubt that others will have other opinions. Did the WG discuss that, if so, got a pointer to the archive? If not, maybe either drop the example or add some WG consensus text about privacy for that case. 4) Why does this not provide an option for the DHCP client to control the LS' behaviour? Can you point me at or summarise the WG discussion of that? I'm a bit surprised about that not being done, since I'd have thought it'd be good for both privacy sensitive folks and their opposites (if you know what I mean). While we ought not provide options for fun, this one would seem quite reasonable and would seem to provide support for those who do and don't care about privacy at the same DHCP relay/server. (I note 3.1 says this is out of scope, but I don't see why.) 5) Does repeated use of the same value for a URI constitute identity information? Arguably it does, given that use of such URIs will be correlated with identity information. The 'MUST NOT reveal' in section 3 5th para if interpreted strictly seems very onerous. It may be better to have a positive MUST statement about peudo-randomness and unpredicatability. 6) How does the MUST NOT from discuss point 5 match the idea that the location URI 'indicate the residence's civic address'? That seems plainly contradictory to me. Could be this is just terminology, but I'd like to check. 7) I don't get how the valid URI schemes is in scope here but the authorization model and other aspects of the de-referencing UA are not. The DHCP client and server do not have to do anything with the scheme, which is only relevant to the de-referencing UA, but that UA also has to support (or not) TLS or proxy authentication or OAUTH or whatever might be needed for handling any real authorization. 8) The reliance on DHCP auth (3118) here seems to me to be entirely bogus. In what circumstances do you expect 3118 to be used? I think just deleting that reference to an almost universally unused RFC would give a more accurate picture of DHCP security. And I'm also unsure what threat is being countered by 3118 in this context - I'm not sure having a fake URI provided to the DHCP client is much of a threat.
- I agree with Barry's first discuss point - intro: Is the DHCP client really the Geopriv target? I think that'd be better stated as the system on which the DHCP client is running is the Geopriv target. - intro: you call out the advantages of indirection, but in fairness you should also admit the disadvantages, which might include extra round-trips and infrastructure and additional exposure of possible private information (current location). - intro: p3, 3rd para: talking about UAs and DHCP clients as if they were the same seems wrong, and I think this is done here. The former is an application thing and the latter a system thing. - intro, p4, maybe expand LCI on 1st use - 2.1, don't you need a reference to RFC 3986 for URI encoding? - section 3, 2nd last para: s/deference/de-reference/ I assume:-) - section 5: critical decisions will never be made on the value of the URIs, but rather on the location value (when renders the non-use of 3118 irrelevant I'd say) - section 5: Saying that someone else ought look at 3552 in your security considerations is bogus. The authors of this document should do that here if its needed. In this case the 'that' is sending the location URI over a network between a DHCP relay and DHCP server I guess.
1. (From Ted Lemon's review) In section 2.5:
o The Valid-For Option MUST NOT be sent from a server, and received
by a client, without an accompanying Location URI Option.
This places special processing requirements on the DHCP server—it
would be as if an RFC said 'for A records within the ORG. zone, the
DNS server MUST NOT return IP addresses within the 128.45 class B
network, which belongs to a commercial entity.'
Just take this text out.
2. (Also from Ted) I would replace this text:
The Valid-For Option offers no meaningful information to a client
without an accompanying Location URI Option, and might be
misunderstood or misapplied, therefore
o The Valid-For Option MUST NOT be sent from a server, and received
by a client, without an accompanying Location URI Option.
o A client receiving a Valid-For Option without a Location URI
Option MUST ignore the Valid-For Option.
o The Valid-For Option MUST only be considered in relation to the
Location URI Option. It has no other purpose in DHCP then in
relation to the Location URI (i.e., there is no other Option in
DHCP to which it has meaning).
o The Valid-For Option MUST NOT cause any error in handling the
Location URI, i.e., if not understood, it MUST be ignored.
o Servers MUST assume that clients will overwrite any existing,
previously sent values of Location URI Option and/or Valid-For
Option.
o Clients MUST overwrite any existing, previously sent values of
Location URI Option and/or Valid-For Option when receiving the
next instance of either Option.
With this:
The Valid-For Option offers no meaningful information to a client
without an accompanying LocationURI Option. Clients receiving a
Valid-for option without an accompanying Location URI option SHOULD
silently ignore this option. Valid-For options relate specifically
to Location URI options within the same DHCP message, and do not
apply to Location URI options received in other DHCP messages.
3. I'm writing this after Brian posted his review and we've started a
conversation about separating the LocationURI and Valid-For options.
There may have been some miscommunication about whether the Valid-For
option could be included in the LocationURI option. I'll make the
suggestion that the Valid-For life be added as an initial 32-bit
fixed-size field at the beginning of the LocationURI option, with the
special value 0 meaning 'no expiration time'.
4. (Also from Ted) In section 3:
It is RECOMMENDED to avoid building URIs, with any parameters,
larger than what a single DHCP response can be. However, if a
message is larger than 255 bytes, concatenation is allowed, per
RFC 3396 [RFC3396].
You should pick one position or the other. Either:
DHCP servers MUST NOT send URIs longer than 255 bytes.
or:
The LocationURI option is a concatenation-requiring option as
described in 'Encoding Long Options in DHCPv4' [RFC3396], section
4. DHCP clients implementing this specification must also
implement RFC3396.
5. The first few paragraphs of section 3 are DHCPv4-centric (and the
message names aren't given accurately). This text should be edited
to discuss both DHCPv4 and DHCPv6 explicitly.
6. The second paragraph of section 3 could be read to imply that a
server might put a Location URI option in a separate (additional)
message to a client. That's not how DHCP works. All the options have
to fit in a single response (DHCPOFFER, DHCPACK for DHCPv4, Advertise
or Reply for DHCPv6). The fourth paragraph is potentially confusing
as well, without specifying if the Location URI option is a
concatenating option. Does 'subsequent LocationURI Options' refer to
option within one DHCP message or in distinct DHCP messages?
7. (From Ted Lemon's review) I'm not sure that the way you've
specified IANA considerations will work. Normally we put text in the
option definition that's replaced by the RFC editor once the option
code has been assigned, like this:
+----------------+---------+--------------------+
| OPT_LURI4 | len | payload |
+----------------+---------+--------------------+
option-code: OPT_LURI4 (TBD)
This gives the RFC editor a place to put the option code inline.
Rather than just following this recommendation, I would look at some
existing examples. For example, compare section 3 here:
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-relay-supplied-options-09
to section 3 here: http://tools.ietf.org/html/rfc6422 and feel free to
plagiarize the IANA considerations section from the draft (not the
RFC!).
Then in the IANA considerations section, you need to say:
The IANA is requested to assign option codes for OPT_LURI4 and
OPT_LURIVALID4 from the BOOTP Vendor Extensions and DHCP Options
registry at
http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xml.
(You also need to say what to put in the Length and Meaning fields;
for LURI, I think it's N, and for LURIVALID it's probably 4.)
The IANA is requested to assign option codes for OPT_LURI6 and
OPT_LURIVALID6 from the DHCP Option Codes registry at
http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml.
(You don't need length and meaning fields for these—we eliminated that
in the DHCPv6 option registry.)
1. The last paragraph of section 2.5 might be more clearly written as It is RECOMMENDED that the Valid-For lifetime always be greater than the expected maximum time before the DHCP client will contact the DHCP server as part of its normal operation. Otherwise, there is a possibility that the host will not have a valid LocationURI for the interval between the Valid-For life expiration and the 2. (From Ted Lemon's review) You should really give the valid-for option a name that references the location URI option—lURI valid-for, or something like that. This will minimize confusion for people reading the option registry. 3. For consistency, use 'LocationURI' or 'Location URI' throughout the document. Editorial suggestion for organizing the document: Paragraphs 1-4 and (perhaps) 9 (beginning with 'This Option is used only...') would fit better with section 2.5, which would be better titled 'DHCP Operational Considerations'. Section 3 should be retitled something like 'URI, URL and LS considerations'.
I have no general objections to this draft, but multiple points to be discussed. However, most of my DISCUSS worthy issues are already covered by parts of Barry's, Stephen's, and Sean's DISCUSS. There is only a single point left: Section 2.5, paragraph 11: > o Clients MUST overwrite any existing, previously sent values of > Location URI Option and/or Valid-For Option when receiving the > next instance of either Option. If a host has multiple interfaces that are used concurrently and the host receives the location URI from multiple DHCP server, how is this handled? This information is handed over to some application that probably doesn't care too much about multiple network locations. However, this is something that should be at least mentioned and discussed.
Here are a few points for your consideration: Section 7., paragraph 1: > The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', > 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this > document are to be interpreted as described in [RFC2119]. This part isn't right here, as it is not part of the ToC, but also not part of any section. Move it to the introduction. Section 1., paragraph 6: > If the client was provided a location URI reference to retain and > hand out when it wants or needs to convey its location (in a > protocol other than DHCP), a location URI that would not change as > the client's location changes (within a domain).Scaling issues This sentence is not complete, isn't it? Or I cannot read and understand the meaning of it. Section 2.1, paragraph 4: > Length=XX: The length of this option, counted in bytes - not > counting the Code and Length bytes. This is a variable > length Option, therefore the length value will change > based on the length of the URI within the Option. I would include a pointer to the datagram length discussion in Section 3, just for completeness and to be sure that everybody understands the issue. Section 2.2, paragraph 5: > option-len: The length of this option, counted in bytes - not > counting the option-code and option-len bytes. This is > a variable length Option, therefore the length value > will change based on the length of the URI within the > Option. I would include a pointer to the datagram length discussion in Section 3, just for completeness and to be sure that everybody understands the issue. Section 2.5, paragraph 2: > o Implementation of the Location URI Option is mandatory on the DHCP > server and client, per this specification. 'mandatory' is not a term per RFC 2119. Should this read 'MUST be implemented by the client and the server if they support <this-RFC>', as you use 'OPTIONAL' just one down? Section 2.5, paragraph 4: > o The Location URI Option MUST be sent from a server, and received > by a client with or without an accompanying Valid-For Option. Doesn't this mean more 'The Location URI Option MUST be only be sent by a server. Clients MUST NOT sent it.' Section 2.5, paragraph 6: > o The Valid-For Option MUST NOT be sent from a server, and received > by a client, without an accompanying Location URI Option. A proposal to improve readability: 'The Valid-For Option MUST be sent by a server together with an accompanying Location URI Option.' I would remove the client part, as it is anyhow described below. The client will receive any unwanted option anyhow, but it ignores it later on during the processing. Section 3396, paragraph 8: > This Option is used only for communications between a DHCP client > and a DHCP server. It can be solicited (requested) by the client, > or it can be pushed by the server without a request for it. DHCP > Options not understood MUST be ignored [RFC2131]. A DHCP server I would make this a single paragraph, to improve readability, i.e., split it from the following rest.. Section 3396, paragraph 11: > In the case of residential gateways being DHCP servers, they usually > perform as DHCP clients in a hierarchical fashion up into a service > provider's network DHCP server(s), or learn what information to > provide via DHCP to residential clients through a protocol, such as > PPP. In these cases, the location URI would likely indicate the > residence's civic address to all wired or wireless clients within > that residence. Not completely true, if there is also a VPN (or tunnel in general) gateway in that premise. How about: 'In these cases, the location URI would likely indicate the residence's civic address of the residential gateway.' Section 3.2, paragraph 4: > o Section 3.3 IANA registers acceptable location URI schemes (or > types) for use by this specification. Clients MUST reject URI > schemes not currently registered in IANA. Isn't this 'MUST reject' a bit too strong? Given that somebody could have a new URI scheme, or one that is not public? A 'SHOULD' would be good enough.
I am baffled by two things in 2.5:
o Implementation of the Location URI Option is mandatory on the DHCP
server and client, per this specification.
Why is this mandatory? You can't be saying that all DHCP servers are now
required to implement this option, can you?
o The Location URI Option MUST be sent from a server, and received
by a client with or without an accompanying Valid-For Option.
I don't understand what this is trying to say that isn't stupidly obvious. As
Martin says in his comment, are you simply trying to say that the Location URI
MUST NOT be sent by a client? I don't get it.
As I said in my reply to Barry's comments, I disagree with Barry's first DISCUSS point. I believe this can be a useful mechanism, but I think some more needs to be said in the intro regarding why it is useful. In addition, there should be some justification in the intro for why this would be at all interesting to fixed location devices (assuming there is one). It seems like passing the actual PIDF-LO instead of a URI would be *more* efficient, if not safer, for fixed devices. But perhaps there are other operational reasons not to do so. Some explanation would be useful. I agree with Barry's DISCUSS points regarding 2.5 and section 3. The Valid-For option only applies to the Location-URI? Perhaps it should be named 'Location-Valid-For' or 'Location-URI-Valid-For'. I can certainly imagine other expiring values appearing in DHCP messages that are not tied to the lease time. Seems like a poor choice for a name that is specific. So, why is the Valid-For not simply included in the Location URI Option? Just put the 4 octets before the URI and the length is always length of URI + 4. Wouldn't that be easier?
This document is scrutinized by Barry, Sean, Martin, and Stephen. I has enough attention, and I trust those ADs will do the right thing.
Alert: This is a long DISCUSS, but don't be daunted; remember that DISCUSS
means that I need to discuss stuff with the authors (et al). The first item is
fundamental, but is likely to be sorted out by whacking me over the head with
some history and explanation. I have already talked with Robert about it, and
I think I might understand. I'd like to hear what James can tell me about it.
Something from Section 3 first:
Location URIs MUST NOT reveal identity information of the user of
the device, since DHCP is a cleartext delivery protocol.
This brings up a fundamental issue I have with this document: DHCP seems a
particularly bad protocol to use for exchanging this sort of information, and
you already have HTTP for the purpose. I don't understand the need for
retrieving these URIs over DHCP -- I don't understand the need at all, and I
certainly don't understand why what need you might have would override the
problems associated with it, compared with using HTTP. Please explain this.
-- Section 4 --
The IANA Considerations here seem entirely inadequate for figuring out what
you're asking IANA to do where. I see that Pearl complained about this during
Last Call, 7 months and two draft versions ago, and that it's been changed...
but the changes do not address Pearl's questions. In particular, the four
subsections say that the document registers four values, but it doesn't make it
clear in what registries those values are registered in. Please update the
document to be clear about that (check http://www.iana.org/protocols and use
the correct registry name(s)).
Section 3.2 says this:
o Section 3.3 IANA registers acceptable location URI schemes (or
types) for use by this specification. Clients MUST reject URI
schemes not currently registered in IANA.
I don't see that this document creates a registry for these; Section 3.3 merely
lists, statically, five acceptable URI schemes. Do you still intend to have a
registry for them?
-----------------
The rest of these points are really editorial, but are points where I think the
document lacks clarity sufficiently that I think they're likely to lead to
confused implementations, especially by people who aren't deeply into this
stuff:
-- Section 2.5 --
o Clients MUST overwrite any existing, previously sent values of
Location URI Option and/or Valid-For Option when receiving the
next instance of either Option.
I think this isn't specified quite right: if a client gets a Valid-For option
without any Location URI option, it's supposed to ignore it, according to the
5th unnumbered bullet. But this says it has to use it to overwrite the
existing value.
o Clients MUST NOT trigger an automatic DHCP refresh on expiry of
the Valid-For timer; rather, they SHOULD follow normal DHCP
mechanics.
SHOULD? Really? Why is this not MUST? What else might they do, and why?
-- Section 3 --
Caution SHOULD always be used involving the creation of large
Options, meaning that this Option MAY need to be in its own INFORM,
OPTION or ACK message.
1. What does that SHOULD really mean, and how can an implementor understand
and fully weigh the implications of not doing this?
2. The 'MAY' is completely wrong here, as a 2119 key word. This is not
describing optional behaviour, but, rather, is talking about a situation in
which something specific might have to be done.
Per [RFC2131], subsequent LocationURI Options, which are
non-concatenated, overwrite the previous value.
I'm really having trouble following this. First, I don't know what it is in
2131 you're citing. Can you give a more specific citation ('[RFC2131], Section
6.6.6') to help? And your non-restrictive clause is throwing me: why,
specifically, are they non-concatenated? Or do you mean for it to be
restrictive ('subsequent LocationURI Options that are not concatenated
overwrite the previous value.') ?
-- Section 3.3 --
Responses to requests for URIs
with other schemes ('sip', 'sips', 'http', and 'https') MUST have
MIME type 'application/pidf+xml'.
I don't know what it means for a DHCP response to have a MIME type (which, by
the way, should be changed to 'media type'). Please explain.
In fact, this whole section confuses me, as it seems to refer to things that
have nothing to do with getting URIs through DCHP. This looks like stuff
that's appropriate for HTTP. Can you help me understand? Maybe I'm just
missing it.
-- Section 1 --
This location URI points a Location
Server [RFC5808] which has the geolocation of the client (e.g.,
uploaded into a wiremap database when the client attached wall-jack,
or by means of 802.11 geolocation mechanisms).
Couple of typos in here; the second one makes it unclear:
1. 'points TO a Location Server'
2. I can't figure out how to parse 'uploaded into a wiremap database when the
client attached wall-jack', and I don't know what you mean to say.
-- Section 2.5 --
o Implementation of the Location URI Option is mandatory on the DHCP
server and client, per this specification.
o Implementation of the Valid-For Option is OPTIONAL on the DHCP
server and client, per this specification.
Is there a reason these are not parallel in their use of 2119 keywords? Maybe
change 'mandatory' in the first bullet to 'REQUIRED'? (And, by the way, I find
the 'per this specification' to be a bit silly, and unnecessary.)
o The Location URI Option MUST be sent from a server, and received
by a client with or without an accompanying Valid-For Option.
o The Valid-For Option MUST NOT be sent from a server, and received
by a client, without an accompanying Location URI Option.
I don't see how you can write 2119 language about what gets received, only
about what gets sent. Is there a reason not to remove ', and received by a
client,' from both of these?
o Servers MUST assume that clients will overwrite any existing,
previously sent values of Location URI Option and/or Valid-For
Option.
'MUST assume' sounds really odd, and, anyway, this item is entirely
unnecessary, as it's covered by the next one, which is properly formed.
-- Section 3 --
It is RECOMMENDED to avoid building URIs, with any parameters,
larger than what a single DHCP response can be. However, if a
message is larger than 255 bytes, concatenation is allowed, per RFC
3396 [RFC3396].
I find the first sentence awkward, and it took me a few passes to get the right
sense of it. Further, again, what is the protocol problem that this is meant
to address? The second sentence already says that we can deal with longer
messages. I suggest getting rid of the 2119 language, and putting it this way:
NEW
DHCP messages are limited in size, and long URIs will require the
use of multiple messages and concatenation [RFC3396]. It is,
therefore, best to limit the total length of a URI, including
any parameters, to 220 bytes.
(I picked 220 so it will fit into a v6 message; adjust this text as
appropriate. If you really think you need to put in a SHOULD or RECOMMENDED,
it'll go in the second sentence of my suggestion.)
-- Section 3.2 --
o URIs received via this Option MUST NOT be automatically sent to a
general-browser to connect to a web page, because they could have
harmful scripts.
What if I have a browser that's set up to defend against harmful scripts? What
if I have a browser that doesn't run scripts automatically? This seems a
perfect place to have a SHOULD NOT, and simply to explain the threat.
o This Option MUST NOT contain 'data:' URLs, because they could
contain harmful scripts.
And I'm puzzled about this: http and data URIs can both get me to harmful
scripts when they're dereferenced. The former are allowed and the latter are
forbidden. Why is that?
Updated after a discussion with Robert... I am having a hard time understanding a few things in this document... 1. Section 3 purports to discuss how DHCP will handle this option. However, the text does not contain a sufficient level of detail to ensure interoperability. Additionally, there are operational differences between DHCPv4 and DHCPv6 that are not considered in this section. Is this information supposed to always be included by a server when an address is assigned to a requesting device? Or should this option really only be returned when it is explicitly requested? Here is one example of how this lack of clarity can cause problems. A DHCP client implementation could assume that this option will be returned with any addresses assigned to the device. The server implementation could assume that this option is only returned when a client requests additional information via an INFORM message. I would suggest having a sub-section within section 3 for both DHCPv4 and DHCPv6 that spell out how the DHCP exchanges are to occur. 2. [Removed since the splitting of the information was a recommendation from DHC] 3. Sections 3.1-3.3 are not related to the operation of DHCP. Is there a reason why they are lumped into section 3? 4. The last paragraph of section 2.5 (discussion of values for the Valid-for option) is quite confusing and may actually be wrong. Given the lack of unity in the URI lifetime and the DHCP lease lifetime, shouldn't the guidance simply be that the URI lifetime should not be less than the DHCP lease lifetime?
There a couple of places where you use the work 'deference' when I think you mean 'dereference'
draft-ietf-tsvwg-sctp-udp-encaps
Please don't take this the wrong way, but I struggled to see why we are bothering with this as a Standards Track document. Rather than get in the way of this work with a Discuss, I am Abstaining. But here are my concerns and comments... --- While I have no doubt that this mechanism will work and can be used to address the problems stated, I do find it really weird that we are publishing 'how to encapsualte the great-but-no-longer-new SCTP in dumb old UDP in order to address problems of non-support of SCTP.' Isn't it odd that 12 years after the publication of RFC 2960 as a standards track RFC we are addressing problems of 'legacy NATs' that don't support SCTP? Isn't it more likely that the adoption of SCTP is in question? As for the ability to implement SCTP without direct access to the IP- layer... Well, really! Surely we can move on beyond that? It isn't rocket science to access the IP-layer, but maybe the issue (again) is one of adoption of SCTP? --- Section 4.2 Do we really need figures 1 and 2? The message is: The payload of the UDP packet is the SCTP Common Header followed by one or more SCTP chunks. --- Section 4.3 Is there anything here that is not standard UDP behavior? --- Section 4.6 If the SCTP header fills up the UDP packet such that no SCTP chunk can be included? --- Isn't this a tunnelling technology? Although 4.8 talks about ECN, it is concerned with SCTP use of ECN. Shouldn't the document (according to TSV best practice) discuss congestion on the tunnel? --- Section 5 should be moved out to an Appendix so as to not confuse the content of the standards track document.
I've not fully followed the mega-thread on Stewart's DISCUSS so apologies if something here overlaps with that (and feel free to entirely ignore any such thing and handle it in the other thread). OTOH, this was almost a DISCUSS so I'd really like to get an answer but not quite enough to try block progress on this. - I don't get how a node knows which non default UDP port to use on the remote node, nor why some method for doing that does not need to be discussed here. (Perhaps its elsewhere which'd be fine, but I don't get it being ok to omit that.) If no standard or de-facto discovery mechanism is defined, then doesn't that mean that the default port is basically all that'll work really? And doesn't that in turn mean that any kernel SCTP implementation effectively MUST support encapsulation on that port, if this spec is to be at all usable and that effectively only one application per host will be able to listen for clients on that port? Or perhaps what you want is that each application using sctp would also register the same UDP port (where possible) for SCTP encapsulation. If so, then I think you ought say that so that coders and IANA are aware of it. nits: 3.1: s/when proving/when providing/ 4.8: I didn't get the point of this section and 'In the other case...' seems ambiguous.
Stephen's comment notwithstanding, I think his question is worthy of a very serious DISCUSSion: There is no provided rendezvous mechanism specified if an implementation does not use the well-known UDP port (9899), unless it is 4.4 (in that one end must be running on the well-known port and the other end must be the initiator). This is not interoperable, and it leads to all sorts of weird language in 4.1: implementations 'MUST store a remote UDP encapsulation port number per destination address for each SCTP association'? That sounds like nonsense: If I am able to use a dynamic rendezvous mechnmism, I may not have to store anything at all. And '9899 MAY be used as this port number'? It SHOULD be used as the port number, unless you want to be non-interoperable (i.e., have a remote port number that you need to discover out of band). This seems like a serious failing in this protocol, and there's nothing in the document or in the writeup that explains this. Please do explain.
I agree with Adrian's comment that the figures are unnecessary. I strongly agree with Adrian and Barry that the language in 4.3 is simply describing standard UDP behavior. The MUSTs (to me) are just silly.
I have just a few non-blocking comments, which I think will make the document clearer. Please consider them seriously, and feel free to chat with me about them: -- Section 3.1 -- A crucial point for implementing SCTP in user space is controlling the source address of outgoing packets. This is not an issue when using all available addresses. However, this is not the case when also using the address management required for NAT traversal described in Section 4.7. The last sentence is somewhat unclear about the referent of 'this', and if I interpret it correctly it uses a confusing double-neagative. I presume you mean that it is not the case that controlling the source address is not an issue. Or, that is, that it *is* an issue. The crucial point itself is also a little unclear: is it that source address has to be controlled? Or is it a question of who controls the source address? Or something else? Does this work (adjust as necessary if I did not understand correctly)?: NEW? A crucial point for implementing SCTP in user space is that the source address of outgoing packets needs to be controlled. This is not an issue when using all available addresses. However, it is an issue when also using the address management required for NAT traversal, described in Section 4.7. -- Section 4.1 -- Using a single UDP encapsulation port number per host is not possible if the SCTP stack is implemented as part of an application. Why not; can you explain (or re-phrase)? Is it maybe this?: NEW? Using a single UDP encapsulation port number per host is not possible if the SCTP stack is implemented as part of each application, and there are multiple applications. -- Section 4.3 -- When inserting the UDP header, the source port [...] Might this be better said as, 'Within the UDP header'? The length of the UDP packet MUST be the length of the SCTP packet plus the size of the UDP header. This is just stating how UDP works, isn't it? That would be made clearer (and doesn't need the MUST) if it's said this way, I think: NEW Because the SCTP packet is the UDP payload, the length of the UDP packet is the length of the SCTP packet plus the size of the UDP header. -- Section 4.4 -- Please note that when a non-encapsulated SCTP packet is received, the encapsulation of outgoing packets belonging to the same association and the corresponding destination address MUST be disabled. I don't understand this. How can a non-encapsulated SCTP packet be received over UDP? Or are you saying that a plain SCTP packet might come on the same port because of an error on the sending side? Or something else? Please clarify this. (I also think 'please note' has a softening tone that seems to be wrong with the MUST at the end of the sentence. But maybe that's just me, so don't worry about that too much.) -- Section 4.5 -- No problem here, just making sure I understand an implication of this: be discarded silently. This means in particular that the SCTP stack MUST NOT rely on receiving ICMP or ICMPv6 messages. Implementation constraints could prevent processing received ICMP or ICMPv6 messages. That seems to mean that SCTP stacks have to be specifically aware that they are being tunnelled over UDP, and be tolerant of missing ICMP messages in that case... is that right? Or is it expected that *all* SCTP stacks will be tolerant of that anyway? -- Section 4.6 -- Nit... Awkward English alert: If the implementation does not allow to control the dont't fragment (DF)-bit contained in the IPv4 header 'Does not allow' shouldn't take an infinitive. This reads better: NEW If the implementation does not allow control of the don't fragment (DF) bit contained in the IPv4 header -- Section 4.8 -- If the implementation supports the sending and receiving of the ECN bits for the IP protocols being used by an SCTP association, the ECN bits MUST NOT be changed during sending and receiving. In the other case, ECN MUST NOT be used for such an SCTP association. In what other case? That would seem to say that if the implementation doesn't support sending and receiving ECN bits, ECN MUST NOT be used. And that *really* seems to go without saying. Is there something else you mean here, and I don't understand?
'For IPv4, the UDP checksum SHOULD be computed and the SCTP checksum MUST be computed, whereas for IPv6, the UDP checksum and the SCTP checksum MUST be computed.' Given that this is by definition SCTP tunneling over UDP (that is the UDP port it runs on) I would like to understand why are the more relaxed UDP tunnel c/s considerations approved last week not applied here? SCTP already has a CRC32 and a cookie to make sure it is delivered correctly so a 16bit checksum seems to add very little additional protection for a lot of work by the encapsulating device.
I agree with Pete's DISCUSS point.
The author and secdir reviewer seem to have worked out some agreed changes. Please add them in the next revision.
draft-ietf-nea-pt-eap
Section 5: The security requirements described in this specification MUST be implemented in any product claiming to be PT-EAP compliant. I couldn't tell *why* a product claiming to be PT-EAP compliant MUST implement the security requirements described in this specification. I think the abobe sentence could mean one of two things: 1. It means, 'A product claiming to be PT-EAP compliant implements all of the security requirements described in this specification.' That is to say, it's simply describing what it means to be compliant. If that's what is meant, say that; MUST isn't helping anything. 2. It means, 'There are security requirements described in this specification that MUST be implemented because they are required for interoperability or to prevent harm.' If that's what is meant, please list the particular sections these requirements appear, or list a summary of them here. Saying that I MUST do some things without telling me what specifically I MUST do is not helpful.
-- Section 7 -- This document also defines one new IANA top-level registry: PT-EAP Versions. This section explains how this registry works. Because only eight (8) values are available in this registry, a high bar is set for new assignments. The only way to register new values in this registry is through Standards Action (via an approved Standards Track RFC). Thanks very much for including an explanation of your choice of registration policy. I really appreciate that. I have a very tiny, non-blocking point, of no significance other than tidiness of the IANA registries. From IANA's last-call comments: Second, a new registry is to be created. This registry will be called the 'PT-EAP Versions' registry. The document requests that the be a top-level registry in the IANA Matrix. They're referring to the 'new IANA top-level registry' bit above. Is there a good reason for this to have its own group on the main IANA page? I suggest this: There's a group called 'TLS-based Posture Transport Protocol (PT-TLS)', which has the PT-TLS Error Codes and PT-TLS Message Types registries in it. Might it be reasonable to rename that group to 'Posture Transport Protocols (PT-EAP and PT-TLS)', and to add this registry to that top-level group?
Trying to piece together RFC 6677, draft-ietf-emu-eap-tunnel-method, and this draft and if we walk through c.10 in draft-ietf-emu-eap-tunnel-method the inner method is bound to the outer method (good): first you set up an EAP tunnel, then you set up a TLS session, and then you do what's in this draft and pass the channel bindings TLV from ietf-emu-eap-tunnel-method. One question though: The Channel_Binding TLV data field points to RFC6677 (s5.3), the only values specified there supports a RADIUS namespace. Doesn't a new namespace need to be defined to carry the tls-unique value? I.e., isn't it going to be an octet string and not a RADIUS attribute?
1) s2: Word smithing, but I would have called s2 'Applicability Statement'. Did Pete beat me to this one ;) 2) s3: This document is at the interesting cross-roads of EAP [RFC6677] and TLS [RFC5056][RFC5929] which use the term 'channel binding' differently. To aid those who might not know they're used differently, it's probably worth pointing out that you're using the 5056 meaning here. 3) s4.3: So I'm probably word smithing here but doesn't this: TEAP [I-D.ietf-emu-eap-tunnel-method] is the mandatory to implement EAP tunnel method. mean: Implementations MUST support the [I-D.ietf-emu-eap-tunnel-method] EAP tunnel method. 4) s4.3: After s4.2, I would have thought that you'd make the point that of the 3 methods only [I-D.ietf-emu-eap-tunnel-method] actually claims to support channel bindings. 5) s4/5/?: Is it worth explicitly noting that if channel bindings is implemented then the Channel-Binding TLV in [I-D.ietf-emu-eap-tunnel-method] MUST be supported.
draft-ietf-oauth-assertions
4.2:
When present, the 'client_id' MUST
identify the client to the authorization server.
I don't understand what this is saying. How is the entity that is creating the
assertion able to be sure that the client_id identifies the client to the
authorization server? Is there some verification that must be done? If it
doesn't identify the client, isn't the server simply going to send back and
invalid_client error? What does this requirement mean?
5.1: Why aren't Issued At and Expires At REQUIRED to be at UTC?
5.2:
The Authorization
Server MUST verify that it is an intended audience for the
assertion.
This is written strangely. Don't you instead mean, 'The Authorization Server
MUST reject [with such-and-so error] an Audience value that it does not belong
to' or something to that effect? Assuming that's right, is it completely out of
band how the server determines that?
The
authorization server MUST verify that the expiration time has not
passed, subject to allowable clock skew between systems.
As above, don't you really mean that the the server MUST reject things that
have expired?
The
authorization server SHOULD reject assertions with an Expires At
attribute value that is unreasonably far in the future.
Given that 'unreasonably far in the future' is clearly a judgment call on the
part of the server, the SHOULD requirement seems weird. Shouldn't that be: 'The
authorization server MAY reject assertions with an Expires At attribute value
that the server considers unreasonably far in the future.'?
The Authorization Server MUST validate the assertion's signature
to verify the Issuer of the assertion.
As above, I think you mean 'Server MUST reject assertions which do not
validate'.
Strictly editorial: I liked the format of 4.1 and 4.2 better than 5.2. Instead
of embedding 'MUST contain' or 'MAY contain', I prefer the format of:
Issuer REQUIRED. Blah blah.
Subject RECOMMENDED. Blah blah.
Issued At OPTIONAL. Blah Blah.
6.1: This is not clarifying; it appears to be completely redundant. If it is
*not* redundant, you need to pull those things out and highlight them. I found
myself jumping back and forth between this section and 4 and 5 trying to figure
out what I missed. I couldn't find any differences. Keep the first sentence and
the example; ditch the rest.
6.2: Skip the bits about client_assertion, client_assertion_type, Subject,
Audience, and signature verification; they're redundant. Skip the first two
sentences of 'Issuer'; also redundant. Move the bit about STS into earlier
sections; it gets re-used. Just keep the intro, the grant_type, and the example.
6.3 and 6.4 have similar issues to 6.1 and 6.2, and similar cleanups. I can go
through in detail if you need, but I think you have the idea.
I very much approve of the assertions set going ahead. I have a number of
things I'd like to DISCUSS on this first:
Point 1:
-- Section 1.1 --
However, even when profiled for specific assertion types, additional
profiling for specific use cases will be required to achieve full
interoperability.
In other words, even the SAML and JWT profiles aren't sufficient? Or do those
documents do this sort of use-case profiling, resulting in something that can
actually work? Or is Section 6 sufficient? If they do, or it is, then saying
that here will help. (As a side note, I would really have preferred seeing at
least the SAML draft in for IESG Eval at the same time as this doc.)
If they don't, then I'm dismayed. OAuth already requires out-of-band agreement
on what sort of token one is going to get. This framework additionally
requires out-of-band agreement on assertion type. If even those assertion
types that are defined *further* require o-o-b agreement on the semantics of
the fields they use, it seems that we're adding to the mess and not building
broad interoperability.
Point 2:
Related to point 1, would it not be good to explicitly define an 'assertion
type unsupported' error response (or two: 'grant type unsupported' and 'client
assertion type unsupported'), so a server can be explicit in saying that that
is why this request can't be processed? If not, why not?
Point 3:
Might it be a good idea, concomitant with the suggested URNs in Sections 4.1 an
4.2, to reserve the namespaces 'urn:ietf:params:oauth:grant-type:' and
'urn:ietf:params:oauth:client-assertion-type:' here, so they won't be used for
anything else? If not, why not?
Point 4:
-- Section 5.2 --
I'm looking at the 'SHOULD be the client_id's in the first two bullets, and
remembering the definition of 'SHOULD' in RFC 2119 -- it says that not
following a SHOULD requires full understanding of the implications and careful
weighing. I see nothing here that gives me a clue how to evaluate the
implications. *Why* SHOULD these be the client_id, and what will happen if
they're not? (This also applies to some of the bullets in Sections 6.x.)
Point 5:
-- Section 5.2 --
o The assertion MAY contain an Assertion ID. An Authorization
Server MAY dictate that Assertion ID is mandatory.
How can a client know that an Authorization Server so dictates?
Point 6:
-- Section 6.1 --
When a client uses an assertion for authentication, it SHOULD do so
according to Section 4.2.
I'm confused: I thought 4.2 normatively described the protocol. What's that
SHOULD here? (Same question applies to the intros to the other Sections 6.x.)
And here are a bunch of non-blocking comments that I think will be useful.
Feel free to chat with me about these, as well -- I'd really like you to
consider them, but I won't get in the way if you disagree with these.
-- Section 1 --
and JSON Web Token (JWT) Bearer Token Profiles for
OAuth 2.0 [I-D.ietf-oauth-jwt-bearer] defines a concrete
instantiation for JWT tokens.
Nit: JSON Web Token tokens? Is that not like 'Personal PIN Number', or 'ATM
Machine'? Wouldn't it do to say, 'concrete instantiation for JWTs.'
-- Section 3 --
1. Bearer Assertions: Any entity in possession of a bearer assertion
(e.g. the bearer) can use it to get access to the associated
<rant>See, this is why I don't like the use of these latin abbreviations:
they're usually unnecessary, and we often get them wrong.</rant> The one you
want here is 'i.e.': the bearer is not an *example* of an entity in possession
of the assertion; any entity in possession of one *is* the bearer of it.
NEW1
1. Bearer Assertions: Any entity in possession of a bearer assertion
(i.e., the bearer) can use it to get access to the associated
... or, more simply (and why not?) ...
NEW2
1. Bearer Assertions: Any entity in possession of a bearer assertion
(the bearer) can use it to get access to the associated
I would also make the whole thing plural when you talk about secure channels
later in that item, because there are multiple channels involved: 'Secure
communication channels are required between all entities....' (Also in Section
7.2.)
-- Section 4.2 --
client_id OPTIONAL. The client identifier as described in Section
2.2 of OAuth 2.0 [RFC6749]. When present, the 'client_id' MUST
identify the client to the authorization server.
Very small point... this strikes me as a wrong use of 2119 MUST: you're not
talking about a protocol choice (as you do in the next item, where the 'MUST be
an absolute URI' is quite correct), but are just saying what this parameter
does. Make it, 'When present, the 'client_id' identifies the client to the
authorization server.'
-- Section 6.1 --
The example here (and the paragraph introducing it) is identical to the example
in Section 4.2 (except for what appears to be a copy/paste error in the snipped
base64 (the final '4')). Do we really need to have it repeated here? At the
most, a 'See the example in Section 4.2,' ought to be enough (or reverse it,
with a forward ref from 4.2 to here).
Similarly, the example in Section 6.3 is identical to the one in Section 4.1.
-- Section 7.3 --
However, this does not prevent
legitimate protocol entities from obtaining information from an
assertion they may not have been allowed to obtain.
This reads like it's the assertion they may not have been allowed to obtain,
when you mean that about the information. I suggest this:
NEW
However, this does not prevent
legitimate protocol entities from obtaining from an assertion
information they may not have been allowed to obtain.
END
To mitigate potential
privacy problems, prior consent from the resource owner has to be
obtained.
Prior consent for what? It's not clear.
1) RFC6749 includes an incomplete list of components that are partially or fully undefined in its 'Interoperability' section. A similar section should be added to this document and I hope it can be a bit more specific. This section would gather all the out of scope or defined in the next specification items. The purpose being to aid implementers in following the bread crumbs leading towards interop. 2) Another point on verification: The only way for the RP to verify the 'signature' is it to have the 'signers' key. Since, this is mostly about keyed MACs you can't just send that key with the 'signed' assertion. My point is, the key distribution is one more thing that's out of scope.
1) Completely agree with Barry's point #1. 2) s1: I think it'd help to define what an assertion is or just point to definition in RFC 6819. 3) s3: (I teetered on making this a discuss) 'sign' is used a couple of times in this document when you're talking about either digital signatures or keyed MACs. Please try to scrub these out and make the distinction that you're either digitally signing or using a keyed MAC.
draft-ietf-avtcore-srtp-encrypted-header-ext
Other than point 1, I'm mostly just checking things here so a few quick mails should be enough to sort this out at which point my ballot will turn into a yes. (1) p9, 2nd para - I don't get why you say that a node MAY send both plaintext and ciphertext - what'd be the (security) benefit in doing that? Seems like a dangerous thing to allow since it'd be likely to remain turned on accidentally if ever turned on. If you do need this then I think some better warning text is needed, but I'm not sure what, since I don't get when you want to have both plain and ciphertext present, nor quite how that'd look in e.g. SDP. (2) The masking is fairly elegant, but just to check, that assumes that all header fields are structured as TLVs always, and there's never a header we might want to encrypt that's e.g. a NULL terminated string or the moral equivalent. I think it also assumes that plaintext values never use escaping either, which could extend their length. Is that correct and ok? If there were non-TLV headers or escaping then I think you'd need to say a little more about how and when to calculate the mask from e.g. the SDP extmap attribute. (3) Again, just checking. This scheme would break if headers were moved, inserted before ciphertext, or deleted by middleboxes, right? Are such changes ever done by middleboxes that possess the right authentication keys? Do you need to say that such middleboxes that are part of the security association MUST NOT mess about with headers ever, since they don't know that this is being used over and above the authentication provided by SRTP? (And they don't know that, right?) (4) The 3711 KDF has a key_derivation_rate input that you don't mention here. I assume the idea is that new keystreams are generated for headers at the same rate as for payloads but don't you need to say that? Otherwise, some might use just the first keystream for all headers and others might roll the keystream breaking interop. (5) Slightly off into flakey concerns land;-) Is there any way a bad actor could use this to probe a keystream or verify bits of a keystream one or a few at a time e.g. via a million-message type attack? I don't see how to do that, and will just believe you if you say its ok, but just wondered if you'd thought about that.
- p4, last para - the description of the mask is a bit hard to follow - maybe moving the example earlier might help, but one does get the right idea after reading further, so just a suggestion - p8, figure 4 has a bunch of numbers that I at least don't understand - what are '2^20|1:32' and '25@600/24' ? I'd like to know why I don't need to understand those:-) - p10, 3rd para - is it even possible to use this with CBC or ECB? Block padding would seem to just break the header syntax except if the plaintext is a multiple of the block size for ECB. I think the note could be deleted or replaced with one that says that this is for stream ciphers only and use of a block cipher would break the header syntax. In any case the MUST NOT seems wrong or moot. - Would it be worth adding an additional security consideration saying that since some headers may well have easily guessed plaintext (some bits anyway) and we're using a stream cipher, the authentication is really really needed or very bad things could happen if attackers flipped bits of ciphertext knowing the likely plaintext and the effects that might ensue?
- Feedback from Joel Jaeggli, part of the OPS directorate, on which I would appreciate an answer: Section 4.1 proposes negotiating the sending of a header element in either encrypted and unecrypted forms which seems a bit self defeating. and I find it a little difficult to stomach to say well its' important that this information be encrypted, but since you can't we'll just send it in the clear. - Really an editorial detail. Take it or leave it. A number of recent proposals for header extensions using the General Mechanism for RTP Header Extensions [RFC5285] carry information for which confidentiality could be desired or essential. Notably, two recent specifications ([RFC6464] and [RFC6465]) carry information about per-packet sound levels of the media data carried in the RTP payload, and exposing this to an eavesdropper is unacceptable in many circumstances. 'exposing this to an eavesdropper is unacceptable in many circumstances.' was not obvious to me, and I kept thinking about that one while reading through the rest of the doc. In the end, I came back to it, and researched this: this is well described in the RFC 6464 and RFC 6465 Security Considerations. NEW (last sentence) Notably, two recent specifications ([RFC6464] and [RFC6465]) carry information about per-packet sound levels of the media data carried in the RTP payload, and exposing this to an eavesdropper is unacceptable in many circumstances (as described in the respective RFC Security Considerations sections)
I support Stephen's DISCUSS point #1.
I support Stephen's discuss and the resolutions proposed by the authors look good to me.
draft-ietf-ccamp-lmp-behavior-negotiation
A strictly procedural question for the shepherd and the AD. The writeup says: There have been no public statements related to implementations, though significant interest was expressed by the working group to progress this extension of the LMP protocol in support of future extensions. The two halves of that sentence seem incongruous. If there is no indication that anyone wants to use this extension mechanism, but it's just that it seems like a good idea for future extensions, I wonder why this is worth doing, especially given backwards compatibility issues outlined in section 4. Is there really nobody that is planning a new extension that intends to use this mechanism? I don't intend to block the document on these grounds, but I do think it is worth an answer. The shepherd writeup was extremely thin all around.
I agree with Pete's question about interest in implementing.
draft-ietf-sidr-algorithm-agility
Should this document be a BCP? Many MUST statements are actions to be taken by the IETF or others that implement IETF specifications.
I have downgraded my Discuss to a Comment after useful input from Stephen Farrell. As Stephen Kent points out, the Abstract contains suitable language that scopes the document to CAs participating in the RPKI. Making a similar statement in the Introduction would be helpful. I continue to feel that the IETF is not in a position to dictate how the RPKI will be run, but I agree that the IETF can dcument the process it believes should be run. I should be happier if the document took a tone more consistent with guidance than with requirement.
This isn't a DISCUSS, since I assume the IETF has to keep the ability to ignore process rules such as the ones embedded in this draft when the need arises, and those rules turn out to be problematic. I think you could lose all the process MUSTs if you wanted to, and the idea of the timeline as an RFC, but I don't object to you having them since if they become badly problematic, that'll have to be sensibly handled at the time of a real transition. Put another way - this plan for the future assumes our current processes remain in place, which seems fragile to me. Overall, I think this would be better re-written as 'here's our best idea for a plan for this transition' and doing so is good whilst the SIDR WG are active, but I would not expect this to be interpreted as other than guidance once a few years have passed and some part(s) of our proceses have changed and the reality of operating the RPKI demonstrates that this document got a couple of details wrong. Another alternative might be to call for a 'phase 0.9999...' where this RFC MUST be updated as a BCP just before phase 1, but that might be too self-referential:-) All that makes me sympathetic to Adrian's discuss but not supportive of blocking the document on that basis. - Section 2 says that 6485 'MUST be updated,' but that the CP policy OID will not change. This assumes that RFC meta-data relationships do not change. - The transition timeline as a BCP depends on the concept of BCP being roughly the same. It could be that a document like that would not be considered a sensible BCP by then. - What happens if the dates set out as goals in the transition timeline document slip? What happens if they slip by less than the time it takes to update the transition timeline document? Saying 'MUST be re-issued' doesn't seem so good a plan to me. - 'Suite B' seems like an unfortunate name for an example as its a term of art that exists in this space but is different. - 4.5 requires action from 'every CA' which also seems fragile. What if some CA ignores this? What if that one is too big to fail? - 4.7 - what if this date slips signicantly? Are you calling for the timeline to be re-issued?
I concur that this document ought to be a BCP. The use of 2119 in this document tickles me, and for weird reasons I think most of it is OK. The IETF procedural MUSTs (like updating documents) I find a bit goofy, but I find the steps like 'CAs MUST have reissued all of their signed product sets' to be rather interoperability oriented, albeit about the interoperation of things at an operational level where the endpoints of the 'protocol' are humans and organizations. (If you don't do some of these things, interoperability does seem to fail.) Although I agree with Stephen that most of these MUSTs are unnecessary, and I certainly think they're weird, they don't violate my sensibilities. I will use this document as an interesting example in an upcoming discussion we're going to have at the WG Chairs lunch.
I support Russ's DISCUSS about making this BCP, rather than PS.
I support Adrian's DISCUSS point on the ability of the IETF to mandate transition dates and have them mean anything.
draft-ietf-rtgwg-ipfrr-notvia-addresses
Please consider the clarifications suggested in the Gen-ART Review by Suresh Krishnan on 4-feb-2013. You can find there review here: http://www.ietf.org/mail-archive/web/gen-art/current/msg08156.html
I'm not totally clear on the ultimate goal of publishing this as an RFC (rather than just a magazine or journal article), based on the IPR and lack of concrete specification. I think the 'Purpose of this Document' could be more clear, despite having a section of that name. Normally we don't just capture a WG's thinking and move on, unless we're maybe declaring open issues and unsolved mysteries that require a bunch of long-term work, and I didn't get that impression from this document.
AAH is cute as is 'mild security'
I wonder if Section 10. Encapsulation should mention that all of the tunnel methods might create MTU issues.
Please consider adding a sentence noting that this document should not be accepted as a normative downref from a standards track document. Any IETF review this document has received has been shaped by the disclaimer that this is just reference for future work and is not appropriate for implementation. When it becomes appropriate, it would be much better if the the relevant algorithms and ideas were copied forward into a standards track document or that this document were explicitly revised to be on the standards track than to incorporate it into the standards track via a downref.
draft-ietf-rtgwg-ordered-fib
Thanks for addressing Dan's review comments
It seems interesting, but I'm confused why if it works so well in simulations, that nobody seems interested in going further with this. What's the value of an IETF RFC versus other types of publication, given that there's IPR attached to this as an Informational document? It's clearly informative, but I get the feeling that there's more information that must not be clear in the writing at the moment about what the ultimate goal is.
- the mechanism -> the mechanisms - It is assumed in the description that follows that all routers in the routing domain are oFIB capable. This can be verified in an operation network by the routers reporting oFIB capability using the IGP in use. Where non-oFIB capable routers exist in the network, normal convergence would be used. I guess you mean Where non-oFIB capable routers exist in the network, normal convergence would be used in all routers. Otherwise, it contradicts the first sentence
I find the rationale in the write-up for publishing this document 'interesting'.
Please see my comment on draft-ietf-rtgwg-ipfrr-notvia-addresses. It applies equally to this document.
I am balloting No Objection based on my unenlightened read and the support of the Sponsoring AD.
draft-ietf-roll-p2p-rpl
As already pointed out in the Gen-ART Review by Alexey Melnikov, please expand the First use of 'DIO'.
(Apologies, I had to read this document in chunks due to other time pressures, so this review might also be a bit chunky;-) - section 3, the term Target might create an irritating conflict with how that same term is used in geopriv but I'm guessing you won't want to change. - section 4, I don't quite get how this is triggered, in the remote-conrol/lamp case, is the remote-control the Origin or a non-router host? If the latter, then I'm not sure how the remote-control's next-hop router could know to trigger this process. The former option seems quite constraining, since it'd mean that all hosts that can benefit from this need to be p2p-rpl aware routers, and that seems less rather than more likely. - section 4, I'm also not sure how the remote-control knows the lamp's IP address to start with. How's that work? Specification for that probably doesn't belong here, but I wondered and it might be good to explain a bit in this draft. - section 4, 3rd last para: I don't see how the guy who makes the remote-control (if its the Source LLN router) can know how to set all those things that the 'network designer' knows how to set. Maybe I'm just missing the point? - section 5: sending application data with routing messages seems to have security issues since the DIOs are sent more or less all over I think? That implies that a one-to-many confidentiality service might be needed which seems very very hard (i.e. silly) in a p2p context. And of course that also assumes that the application runs on the 'Source' LLN router as well so you can know what is and is not time-critical. I also wonder what'd happen if the 'application data' you mean were a TCP SYN packet which seems likely isn't it? The same security issues arise with the data option in a DRO. (FYI in case it helps this would have generated a DISCUSS from me for a standards track protocol but since there are already two discusses about this I'll not pile on.) - 6.1, Why is 'Authentication Enabled: 0' the default and why does that differ from 6550? (If it does.) - 7.1, Lifetime field - it wasn't clear to me when a router starts counting down to the end of the Lifetime for the DAG. - 7.2, Only allowing 256 bytes here may effectively mean securing that data is never possible. That seems undesirable. - 7.2 saying a deployment SHOULD take security into consideration seems meaningless. - section 8 says the DODAGID identifies the Origin and that confused me, do you mean its value is the origin's IP address? - section 13 says: 'Each RPL control message has a secure version that allows the specification of the level of security and the algorithms used to secure the message. ' and ' These DIOs can be used in their secure versions if desired' but I have to say I'm unconvinced that that's sufficiently well defined here (or in 6550) to allow interop and offer useful security. There doesn't seem to be any mention of the 'secure DRO' in section 11 for example. I'd love to be proven wrong however, so can you try convince me that I'm wrong? (This would also have been a DISCUSS on a standards track document, even if the authors could justifiably say that the real fault lies in 6550.)
I have several architectural issues with the protocol specified in
draft-ietf-roll-p2p-rpl that I would like to discuss.
1. The Data Option introduces a new style of datagram delivery,
roughly based on IPv6, but with different delivery semantics. The
Data Option also appears to be underspecified; for example:
* How is the checksum in the 'upper layer protocol header ... in the
Data field ...' computed; what is the pseudo-header?
* Does it make sense to carry, e.g., TCP in a P2P-RPL message that
might be delivered to multiple targets?
I'm especially concerned by:
'By not allowing the generation of DRO messages,
an Origin can use P2P-RPL as purely a mechanism to deliver time-
critical application data to the Target(s).'
which seems to allow P2P-RPL to operate solely as a Internet-layer
delivery mechanism without generating any routing information.
I had a brief discussion with Adrian about the Data Option. In my
opinion, the Data Option needs a more careful review, for example by
the 6man working group (someone in Transport, as well?), before it can
be published. Adrian made the suggestion to remove the Data Option
from this document and publish it as a separate draft, which would
avoid delaying this document and allow for additional refinement of
the Data Option specification.
2. The use of the PIO option in P2P-RPL needs to be reviewed by 6man.
In my opinion, the PIO option should not be used here. We already
have ND and RPL for disseminating information about prefixes.
3. Does it matter which of its addresses an intermediate node inserts
in the address list in the P2P-RDO? If it does - and I expect it
might make a difference if, for example, the node has multiple non-LL
addresses from multiple RPL instances or the node has multiple
interfaces - how does the node know which address to select? Are LL
addresses OK?
4. How does a node process and forward P2P-RPL control messages if it
has multiple interfaces? For example, does it forward those messages
on all interfaces, including the one on which the control message was
received (as it would if the node has one interface)?
1. selection of routes by the Target and sending the DRO: In the Hop-by-Hop case, after the route is selected and DRO is sent, can the Target send a better route to override the route sent earlier? I'm thinking of the case in which an optimization occurs while the temporary DODAG is running and the Target gets a better route. Or, once it has sent a DRO, does it resend the same route after receipt subsequent DIOs? In the Source-route case, does the Target send N DROs, one with each selected route, and then stop sending DROs? 2. In section 9.7: Why is the DRO multicast to the next hop on the path to the Origin? Isn't the address of the next hop in the DRO address list? 3. Does RPL have the same behavior that routes installed by RPL may be retained beyond the lifetime of the DAG that caused the routes to be installed? If not, it might be helpful to add a note giving implementors a heads-up. 4. Related to earlier comments about address selection, in section 9.4, this text: if the router cannot elide Compr (as specified in the P2P-RDO) prefix octets from its IPv6 address ought to be edited to reflect that the Intermediate Router may have multiple IPv6 addresses to choose from. Should the Intermediate Router consider the Target prefix and Compr in the selection of an address to add to the P2P-RDO? 5. What link-scoped multicast address is used for forwarding DROs? The following are simply editorial nits: 1. It would be clearer (for me, anyway!) if the mode were simply given as 'Hop-by-Hop mode' or 'Source routing mode' rather than by 'H flag is zero'. 2. In section 11, 'An Origin MAY use a Source Routing Header (SRH) [RFC6554]...'. What else would it use? How about 'An Origin uses the Source Routing Header (SRH) [RFC6554]...' 3. section 9.3: 'send or receive' -> 'send or process' (it's hard to not receive the messages) 4. This sentence might benefit from more detail: 'The temporary DAG MUST NOT be used to route packets' (unless using a DAG to route data packets [which is what I think is implied] is a term of art). 5. For consistency, could the DRO be named P2P-DRO?
I have no general objections to the publication of the draft, but I have a few points to be discussed. And here is my full review: *Issue 1): data piggybacking: Section 1., paragraph 9: > o The utility and the implementation complexity of the Data Option > (Section 7.2) that provides a facility to piggyback time-critical > application data on the routing messages; My DISCUSS is basically the same as Ralph's DISCUSS about the data piggybacking is actually in this protocol. I do not see any good justification for this in the draft and the introduction of this mode raises tons of questions on how this is handled in real life. There is some light text about the purpose of this piggybacking in Section 5., paragraph 8, but there is for instance no central place where the usage of this mode and its implications is described. This looks like a hack, but not like a good idea. See also right down here for some further questions, just a few that came immediately to my mind: Section 7.2., paragraph 9: > Data Option received inside a parent's DIO and MUST include this Data > Option in all its future DIO transmissions for this temporary DAG. > The same is true for a Target that needs to propagate the DIOs > further (required when the route discovery involves multiple > Targets). If a Target chooses to include a Data Option inside a DRO, So this effectively means that the data is copied into multiple other messages and send out to the network, isn't it? Is there any control on whether this is causing congestion in that area where the messages are multiplied? Section 7.2., paragraph 11: > Note that the data inside a Data Option has the same level of > security as the DIO/DRO message it is part of. A P2P-RPL deployment > SHOULD take in consideration the security requirements of the data > being sent inside the Data Options when deciding the overall security > requirements. Further, note that P2P-RPL does not guarantee > successful delivery of the data contained in a Data Option. There is a not so obvious dependency between the data carried in the Data Option and the P2P-RDO's R flag: If the upper layer is TCP and it is a TCP SYN the R flag must be set in order to carry the SYN ACK back to the originator. Section 8.2., paragraph 2: > o Reply (R): This flag MUST be set to zero on transmission and > ignored on reception. What if the piggybacked data requieres a response and a reply on the rpl level is not allowed? Section 7.2., paragraph 8: > If the Origin chooses to include a Data Option inside its DIO, it > MUST include the same Data Option in all its future DIO transmissions > for this temporary DAG. An Intermediate Router MUST NOT modify the What is 'same Data Option' meaning? Is it just the option itself or is the option with always the same data? *Issue 2) Extemely vague retransmission handling of DRO-ACK Section 10., paragraph 3: > A DRO message may fail to reach the Origin due to a number of > reasons. Unlike the DIO messages that benefit from Trickle- > controlled retransmissions, the DRO messages are prone to loss due to > unreliable packet transmission in LLNs. Since a DRO message travels > via link-local multicast, it cannot use link-level acknowledgements > to improve the reliability of its transmission. Also, an > Intermediate Router may drop the DRO message (e.g., because of its > inability to store the state for the Hop-by-hop Route the DRO is > establishing). To protect against the potential failure of a DRO > message to reach the Origin, the Target MAY request the Origin to > send back a DRO Acknowledgement (DRO-ACK) message on receiving a DRO > message. Failure to receive such an acknowledgement within the > DRO_ACK_WAIT_TIME interval of sending the DRO message forces the > Target to resend the message. Is there anyback off mechanism for the retransmission of the DRO-ACK message? I haven't seen any. *Issue 3) Missing safety margin for the reuse of RPLInstanceID: Section 6.1., paragraph 2: > o RPLInstanceID: RPLInstanceID MUST be a local value as described in > Section 5.1 of [RFC6550]. The Origin MUST NOT reuse an > RPLInstanceID for a route discovery if its previous route > discovery using this RPLInstanceID might still be going on. As > described in Section 7.1, the Life Time parameter in the P2P Route > Discovery Option specifies the time duration the route discovery > lasts. So, the Origin MUST NOT reuse an RPLInstanceID in a route > discovery until the Life Time of its previous route discovery > using this RPLInstanceID is over. When initiating a new route > discovery to a particular Target, the Origin MUST NOT reuse the > RPLInstanceID used in a previous route discovery to this Target if > the previously discovered routes might still exist. The Default What is the safety margin associated with 'might still exists'? In TCP there is the Maximum Segment Lifetime (MSL) that is an upper bound on how long something is expected to be in the network. Your phrasing is a bit weak in that respect, especially not all routers along a path will forget the RPLInstanceID at the same time. However, as this is an experimental specification where such an ultimate timeout is not known, I would be happy to have this documented in a separate section under 'Known Issues/Future Work'. Section 6.1., paragraph 3: > Lifetime and Lifetime Unit parameters in the DODAG Configuration > Option specify the lifetime of the state the routers, including > the Origin and the Target, maintain for a Hop-by-hop or a Source > Route discovered using P2P-RPL. Thus, an Origin can safely reuse > an RPLInstanceID to discover a new route to a Target if the > lifetime of all previously discovered routes to this Target using > this RPLInstanceID is over. I would suggest is over plus some delta on top of it, in order to have a safety margin.
I suggest to add a section that describes more the experimental framework of this draft, including a list of items that a unclear by now, potentially in a (sub-)section 'Known Issues/Future Work'. I have found several places where open issues exists (see below) and also issue 3 in the DISCUSS part that should be documented in a single place -- for clarity and also for the simplicity of finding them in one spot and not scatterd around in the draft. Section 6.1., paragraph 27: > Individual P2P-RPL deployments are encouraged to share their > experience with these default values with ROLL working group to help > guide the development of standards track version of the protocol. I would add this to the proposed section 'Known Issues/Future Work', just to have the possible 'construction areas' documented in a single place. Section 9.2., paragraph 16: > Individual P2P-RPL deployments are encouraged to share their > experience with these rules with ROLL working group to help guide the > development of standards track version of the protocol. > Applicability Statements that specify the use of P2P-RPL MUST provide > guidance for setting Trickle parameters, particularly Imin and the > redundancy constant. This section until here seems to raise a number of questions that can only be answered in real deployments. I would add a pointer here to the proposed section 'Known Issues/Future Work'. The description itself in this section looks pretty comprehensive. Section 2., paragraph 1: > One use case, common in home [RFC5826] and commercial building > [RFC5867] environments, involves a device (say a remote control or an > airduct controller) that suddenly needs to communicate with another > device (say a lamp or a humidity sensor) to which it does not already > have a route. In this case, the remote control (or the airduct > controller) must be able to discover a route to the lamp (or the > humidity sensor) 'on demand'. I would remove the 'airduct controller' from the example as it doesn't add anything to the example, but just makes the text harder to read. Section 8., paragraph 4: > A DRO message MAY serve the function of letting the routers in the > LLN know that a P2P-RPL route discovery is complete and no more DIO I am confused about the 'MAY'. Is the function now to let the routers know that the discovery is complete or not? I guess it should more read 'messages can server'?
I am confused by the last bullet in 6.1. It states that a P2P-mode DIO may carry a PIO option, but no where does this document describe why (or how) that option would be used in this approach. What benefit would including a PIO have? Where would an arbitrary node in a RPL network get the information to include in a PIO? I support Ralph's concern about the inclusion of the Data Option in this specification.
I have no objections to the publication of this document, but I do have one comment: The 2nd paragraph of Section 2 reads as if it is desirable to route traffic through a point of congestion. I would suggest re-wording the second part of the paragraph to say that avoiding the congestion near the root is desirable using P2P routes.
draft-ietf-roll-p2p-measurement
The Gen-ART Review by Pete McCann on 5-Feb-2013 raises one concern about clarity. In Section 5, it says: > > An Intermediate Point MUST discard the packet with no further > processing if the received MO is not a Measurement Request (i.e., > T = 0). > The Intermediate Points are the routers on the route that are being measured, excluding the Start Point and the End Point. Section 6.1 identifies situations where the Measurement Reply _may_ travel back to the Start Point using the reverse of the measured route. So, it is possible that the Measurement Reply travels along the reverse of the measured path and, in this case, the Measurement Reply does pass through all the Intermediate Points. However, the End Point may decide to send the Measurement Reply along a different path than the measured one. In that case, the Measurement Reply may not pass through the Intermediate Points. It would be helpful to share this information with the reader in Section 5, instead of waiting for Section 6.1.
Very well-written and easy to understand document. Thank you. I have only a few minor comments for your consideration. 1. In this text: Such a route could be a Source Route [I-D.ietf-roll-p2p-rpl] or a Hop-by-hop Route [I-D.ietf-roll-p2p-rpl] established using RPL [RFC6550] or P2P-RPL [I-D.ietf-roll-p2p-rpl] I found the first two citations of [I-D.ietf-roll-p2p-rpl] a little confusing. The use of terminology from [I-D.ietf-roll-p2p-rpl] was already mentioned; no need to cite the sources of those terms here. 2. Are there any restrictions on the addresses (link-local, global scope, etc.) in the address list, used either for source-routing or accumulating a route? 4. Are there rules about what address a node should insert in the address list - for example, link-local if possible, MUST match End Point address prefix as specified by Compr? 5. Is the RPLInstanceID value 0b10000000 now reserved in some way? Section 4.4 call for the RPLInstanceID to be set to 0b10000000, but I don't see any requirement to check that value in a received MO.
3.1, Accumulate Route:
Route accumulation is allowed (i.e., this flag MAY be set to one)
inside a Measurement Request only if it travels along a Hop-by-hop
Route represented by a local RPLInstanceID (i.e., H = 1,
RPLInstanceID has a local value).
I think you buried the lede here. I suggest instead:
Route accumulation MUST NOT be used (i.e., this flag set to one)
inside a Measurement Request unless it travels along a Hop-by-hop
Route represented by a local RPLInstanceID (i.e., H = 1,
RPLInstanceID has a local value).
That MAY could cause a reader to miss the important point that this is a
requirement, even though this is followed with 'In other cases, this flag MUST
be set to zero'.
This is a nice, clear document, which was easy to review. I have just two very minor points, of the extreme-NON-blocking variety: -- Section 1 -- Note that it is important that the routing constraints are not overly strict; otherwise the P2P-RPL route discovery may fail even though a route, much better than the one currently being used, exists. The commas setting off that last phrase make it non-restrictive (it could be removed without changing the meaning of the sentence), and that's not what you want. So (adding a change to subjunctive mood along the way)... NEW1 Note that it is important that the routing constraints not be overly strict; otherwise, the P2P-RPL route discovery may fail even though a route much better than the one currently being used exists. ...or... NEW2 Note that it is important that the routing constraints not be overly strict; otherwise, the P2P-RPL route discovery may fail even though a route exists that is much better than the one currently being used. -- Section 6.1 -- The remaining fields inside a Measurement Reply may have any value and MUST be ignored on reception at the Start Point. The received Measurement Request MAY trivially be converted into a Measurement Reply by setting the Type (T) flag to zero. It's really a small point, but this doesn't feel like the right use of 2119 'MAY', because it simply follows from the rest of the paragraph, and the protocol only cares about what the Measurement Reply looks like, not how you went about creating it. I suggest this slight change: NEW The remaining fields inside a Measurement Reply may have any value and MUST be ignored on reception at the Start Point; the received Measurement Request can, therefore, trivially be converted into a Measurement Reply by setting the Type (T) flag to zero. END
I support the publication of this document modulo the changes resulting from Sean's points.
Thank you for addressing my concerns.
draft-ietf-eman-requirements
I have a large number of Comments, some of which I think are quite significant and I would appreciate it if the authors, shepherd, and AD looked at them carefully. However, I am only elevating two of them to the level of a Discuss --- I'm not convinced by the indirection of reading/controlling the power consumption/supply of/to one entity by accessing a different entity. I understand the practicalities of this (for example, we have had IP- connected power supplies for a number of decades), but I don't see the correlation between powered entity and power supply being made anywhere. That is, this indirection relies on manual configuration made in the management system or possibly in the power supply. I think you should observe this reliance, note its potential failings and the potential for attacks, and discuss how this conifiguration could be verified. (Noting that the security issue here is not one of direct control - which you call out in Section 9 - but of making attempted control of power to one entity actually affect the power to another entity.) There is a *tiny* amount of information found in 5.2.2 and 5.2.3. But, the mechanisms discussed in that section appear to simply allow one entity to be configured with the identity of a paower-partner entity, which doesn't seem to close many holes - imaging if we did routing like that! --- Some of your references are used in a Normative way. In particular, those referenced from Section 4.3 and also from 5.3 where it says: For reporting accuracy, the accuracy classes specified in IEC 62053-21 [IEC.62053-21] and IEC 62053-22 [IEC.62053-22] should be considered. Additionally, the reference from 9.1 is normative.
Congratulations on resisting the use of 2119 language. Well done!
---
In Section 2
Energy control
Energy control is a part of energy management that deals with
directing influence over network elements and attached devices and
their components.
'Directing influence' is too imprecise for me. For example, as written,
this could involve controlling fatures of a network element so as to
reduce power consumption. But, according to the Abstract/Introduction,
the control that you are talking about is limited to 'controlling power
supply and power state'. Could you tighten up this definition?
---
Section 3.1
In principle, there are three basic types of Power
States for an entity or for a whole system:
o full Power State
o sleep state (not functional, but immediately available)
o off state (may require significant time to become operational)
In specific devices, the number of Power States and their properties
varies considerably.
Superficially, it seems hard to conceive that the variation in a total
of 3 basic types of state cold vary significantly!
I would suggest that you introduce a 2nd entry in the list, viz.
o reduced power operational state (not fully functional, but still
operational)
It is this basic type that has the widest potential for variation and
fits with your subsequent statement:
However, more finely grained Power States can be implemented.
Indeed, there are no granularities of the the three absolutes that
form your list!
---
A little surprised to find no mention of allowing local policy to
override attempted control of power state. The is some hint in Section
3.3, but nothing much.
It seems to me that there is a need for both:
- An entity to have a good reason to know better than the management
system
- A management system to be able to override the local entity
I would suggest that this needs to be discussed so that it can be built
into the framework and solutions.
---
The term 'power properties' is used in the Abstract and Introduction,
and then shows up in Section 3.5. No clue is given as to what it means
until Section 5.3; and then only definition by examples.
Could you add it to the terminology section?
---
Shouldn't Section 4 expand on 'subtended devices'? Or is this a forward
pointer to Section 7?
---
4.2. Persistence of identifiers
The standard must provide means for indicating whether identifiers of
entities are persistent across a re-start of the entity.
This is important, but doesn't go far enough.
In *any* case where the identity of an entity or its components can
change there has to be a mechanism in place to ensure that the control
exerted by a management system is applied to the correct component.
---
4.3. Using entity identifiers of other MIB modules
s/other/existing/
---
5.1
it may be important to exclude
some vital network devices from being switched to lower power or even
from being switched off
I think you have your two cases reversed.
it may be important to exclude
some vital network devices from being switched off or even from being
switched to lower power
FWIW, 'vital' might actually be being used correctly here, but I suspect
you mean a more general 'mission critical' type term.
---
5.1.1. Type of entity
The standard must provide means to configure, retrieve and report a
textual name or a description of an entity.
I don't feel that a textual name/description helps to classify the type
of an entity. Furthermore, this hasn't really helped me understand what
you mean by 'type of entity'.
---
I found 5.1.2 and 5.1.3 a bit vague notwithstanding the examples
provided.
tags associated with an entity
that indicate the entity's role.
What roles have you in mind?
how
important the entity is.
Important to whom? Important for what? In what context?
---
I'm not sure, but it seemed to me that there is confusion between
Secitons 5.2 and 5.3. 5.2 is supposed to describe the capabilities
of the power interfaces, while 5.3 monitors what is happening at them.
In some cases, the issue is simply not enough flexibility. For example,
in 5.2.7 the 'nominal voltage' on an interface may actually be a range.
Consider devices that can be plugged into a varieties of supply and
auto-detect.
In some cases there seems to be direct overlap. For example, 5.2.5. says
'The standard must provide means for monitoring for each Power Interface
if it is in actual use.' On the other hand, Section 5.2 seems to be
missing an entry for nominal power ranges (especially maxima).
---
Not that it matters, but if you are reporting instantaneous power and
actual voltage, you probably don't need to also report actual current.
---
High/low power notifications in 5.3.6 are good. Did you consider high/
low voltage and high/low frequency notifications?
I was surprised that Power State is consistently capitalized, but is really a pretty fuzzy concept. Instead of broad power states, most of the equipment I know of works by enabling / disabling or tuning subsystems in order to control the current being drawn overall. For instance, turning off radio amplifiers, dimming or turning off displays, turning off hard disks, stepping down CPU performance, etc. Are those sub-states of a Power State? Apologies if it's clear to the authors or other readers, but I was not understanding this from the rough description in the document. It isn't clear to me that this requires supporting conveyance of that kind of state, or management of that level of state. Instead it's talking more about inlets and outlets, which sounds more like it's for managing a rough-grained set of power buses, but not so much for really working at managing the energy used by a network of functioning devices. To resolve this DISCUSS: If that's supposed to be in-scope, then I don't think it's clear. I'll go to 'No Objection' if I'm the only one confused. If that's NOT supposed to be in-scope, then I think it should be said explicitly.
(1) Are sleepy nodes, power harvesting and self-controlling devices included? (By self-controlling I mean devices that set their own sleep-thresholds based on history.) They need to be in some eventual standards. Maybe eman standards (and this document) ought have some kind of applicability statement limiting scope to 'reasonably ok infrastructure' use-cases. You might even be better off splitting battery powered devices out at first as well. (2) section 4, 'Entities must be uniquely identified' is plain wrong - 10.0.0.1 is just fine in lots of places. Other parts of section 4 based on this error will likely also need changing. (2nd paragraph for example.) Note that this is not the same as objecting to 4.1, which is fine. Having well-defined ways to identify things is fine but insisting that all things are identified in any particular way (or ways) is not. (7.4 and 8.1.4 have the same problem with their combinations of 'must' and 'all'.) (3) 6.1, 6.2 and section 8 may have serious consequences - are we really ready to go straight there? I think the authorization implied by this is maybe too onerous to attempt now except in limited cases (e.g. a data centre's separate control VLAN). I don't believe saying 'sufficiently protected' is enough, as you do in section 9. Again an applicability statement might help here limiting these features to networks that are reasonably well managed. (4) section 9, the relevant privacy protection needed here relates to stored data. Transmitted data will require confidentiality but stored data has serious privacy consequences, especially for home network devices.
- section 2, I think it'd be better to distinguish 'mains' power inlets and power harvesting or 'dodgy supply' inputs as those have very different characteristics. - 3.1 - it seems odd to not reference existing power state standards here as those are widely used (S0 etc.) - 3.2 - not all energy management is about simply using less, in the case of power harvesting devices, one may need to preserve energy so that it can be used when communications are needed (with radios being the most expensive power consumers) - section 4, 2nd para: 'important to' do X is not stating a requirement. - 4.1, 'The standard...' seems badly phrased. What if more than one is needed? - 4.2 seems like it'd need a new grand unified naming scheme. I doubt that such will be done. - is 5.1.1 really needed? seems too fine grained to be useful to me - 5.1.3 seems very vague - 5.2, a solar panel connected to a charge controller doesn't seem like a transmission medium to me - 5.2, some devices supply power - 5.2.5 might be impossible for a sleepy router (if you can't ask cause its asleep which isn't instantaneously distinguishable from broken) - 5.6.1, in what units do you define battery charge? don't you need to say? - 5.6.4, isn't that temperature dependent? maybe actual voltage would be as or more useful (I dunno, but that's worked better for us with gel/VRLA batteries) - 5.6.7, charge cycles are not the only causes of replacement notifications I think - doesn't that depend on the battery technology? e.g. memory effects - 5.6.8 is too much - some arrangements of cells can only be handled as a group - 7.2 note that reporting for aggregates rather than lists of individual indentifiers might be more useful - 9.1 s/privacy/confidentiality/ - 9.1 protection against traffic analysis seems very hard here in some cases but would be implied by referring to 3711, 1.4 - do you really want that?
I have some comments, mostly in the form of questions asking for clarification. the name intended to be a unique identifier? Does that identifier encode information about the type of the entity? Or is the 'name' a type identifier for the entity? 5.2.4. Availability of power The standard must provide means for monitoring the availability of power at each Power Interface. This indicates whether at a Power Interfaces power supply is switched on or off. I can't parse the last sentence, and I'm not sure what the intended meaning is. 5.3.1. Real power The standard must provide means for reporting the real power for each Power Interface as well as for an entity. Reporting power includes reporting the direction of power flow. Is 'real power' a term of art (a brief definition would have helped me). 5.3.4. Accuracy of power and energy values The standard must provide means for reporting the accuracy of reported power and energy values. Would the precision of the measurement be useful as well? 6.2. Controlling power supply The standard must provide means for switching power supply off or turning power supply on at power interfaces providing power to one or more device. This requirement raises a small philosophical question. Does 'Power State' apply to power supplies (and, more generally, entities that provide pwoer to a power outlet)? If so, is thee a need to call out power supplies as special entities or can they be controlled by their Power State like other entities?
3.2: The title of the section is a bit restrictive; delete the word 'Agreements' 5.2: Though mentioned in the main body of 5.2, none of the 5.2 subsections mention that the standard must provide means to determining whether any particular interface is currently operating as an inlet or an outlet for those interfaces that change. 5.6: I find it a bit weird for batteries to be dealt with as something that an entity 'contains' rather than being a full-fledged entity unto themselves. Batteries have a power interface that may be used as an outlet, and inlet, or both; they have voltage and power states on that interface; etc. Batteries are a special kind of entity in that they store charge, but calling them out as part of another entity seems weird. (By the way: Temperature is an awfully important property of batteries when it comes to power management; should it be required to be dealt with by eman standards?)
No objection, and nothing blocking here -- just some clarity points:
This document is going to get a lot of editing from the RFC Editor, so be
prepared for that during AUTH48, and give it careful review to make sure they
didn't make any mistakes in the process. I'm not going to try to do their job,
but I will try to call out a few of the items that I found actually confusing
when I reviewed it.
-- General --
You capitalize 'Power Interface' and 'Power State', but not 'power inlet' and
'power outlet'. This seems purposeful, but the purpose isn't clear. What's
the purpose? Is it worth explaining that in the document (quite possibly it
isn't)?
-- Section 1 --
Subject of energy management are entities in the network. An entity
is either a device or one of a device's components that is subject to
individual energy monitoring or control or both.
Too many 'or's make it a bit confusing what the 'or both' means. Is it 'a
device, a component, or both,' or is it 'monitoring, control, or both'? It's
also not clear whether the 'that is subject to' part applies to both devices
and components, or just to components. Maybe this is crisper?:
NEW
Subjects of energy management are entities in the network. An entity
is a device or one of a device's components, which is subject to
individual energy monitoring and/or control.
END
In detail, the requirements listed are focused on the following
features: identification of entities, monitoring of their Power
State, power inlets, power outlets, actual power, power properties,
received energy, provided energy, and contained batteries. Further
included is control of entities' power supply and Power State.
As I read this, I get a list of features:
1. Identification of entities.
2. Monitoring of their [the entities'] Power State.
3. Power inlets.
4. Power outlets.
5. Actual power.
... etc ...
You can see that 1 and 2 have verbs, but the rest don't. Or did you mean for
'monitoring' to apply to all of them? If that's the case, let me suggest using
semicolons to group the comma-separated lists, this way>
NEW
In detail, the requirements listed are focused on the following
features: identification of entities; monitoring of their Power
State, power inlets, power outlets, actual power, power properties,
received energy, provided energy, and contained batteries; and
control of their power supply and Power State.
END
-- Section 2 --
Energy Management is a set of functions for measuring, modeling,
planning, and optimizing networks to ensure that the network
elements and attached devices use energy efficiently and is
appropriate for the nature of the application and the cost
constraints of the organization [ITU-M.3400].
One gets lost in such a long sentence, and by the time 'and is appropriate'
comes along, one can't decide what the subject of 'is' is. It looks like it
should be 'Energy Management', but that can't be right, because breaking out a
sentence such as, 'Energy Management is appropriate for the nature...' doesn't
work.
I think maybe you mean this, yes?:
NEW
Energy Management is a set of functions for measuring, modeling,
planning, and optimizing networks to ensure that the network
elements and attached devices use energy efficiently and in a
manner appropriate to the nature of the application and the cost
constraints of the organization [ITU-M.3400].
END
Oh, and you can't seem to decide whether it's 'energy management' (the
definition heading and subsequent usage) or 'Energy Management' (the definition
body). The same is true for 'energy management system', which follows.
Please be sure you're consistent in your capitalization of all these terms; the
RFC Editor will call that out, so save time now.
-- Section 3.1 --
However, more finely grained Power
States can be implemented.
Perhaps it's worth giving an example or two of what finer-grained Power States
might look like (or providing a citation to where such examples are)?
-- Section 3.2 --
In many cases there is
no way of reducing power without the consequence of a potential
performance, service, or capacity degradation.
Aren't performance degradation and capacity degradation *types* of service
degradation?
The discussion of time series measurements in 5.7 raises the question of time synchronization. Is there a need to ensure that time is synchronized between data collectors and data generators?
There is a lot of text in this document that tries to constrain how to build an Energy Management System, and don't have anything to do with placing requirements on standards documents for interacting with what they measure. The instance that elevated this to a DISCUSS for me is in 5.7 where the document says 'It should be avoided that time series data can only be obtained through regular polling by the energy management system.' Why should the IETF be making such a statement in this document?
Many logging systems in existing energy management systems only create records when the thing being measured changes by a threshold (such as a temperature changing by so much). It's not clear how the data from this type of system and the requirements at 5.7.1, 5.7.2, and 5.5.2 interact. How does section 3 (particularly section 3.2) inform requirements on standards documents. It would help to recast these in what difference it makes to what's required of those standards documents.
0) Support Stephen's discuss wrt privacy/confidentiality. Attackers are going to go after the most significant entity first, so we need to keep their data private when stored and protected in transit. 1) abstract: r/functions:/functions. 2) abstract/intro: is actual power consumed power? No wait it's supposed to be power state? 3) intro: The 2nd paragraph's last two sentences are repeated in the 4th so maybe just delete the 2nd paragraph's last two sentences and merge the 2nd and 4th paragraph? 4) I echo Adrian's kudos for avoiding 2119. 5) s1.2: Hoping that the authentication/authorization scheme to allow one device to monitor another is going to be a requirement later on. 6) s2: Had the same issue Barry did with Energy Management definition. 7) s3.1: Agree with Adrian on power states. There's also always standby as opposed to sleep - or are they the same thing? Maybe also full power = on for those simple entities. 8) s3: Is energy management all about actually using less energy? I would have thought energy management was about informing the management entity about the power consumption to allow them to take some action, which just as well might be no action because it's operating in some normal range. I mean I can run a nuclear reactor right at the minimum Level of Energy needed or maybe I can be somewhere above that minimum in a safety zone. Then again, maybe minimal is the lower bar of the safety bar. Regardless, I'm sticking with my first sentence ;) 9) s3.2: Awkward (well at least for me) OLD: Then a trade-off needs to be dealt with between service level objectives and energy minimization. NEW: In this case, a trade-off needs to be made between service level objections and energy minimization. 10) s3.3: I guess we need some kind of requirement for synching clocks? 11) s?: Do you also need to know who's been assigned to manage the entity? Is that in context of an entity? Also do you need to know location data or is that provided through another mechanism? 12) s5.4: Does this section cover the timers set on local systems for stuff like System Sleep Timer, Disk Sleep Timer, etc?
conflict-review-levine-tld-variant
I did wonder whether the response shouldn't read 'Related to dnsop, but no conflict'. OPS ADs can probably tell us.
I wondered if there was a basis on which these ccTLDs were selected.
conflict-review-hartmann-default-port-for-irc-via-tls-ssl
In support of Robert's DISCUSS.
This document currently claims to Update RFCs 2812 and 2813, which are IETF stream documents that went through a Last Call. It's not clear it actually does, and that these are meant as 'see also'. If that's right, I suggest we ask these be removed. If that's not right, and these actually do update those RFCs, we should discuss whether this document is in the correct stream.
I agree with Robert's Discuss. I also have concerns about giving this document any status with the port number included until it has been through port number review by the designated experts since this may precipitate a collision in the wild.
Note that if this document had come through the IETF stream I probably would have asked for a bit more information about the certificates: s2.3.1/2: why only common name what about putting the FQDN/nick in the subject alt extension? s2.3.1/2: when you say should verify that the certificate validates back to an installed Trust Anchor as in [RFC5280]? s2.3.2: Should the server also verify the client's cert? WRT to naming matching should RFC 6125 be followed?