IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2015-04-23. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: Spencer
1 Administrivia
2. Protocol actions
2.1 WG submissions
2.1.1 New items
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
2.3 Status changes
2.3.1 New items
2.3.2 Returning items
3. Document actions
3.1 WG submissions
3.1.1 New items
Telechat:
3.1.2 Returning items
3.2 Individual submissions via AD
3.2.1 New items
3.2.2 Returning items
3.3 Status changes
3.3.1 New items
3.3.2 Returning items
3.4 IRTF and Independent Submission stream documents
3.4.1 New items
Telechat:
Telechat:
3.4.2 Returning items
3.4.3 For action
Telechat:
Telechat:
1025 EDT no break
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
Telechat::
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
7. Working Group News
Amy: still collecting data on timing of BoF coordination
Amy: please let us know if we should hold any hotel rooms for you (or say you've made arrangements elsewhere
1102 EDT Adjourned
(at 2015-04-23 06:00:03 PDT)
draft-ietf-tram-stun-origin
Just to keep the IESG in the loop, without revising the document during balloting ... In discussion in Dallas, the editor agreed to remove this sentence from Section 2. of draft-ietf-stun-origin: "The size of ORIGINs included in a STUN message can have a major impact on the size of a STUN packet, and could potentially cause UDP fragmentation." This mention of fragmentation had raised the possibility of requiring support for SCTP in STUN and other things that there was no interest in doing, so the decision was to just remove this non-normative statement. Also, this statement is highly speculative as there are no known use cases where multiple ORIGINs will be included for WebRTC, SIP, or XMPP.
"Analytics" here together with the MUST include statements could amount to a fancy way to describe monetizing people's WebRTC calls in ways that the end user will just not expect. I'd like to check that we're not doing that, as it'd arguably run counter to e.g. RFC7258 or to the general trend towards data minimisation. And making privacy worse, even by a little, seems worse than making it better. (Note: I am here asking about the STUN/TURN server being perhaps unnecessarily told the origin, not the risk that someone sees that in-transit, which is handled in the draft already.) I do agree that the TURN 401-like challenge use-case is perhaps needed, but I do not see that other use cases need to see the origin for them to work at all. And I'm not sure that such a spoofable origin is so useful for that TURN case, esp. when there's parallel work on an authenticated equivalent. (I mean the tram 3rd party thing.) I also don't see that that is needed for network management reasons - surely everything needed for network managment is no more nor less visible to the STUN or TURN servers when this is used vs. when this is not used. So why are we pushing for this? If it is really only for so-called "analytics" then is that ok? (And where can I find a definition of what that means?) Apologies if this discuss seems somewhat high level, but as well as the general concern, the last paragraph of the current tram charter seems to me to me to say that tram ought not make privacy worse. But maybe I'm missing the networking function that needs this - if so, I'm sure someone will point that out.
- intro, para 2: STUN only defines two auth modes that I can see, and you only mention two here - what's the 3rd one you mean? (Is it DTLS?) - What if >1 TURN session with different origins is being setup from same client/browser? Does that work? (Say two parallel calls, not the case where the same resource is being accessed at the same time loaded from different referring web pages.) - I'd suggest to not allow >1 ORIGIN in a STUN request? But that discussion seems to be in-hand. - section 2: suggest providng similar examples for all schemes, http(s),sip & xmpp. - 2.1 & 2.2: MUST include web origin - couldn't there be "private browsing" scenarios where that MUST would be a problem? I'm not suggesting that the origin exposes very much but I think a SHOULD would be more appropriate. - 2.1 last para: source here means the webrtc server right? That's a bit ambiguous and would be better clarified. - What is the benefit of sending an empty origin as opposed to no origin attribute? I don't see any and the former just advertises that the client is "privacy sensitive" which seems incongruous.
I agree with all 3 points of Barry's discuss. I think the normative language in section 2.1 is ambiguous about whether it applies to all stun implementations used by a browser, SIP, or XMPP, or just those that "implement this draft". A thoughtful reader can infer the answer from the fact that the draft does not update STUN, but it might be helpful to clarify. [Removed some comments that have been explained to my satisfaction] Nits: -- Section 1: I agree with Barry that the first reference to STUN should probably go in the previous sentence. Should reference to " Section 4.5 of [RFC7376]" really be 4.6"? 4.5 talks about a MiTM learning USERNAME. 4.6 talks about hosting multiple realms from the same IP address. (And as Barry mentioned, these are really "List entries 5 or 6 in Section 4")
A point of detail, really, if you update the draft. For a web application provider STUN or TURN server, the server will have no idea which web pages or sites are sending binding requests to the service. In conventional applications, the SOFTWARE attribute would provide some identifying information to the service, but that no longer works when the browser is the application. SOFTWARE attribute: a reference to http://tools.ietf.org/html/rfc5389#section-15.10 would be beneficial
I support Stephen's Discuss.
I have three questions I'd like to discuss. The discussion might or might not
lead to any document changes, so let's please have the discussion first, and
see where it leads.
1. In Sections 2.1 and 2.2, I find this combination odd:
a. For non-web origins, you SHOULD (not MUST) send ORIGIN.
b. But for web origins, you MUST send ORIGIN.
c. But that ORIGIN can be empty.
If you're allowed to send an empty origin, and you can sometimes not send
ORIGIN at all, why is ORIGIN REQUIRED (but can be empty) in some cases? How
does that help interoperability or security or whatnot?
2. In Sections 2.2 and 2.6, about the SHOULD NOT ("NOT RECOMMENDED"): Why?
What happens if you use it? Under what conditions might you do so, even though
this says you SHOULD NOT? (Why is it not "MUST NOT"?)
3. In Section 2.7:
Therefore, if
a STUN request contains multiple origins, the first origin MUST be
used and the remaining origins ignored.
For all cases (that's what it says)? Or was this just meant to apply to SIP
and XMPP? Or SIP, XMPP, and WebRTC? But not to other HTTP uses? Or yes to
HTTP? If this really does apply to all cases, why are multiple origins allowed
in the first place?
-- Section 1 --
A minor thing: the citation for STUN in the first two sentences seems odd.
Instead of citing 5389 with the first use of "STUN" in the first sentence, you
cite it in the second sentence where it appears to be a reference for "a STUN
extension". I suggest moving the citation to the first sentence, so: "STUN, or
Session Traversal Utilities for NAT [RFC5389], is a protocol used...."
It wouldn't be a bad thing to add an informative reference to CORS and to cite
it when you mention it. <http://www.w3.org/TR/cors/>
There is no Section 4.5 in RFC 7376. Perhaps you mean Section 4, bullet 5?
-- Section 2.1 --
For STUN requests sent without authentication to a STUN server (i.e.
STUN binding requests sent to a STUN server), the STUN client MUST
include the ORIGIN attribute when the origin is a web origin. For
other origins, such as SIP or XMPP, the STUN client SHOULD include
the ORIGIN attribute.
Note that for privacy reasons, an empty ORIGIN attribute can be
sent, as described in the Security Considerations.
The "i.e." tells me that the two things are synonymous: that "STUN requests
sent without authentication" is the same as "STUN binding requests". Is that
really true? Is it true that all binding requests are sent without
authentication? Or am I quite misunderstanding what you're trying to say here?
What, exactly, do you mean by "when the origin is a web origin"? From the
previous section, that seems to refer to something sent by a web browser. But
a web browser is just a piece of software, and a web browser could happen to be
a SIP or XMPP client, as well. Do you really mean to refer to origins that use
the "http" scheme? You might clarify this, particularly because it's involved
in a "MUST".
A STUN server can derive additional information for logging and
analytics about the request through the ORIGIN attribute, such as the
source of the request. For example, an enterprise STUN server might
only reply to STUN binding requests from certain domains.
In the example case, does that mean that such a server would not reply to
binding requests that lacked ORIGIN (or had an empty one)? If so, that would
be a good bit of explanation to add. I don't think that what's in the Security
Considerations is enough to answer that question up here.
-- Section 2.2 --
When the origin is a web origin, TURN [RFC5766] Allocate requests
MUST include the ORIGIN attribute. For all other TURN requests,
including the Send method, the use of the ORIGIN attribute is NOT
RECOMMENDED. For other origins, such as SIP or XMPP, TURN Allocate
requests SHOULD include the ORIGIN attribute.
The order here is odd, and made me read it a few times to be sure that I
(thought I) understood it. I would switch the order of the second and third
sentences. Apart from that, I have the same comments here that I had about
Section 2.1.
-- Section 4 --
DTLS or TLS transport SHOULD be
used when integrity protection for the ORIGIN attribute is important.
Just curious here: When is integrity protection for it *not* important (and how
will the client know that), given that the server might use it to determine
whether it should respond, or to affect the authentication challenge? (And,
actually, the first sentence of the next paragraph repeats the SHOULD without
the qualifier. I suggest just removing the qualifier and merging the "TLS/DTLS
SHOULD be used" advice from the two paragraphs.
Also, given that Section 2.1 says that the server might use it for logging and
analytics, it might be good to add that the server SHOULD NOT rely on
information from the ORIGIN attribute in the absence of secure transport.
I suggest factoring out the ends of the last two paragraphs (the parts that
start with "In cases where") into a new last paragraph, rather than saying the
same thing twice saying the same thing twice.
draft-ietf-isis-extended-sequence-no-tlv
- last para of section 5 (before 5.1) could do with a bit of a re-write, it's not very clear. - section 7: When this mechanism is used, can an attacker who can delete or re-order packets (which is v. similar to one who can replay packets) cause any new bad outcomes due to the verification of the out-of-order arrival? (Sorry, I don't know IS-IS enough to know the answer there, it's probably obvious.) If so, then maybe that argues that one ought note that this doesn't address such threats (but that this is still I guess worthwhile).
Just a small formatting nit: Sections 10 and 11 seem to be intended as appendixes, but show up as sections.
-- Section 5, third paragraph: Can you offer any guidance on timeliness? At least an order of magnitude? . Nits: -- Please expand IS-IS on first mention in the body, even though you already did in the abstract. -- Section 5, 2nd paragraph: "The implementation SHOULD also allow operators to control the configuration of ’send’ and/or ’verify’ the feature of IS-IS PDUs for the links and for the node." I don't understand the sentence
Thanks for addressing the SecDir review: https://www.ietf.org/mail-archive/web/secdir/current/msg05560.html
With respect to keeping the ESSN increasing, you mention cold-starting the router... but what about when the router hardware is replaced? The mechanism outlined in Section 10.1 should cover things there (just make sure that the old and new routers both have the time set correctly), but the mechanism in 10.2 won't. Does this matter? Or will the new router always have new keys, so it doesn't matter (I guess the last sentence in 10.2 covers that)? As long as you call Sections 10 and 11 "Appendix", the RFC Editor will move them to the end and re-number them. Please check in AUTH48 to be sure the forward references to Section 10 (in Sections 3 and 3.1) are correct. Or perhaps just don't call those sections appendices. It seems to me that they're useful enough and brief enough to be part of the document main.
draft-ietf-bess-mvpn-bidir
The remaining comment from Elwyn's Gen-ART review would be worthwhile one to address, in my opinion.
I am balloting no-obj on the premise that folks with more MPLS expertise have performed an in-depth review of this work.
draft-ietf-httpauth-digest
A simple comment to resolve, I would think - avoid using actual DNS domains. Please use example.com, or at least provide rational as to why example.com/net can't be used.
I'm a yes on this, not because it's great technology (it just isn't;-), but because it is a valiant effort to do responsible updates to a scheme that is used somewhat. Thanks for doing the work. - The intro could usefully say that this extends but is generally backwards compatible with 2617 if you don't use any new stuff and include a pointer to appendix A as well. - p5, "nonce": "data string" is an odd combination - p6, "stale": Is "TRUE" the literal value? What if it's "1" or "y" - just wondering in case current code does something there. Section 3.3 (and elsewhere) uses "true" and "false" which aren't the same as TRUE and FALSE (or are they?) It'd be good to be consistent or to say that we're not being consistent, presumably for historical reasons. - end of 3.4: is there a specific section of 7234 that's most relevant? If so, good to say so. - 5.3, you could maybe add a reference to RFC7486 at the end of the 1st para (that is blatent self-advertisement, but I couldn't resist:-) - 5.6, is the "note" about Basic still true? I thought Julian or someone tested it and found it not quite so bad? - I think something went wrong with the secdir review [1] but I'd also encourage us to try to bottom out on Hilarie's comments. There may be something there that could be used, without any damage to backwards compatibility, which would be interesting. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05621.html
Just a few minor comments: 3.3, domain: "If the URI is an abs_path..." Should that be "path-absolute", in keeping with the reference to 3986? 3.6, paragraph 4: "Because the client is REQUIRED to return..." The use of a 2119 keyword in a dependent clause seems odd. 5.1: "Digest authentication SHOULD be used over a secure channel like HTTPS" Does this mean that, if you have a secure channel you should use digest, or if you use digest you should use a a secure channel? I assume the second, but the sentence can be parsed either way.
testrealm.com is of course a domain that actually exists... testrealm.example.org/com would seem fine.
draft-ietf-uta-xmpp
This is important work. Thank you for doing it. I have a couple of points where I wasn't clear on the text, but they're nits. I'm not quite sure what this text: 3.3. Session Resumption In XMPP, TLS session resumption can be used in concert with the XMPP Stream Management extension; see [XEP-0198] for further details. means in a major section called "Recommendations". Good idea? Bad idea? Doesn't matter? It depends? I could read "can be used" as saying "it's physically possible", or "it's OK", so I thought I should ask. I'm fine with you not saying anything normative, but it seems like a thumbs up/down/sideways would be helpful, at a minimum. In this text: 5. Security Considerations The use of TLS can help limit the information available for correlation to the network and transport layer headers as opposed to the application layer. I'm guessing what "as opposed to" means. Is this saying The use of TLS can help limit the information available for correlation between the network and transport layer headers and the application layer. or something else?
3.4, paragraph 3: Would you offer different guidance about the multi-tenant problem if POSH and DNA were finished? I don't suggest delaying for that, even though they are both post-WGLC. But I wonder if there is something here we need to clean up after POSH and DNA are published? Paragraph 4: By "unauthenticated connections", I assume it means "unauthenticated TLS [or encrypted] connections". Is this correct?
-- Section 3.4 -- Wherever possible, it is best to prefer authenticated connections (along with SASL [RFC4422]), as already stated in the core XMPP specification [RFC6120]. In particular, clients MUST authenticate servers and servers MUST authenticate clients. How does "prefer" "whenever possible" match up with "MUST" and "MUST"? Ah, I see; in the next paragraph, we have server-to-server authentication, which isn't a MUST. Got it. So, purely optional if you agree with me, but I'd find it less confusing like this: NEW Wherever possible, it is best to prefer authenticated connections (along with SASL [RFC4422]), as already stated in the core XMPP specification [RFC6120]. In particular: * Clients MUST authenticate servers. * Servers MUST authenticate clients. * Servers SHOULD authenticate other servers. This document does not mandate that servers need to authenticate peer servers, although such authentication is strongly preferred. Unfortunately, [...etc...] END -- Section 3.6 -- I understand that, while most users won't understand it, there's value in trying to communicate to an end user that she is using a secure connection. I am very skeptical that there's the slightest bit of value in giving end users information about the version of TLS used, the mechanism for verification, the details of the certs (if any), or the details of the cipher suite. I'm certainly skeptical that making that available to end users should rise to the level of "strongly encouraged". I'm not going to block anything with regard to this, but I see this as something you might strongly encourage be available to an administrator, but not to an end user (other than, perhaps, by enabling detailed logging through an advanced setting, then inspecting the logs).
draft-ietf-dane-srv
Just a nit.. Every day I learn new things. Today was the day that I learned that TLSA actually doesn't mean anything. My first guess had been that it had something to do with TLS (TLS Authentication?) and spent some time trying to decipher in the context of the draft. Eventually I did find the "definition" in rfc6698: "TLSA" does not stand for anything; it is just the name of the RRtype. Maybe most/all of the readers of this document will already know what TLSA is, but just like we tend to expand non obvious (at least to me!) acronyms when they are first mentioned, it would be nice (specially for readers like me) to clear up front what it means (or doesn't mean).
Thanks for this. Protocols using SRV have been left out of the DANE party for too long :-) But I still have a couple of comments: 3.1, 2nd paragraph (note) I have mixed emotions about smtp-with-dane as an informational reference. Putting it in a "note" aside, can one safely implement and use dane-srv without reading that draft? (If the answer is really "yes", then I'm okay with it.) 3.2, first paragraph: Is this meant to imply that one must resolve every SRV target? I would assume that it follows the normal SRV rules and application protocol rules, which may or may not result in queries for every SRV target in the set.
* The reference to Section 4 of draft-ietf-dane-smtp-with-dane in the Note within section 3.1 seems out-of-date. * The intro to Section 3.2 says "A and/or AAAA", but the first two bullets in the list seems to assume that both A and AAAA lookups are performed.
draft-ietf-eman-applicability-statement
This is updated. The original comments were posted for -08 back in December. I don't believe I've ever seen any mail on this one since. (Not unreasonable as Pete's discuss was being handled.) However, I don't see major changes between -08 and -10 so I've not (yet, I will if time) gone fully back over this again. It'd be nice (for me:-) if someone responded to these comments as if they were made on -10 before the telechat. - general: I am not at all sure that this does match the other EMAN documents that have been through IESG evaluation (which is the stated reason for this being last). See my comments below, but this seems to me to not have been updated to reflect where the actual EMAN drafts/RFCs ended up. Is that a fair comment? If so, it really should at least be noted in this draft (or fixed!). If not, then I'm confused and my memory must be worse than I thought. - I support Pete's discuss - general: I don't care much if the title confuses this with an AS or not:-) - general: Given the write-up would it be worth re-casting this into the past tense? (Or a part of the abstract and intro at least and then explaining the use of the present tense elsewhere.) - 1.3, 2nd last para: what is a proxy here? - 1.5: EnMS vs NMS - aren't both likely to be pronounced the same by some folks? Is this term used in other EMAN docs? If not, maybe get rid of it as it'd not then be needed perhaps? - 2.11 - I don't recall printers being mentioned in other EMAN docs, but that's probably my fallible memory. - 2.12 - I thought these devices were out of scope for EMAN? If so don't you need to say? If not, then can you explain how I'm confused given that there were a bunch of times Pete and I asked about energy harvesting setups and were told those were not in scope? - 4.1.2.1 - ACPI is mentioned twice but is never expanded never mind explained. Given that this is the power state thing with which most readers of this RFC will be familiar, I think that is quite an omission, and one that ought be fixed. - 4.1.4 refers to a 2011 draft - surely that's been updated or OBE by now? If "draft" here means something sufficiently different from Internet-draft, then that'd be worth explaining. - section 4 generally seems quite US centric, which is a pity. I'm not suggesting you try fix that now, but nonetheless... a pity. - section 5 seems quite outdated if I correctly recall the discussions we had at iesg evaluation of other EMAN documents. Why wasn't this kept in sync with those discussions? - section 6 is bogus - you said EMAN could also use YANG so SNMP is not sufficient here. I would like to have seen a real analysis of the security and privacy issues related to energy management but that seems to still be missing. And again if I recall correctly that was a topic that you de-scoped for other EMAN documents. Yet again that is not recoreded here. - the secdir review [1] also notes the paucity of the security considerations text (and was only responded to by the AD, not by the authors, even though it raises some specific issues). [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05257.html - The above two points are not DISCUSSes for a couple of reasons. 1) the charter (sadly) doesn't explicitly call for security or privacy to be considered and clearly this group were not interested in those topics, and 2) there seems to be no hope at all that such work would be done given where the WG are in their life-cycle. I would hope that any newly chartered work on energy management would better take into account these real issues. (And should I still be on the IESG, that'd be more than a "hope":-)
[edited to fix missing word] I agree with Stephen's comments that the security considerations are sorely lacking. I understand his reasoning for not asking the group to do considerably more work at this point in the process. But I'd like to see at least an explicit mention that power management as described in some of the use cases in this draft may have significant privacy considerations--even if that mention takes the form of "We haven't fully analyzed privacy issues, and leave that work to a follow on effort." If, on the other hand, people think there aren't privacy issues, I'd like to see that assertion along with supporting arguments.
- This draft (section 2) reads more like a collection of use cases than an
applicability statement explaining how the EMAN framework can be applied to the
different use cases. Only a few use cases provide guidelines wrt EMAN
relationships between objects. Let's take an blatant example, section 2.10
"industrial automation networks": where is the applicability statement in that
section? I started reading the document with a No Objection in mind, more like
Alissa, who wrote:
I would suggest that the authors and WG consider the
existing text in light of what is involved in an Applicability Statement
(RFC 2026 Section 3.2) before that re-evaluation happens. In particular, an
Applicability Statement is supposed to describe how, and under what
circumstances, one or more technical specifications can be applied to
support a particular Internet capability. There are several use cases in
this document that provide no explanation of how the EMAN technical
specifications can be applied to support the use cases, in particular the
ones listed in 2.10, 2.11, and 2.12.
Then I thought about a DISCUSS, but Brad already proposed to delete the last
paragraph of 2.7 and the sections 2.12 & 2.14. That would address my point. The
alternative is to keep those section but to explain how the EMAN framework, as
one building/foundational block, would help solving those use cases, and
elaborate on which extensions would be required, even succinctly.
- What is your message with section 3? I guess you want to say that the EMAN
framework (in his entirety of as a building) is applicable to all of these
patterns, and that other energy use cases, not described in this document, with
those parameters are potentially applicable to the EMAN framework. You might
want to stress this point.
I support Stephen's comments and don't have any others to add since it use SNMP security and I hope we'll see more details in solution drafts. Thanks for your work on this draft, the summary of work elsewhere was useful.
-09 seems to have corrected most of the bad references and citations, as far as I can tell by a fairly quick check. One that remains: The reference for [EMAN-MONITORING-MIB] has an incorrect document filename; the correct name is "draft-ietf-eman-energy-monitoring-mib". Thanks very much for handling that, and for addressing my other comments.
The draft still calls out some use cases that appear out of scope, especially after the discussion around the EMAN MIB document. This DISCUSS is a placeholder to address one of the author's suggestion to delete: 1) the use cases in section 2.7 last paragraph (net-zero building), 2) 2.12 (off-grid devices), and 3) 2.14 (power capping).
Thank you for addressing the issue of the document's status.
I generally support the points raised by Brian, Pete, and Stephen.
It sounds like this document is going to get re-evaluated as a standards track
Applicability Statement. I would suggest that the authors and WG consider the
existing text in light of what is involved in an Applicability Statement (RFC
2026 Section 3.2) before that re-evaluation happens. In particular, an
Applicability Statement is supposed to describe how, and under what
circumstances, one or more technical specifications can be applied to support a
particular Internet capability. There are several use cases in this document
that provide no explanation of how the EMAN technical specifications can be
applied to support the use cases, in particular the ones listed in 2.10, 2.11,
and 2.12.
Editorial comment on Section 4.1.3:
"In particular, one of the concepts being considered
different energy meters based on if the device consumes
electricity, produces electricity, or is a passive device."
This sentence does not parse.
This version got a second last called as a proposed standard to address Brian's dicsuss.
draft-ietf-scim-use-cases
- 2.1: "make ... easier" seems understated, presumably we care about interop, security, scaling etc. and it'd actually have been easier (in a sense) to just have everyone follow one vendor or open-source thing. - 2.1, "It's intent" - the It's is a little ambiguous. - 2.2.1, last bullet: I don't get that. Are real-time things even in charter I wonder? (CHECK) - 2.2.2, Better to use example.com, example.net than FooBar.Inc etc unless there is a reason that the usual examples do not work. - 2.4, what is the impact for SCIM generally of "assuming" use of LDAP here? If that's just an example, that's fine (but it could be clarified), if it's more than that, then it'd be good to know what exactly is meant. - 3.1, file permissions seem to me to be out of scope of SCIM. Changing UIDs, UUIDs, or similar is in scope though but this section doesn't make that clear. (Put another way: I am correct that SCIM is not NFS, right? :-) - 3.3, as per my comment on 3.1, this is unclear as to what is in or out of scope of SCIM. - 3.5 you say "selected attributes" a number of times. Don't you need to say by whom and when? - 4: it'd be good if this explicitly called out that there can be privacy issues here that go beyond transport security, e.g. moving PII offshore between CSPs. I don't think you need say more than that, but it'd be worth doing I think.
- From the charter: The use cases document will be a "living document", guiding the working group during its development of the standards. The group may take snapshots of that document for Informational publication, to serve as documentation of the motivation for the work in progress and to similarly guide planning and implementation. ... Mar 2013 - Initial adoption of SCIM use cases, as a living document Looking at the charter and the draft name, I was ready to ask: is this a living document? should it be published? Reading the draft, it contains way more than the use cases: concepts and requirements are included. Which means that, even if you add new use cases, the requirements will (hopefully) not change. This is a good reason to publish. You should really update the title, and potentially the abstract to match the content: a mix of use cases, requirements, some (framework type of level) concepts and flows. Don't get me wrong, it's not a bad thing to combine all these into a single document, and I enjoyed the read. Proposal: from "SCIM Definitions, Overview, and Flows" to something such as "SCIM Definitions, Overview, Concepts, and Requirements" - I'm certainly not an expert in identity management, but I understood the difference between SCIM and ABFAB as ABFAB = just in time provisioning, as opposed to SCIM = pre-provisioning (ok, except maybe in the SSO "special" use case). A few words on this in the intro would have helped me to put the right context. Editorial: - It's intent is to reduce -> Its intend is to reduce - C.R.U.D -> CRUD (since you have it in the acronym section)
Section 2.4 I agree with Stephen's question on the assumption of using LDAP. If its' just an example, could you say that or abstract it from LDAP or a particular choice. Section 3.2 I agree with Stephen (his comment on security considerations section) that there should be some mention of regulatory concerns when moving identity information between jurisdictional regions (countries, state-by-state for regulations on privacy, and universities have additional regulations on personal information). This also applies to Section 3.4 (or likely all use cases) as personal information is discussed in that use case description. For section 3.4, you'd need to worry about where accounts are provisioned. Nit: Section 2.3.4 At the protocol level, this class of scenarios may result in the use of common protocol exchange patters between CSP-1 & CSP-2. s/patters/patterns/
conflict-review-fox-tcpm-shared-memory-rdma
- I agree with Martin's suggestion - I think it's a fine thing if esp. such detailed protocols that are vendor specific are more obviously vendor specific. - This is a bit of a monster but (flicking through it only) looks entirely well worked out. That usually makes me wonder why a spec has been taken via the ISE route. It might be good for the ISE (or authors) to try to somewhere explain the logic for that.
A note to the ISE: It would be much better to state in the document title that this is IBM's protocol work, i.e., change the title from "Shared Memory Communications over RDMA" to "IBM's Shared Memory Communications over RDMA"
What Martin and Barry said. This would be consistent with previous ISE publications (ex: RFC 6812)
Further to Martin's comment: I'd say it should be in the Abstract and Introduction, as well.
conflict-review-gundavelli-ipsecme-3gpp-ims-options
I just looked at the draft a tiny bit and noticed IPsec was written inconsistently, variations appeared in several spots. It should be IPsec.
ikev2 attribute approval is subject to expert review. this document documents two attributes and their usage that can be assigned independently from ietf consensus.
conflict-review-boucadair-intarea-host-identifier-scenarios
conflict-review-sridharan-virtualization-nvgre