IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2015-09-03. These are not an official record of the meeting.
Narrative scribe: John Leslie and Susan Hares (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:
Telechat:
2.1.2 Returning items
2.2 Individual submissions
2.2.1 New items
Telechat:
Telechat:
Telechat:
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
Telechat:
3.2 Individual submissions via AD
3.2.1 New items
Telechat:
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:
3.4.2 Returning items
3.4.2 Returning items
1046 EDT no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat::
Telechat::
Telechat::
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
Telechat::
7. Working Group News
1138 EDT Adjourned
(at 2015-09-03 06:04:40 PDT)
draft-ietf-precis-nickname
Yay! Just a few nits: -- Abstract: The abstract could be beefed up against? Maybe say what a nickname is in this context? [Edit: "Against"? I meant "a bit".] -- 1.1, first paragraph: "...participants to specify a nickname ..." Plural agreement mismatch. -- 1.1, 2nd paragraph: People really use "petname" for this? Who knew?
Thanks for another well-written draft! I just have one question and could be wrong, but in table 1, should the output for #9 have <> around it? <richard iv>
Thanks for doing this work!
Melinda Shore did the opsdir review.
draft-ietf-ecrit-additional-data
I've two things I'd like to chat about. (Note: I'm not trying here to insist on my preferred outcome, but I would like to have the discussion or else be pointed at where the WG already did that.) (1) section 3: You say these MAY be used. I'm not sure that's a good option. I think the data minimisation recommendations argued for in RFC6973 and RFC7258 would argue to add a MUST NOT. For example, saying that these additional data MUST NOT be sent in any non-emergency call without explicit user permission on a per-call basis or something similar? I have to admit I'm nervous that defining all of these may mean that some UA somewhere starts sending some of them in other calls without asking. A restriction along those lines would also be more in line with webrtc too perhaps. But maybe this was discussed in the WG, having considered those privacy issues - was it? Either way, would adding such a "MUST NOT except if..." be a good plan? 4.3.4 is a good example of the kind of thing I'd not want easily emitted in a call. (2) I'd like to (perhaps briefly) argue that the registries here should require more than expert review. Extensibility in dealing with what will inevitably be highly privacy sensitive data structures that are vulnerable to misuse once registered seems to perhaps call for a more stringent registration regime. The document itself also argues (in 4.3.7) that adding new kinds of data here can be counter productive for emergency call handling, so being more conservative in what we add seems unusually correct here. I'd like to suggest we require standards track for extensions. The following very recent -00 draft [1] makes some related arguments (but of course has no standing in the IETF so is just offered as a way to avoid repeating some arguments, not as an appeal to authority.) [1] https://tools.ietf.org/html/draft-nottingham-transport-metadata-impact-00
- abstract: the "or by reference" point is made twice in the abstract - intro: floor plans? HVAC status? really? Why not contact lists? proximity of friends? That (or inferring as much) seems to me to be going too far, if applied to all calls. I'd say just saying that this could be extended in future by other standards-track specifications is enough. (See also discuss points above) - intro: Wedding anniversary? That's surely not relevant to a PSAP. - figure 5: "prison" is out of context here, I'd suggest deleting it. If not, why not add hospital, power station and many other kinds of building? There may be some country specific issue or technical here, but labelling that with "prison" seems inappropriate to me. - 4.3.8: sorry I don't get the privacy argument, can you try explain it to me? (I didn't know it was possible to tempt an implementation, so the language there could be improved for sure:-) - section 5: good that this is HTTPS only. I think provisioning the PKI for such a thing is easily done these days and is rightly not optional. It might be useful to say that TLS here needs to follow BCP195. I agree with the earlier comment that you should be clear as to when mutually authenticated TLS is required. The secdir review [2] also raised similar issues and it'd be good to see responses to that too. (Yes, that review only arrived today so it's entirely reasonable to not have responded so far.) [2] https://www.ietf.org/mail-archive/web/secdir/current/msg05982.html - section 8: the sizes of the various additional data items here could be characteristic and leak value information regardless of TLS or not-TLS - perhaps add a warning that these may enable relatively simple traffic analysis. And wouldn't it be nice if someone had done the analysis of this potential vulnerability? This is btw a real issue - recall that avatar icon image size was usable to identify 30+% of contacts in one social network even over TLS, but before the provider canonicalised the avatar image sizes. - Thanks for section 9. Good job.
Given that the intent of the document “is that every emergency call carry the information described here using the mechanisms described here”, and that additional information is being introduced as ‘Required’, shouldn’t it update RFC6443 and/or at least RFC6881?
[Edit: I asked a question below about what happens if you dereference a block, and find the URL points to something other than what you expected. On reflection, I should expand that to ask how dereferencing errors should be handled in general.] This draft was clearly lots of work; thanks for making it happen. However, I have a number of comments: The shepherd’s writeup indicates that no XML or media type reviews were required—but this document contains a lot of XML (examples and schema), and a number of media type registrations. Is that an error in the writeup, or have those reviews been skipped? This draft implicitly assumes that the emergency calls are signaled with SIP. I don't dispute that assumption, but I think it should it's worth a paragraph stating it explicitly. -- section 2, 2nd paragraph: Are there any considerations for services provided with no "company" or "service provider" behind them? For example, lets say an individual hosts some VoIP related services for her own use (e.g. a SIP registrar, maybe a stun/turn server,etc) Are those in scope? I'm guessing not, since they would be unlikely to be registered with NENA, but it would be worth saying that explicitly. -- 3: Is there a critical need for the bit about "certain private-use situations"? That seems like license for abuse, without more elaboration about "prexisting relationship" and "privacy issues addressed". -- 4, third paragraph from end: Can you elaborate on what you mean by "at the same time"? Does that mean for the same call? Occurring in some interval of time ? -- 4.1.4 Is a provider limited to one type? If the same provider provides services in multiple categories, would they create multiple instances? -- 4.1.5: Do you intend 24x7 support to be a prerequisite to be a data provider? -- 4.1.7, Description: "Although multiple <vcard> elements may be contained in a structure only one <vcard> element SHOULD be provided. If more than one appears, the first SHOULD be used." When might it be reasonable to violate either of these SHOULDs? If the receiver should only look at the first entry why are multiple entries allowed at all? Also, it seems like there are vcard fields that are not useful to this purpose and might still have privacy implications. Do we really need people to send everything? -- 4.2.1, How Used..., last sentence: The term "wireless "needs more precision if you're going to use it in a 2119 expression. With a Wi-Fi handset connected to a wired Internet service count as wireless? How about a cordless phone? -- Figure 5: -Can the list of wireless types change over time? -I don't understand the full definition of "temp". Are these terms defined somewhere? -Do you really want "POTS" vs "PSTN"? -Is VoIP intentionally limited to OTT services? -- 4.3.3: What if the device model designation is not a number? -- 5, list item 1: "The "purpose" parameter also indicates the kind of data (by its MIME subtype) that is available at the URI" What happens if the URL points to something other than the indicated thing? - list item 2, last sentence: I gathered this section was an overview, since you have detailed procedures later. Please consider moving 2119 language to that section. -- Section 5, last paragraph: "only blocks in the registry are permitted to be sent using the mechanisms specified in this document" Are implementations supposed to check the registry at run time? (Also, that language sounds like it should be normative.) -- 5.1, last paragraph: "More than one Call-Info header field with a purpose value starting with ’EmergencyCallData’ can be expected, but at least one MUST be provided. The device MUST provide one if it knows no service provider is in the path of the call." What's the scope of the first MUST? Emergency calls? Is it possible the device doesn't know whether there is a service provider in the path? Should this say it MUST insert unless it knows there is a service provider in tHe path? -- 8: It might be worth discussing the potential harm done by a malicious proxy modifying a data element, or a compromised data source return incorrect information when dereferencing a URL. The first paragraph REQUIRES verification of requester credentials, but does specify the form of those credentials. Subsequent text talks about client-certs and PKI verification. Are other forms of credentials allows? (HTTP-digest, application level logins, etc). If client-certs are required, please say that explicitly. - "PSAPs and responder agencies SHOULD deploy a PKI " When might they not? What if they don't? - "emergency services authorities could obtain a credential from the DNS entry of the domain" Can you elaborate on that or cite something? - paragraph starting with "Much of the information supplied by service providers and devices is private and confidential": Seems like that should go in the privacy considerations. (And probably also the intro.) -- section 10: Many of the registry policies require experts to access whether an organization might be "legitimate" or "relevant". Are these reasonable expectations on the DEs? (I don't know the answer.) Nits and Editorial Comments: -- 4.2.1, Description: Currently, the only valid entries are... Current as of when? I suggest "The initially valid entries are..." -- 4.2.1, How Used... : "... service provider does not know ..." Does not know...what? (That's part of a long, convoluted sentence. Please consider breaking it into simpler sentences.) "... it is known to be valuable." Known by whom? -- 4.3.1, Description: "It is possible to receive two Additional Data Associated with a Call data structures,..." (Occurs in several places.) The naming is confusing. It's easy to read "additional data associated with..." as it's plain English meaning, rather than as a name. I suggest doing something more distinctive than capital letters. Perhaps quotes, or even an abbreviation. -- 4.3.7: That seems odd for this to be a subsection of the device information function. -- section 5: It seems awkard to use a numbered list for elements that are close to a page long each. This forces each to be a single, overlong paragraph. Please consider subsections. -- section 5, list item 2: "circumstances about the provision of the location" I'm not sure I understand the meaning of "provision" in this context. - Sentence starting with: "When the access network provider" This sentence provides context information that would have been useful to have at the start of the section. -- 5.4, 2nd paragraph: I think people are going to be confused and look for "by-reference" in 3204 or 3459. It might be worth re-citing 5621. --10: Some sections reference tables from other sections, and some include the tables directly. It would be nice to be consistent, one way or the other.
A Gen-ART review arrived from Francis Dupont a while ago. Hopefully the authors can go over the comments and see what needs addressing, before the draft is approved.
Thanks for your work on this document and the detailed security and privacy considerations balanced against safety risks. I don't have any questions besides those already asked, but do appreciate the detailed security and privacy recommendations with the understanding of the need to balance risk (to the caller) for this work.
Two things are incorrect and need fixing: ---- In Section 4, you have "tel" and "TYPE", and "property" and "parameter" reversed in the explanation about the "main" parameter value. The sentence is also confusingly worded. Try this (and see also my comments on this bit, below): NEW This document adds a new parameter value called "main" to the "TYPE" parameter of the "tel" property. END ---- In Section 6, there are problems in the MIME structure in the examples (figures 16 and 17). 1. The XML content should be indented at least as much as the SIP headers, so you should either make sure that all XML lines are indented at least 6 characters, or you should make the SIP headers be indented only by 3. 2. There should not be a blank line between the Content-Type and Content-Length headers. 3. There should not be a blank line after each boundary line; the part headers should start immediately, as the first blank line ends the headers. 4. There should be a blank line between the Content-Disposition header and the XML content; that blank line ends the part headers and signals the start of the part body. 5. The intermediate boundary lines should not have the trailing "--"; that's reserved for the ending boundary. The intermediates should all be "--boundary1". 6. Figure 17 is missing the ending boundary, "--boundary1--", at the very end of the figure.
Throughout the document:
The current term is "media type", not "MIME type". It would be good if you can
change that throughout the document.
-- Section 3 --
A tiny, tiny point: I don't think the MAY in the last sentence is really a 2119
key word, and suggest making it lower case.
-- Section 4 --
In an xCard there is no way to
specify a "main" telephone number. These numbers are useful to
emergency responders who are called to a large enterprise. This
document adds a new property value to the "tel" property of the TYPE
parameter called "main".
This doesn't explain sufficiently what you're after. I initially wondered why
the PREF parameter didn't give you what you need (PREF=1, this is my main phone
number). It was only when I read the registration in Section 10 that I
understood. I'd suggest a value other than "main", but I can't think of one
right away. At the least, please add more text here to explain what you mean
by "main".
I'll also note that none of the examples include the new "main" parameter
value. Given that you're creating the value, it might be good to show it in
use.
-- Section 4.1.5 --
The Data
Provider Contact URI SHOULD be a TEL URI [RFC3966] in E.164 format
fully specified with country code. If a TEL URI is not available,
it MAY be a generic SIP URI.
2119 key word problem @1: "you SHOULD do X, but you MAY do Y instead." MAY
contradicts the SHOULD. It's not so bad here because your "if" restricts the
MAY (Section 5.3 isn't that way; see below), but I'd prefer it if you'd change
it to something like "If a TEL URI is not available, a generic SIP URI is
acceptable." Or perhaps "A generic SIP URI is acceptable only if a TEL URI is
not available," which is a little stronger.
-- Section 4.4.2 --
If more than one <tel> property is provided, a parameter from the
vCard Property Value registry MUST be specified on each <tel>.
Do you really want that MUST, rather than a SHOULD? Are you really saying that
if there are multiple phone numbers but I don't know their TYPE values, it's
better to pick one and send only that one than it is to send you all of them
just in case?
-- Section 5.1 --
The data may also be supplied by value in any SIP request or response
method that is permitted to contain a body (i.e., not a BYE request).
Is BYE the only SIP request that can't contain a body? Or should that be
"e.g."? (I'm asking; I don't know the answer.)
-- Section 5.3 --
It is RECOMMENDED that access networks supply the data specified in
this document by reference, but they MAY provide the data by value.
Here's the SHOULD/MAY problem without an "if" to mitigate it. In this case, I
suggest explaining:
NEW
It is RECOMMENDED that access networks supply the data specified in
this document by reference. While it's permissible to provide the
data by value, this can expose private information [and/or whatever
other explanation].
END
-- Section 10.1 --
Thanks for providing guidance to the expert reviewers; that's really helpful.
-- Section 11 --
Is the comma in "Christian, Militeau" spurious?
-- Appendix A --
You appear to have turned the RELAX NG schema from RFC 6351 into an XML schema
and put it here, but then labelled it as informational -- a hedge, I guess, in
case there's a mistake in this version. Why does it need to be included here?
And how much review has it actually had, to make sure that there weren't any
mistakes in the conversion?
I note that Stephen hasn't cleared his Discuss yet, so I'll let that play out (and thanks to all who are busily Discussing it), but just for the record, I'm also confused between The intent is that every emergency call carry the information described here using the mechanisms described here. and (paraphrasing) "we aren't the experts on extending this mechanism, and we can't say who is, but there's more than one set of experts" This tussle sounds like a fork waiting to happen. Is that going to be a problem? One answer could be "if it is, we aren't the ones who are going to have to solve it", but I thought I'd ask.
I have no objections to the publication of this document. - I find text like "Optional for blocks supplied by the originating device, mandatory otherwise" in multiple places in this specification. Is there a reason for not saying "originating devices MAY supply this information, all other entities MUST supply this information" or some such? - I look forward to the resolution of Stephen's DISCUSS points.
draft-ietf-mpls-tp-oam-id-mib
Based on the feedback of the security AD, the security guidelines for the IETF MIB modules (http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security) have been changed 9 months ago. The exact change at http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security?action=diff&version=7&old_version=6
The MIB doctor latest review from Joan Cucchiara: My comments (which I made to the authors also about Feb 28, 2015) was about these warnings: Warning with SMICNG compiler: W: f(MPLS-TP-OAM-MIB.my), (883,22) MIN-ACCESS value identical to access specified for "mplsOamIdMegOperStatus" W: f(MPLS-TP-OAM-MIB.my), (888,22) MIN-ACCESS value identical to access specified for "mplsOamIdMegSubOperStatus" Yes, these are just warnings, but they are easily fixable and I believe the authors agreed to fix these warnings during the AD review process (that would be you Other than these warnings, the MIB is fine with me to go forward.
Thanks for addressing the SecDir review comments.
mib doctors review of this looked um... extensive.
draft-ietf-dnsop-onion-tld
(6 pages, so I read it now:-) We definitely need to approve this. It's been too long in the process already and that's been our (the IETF's) fault. (I won't object to us trying to improve 6761 after we've done this one, so some of the long debate will have lasting utility.) I thought I saw some edits from the last call that were agreed to be applied and that would improve the document. In particular, one that was to the effect that .onion names would in future need to conform to DNS name syntactic constraints (lengths basically) so that if a node did send a DNS query containing a .onion name, that'd be less likely to cause weird issues. Section 2 is a little sloppy in how it talks about ".onion addresses (point 1), ".onion names" (which is the right term I think) and "queries for .onion" (I think you mean any query for any .onion name and not only for the TLD #4 and #5). A bit more consistency would be no harm, though it's clear enough as is.
[Personally, I believe having the IETF assign TLDs is a very slippery slope. Of course, given rfc6761, that boat seems to have already sailed.] 1. I know there’s an update to the Security Considerations in progress..but I would like to point out an additional item: Section 2 (The ".onion" Special-Use Domain Name) says that "human users are expected to recognize .onion names as having different security properties”. While Tor users may have no issues with recognizing the .onion names, I don’t think it is sensible to expect that the average Internet user will be able to clearly identify them as special, much less understand their properties. Also, the Security Considerations section says that “users must take special precautions to ensure that the .onion name they are communicating with is correct”, but none of those precautions are mentioned, nor what “correct” means (specially in light of the fact that part of "a .onion name is not intended to be human-meaningful”). I would like to see some text in the Security Considerations around the risks that the average user may face if using a .onion addresses (or something that looks like one) through their browser (for example) — I realize that won’t necessarily help the average user (who probably will never know this document even exists), but I think it is important to call out. 2. References. Given that Section 2 (The ".onion" Special-Use Domain Name) says that "Resolvers MUST…respond to requests…by resolving them according to [tor-rendezvous]…” I think that reference should be normative. The same for the main Tor reference [Dingledine2004], which builds the base of why these are special names. 3. Nit. Section 2 (The ".onion" Special-Use Domain Name) s/either either/either
This one took some soul searching. But I think the arguments have been made, and that on the whole this registration does more good than harm. I agree with the several people who have pointed out that [tor-rendezvous] should be a normative reference. Nit: The abstract could use a bit more meat. For example, that the .onion special-purpose name is for use with Tor.
The two last references need to be normative ones, I believe. I would like to suggest a note to the IETF list (if not already happened) that this is being changed (alongside with any down ref implications) and only then approving the document.
Quoting Alvara, whose opinion I share: " [Personally, I believe having the IETF
assign TLDs is a very slippery slope. Of course, given rfc6761, that boat seems
to have already sailed.]
Discussing this matter with Joel, one extra argument (not in the write-up) in
favor of allocating .onion is that ICANN set this .onion TLD aside (flagged as
problematic). So there is no monetized value for it.
If/Once [tor-rendezvous] is a normative reference, do we consider github as
stable enough? What if that link disappears?
Nits/editorials (flagged by Tom Taylor's OPS directorate review)
Section 2 item 3: s/either either/either/
Thanks for addressing the SecDir review comments (in progress, should be in next revision). https://www.ietf.org/mail-archive/web/secdir/current/msg05876.html
I believe the IETF shouldn't be involved with registering special-use TLDs for things that were used outside of IETF protocols, and should not be wading into territory that belongs to ICANN. I know there are a bunch of other such TLDs that people/organizations would have us snag for them, and I very much want to avoid doing a batch of others. That said, I well understand the deployed code involved and the importance of keeping things working in this case, and I don't want to stand in the way. So I'm standing aside with an "Abstain" ballot.
I'm seeing a lot of discussion (even during IESG Evaluation) that resonates with me, but the people having that discussion are more clued about DNS and the policy thereof, than I am. I do have one observation that I haven't seen anyone else touch on: I thought .onion was tied closely to the TOR protocol, so I have no idea why the second sentence in this paragraph is here, or what it means, and neither the string "TOR" nor the string "onion" appear in RFC 7230, so chasing that reference didn't help. Like Top-Level Domain Names, .onion addresses can have an arbitrary number of subdomain components. This information is not meaningful to the Tor protocol, but can be used in application protocols like HTTP [RFC7230]. Am I just being dense the night before a telechat, and everyone else understands what this means and why it needs to be included in this document? If this isn't clear to other people, could you either say more about what it means, or delete the second sentence? I'm not confused about the first sentence, only the second ...
I agree with Stephen's points that the long debate has utility and that there were some proposed text changes that appear to be missing.
Registering this name seems warranted in light of the potential security impact. We need to make our processes work for the Internet, not vice versa. I agree with Alvaro and Stephen's comments. In particular, to my eye [tor-rendezvous] should be a normative reference given item #3 in Section 2. However, it seems more important to publish this document than to re-issue the last call to call out a new downref.
draft-ietf-httpbis-cice
Did anyone think through the potential for this kind of change to interact with attacks like BREACH? [1] It looks like at least some of the mitigations mentioned on [1] would not apply to requests, or possibly not, so I suspect there is something to say here. If that analysis was not done, I think someone ought look at it. If that analysis was done, shouldn't there be some mention here? [1] http://breachattack.com/
This should be easy to resolve, but I want to make sure there's been thought on it: section 3 says: "Note that this information is specific to the associated request; the set of supported encodings might be different for other resources on the same server, and could change over time or depend on other aspects of the request (such as the request method)." .. but then later... "[...] However, the header field can also be used to indicate to clients that content codings are supported, to optimize future interactions. For example, a resource might include it in a 2xx response when the request payload was big enough to justify use of a compression coding, but the client failed do so." This seems to indicate a need for guidance on when the client can reuse the Accept-Encoding value.
-- section 3, 5th paragraph: For the two SHOULDs and one SHOULD NOT in this paragraph, can you suggest some reasons an implementation of this spec might choose something different?
Both me and my Gen-ART reviewer believe that the draft should have an Updates: RFC 7231 header. I do not believe this is discuss-worthy, however, given the vague formalism that we've given to RFC headers of this type.
Like in Ben's review, I wondered about the first two SHOULD in this sentence below. If there is a SHOULD, you should either explain the exception, or stress that you want to be compliant with RFC7231. Encoding" header field in that response, allowing clients to distinguish between content coding related issues and media type related issues. In order to avoid confusion with media type related problems, servers that fail a request with a 415 status for reasons unrelated to content codings SHOULD NOT include the "Accept-Encoding" header field. Let's continue this discussion in the "Ben Campbell's Discuss on draft-ietf-httpbis-cice-02: (with DISCUSS and COMMENT)" email thread, which goes in the right direction IMO.
Thanks for responding to the SecDir review. I see you are waiting for proposed text and can see if Charlie has some or can propose something. https://www.ietf.org/mail-archive/web/secdir/current/msg05894.html
- A nice easy read. Thanks. - Any reason why this document does not update 7231?
draft-ietf-bess-mvpn-global-table-mcast
What Kathleen said.
Thank you for addressing the SecDir review questions. I found the explanation helpful and think some text in the draft would be good for this particular question from the review since this is specific to this draft: [Cathy] What is not clear here is what is additional risk of information leaking out into the wild the use of the GTM procedures proposed in this document would incur. Does the use in a wider context mean that the information is more widely distributed and thus has more chance of leaking? [Eric/Editor response] When L3VPN/MVPN is provisioned, each VRF is configured with import RTs and export RTs. These RTs constrain the distribution and the import of L3VPN/MVPN routes, making it difficult to cause a route to be distributed to and imported by a VRF (or a global table) that is not authorized to import that route. Additionally, VPN routes do not go into the "global table" with the "ordinary Internet routes" (i.e., non-VPN routes), and non-VPN routes do not impact the flow of multicast data within a VPN. In GTM, some of these protections against improper distribution/import of the routes is lost. Import of the routes is not restricted to VRFs, and the RT infrastructure that controls the distribution of routes among the VRFs is not present when routes are exported from and imported into global tables. But I don't think this needs to be explained in detail to the intended audience of the draft, who will already be familiar with VPN and MVPN technology. SecDir Review: https://www.ietf.org/mail-archive/web/secdir/current/msg05940.html
I support the publication of this document, but I have one (non-blocking) comment... I do not see any forwarding plane discussions in this document and I wonder if there was discussion about impacts on multicast forwarding. With the removal of the VPN-related checks, is there a possibility of loops in the forwarding of multicast data based on the GTM information? What about implications for RPF checks?
draft-ietf-tls-padding
As Alissa, I was wondering why it wasn’t easier to fix the one implementation instead. The shepherd wrote: "Since then it has been found that this extension can server (sic) to alleviate issues with issues in several vendor's products. There was good consensus to move forward with this document as it may find further applicability in the future.” So it looks like the problem is not just one implementation… If the WG now thinks that this extension may be valuable for other things besides fixing bugs, then it might be nice to reword some of the document to not focus on what seems to be one bug and just present the extension for what it is: padding.
-- Abstract: More in the abstract would be nice. Why'd would one want to do this? -- 1, first paragraph, last sentence: Can you elaborate on this? The motivation seems weak without a bit more. When would you choose to use this at all? Wouldn't it make more sense to fix the bug? -- 5, last sentence: Do you expect anyone to implement this MAY? It seems like this either needs to be stronger, or removed as a "why bother"? -- 6: I'm not sure I understand the meaning of "permanently assign the early code point for the padding extension in its ExtensionType registry". Does this mean that an early allocation was done for this? If so, it seems like the IANA section should still describe the code point being registered, or perhaps give a pointer to or description of the early allocation.
Like Ben: -- 5, last sentence: Do you expect anyone to implement this MAY? It seems like this either needs to be stronger, or removed as a "why bother"? In my spec, I usually write this way: Servers SHOULD verify that the extension is either empty or contains only zero bytes and log the exceptions.
Would be nice to include a reference to something that explains or at least identifies the implementation that hangs when receiving ClientHellos of a certain size. Otherwise one wonders why it's easier to define this extension than it is to just fix that one implementation (assuming it is only one).
draft-hansen-scram-sha256
-- abstract: Spurious colon == 5.2, first "note" I tend to think of anything marked as "note", at least without further explanation, as a sidebar or parenthetical information. From that perspective, they probably aren't a good place for 2119 keywords. I suggest removing the "note" label.
Nits in the abstract: registers: -> registers provdes -> provides
No issues with the publication of this draft. Just a grammatical issue to pick at. * Abstract : s/provdes guidance for secure implentation/provides guidance for secure implementation/
draft-iab-crypto-alg-agility
All of my comments have either been made by someone else, or otherwise covered in email discussion. So, yes!
Discussion between Russ and Suresh (the Gen-ART reviewer) should complete before the draft is approved. There was potentially one more clarification needed in the thread, while other things have been resolved.
Thank you for your work on this draft, Russ! I think it's a very good and helpful draft or the community. I'll switch to a Yes once we have a clearer answer as to where we are on consensus for the paragraph in Section 2.9. I know there is similar text in the OS RFC and the discussion was had with mail operators around another RFC, but I don't think there was an adequate discussion on this topic with the fuller audience. The discussion never happened with the OS RFC and Viktor had some assumptions that are clear on mailing lists in recent threads, but not necessarily in that document or discussions for that document. The mail/applications discussion was specific to a use case of software that had no plans for upgrades, which results in legacy systems using older selections for transport encryption (fine, we can deal with that and just say it's legacy). This discussion didn't involve the SAAG or per pass list and was spurred on by the RC4 deprecation (RFC7435). I think whatever statements we make on this going forward should be derived from some level of consensus or we risk demonstrating consensus in a series of published documents that I don't think we really have. I'm happy to be in the rough on this, but do want to wait on the outcome of the discussion and see if text for this section requires updating. Here is the question I sent to the list and I also prodded on the perpass list to chime in on this thread. https://mailarchive.ietf.org/arch/msg/saag/PXrRghfHM-OBj2Y2TniuKptpKCs I'm happy to wait to see what happens with this thread and what statements are deemed appropriate.
I have some comments I'd like to have considered as well.
1. Section 2.6
I'm finding it helpful to make product teams aware of support in browsers for
newer algorithms and protocols as well as making them aware that browsers will
show deprecated selections as broken in some way. This is motivational for
products to transition on the server side for web traffic. I suggest adding
some text in 2.6 after the following paragraph as I have found this to be the
case (and needed) for product teams.
Without clear mechanisms for algorithm and suite rollover, preserving
interoperability becomes a difficult social problem. For example,
consider web browsers. Dropping support for an algorithm suite can
break connectivity to some web sites, and the browser vendor will
lose users by doing so. This situation creates incentives to support
algorithm suites that would otherwise be deprecated in order to
preserve interoperability.
Something similar to the following could be helpful:
Resistance to deprecate algorithm suites on the server side by product
teams or web server administrators is often driven by a concern for their
customers ability to reach their site. Product teams and server
administrators are typically motivated either by customer requirements
for improved security specific to algorithm and suite rollover as well as
understanding the level of support for these options in deployed browsers.
Additional motivation has come from the knowledge that certain browser
vendors have visual warnings present in their user interface, shown to
customers, when a deprecated algorithm or cipher suite is in use.
2. The SecDir review had some comments and nits that I don't think have been
addressed yet. SOme of the nits were addressed in other ways, which is fine.
I'm okay with the 'ought' language in 3.1, but a response or update resulting
to the suggestion for 3.2 and 3.3 would be helpful.
https://mailarchive.ietf.org/arch/msg/secdir/bykvhh43HOiznC5nv7V-paas_lo
2. Sections 3.2 and 3.3 should in some way relate back to the
recommendation to specify algorithm choices separately from base
protocol specifications (esp. since 3.2 suggests that this practice
can drive added complexity in the form of algorithm/suite overload)
This is exceptionally well written and clear; thanks.
This is one heck of a document. Thank you for producing it. I know there are still conversations that haven't converged, but I'm a "yes" on what's there now (in pre-08). I also read -07, but my comments are all nits, and are actually against pre-08 ... just so the RFC Editor doesn't have to find them again. I'm seeing this text "advances cryptoanalytic techniques" that's probably missing a word. This text "has lead to interoperability problems" should be "has led to". This text "algorithms SHOULD to have a public stable specification" probably has an extraneous "to".
Nice document. = Section 2: OLD For this reason, the protocol MUST specify one or more strong mandatory-to-implement algorithm or suite. NEW For this reason, IETF protocols MUST specify one or more strong mandatory-to-implement algorithm or suite. (I think this is what you meant here, but if not then I don't know which protocol you mean by "the protocol.") s/the base protocol specification includes a reference/the base protocol specification should include a reference/ = Section 2.2.3: "Fortunately, catastrophic algorithm failures without warning are rare." I would guess that if you really mean "catastrophic" then it's not that they are rare but that they never happen. I think this sentence works without the word "catastrophic." = Section 2.4: The 2119 language here seems out of place: "Transition mechanisms SHOULD consider the algorithm that is used to provide integrity protection for algorithm negotiation itself." = Section 2.8: The 2119 language here seems out of place: "Protocol designers MUST be prepared for the supported cryptographic algorithm set to change over time."
> Advances in computing power available to the attacker will eventually make any algorithm obsolete. While I don't necessarily disagree (and counterfactuals are hard) I worry moreso about advances in technique that render additional computational power unnecessary, deliberate subversion buried in algorithms, sidechannels that make attacking it vastly simpler then I do exponentially increasing computational assets. the later is relatively transparent whereas the former prospects are all things we are living with.
draft-bradner-iaoc-terms
Three nits, could be worth fixing though: 1. Is "Updates: 4071" correct in the header? I'd have expected "Updates: BCP 101" or nothing (and that this be added to BCP101). 2. Section 2 says: "the sentence defining when IOAC member terms" that seems possibly quite loosely written - quoting the precise text to be removed would be better and not hard. (If that were hard, then this point should be a discuss I guess;-) 3. Section 2 also says "relative to the above mentioned IAOC meeting" - that's ambiguous and could be interpreted as meaning that it is ok for the IAOC to decide that terms will start 11 months after that meeting. (At least if there's no other text somewhere else that'd prevent that.) Again, that seems loose and easily improved, just add a sentence saying "IAOC member terms MUST start/end close to the time of the 1st IETF meeting."
This is a fine document, even if the need for it makes me discouraged about our ability to get any process right the first time :-) I would support text changes to accommodate Stephen's #2 and #3 comments.
wfm
draft-ietf-precis-mappings
- The write-up didn't tell me if this is likely to be considered as neutral by the Unicode folks, or as something non-neutral. I'm curious about that, but not concerned much. I do think the IESG should be aware though if this is something that might cause e.g. liaison fun for the IAB later on. (I'm not saying I think it does/would btw, just that I'd like to know if it might.) - The secdir review [1] raised an issue and some changes were proposed for a -12 version that hasn't yet popped out (which is fine). This is just to note that to decrease the probability we forget:-) [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05900.html
Just a small nit. Section 2.3. (Local case mapping) includes the phrase "It is RECOMMENDED to use…”, which looks like an RFC2119 keyword, but that RFC is not referenced in the document. The phrase is used to refer to what is specified in RFC7564..but it may confusing. Maybe using quotation marks to make it clear that the text comes form somewhere else, and using a reference would help.
I don't have substantive comments, but I do have a fair number of editorial comments. There are a number of places where I found the sentence structure very hard to follow. I apologize for not suggesting text, but for the most part I was not sure of the intent. Details follow: -2.3, first paragraph, note: I'm having trouble parsing that sentence, starting with "Because". -2.3, 3rd paragraph: s/"... Case Folding in PRECIS framework..."/"... Case Folding in the PRECIS framework..." "Local case mapping defined in this document corresponds to demands from applications which supports users’ locale and/or context." I don't follow the sentence. -2.3, 2nd to last paragraph: I suggest avoiding 2119 keywords when referring to requirements from other specs-- especially since _this_ draft doesn't have the 2119 boilerplate. -2.3, last paragraph: I can't parse the paragraph. -- 6: I don't understand the meaning of "need for the case folding about the mapping" -- Appendix B: I'm having a lot of trouble following the sentence structure for the whole section.
Vijay Gurbani's Gen-ART review pointed out a possible need to refer to RFC 2119. Can the authors check this?
Thanks for addressing the SecDir review with text coming in the next version.
opsdir review was performed by Mahesh Jethanandani who notes a significant number of nits in draft 11 so you'll want to look at it through the tool
draft-ietf-grow-irr-routing-policy-considerations
I support Adrian's Discuss on the need to have Terry's review comments
addressed.
I also found this draft a bit hard to read and parse - though not to the extent
of pulling out specific examples, but please do think about Barry's comments as
well.
Although the abstract and intro claim that the draft will provide a discussion
of the existing or remaining concerns, I would STRONGLY (not quite DISCUSS
but...) like them to be pulled out more clearly. Without this, the draft seems
to be more retrospective and rambling than clearly articulating what was a
problem, what changed, and what still remained as a problem.
For instance, from reading the draft, I would say that:
a) Getting fresh IRR data is still a problem. Pull mechanisms use long
intervals based
upon historic problems (see Sec. ...) and push mechanisms are not fully
described.
b) RPKI provides a solution only for verifying route origination but this is
not sufficient
for verifying IRR data because such data also includes asnum, etc.
c) Stale data in IRRs: incentives don't exist for removing stale data and
overriding the
existing data requires work and has the risk of black-holing if the data
wasn't really stale
d) Propogation delay across different ISPs affect how rapidly changes can
occur. e) Configuration based on the new IRR data is less operator-intensive
because of the ability
to use NetConf to deliver the updates, but a lack of vendor-agnostic
models still makes such updates complicated.
f) Router capabilities are rarely a problem anymore. (Incremental updates
of prefix-lists,
more static memory, BGP extensions to push new config in without
traffic-impacting side-effects).
I'm sure I've missed some and maybe gotten a few wrong- but I'd really like to
see some actual takeaways. This currently leaves me feeling like I had a good
dinner conversation chatting about how bad the old times were but without any
action items or guidance for the future to improve.
Thanks for this. I learned from reading it and following some links etc. I think other readers will be similarly educated. - I agree with Adrian's request that the routing review be discussed. In particular, wrt the relationship between this work and the RPKI - it'd be good that that be (checked as having been) documented correctly. No disrespect to the authors here, but the RPKI vs. IRR stuff here is not that crisply described - most likely (I'm guessing) because that relationship is just in reality vague. But if I'm recalling correctly some of the very capable authors here aren't the biggest fans of the RPKI so it'd be good for them and this document that their description of RPKI be challenged now a little bit rather than that be done later (if that has not already happened, which may well be the case). - 5.1, I'd be interested in why RFC2725 is now seen as then having been a barrier to deployment and whether or not that is still considered to be the case. Put another way - was the problem the security requirements or the design provided in 2725? (Note, I'm not asking for any change, just wondering.) - section 6 has a "[REF?]" that's presumably an undone TBD
[My comments are similar to Alia’s review of –05.] It is somewhat hard to pinpoint the expected outputs promised in the Introduction, where is says that the "purpose of this document is to catalog past issues... Additionally, it provides a discussion regarding which of these issues still pose problems in practice, and which are no longer obstacles…” Section 3 seems to provide a roadmap of the document pointing out the pieces covered: "First, accuracy and integrity of data contained within the IRR. Second, the Resource Policy Specification Language (RPSL) used to represent various types of data in the IRR. Third, operation of the IRR infrastructure, i.e.: synchronization of resources from one IRR to other IRRs. Finally, the methods related to extraction of policy from the IRR and the input plus activation of that policy within routers.” While that is ok, there’s no clear correlation with the TOC. The contents of the document don’t have to strictly be reflected in the TOC, but it would be nice to at least call out which sections cover the points listed above. According to my reading, that would be 4 (for #1), 5.1 (for #3) and 5.2, 6 and 7 (for #4). It is not clear to me that independent issues related to RPSL (and not related to #1) are covered..any are intermingled in Section 4. Going back to the purpose of the document. Section 8 (Summary) says that "many of the problems that have traditionally stifled IRR deployment have, themselves, become historical”. But in my reading the only issue that seems to not be an obstacle anymore is the graceful application of policy in BGP (Section 6 and 7). If the intent was to highlight others as non-issues then that should be made clearer. Nits: Section 4. (Accuracy and Integrity of Data Contained within the IRR) s/section/sections Section 5.1. (Replication of Resources Among IRRs) s/has a several weaknesses/has several weaknesses Section 5.2. (Updating Routing Policies from Updated IRR Resources) s/An ISP's customers/An ISP's customer
Thanks for writing an interesting document. This reference clearly needs a fix: BGP soft-reconfiguration [REF?]
I see you have some high-level considerations that could encompass the various security properties that would be expected, but would prefer to see them spelled out a bit. For instance, in the first paragraph of the security considerations section: "operators may want to be circumspect about ingesting contents from external parties" Wouldn't you want to see integrity protection so that the operators would have some level of assurance that the source is who they think it is and that the data has not been tampered. This might apply to the described examples where FTP is used to share information. Authentication would be helpful here too. Then, if automation increases, you would also want confidentiality (session encryption for privacy and security reasons). C This this is a summary of current state, this is just a comment. But I would think these properties are used in the current state - at least integrity protection and authentication. (Security's CIA principle) Thanks.
Thank you for putting the effort into this draft! The latest revision is improved, and addresses 98% of my comments when I was wearing a routing area directorate reviewer hat. Mostly I'm pleased to see a sentence in there which highlights that the RPKI doesn't carry routing policy information. I think there is a very real undertone in this document that shouldn't be avoided in that the RPKI takes steps to routing security, but misses a mark on policy integrity. I still don't buy the ideal that 10gig circuits are perceived as the norm - but happy to let that go as a future ideal.. mores law and all :) This document is one of the better outcomes of documenting in the IETF what was (is) and why wrt routing.
I think this is a good document to publish. Thanks for the effort. I agree with Adrian that Terry's review comments need to be addressed.
I find some of the writing throughout the document to be a bit hard to get
through -- not to the extent that I think it's a serious problem, but enough so
that I'd say this is making the reader work a bit too hard. Some examples:
While these resources
are generally allocated by hierarchical authorities, a general
mechanism for formally verifying (such as through cryptographic
mechanisms) when parties have been allocated resource remains an open
challenge. We generally define such a system a Resource
Certification System, and we note that some candidate examples of how
such a general system might be implemented and deployed exist[.]
The structure of both of these sentences makes understanding them require a bit
of rewinding and re-parsing, at least for me. Phrases such as "have been
allocated resource" seem odd ("allocated resources" or "allocated a resource"
would seem better). Phrases such as "some examples exist" are straightforward,
but get harder when a long modifying phrase is stuck in before "exist", as
here. This is an example; there are other such bits in the document.
In the end, it's probably fine, though I think it'd be a good idea to alert the
RFC Editor to watch for complicated sentences whose structure makes then a bit
difficult to read smoothly. Below I suggest a few specific sentences that I
hope the authors will re-do themselves, before it goes to the RFC Editor.
-- Section 4.1 --
One of the largest weaknesses often cited with the IRR system is that
the data contained within the IRRs is out of date or lacks integrity.
This is largely attributable to the fact that existing IRR mechanisms
do not provide ways for a relying party to (cryptographically) verify
the validity of an IRR object. That is, there has never existed a
resource certification infrastructure that enables a resource holder
to authorize a particular autonomous system to originate network
layer reachability advertisements for a given IPv4 or IPv6 prefix.
Two questions here:
1. The last sentence is written as a clarification of the one before it ("that
is..."), but seems to veer. Would it perhaps be better to say, "...that
enables a resource holder to verifiably authorize...", or, "...that enables a
resource holder to provide verifiable authorization that a particular
autonomous system may originate..." ?
2. This clearly explains the "lacks integrity" piece, but adding cryptographic
verifiability will not fix out-of-date information, will it? Isn't there also
an issue of keeping the information current in the first place, which is not
mentioned here?
-- Section 4.5 --
Only now is an
experimental test bed that reports to provide this function
I think "purports" is the word you're looking for here.
-- Section 5.2 --
An ISP's customers may not adequately plan for pre-planned
maintenance or, more likely, need to rapidly begin announcing a new
IP prefix as a result of, for example, an emergency turn-up of the
ISP customer's new downstream customer.
I'm having trouble making sense of this sentence. The subject seems to change
throughout the sentence, starting as "an ISP's customers", and shifting to the
ISP later. Can you please re-word this, perhaps splitting it into two
sentences? (It'd also be nice if you'd use "might" to refer to something that
might happen, and save "may" for referring to something that's *allowed* to
happen.)
It is likely that the length of time at which IRRs mirror
changes will have to be dramatically reduced with a corresponding
reduction in time at the ISPs that, in turn, need to evaluate whether
changes in a set of IRR resources need to get reflected in updated
router policies that will get pushed out to ASBR's, connected to
peering circuits, on their network.
I get this one, in the end, but it's also in need of splitting into two, please.
-- Section 6 --
Ultimately, either of the two scenarios above further lengthen the
effective time it would take for changes in IRR resources to take
affect within BGP in the network.
That should be "take effect", not "take affect". And I think the combination
of "effective time" and "take effect" can be confusing, so maybe try some
rewording?
I agree with many of the other ADs' comments on this document.
draft-sparks-genarea-review-tracker
The shepherd write-up says Brian C's comments have still to be handled - is that still true? I guess they have been handled, given the dates.
This is a nice document, and the expected enhancements will fill a needed gap. However, I really don’t see the need to publish a list of tool requirements as an RFC. Not only will the requirements eventually be satisfied, but others will come up — for example the author/editor-focused requirements briefly mentioned in the appendix. I think it would be better if this document was kept in the GEN Area wiki. Having said that, I won’t stand in the way of publication.
-- 3, bullet starting with "Reviewers must be able to indicate they are transitioning..." Is this different than a "soft hiatus" followed by a "hard hiatus"?
Thank you for your work summarizing the tool requirements, it will be good to have reviewers tied to the tracker in the future. It would be nice to see the connection from a draft to the review without the need for the secretariat to create that match. I see the last bullet of section3 is out of scope for this effort and I have one other item that would be nice to have, but could also be a future request similar in nature. This would be the ability for the AD to send a thank you note from the interface when they are notified that their review was used.
This draft is really clear. I haven't been on a review team since 2010, but it
sure looks good from the outside.
Just a couple of nits and minor thoughts ...
"all the of documents" is probably "all of the documents".
In this text,
o The tool must make it easy for the secretary to see the result of
previous reviews from this team for a given document. In Secdir,
for example, if the request is for a revision that has only minor
differences, and the previous review result was "Ready", a new
assignment will not be made.
^^^^^^^^^^^^^^^^
I would have parsed this more easily if the text had been "the secretary will
not make a new assignment". Darned past tense.
In this text,
o A secretary must be able to configure the tool to remind them to
followup when actions are due. (For instance, a secretary could
receive email when a review is about to become overdue).
I've never been a secretary, but is it obvious whether this would be
per-secretary or per-document (possibly inherited from a per-secretary
setting)? If this was a calendar, there would be a default alert interval, but
I'd be able to say "remind me again on Tuesday". Is that relevant here?
Thank you for capturing Appendix B. Suggested features deferred for future
work. That stuff would likely be great, but not worth holding everything else
up for.
I agree with Alvaro that there is no need to publish this fine document as an RFC. Let it exist as a living document somewhere.
conflict-review-savage-eigrp
I don't object, but two points.... - The title doesn't mention Cisco. The 1st sentence of the intro does. I always find including such information in the title useful - I think it means far fewer readers might end up confused about the status of the eventual RFC. I would hope (and encourage) the ISE to have that included in the title whenever possible as that is one of the ways in which we can get value from the Independent stream (I mean documenting proprietary protocols that might one day be input to the IETF stream). - Without having read the rest of the document (sorry, but it is loooooong), I really didn't find the security considerations convincing at all. I wish I had a better understanding of the kind of review the ISE calls for for such drafts. Generalising, ISE stream security considerations text seems to arrive at 5742 review at an almost random point on a continuum from really not good to great.